OpenRCE

📚 OpenRCE is preserved as a read-only archive. Launched at RECon Montreal in 2005. Registration and posting are disabled.

About Articles Book Store Distributed RCE Downloads Event Calendar Forums Live Discussion Reference Library RSS Feeds Search Users What's New

Customize Theme

Flag: Tornado! Hurricane!

Created: Wednesday, April 9 2008 12:54.46 CDT

Direct Link, View / Make / Edit Comments

What's in a name?

Author:

nummish

# Views: 2158

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())

Created: Monday, April 7 2008 12:45.20 CDT

Modified: Monday, April 7 2008 12:45.41 CDT

Direct Link, View / Make / Edit Comments

OS X / Objc Reversing

Author:

nummish

# Views: 4567

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

Created: Monday, August 1 2005 01:20.04 CDT

Modified: Monday, August 1 2005 01:20.04 CDT

Direct Link, View / Make / Edit Comments

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

Author:

nummish

# Views: 1624

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.

Created: Saturday, July 23 2005 17:21.53 CDT

Modified: Saturday, July 23 2005 17:23.53 CDT

Direct Link, View / Make / Edit Comments

I <3 Intel

Author:

nummish

# Views: 1907

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.

Created: Thursday, July 14 2005 14:20.52 CDT

Modified: Thursday, July 14 2005 14:20.52 CDT

Direct Link, View / Make / Edit Comments

Not quite free of the mnemonic stranglehold.

Author:

nummish

# Views: 1962

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")]

Archived Entries for nummish

Subject	# Views	Created On
No archived blog entries found.

There are 31,328 total registered users.

Recently Created Topics
[help] Unpacking VMP...	Mar/12
Reverse Engineering ...	Jul/06
let 'IDAPython' impo...	Sep/24
set 'IDAPython' as t...	Sep/24
GuessType return une...	Sep/20
About retrieving the...	Sep/07
How to find specific...	Aug/15
How to get data depe...	Jul/07
Identify RVA data in...	May/06
Question about memor...	Dec/12

Recent Forum Posts
Finding the procedur...	rolEYder
Question about debbu...	rolEYder
Identify RVA data in...	sohlow
let 'IDAPython' impo...	sohlow
How to find specific...	hackgreti
Problem with ollydbg	sh3dow
How can I write olly...	sh3dow
New LoadMAP plugin v...	mefisto...
Intel pin in loaded ...	djnemo
OOP_RE tool available?	Bl4ckm4n

Recent Blog Entries
	halsten	Mar/14
Breaking IonCUBE VM
	oleavr	Oct/24
Anatomy of a code tracer
	hasherezade	Sep/24
IAT Patcher - new tool for ...
	oleavr	Aug/27
CryptoShark: code tracer ba...
	oleavr	Jun/25
Build a debugger in 5 minutes
More ...

Recent Blog Comments
	nieo on:	Mar/22
IAT Patcher - new tool for ...
	djnemo on:	Nov/17
Kernel debugger vs user mod...
	acel on:	Nov/14
Kernel debugger vs user mod...
	pedram on:	Dec/21
frida.github.io: scriptable...
	capadleman on:	Jun/19
Using NtCreateThreadEx for ...
More ...

Imagery

SoySauce Blueprint
Jun 6, 2008

[+] expand

View Gallery (11) / Submit