The Making of MalCon CTM-2011 Challenge.

Well, it was declared last year itself after the first malcon that we'll be having our own version of an online challenge for the world to compete over.We called it the CTM. Which stood for 'Capture the Mal' challenge. Nothing much happened after that though. We all got busy with the rest of our work until about 3 months before the event, when we realized that we promised a CTM & had completely forgotten about it. As usual, when it comes to technical stuff @MalCon, am the SPOC.

So, I was left with a mammoth task.Its not that I've never designed a CTF contest before.. infact I do that for all my workshops & training sessions. But this one was different. We do malcon every year not because it earns us something.. or because we get perks for doing it. Infact, we make no money out of it at all. We do it because it was our dream. We've learnt about 90% of what we know by reading 'tuts' n textfiles on the internet, created by generous & highly talented people. We wanted to do our bit too. Malcon is not about spreading malwares. Its about generating proactive research by good people to build secure systems.


Well, so here I was, with no idea at all about how am gonna design this CTM thingy. And then it happened. :) I have this weird 'moment' once in a while where I get bombarded with loads of crazy ideas. Thats how the idea of creating a Virtual-Machine based challenge came to my mind. But there were 2 major problems.

1. I had no experience in creating a VM manually.
2. I wanted it to be simple enough so that even a common man can attempt it.

At first, I had to create a VM myself to prove that its possible. I know that there are thousands of articles on that available but this one had to be simple. The idea was to create a VM architecture that was as simple as possible so that the ones attempting it do not end up getting demoralized. While, the VM-Code or the 'Bootrom' as I call it, can be complex enough to deliver the quality & standards that we at malcon are fanatic about.

The good part was, I have considerable understanding & experience with programming as well as reverse-engineering. I've got past experience with creating some really complex & effective anti-reversing routines too. So, I figured out that this one wont be as tough as I thought it would be, initially. How wrong was I. :D

To begin with, I named my Abstract Processor as 'Aod8'. Then, I tried to design it similar to the intel-processors am comfortable with. Although, I figured out that I dont need more than 15 Instructions in my instruction-set to create a complex CTM, I thought that maybe someone, someday might wanna write some cool program for it & thats the only reason why I endedup having about 40 instructions in all. Once the design part of it was over & I was almost sure that I had the required instructions in there, it was time to code the processor.My first choice was 'PERL'. Its easy to program in, robust with REGEX & more importantly I didnot have to mess with variable types.Ah, I think I forgot to mention that in order to keep the CTM easy to attempt, I designed the processor to work with 'Byte' sized instructions & data. Most people are not comfortable with handling data at 'bit' level.So, that was the reason behind this super simplistic Aod8 Architecture design.

Well, the PERL idea was disastrous. Initially I struggled a little with type conversion. Then again...I never write the entire code at one stretch, ever. :P I write some..then test it thoroughly & then go further. When am trying a new idea or a theory, I am totally impatient to see if it works or not. :) So obviously, the first instructions I implemented in my Aod8 processor were the ones that'll allow me to print a character on the screen.. so that if it works as expected, I can jump up & down & celebrate victory. But but but... the way I've designed it, I can only print one character at a time.That too, if I send the 'output' opcode, it'll fetch the byte at the current location of the stack-pointer on the stack & print it.Now, lets say I want to print 'A' on the screen. For that, I'll have to first push its ascii code onto the stack. :D As you can see, I cannot directly push data onto the stack either.For that, I'll have to move the ascii code to a GPR like 'A' or 'B', then push it onto the stack, then call the 'output' instruction. In essence, the set of instructions to print a char 'A' on the screen in Aod8 Assembly would be:

mov a,65
mov [sp],a
output
halt

[ Well, I've already uploaded all the Tools, source-codes & everything related to my Aod8 project on GitHub & you can find them here: https://github.com/Aodrulez/Aod8 ]

Below is the output on my terminal when I compile this code using my Aod8 Assembler written in PERL just to give you an idea of how the entire thing works.


So yea, that works perfectly! when the bootrom is executed by the Aod8 Emulator/Virtual Machine or Abstract Processor implementation..which ever way you like to call it, it does print 'A' on the screen. \m/ But let me remind you that at that time... I never had an assembler! :) So, to see that output, I had to manually construct a bootrom using a Hex-Editor by inserting opcodes & data in hex. The moment I saw it print 'A' on the screen, I was in trance :D That was it! It proved my theory of a crazy CTM to be practically possible & from that point onwards... it was a mad rush to complete the processor implementation as soon as possible. Well, I wrote it entirely in PERL first. But after constructing bootrom manually, I wasnt getting expected results. Thats when I found out that I made some major 'Type Conversion' errors here & there. This was awefully painful. Either I could spend another day fixing the perl implementation which was starting to get me frustrated or I can switch to c/c++ & wind it up asap. I opted for the second option for two reasons.

1. I know c/c++ very well.
2. It'll prove my theory that the ctm can be played by anyone who can implement the Processor, in any language he likes.

So that was it.I got the processor written top-to-bottom in less than 2hrs. Now, I knew that I've implemented the Design perfectly, it was time to test each & every instruction. Initially I enjoyed the geek-feeling it gave to construct bootroms out of hex-editors manually but pretty soon.. I was having severe head-aches. :D Thats when I decided its time to write an 'Assembler' for this Architecture. In the mean time, I had my PERL implementation too sorted out by comparing the output of my 'c' implementation.

I didnot even realize when this became an obsession. I was working on my office related work all day & working on this CTM all nite! In a few day's time, I had a very crude Assembler than can convert asm code to bootroms, 2 implementations of the Aod8 processor & a slightly tweaked version of the 'c' implementation acting like a debugger/tracer. It was time to learn the basics of programming something that I created. :D Yea, it sure sounds easy but it was not.Just when I started to try serious programming, I realised that in my obsession with keeping the design simple, I had seriously limited the programming possibilities of the architecture. The design was so simplistic that I couldnot even implement self-modifying code. Because, the ROM was as the name suggests, Read-Only. The Aod8 processor was designed to fetch instructions & execute them & the stack was provided solely to store temporary data.It was impossible to modify the code during execution. This meant that everything that was part of the CTM challenge had to be put up in a clearly-visible form inside the bootrom.Anyone with a code tracer would end up dumping all the important data off the bootrom.

Another limitation was the 'byte' implementation. :) The only Flow-control instructions that were used in the CTM were cmp,je,jne,jle,jmp & loop. As you can see, every other jmp instruction requires a parameter.This parameter specifies the location to jump/execute from now on. The catch here though is that, the Aod8 Architecture can only have data upto the size of a 'byte'.The biggest number in a single byte is 255 which meant that theoretically I would have been limited to a bootrom of size 255 bytes as I couldnot access a higher number because of the limitation in the design. Thats when I decided to tweak the design a little bit & partially bypass the limitation yet keeping the design simple. You'll understand what I did if you observe the way I've implemented the 'jmp/loop' instructions. :)

So far, so good.Now that I had some crude tools & thorough understanding of the programming details, it was time to begin creating the CTM. Somewhere near that time a huge tragedy struck. Steve Jobs passed away & we were all in shock. That was when I decided that am going to do my bit for him. Thats the reason you'll see a brief text right in the beginning of the CTM challenge when you boot it. It was my way of thanking him for all that he has done. :) Well, at first, I wanted to have challenges appearing back to back as the Aod8 Architecture was seriously limited but once I had the first level done, it looked so very boring! It was time to push it up a few notches & be artistic! That was when I realised that my Assembler was seriously crude. :D Spent another day adding support for 'Labels' in my Assembler so that I can write code like "jmp label_beginning" instead of "jmp 134".That was one helluva experience in itself.At the end of the day, I had a sophisticated Assembler which made it much much easier to code things.

I needed to start designing the CTM again from scratch. phew! But now am so glad that I did. This time around wanted to create a Linux-like feeling to it. Getting the initial UI until you hit 'run' took about 2 days to code. It was amazing yet I felt something was just not right. I thought that if I put-up an Easter-Egg in the section where the general UI resides, chances are people wont find it out that easily. Thats when I thought, why not create a 'Brainfuck Interpreter' for this architecture? :D It'll be piece of A.R.T. And guess what? it took more time than creating the rest of the CTM itself.

If you want to see the first Easter-Egg, boot the CTM challenge & when it says "Press ENTER to boot AoDOS-Trial from this Bootrom.", type '^' & hit enter. :)




Well, its a full-fledged Brainfuck interpreter written entirely in Aod8 Assembler. You can try most of the brainfuck programs in it. This was when my boss asked me to report the progress I made with the CTM. :D It took me some time to explain what I've done & although he understood the beauty of it, he was worried that maybe not many will be able to solve it. Thats when we decided that we keep it as simple as possible so that most of the people who attempt it, can crack it. I was already done with 3 levels by this time. I had some major plans for level-4 & level-5 when we had this discussion & thats when I decided to completely drop the idea of Level-5.

I also re-wrote level-3 to have a very simple algorithm that can be easily reversed. Level-4 is basically a crackme that I wrote in Brainfuck, being emulated on my Aod8 Brainfuck Interpreter. Again, I re-wrote a simpler version of the Brainfuck crackme so that its do-able. It was not designed for the Uber-Reversers at all. :) It was for noobs & for people who are majorly into programming. Just by looking at the design I can think of funny ways to defeat all the levels. The weakest point of the design being the "Stack". An emulator that dumps stack contents would have ended the game right away! And frankly, we wanted winners. Its amazing that I spent 1 whole month re-writing the CTM to make it simpler!

We had officially 2 winners this time. Aseem & Dhanesh. They did a wonderful job. :) But trust me, I've received more mails with compliments & evident eagerness from people who were just attempting it. For most, the part when they got the Emulator done & when the bootrom displayed the initial message was an achievement in itself! And for each mail that I received, I won once. :)

Now, let me give a brief idea of what the CTM contained. It was about 130kb in size. I managed to squeeze in 4 levels, 2 Easter-Eggs, Entire asm code of the CTM except Level-4, Aod8 Processor implementation in C as well as PERL, a real-virus code, complete 3-pass Assembler for Aod8 & a sample asm file to explain the usage. Now, thats pure Art. :)

But, it took me close to 2 months ( yea, I have a very hectic day-job where I work on ten thousand things at a time. :P ) to complete it, out of which I spent one whole month re-designing it to be simple. I wrote the CTM almost 3 times from scratch. Tested it on windows, linux & even on my iPod to be sure that it works. The Brainfuck Interpreter was a test of my patience & persistence. :D I wrote that right from scratch almost 34 times until I got it right! Infact, I wrote the Aod8 Asm code for it on paper manually about 4 times. I designed each level separately & finally when it was time to combine all of them into one single bootrom, it just wont work! Spent another whole week going through about 1,29,918 lines of code & debugging every single jump & loop instruction until I got it fixed. I guess its not patience after all, am just plain adamant :)

Overall, for me it was a huge learning curve. More than that, it has been a personal milestone in many ways. I've always wanted to give back to the community & this one gave me a platform to reach a wide range of people. I hope that everyone who attempted the MalCon CTM this year had a good time. Special Thanks to Shantanu Gawade for being my Beta-Tester. :)

#Nirvana-Achieved.