Monthly Archives: November 2006


I sometimes hypothesize about reverse engineering code compiled for alternate (i.e. non-x86) CPU architectures. It makes one question why so much effort is focused on x86 RE (to which the simple and immediate answer is, because all the interesting code is compiled for the x86 architecture). Maybe I’m just enamored at how neat RISC code tends to be, with typical architectures featuring 32-bit instruction words. Writing a disassembler obviously embodies not even a fraction of the complexity of a decent x86 disassembler. Fortunately, the GNU binutils take care the disassembly details already (I recently posted a Wiki page on using objdump, even cross-compiling for non-native architectures). Here is some representative disassembly from a PowerPC ELF binary, for those who have never been exposed:

   16b40:       80 e1 01 14     lwz     r7,276(r1)
   16b44:       7c 09 3a 14     add     r0,r9,r7
   16b48:       7d 3e 00 ae     lbzx    r9,r30,r0
   16b4c:       55 20 e1 3e     rlwinm  r0,r9,28,4,31
   16b50:       48 00 00 08     b       16b58
   16b54:       38 00 00 0f     li      r0,15
   16b58:       2c 0b 00 0f     cmpwi   r11,15
   16b5c:       7c 04 03 78     mr      r4,r0
   16b60:       40 82 00 54     bne-    16bb4
   16b64:       88 19 00 02     lbz     r0,2(r25)

Quite a change from the typical x86 slop. Though I sometimes wonder what the ‘reduced’ in reduced instruction set computer (RISC) is really supposed to mean. It definitely doesn’t indicate reduced functionality for individual instructions. I looked up that rlwinm instruction: Rotate Left Word Immediate Then AND with Mask. I started to wonder if it would be simpler to compose an assembly re-targeter for a RISC CPU until I started reading up on this instruction.

And here’s some MIPS RISC code:

  20157c:       84820002        lh      v0,2(a0)
  201580:       2484000a        addiu   a0,a0,10
  201584:       44820000        mtc1    v0,$f0
  201588:       46800020        cvt.s.w $f0,$f0
  20158c:       46010002        mul.s   $f0,$f0,$f1
  201590:       e4600000        swc1    $f0,0(v1)
  201594:       0501fff2        bgez    t0,0x201560
  201598:       24630008        addiu   v1,v1,8
  20159c:       1000000a        b       0x2015c8
  2015a0:       3c020000        lui     v0,0x0

As memory serves, with MIPS CPUs, you get the added fun of manually tracking in your brain the CPU pipelining. I.e., an arithmetic operation from one instruction may not be completed by the next instruction, which happens to operate on the same register, and the compiler was specifically counting on that, and you need to count on it as well during your RE efforts.

Unnamed RE Project

“Unnamed RE Project” is the impromptu name I gave to a program that I hastily wanted to start but couldn’t be bothered to come up with even a quasi-clever name. Moreover, I actually got it to do something. I can’t believe I actually made a go of this, perhaps one of the most useless reverse engineering exercises.

Aside: Does this still qualify for my “outlandish brainstorms” blog category if I actually made it work?

The basic idea is one that a lot of reverse engineers surely kick around at some point: A set of CPU registers can be abstracted as a set of global C program variables and individual assembly language instructions map quite neatly onto C program statements. Thus, what about an automatic conversion utility that can take an ASM disassembly and convert it into a C program that can be portably compiled? Not optimal, but it might be a start for other RE projects.

Traditionally, I objected to this approach on the basis of its inherent impurity– one of my objectives in this RE journey is to understand the algorithms being recovered. Technically, while it sounded like a simple enough concept, when one actually sits down to think about, all kinds of problems crop up. One of the most immediate is how case statements (jumps using dynamic tables) would be handled.

Putting aside all uncertainty, I decided to go for it and see what could happen. Believe it or not, I met with some success while also discovering a number of problems I hadn’t yet realized (for example, the dream of portability goes right out the window). I hope to write up some more about this shortly. But for tonight, I will just show the results of the first experiment.

Continue reading

What Is DoubleTwist Ventures Up To?

I generally don’t like to talk about the top search terms that are driving traffic to this blog since doing so tends to have the effect of driving more traffic based on particular terms to the posts that discuss that particular term. But last month, I noticed that “doubletwist ventures” drove a huge amount of traffic to this old post.

Is it just me, or are DRM-cracking stories just not interesting anymore? Maybe I just think of cracked DRM to be a fait accompli— I accept it as a forgone conclusion that DRM can’t work and it’s just a matter of time before the specific DRM algorithms are recovered (that is, if it’s not just stock AES).


At long last, I am getting around to posting some omelette pictures in an effort to re-hijack the search term. Not only is the site named for the breakfast food, it will have a post about the same illustrated with pictures. Omelettes– they’re not just about multimedia technology and reverse engineering anymore! Without further ado…

This was an all-around well-done omelette.

Omelette cooking
This is an omelette in the early stages of cooking. I must have used most of the spices on my shelf for this one.

Omelette with jalapenos
This one looks like it has jalapenos baked in.

Omelette burned
Sometimes, things go bad. I probably just wasn’t watching this one and it burned. Looks like it is leaking chopped onions, too.