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








Flag: Tornado! Hurricane!

 Forums >>  Brainstorms - General  >>  Offuscated code not a problem any more?

Topic created on: June 23, 2006 11:29 CDT by gera .

Hi, during recon, which was awesom and quite brain activating, we came up with this idea for offuscated code analysis, specially for branches into the middle of an instruction: As we are now all using graphs for representing the code, this branching into an instruction is not a problem anymore, we just need to branch the analysis.
One of the branches will probably die soon from invalid addresses, for example. In any case, manually collapsing all the subtree for the invalid branch should be enough to clean the graph.
uhm.. I think the ideas is simpler than this explanation. I have implemented a proof of concept version of this usign pydasm (ero's wrapper for libdisasm) on PaiMei (pedram's excelent framework). I need to clean and we'll hopefully integrate into PaiMai, or I'll release separately.

with non linear analysis (graphs), this offuscation should not be a problem, what do you think?

  pedram     June 23, 2006 14:17.16 CDT
As discussed the downfall to not doing any linear disassembly is missing a bunch of code (ie: code marked as data). It will be interesting to see what comes of this though.

In talking to Gera off-line, he's on the track to decoupling IDA from PaiMei which would be awesome.

  gera     June 23, 2006 16:29.39 CDT
Run-time information (dynamic function pointers) are not easy to resolve statically, however, if we have our own disassembler integrated into PaiMai nothing prevents us from firing it from a breakpoint, for example, or manually after some event, or anything else that could take advantage of runtime information.

I'm also thinking on tracking registers, and sumarizing this changes on a per basic block basis, what could make it easier to track them... for this we'll need some kind of "static code emmulation" (wow!), but I'm just talking from the top of my head here. This may let us resolve some runtime pointers on static analisys.

The remaining code still marked as data is probably not used ? or not needed on a first reversing pass? but then, this makes me think we may need interactivity for the disassembler, leading us to... IDA

Note: Registration is required to post to the forums.

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