Log in

View Full Version : deobfuscation


swirl
June 27th, 2005, 11:28
Hi all,

im dealing with an obfuscated code, its really annoying full of
jumps, void instructions, self modifying code and such things
really annoying to track; atm i've tracked a good part of code
but i would ask is someone has encountered my same problem
and can suggest me some strategy for a better approch or
some tool that makes deobfuscation or just helps at least with
jumps (ex: some control flow graph synthesis, but i dont know).


thanks and sorry for poor english

p.s. hope i've not break some FAQ rule..

NOP
June 27th, 2005, 11:38
try search prog named imhotep ...

Extremist
June 27th, 2005, 14:50
Write an IDA script.

swirl
June 27th, 2005, 17:17
thanks NOP, it worked to eliminate some of obfuscation, at the first stage
but it keeps de-scrambling its code, so i should on every de-scrambling
save the process image, patch it, and rerun imhotep on the new binary.
btw thanks a lot.
Extremist hope u wasnt' referring to me saying "write a IDA script" it is the
newbies section not advanced section

bye

swirl
June 28th, 2005, 11:47
it comes out that it was a well known packer , so all the process of deobfuscation was not needed.

bye

Extremist
June 28th, 2005, 16:36
if it is the usual obfuscation of this type, IDA skripts are not hard to write... basically it's just search & replace (search & destroy?).

NOP
June 29th, 2005, 13:12
Quote:
[Originally Posted by Extremist]if it is the usual obfuscation of this type, IDA skripts are not hard to write... basically it's just search & replace (search & destroy?).

yes write IDA script is easy ...

swirl
June 29th, 2005, 15:08
eh, atm i's need more time learning how to write an IDA script than
just jumping obfuscated sections, that is, now i knwo that it was
packed with armadillo, and most of transformations are always the same
so now is easy avoid them; further more i've got some documentation about
armadillo, even if a bit outdated, that permitted me not to deal with
obfuscated code.

maybe in the future i'll write one.

swirl
June 29th, 2005, 19:53
well, i dont know what is the packer, here some peculiar characteristics
i've found that might help in identifying which packer is:

- after some de-scrambling uses some raw debugger detection code

00948D83 0F31 RDTSC
00948D85 8BD8 MOV EBX,EAX
00948D87 83F8 01 CMP EAX,1
00948D8A 74 0A JE SHORT TARGET.00948D96
00948D8C 0F31 RDTSC
00948D8E 8BC8 MOV ECX,EAX
00948D90 E3 04 JECXZ SHORT TARGET.00948D96
00948D92 3BCB CMP ECX,EBX
00948D94 75 0A JNZ SHORT TARGET.00948DA0
00948D96 C785 8C840000 6B>MOV DWORD PTR SS:[EBP+848C],6675636B

6675636b = "fuck" for those who dont see it...

- after some jumping calls GetProcAddress to retrieve address of the follwing
functions:

00948A71 IsDebuggerPresent.
00948A91 WriteProcessMemory.ReadProcessMe
00948AB1 mory.WaitForDebugEvent.GetVersio
00948AD1 n.GetModuleHandleA.GetCommandLin
00948AF1 eA.GetProcAddress.LoadLibraryA.G
00948B11 etStartupInfoA.CreateProcessA.Se
00948B31 tEnvironmentVariableA.GetEnviron
00948B51 mentVariableA.GetCurrentProcessI
00948B71 d.Sleep.CreateThread.CreateFileA

etc etc

- here comes the pain it uses some onion structure for obfuscation:

[de-scrambling code (1)] [ de-scrambled data == next code(2)] [data for de-scrambling(3)]

(1) the code is something like:

00949125 47 INC EDI

[plenty of jumps here]

00949126 8B9CBD 50840000 MOV EBX,DWORD PTR SS:[EBP+EDI*4+8450]
0094912D 03DD ADD EBX,EBP

[jumps]

0094913F FFE3 JMP EBX (4)

00949176 83FF 04 CMP EDI,4



where:
EBP is process base address
EDI is a counter, from 0 to 4, each value of edi corresponds to a different
operations, usually 0-3 are the set up for descrambling which takes place
at edi = 4
EBP+8450 is an array of offsets, used to calculate the functions to jump at:

array = EBP+8450
ebx = array[edi]
jmp ebx

the array is located on (3)

after de-scrambling it jumps to (2) where it makes the same operations
obvioulsy with different data.

i've recognized some regularity in the addresses generated:the address of
this operation

MOV EBX,DWORD PTR SS:[EBP+EDI*4+8450]

for each onion skin just increase by 0x83
that is if the address for skin.1 is
00949126
the next, for the same op, in skin.2 will be
009491a9


even if i can calculate next addresses i cannot set breakpoints, otherwise
de-scrambling will be corrupted and all goes f....

some way to set breakpoint without setting the 0xCC on memory ?

thanks
swirl

upb
July 7th, 2005, 21:38
you could use hardware bpx (debug regs)
good luck doing this manually, there can be few hundred of those layers..

swirl
July 8th, 2005, 03:44
at last i followed the suggestion and make a olly script to bypass all those
layers, i think its packed with armadillo since it then creates the child, but cannot identify the version.
another characterstics could be this string "sKAMERsUCKSs" used in those annoying de-scrambling functions...

bye