OpenRCE: Blog

What's in a name?

Wed, 09 Apr 2008 12:54:46 -0500

Most of the RE work I've done in the past was on windows where cdecl is implemented for

function(arg1,arg2)

as:

push arg2
push arg1
call function

But lately I've been working with gcc compiled binaries that allocate the stack space before hand and implement cdecl as:

mov [esp+4], arg2
mov [esp], arg1
call function

Apparently this is referred to as SUB/MOV method (thx Ero!) and is default for gcc. When IDA disassembles binaries using this method, it looks somewhat weird:

mov     [esp+3C218h+var_3C214], arg2
mov     [esp+3C218h+var_3C218], arg1
call    function

My initial reaction to this was to write a script that would jump to each function that called other functions and rename the first (last?) couple variables to something a little more sane to enhance the readability. This was a bad idea. What ended up happening is that in some functions the stack offset changed part way through the function, causing the names to be off about half the time.

The solution? OpAlt(). The Edit->Operand type->Manual.../Alt-F1. This does not propagate like a standard variable renaming does,  it just changes the one instance of that operand. This will cause a little bit more work when scripting, but the results are somewhat more accurate. Renaming the variable in the frame is still ok, but only if you check that the stack offset for all outgoing calls are the same. (hint: GetSpd())

OS X / Objc Reversing

Mon, 07 Apr 2008 12:45:20 -0500

I've been doing some reversing on my mbp lately, and noticed there really isn't a large community resource for anyone reversing objective c binaries, or reversing on the apple at all. I know there are people doing it with all the iTunes DRM stuff and the iPhone unlocking scene, but everyone either keeps to themselves, or starts to look at a binary, sees all the symbols and walks away because it's too easy.

For the most part people seem to simply use otool+otx, class-dumper or IDA on parallels.

To make up for this vacuum of knowledge, I've put together a mailing list at 0x90.org for anyone interested in this topic. It's low traffic, but hopefully it can be useful in the long run.

http://0x90.org/mailman/listinfo/xso

When the starting point isn't the starting point..

Mon, 01 Aug 2005 01:20:04 -0500

After taking the time to rewrite every mnemonic from scratch, again, I decided to attack the nagging flaw that kora pointed out over coffee.

With larger applications it seemed like they were disassembling properly, so to actually test properly we threw a very simple 5 line program with no calls. Sadly, out of the ten functions disassembled, none of them were the actual test program.

Other than the entry point, there are at least 10 direct or relative called functions that can be disassembled for most of the code I've compiled with gcc. One of the ones that wasn't showing up was main(). The main() function is called in start usually by a call to a jump to the base of the stack, which isn't currently handled.

I finally got the the symbol tables (which include the address of main()) adding functions after the rest of them are found. Next up, repairing the damage I did to the Indirect Operands.

I <3 Intel

Sat, 23 Jul 2005 17:21:53 -0500

The documentation is ok. But every so often you find something that forces you to ask questions, and you're only comfort is a manual so large it had to be split into two very large manuals that are totally inconsistent between revisions and really don't have a solution to wtf you wanted to know in the first place.

For example:

An instruction on the intel chipset can be from one to about 15 bytes long. Or anywhere inbetween. Fine. No problem.

[prefixes][opcode][mod r/m][sib][other crap..]

makes sense.. I can deal with that.. so start off with the first less than obvious part:

Mod R/M: (one byte)

[Mod - 2 bits][Reg - 3 bits][R/M - 3 bits]

... ok, so the way this works is that the Reg field always indicates which one of 8 registers is being referenced. if Mod == 3 (11b) Then the R/M field is another register indicator.

So.. if your operands are "r32, r/m32" then the r32 portion is the reg field and the r/m32 is the r/m field. if it happens to be two registers, then mod is 3, as I already stated.

Now.. if your operands are "r/m32, r32" then it's the same, the only difference here is that your destination and source is supplied by the opposite fields as before. But they're read from the same fields.. makes perfect sense.

Until.. if your operands are "r32, r32" .. what.. the.. fuck.. like seriously, there's about 10 instructions that have a format similar to this. You would think that it would be explained clearly or upfront somewhere. After a brief googling, I found some guy who referred to the Mod R/M byte as being "cryptically named", at which point I lost my faith in humanity on the internet and decided to break out nasm and just compile them.

From what I can guess, the rule for Mod R/M goes like this:
if Dest == register and Src == reg/mem -> Dest == reg Src == r/m
if Dest == reg/mem and Src == register -> Dest == r/m Src == reg
if Dest == register and AnythingElse == register -> Dest == reg AnythingElse == r/m

I may have missed the brief sentence where that was explained somewhere, but really it's a completeness thing that annoyed the crap out of me last night. If I'm wrong about this, please tell me.

Not quite free of the mnemonic stranglehold.

Thu, 14 Jul 2005 14:20:52 -0500

Yesterday, or the day before (I can't really remember now), I posted what I thought was the most glorious commit logs for KlaunmoetD. All menmonics are done .. It took me a day of breaking other parts of the disassembly system to realize that all the original conditional instructions were built as one single class (MOVcc, SETcc, JccREL8 & JccREL32).. I think I'm going to cry. Hopefully I can knock those out of the park tonight, but I'm really going to need to rebuild the OperandBuilder class to accept Intel style operand strings. There may be a performance hit there, but the readability of the classes and the accuracy should be worth it.

Today's useful C# fact:
[Obsolete("Put this around all your conditional classes, and if you didn't already have 400 compiler warnings your life would be easier tracking those conditional mnemonic classes")]