Just wondering if somebody knows of a tool to circumvent the anti-disassembler tricks that are used f.ex. in sd

With anti-disassembler tricks, I'm referring to the following sort of code sequences:

<< snippet from ~df394b.dll >>
1000100c: 70 0d jo 0x1000101b
1000100e: 77 03 ja 0x10001013
10001010: 87 ff xchg %edi,%edi
10001012: 90 nop
10001013: 78 0b js 0x10001020
10001015: 87 ff xchg %edi,%edi
10001017: 77 00 ja 0x10001019
10001019: 79 05 jns 0x10001020
1000101b: 87 d2 xchg %edx,%edx
1000101d: eb ef jmp 0x1000100e
1000101f: 03 eb add %ebx,%ebp
10001021: 07 pop %es

The disassembler is confused and doesn't disassemble the 0x10001020 offset correctly. (note: this is an objdump disassembly).

This also fools: IDA, W32Dasm

It's easy to manually 'correct', but I don't like the 'manually' aspect ;-)


I'm sure somebody already worked on this kind of stuff, so instead of me re-inventing the wheel, I thought I'd ask here.

Hiya SiNTAX

I have also seen the effects of anti IDA/W32dasm stuff. Sometimes only IDA is affected, other times only W32dasm.

First of all I WOULD like to know how to manually fix this problem. Second have you seen ANY tutorials on this type of stuff?? I have not. Also do programmers buy this sh*t or do they create it themselves?

FYI, my current project dissambles fine in W32dasm , however IDA is sent of to LaLa land, and dissassembles some DLL (not the exe I started with) so any pointers from you would be appreciated.

One program that uses this crap is 3Dstudio Max.

Thanks
MTB

I haven't seen an automated anti-disassembler fixer in my searches but I did come across this zip file that has a couple of things by ?ferret and Kayaker and an article on self-modifying code that might be of some interest on the anti-disassembler issue.

MTB.. to fix this in IDA, you just convert the 'faulty' instruction to 'unexplored' and then convert the correct offset to code. So in this example, go to line 1000101f then press 'U', then move to offset 10001020 and press 'C'

1000100c: 70 0d jo 0x1000101b
1000100e: 77 03 ja 0x10001013
10001010: 87 ff xchg %edi,%edi
10001012: 90 nop
10001013: 78 0b js 0x10001020
10001015: 87 ff xchg %edi,%edi
10001017: 77 00 ja 0x10001019
10001019: 79 05 jns 0x10001020
1000101b: 87 d2 xchg %edx,%edx
1000101d: eb ef jmp 0x1000100e
1000101f: 03 eb add %ebx,%ebp
10001021: 07 pop %es


Anyway this kind of code is most probably autogenerated, as if you look at sd, you see that it all sort of looks the same. Probably is done using some polymorphic engine (a la virus code) to get some 'variation'


Hmm I sure could use r!sc's maid matilda ;-)

Hello SiNTAX

First of all I don't think that the problem is at a specific address. The whole snippet seems meaningless to me.
The antidissassm tricks are very interesting to me.
I would like to explore this dll. Could you send it to me(if it is not very large)?

2. I don't know any way to autogenerate these tricks. But...who knows
Here is an example of an antidissassm trick.
Usually it is used when you write a protection in asm.
Suppose you have:
mov eax, offset func
call eax
The opcodes for call eax are: FF D0

Now change your code in this way:
mov eax, offset func
db 0EBh
call eax

Obviously the compliler will generate the sequence:
EB FF D0

The dissassembler (i.e. IDA) will dissassemble
mov eax, offset func in the right way.
But what to do with EB FF D0?
EB is the opcode for jmp, so you will see:
00401013 EB FF jmp short near ptr loc_401013+1
00401015 D0 68 5F shr byte ptr [eax+5Fh], 1

Note that this EB FF D0 don't change the program flow.
At the loc_401013+1 we have FF D0 so the next instuction is our call eax

Greetings!
Maldoror

Maldoror,

The DLL is from a Safedisc2 executable, so take your favourite sd2 title and run it. It extracts 2 dll's to your temp dir, so if you break on LoadLibraryA, then halt the executable and copy the DLL's from your temp dir.
The dll is called '~df394b.dll' -- it's full of these code sequences.

And you are right that the code snippet seems meaningless, that's because it IS meaningless.. ie. it doesn't really do anything, you might well replace it all with NOP's.
The code doesn't change any flags, registers, ... so it can be injected at random locations in the real code. And to prevent a simple search 'n replace, it uses different instructions.

here's a properly decoded sequence:
----
1000653E EB 07 jmp short loc_10006547
10006540 ; ---------------------------------------------------------------------------
10006540
10006540 loc_10006540: ; CODE XREF: .txt2:10006547j
10006540 8B C0 mov eax, eax
10006542 78 06 js short loc_1000654A
10006544 90 nop
10006545 79 03 jns short loc_1000654A
10006547
10006547 loc_10006547: ; CODE XREF: .txt2:1000653Ej
10006547 EB F7 jmp short loc_10006540
10006547 ; ---------------------------------------------------------------------------
10006549 35 db 35h
1000654A ; ---------------------------------------------------------------------------
1000654A
1000654A loc_1000654A: ; CODE XREF: .txt2:10006542j
1000654A 7F 09 ; .txt2:10006545j
1000654A jg short loc_10006555
1000654C
1000654C loc_1000654C: ; CODE XREF: .txt2:10006557j
1000654C 90 nop
1000654D 87 C0 xchg eax, eax
1000654F 78 09 js short loc_1000655A
10006551 87 FF xchg edi, edi
10006553 79 05 jns short loc_1000655A
10006555
10006555 loc_10006555: ; CODE XREF: .txt2:1000654Aj
10006555 77 00 ja short $+2
10006557 7F F3 jg short loc_1000654C
10006557 ; ---------------------------------------------------------------------------
10006559 87 db 87h ; ç
1000655A ; ---------------------------------------------------------------------------
1000655A
1000655A loc_1000655A: ; CODE XREF: .txt2:1000654Fj
1000655A 8B 4D E4 ; .txt2:10006553j
1000655A mov ecx, [ebp-1Ch]

-----

The code between 1000653E and 1000655A does nothing, except fuck up IDA/W32Dasm/... auto-disassembly.. ie this is what you normally get (without intervening):

1000653E EB 07 jmp short loc_10006547
10006540 ; ---------------------------------------------------------------------------
10006540
10006540 loc_10006540: ; CODE XREF: .txt2:10006547j
10006540 8B C0 mov eax, eax
10006542 78 06 js short loc_1000654A
10006544 90 nop
10006545 79 03 jns short loc_1000654A
10006547
10006547 loc_10006547: ; CODE XREF: .txt2:1000653Ej
10006547 EB F7 jmp short loc_10006540
10006547 ; ---------------------------------------------------------------------------
10006549 35 db 35h
1000654A ; ---------------------------------------------------------------------------
1000654A
1000654A loc_1000654A: ; CODE XREF: .txt2:10006542j
1000654A 7F 09 ; .txt2:10006545j
1000654A jg short loc_10006555
1000654C
1000654C loc_1000654C: ; CODE XREF: .txt2:10006557j
1000654C 90 nop
1000654D 87 C0 xchg eax, eax
1000654F 78 09 js short near ptr loc_10006559+1
10006551 87 FF xchg edi, edi
10006553 79 05 jns short near ptr loc_10006559+1
10006555
10006555 loc_10006555: ; CODE XREF: .txt2:1000654Aj
10006555 77 00 ja short $+2
10006557 7F F3 jg short loc_1000654C
10006559
10006559 loc_10006559: ; CODE XREF: .txt2:1000654Fj
10006559 87 8B 4D E4 8D 45 ; .txt2:10006553j
10006559 xchg ecx, [ebx+458DE44Dh]
1000655F 08 8B 11 52 50 6A or [ebx+6A505211h], cl


Offset 1000655a is not properly decoded anymore.


(I hope this is 'readable' in a browser ;-)

ArthaXerXes,

Ah.. I knew somebody must have done this before ;-) Saves me the trouble.. was thinking of writing an IDC script to clean up this mess.

I'll give imhotep a go...

If you're looking for further reading materials on anti-debugging tutotials, Krobar has a selection in his "Complete" section.

Regards.

And where can I find Krobar's material?

Anyway imhotep does a decent job at cleaning the cruft from sd

Searching would be a good place to start. Typing "Krobar" into google immediately gives at least three alternative locations for "tHe Krobar Collection." The one I've been using is at :
http://www.krobar.cjb.net