Dillo protected DLL

[Archer]

IMHO, it would be better to do everything (finding OEP and import table address) manually without relying on scripts or anything else. You said that you'd found Call Edi, which leads to OEP, so you should better use this OEP (put break there and don't worry that Olly complains about setting break outside code), because I suppose, script found the wrong one. As for me, I taught unpacking Arma on Kagra's tuts, but he unpacks exe-s only. If you understand russian, i saw unpacking Arma dll tut on hxxp://cracklab.ru

[taos]

Originally Posted by Archer

No, DLL can checksum itself. It can check not only filesize of file on the disk, but it can also check some code in the memory (and for example calculate it's CRC). Then you should try to break on ReadProcessMemory.

Yes & no.
You obviously can checksum simple lines of code with "delta offset" technic but only simple (I'm speaking about armadillo protected program!!!) lines because if you CRC a lot of code, API redirection, stolen bytes, ofuscation code, nanomites , etc... are inserted AFTER you compile and so CRC is not the same never.
To know if you prog is altered you need to checksum a lot of code (like in this program).
Armadillo "touch" your code.(other protectors unpack only parts of your code and checksums not run).
Regards.

[Archer]

To 5Alive:
Clear you box for incoming pm-s.
To All:
Don't kick me for this post, I'm helping him to unpack this dll in pm-s.

[5Alive]

Hi Archer I'm having trouble PM'ing you so I'll post here to let you know my inbox is tidied. I'll delete this post when you PM me.

The problem I'm having with PM is that the reply page ist drawn in the top left hand corner of the page instead of the centre and the submit button is inoperative.

Sometimes it works, sometimes not. Any suggestions what might be up? I'm using IE6.

5aLIVE

[Asus]

Hi,

I used Stripper 1.6, after loaded .dll is packed with Armdillo, tools diplayed like below:
Arma Security DLL Base Addess: xxxxxxh
Scanning Security DLL...
Scanning Security DLL export table..
IAT decryption block found at xxxxxxh
Scanning for Import Redirect...

and it stopped there. What I made wrong?

[Archer]

2 Asus:
Maybe it's not you, maybe this prog can't unpack this version of arma and gets for example in endless loop.

[5Alive]

Okay time to resurrect this thread back from the dead. I decided to put this little project on hold until I read some more tutorials on the subject (which I have).

I found a new tutorial by MaDMAn_H3rCuL3s which shows how to unpack an Arm 4.x protected DLL. It mentions a quick and easy method of find the OEP, simply by setting a break on access (F2) of the .text section of the DLL.

With the DLL at the EP, and pressing Shift-F9 a meesagebox shows "Error while unpacking program, code 5-15. Please report to author". This happens when no breakpoints are set too.

I never had this message appear when I was working on this before.
Here's a list of my setup:
XP home SP2,
Ricardo's patched Ollydbg 1.10 (Parcheado 4.EXE)
HideDebugger 1.2.3f with all the options enabled.
I also have all exceptions set to pass to the program
I've added the following custom exceptions:
000006BA, 0EEDFADE
C0000005(ACCESS VIOLATION), C000001D(ILLEGAL INSTRUCTION)
C000001E(INVALID LOCK SEQUENCE), C0000096(PRIVILEGED INSTRUCTION)
C000001D (Invalid lock sequence).

Pressing Shift-F9 gave a stack over flow (C00000FD). I added this to the custom exception list and restarted the driver. I still get the error message.
Can anyone help please?

Hi Archer and Messer

[Archer]

Error while unpacking usually happens, when Arma detects debugger. Maybe it sees installed SoftIce or IceExt (it can detect even, if SIce isn't running). Maybe some breakpoints set (software or hardware). Maybe something else (found Olly in some other way, don't know exactly, because mine Olly is all patched with hands, renamed and even packed with ASPack). For example HideDebugger plugin for me doesn't work properly, so I use IsDebuggerPresent plugin instead.

[5Alive]

Hi Archer, thanks for replying. This is driving me crazy, I never had this problem before when looking at this DLL.

Originally Posted by Archer

Error while unpacking usually happens, when Arma detects debugger. Maybe it sees installed SoftIce or IceExt (it can detect even, if SIce isn't running).

Yes, I would agree it appears to be detecting something. I have both SoftIce and IceExt installed. When I first got this file it would not run under normal conditions (no debugger loaded), so I edited the IceExt registry entry. Then it ran okay.

Originally Posted by Archer

Maybe some breakpoints set (software or hardware). Maybe something else (found Olly in some other way, don't know exactly, because mine Olly is all patched with hands, renamed and even packed with ASPack).

I don't have any software or hardware BPs set, and it still gives this error message.

Originally Posted by Archer

For example HideDebugger plugin for me doesn't work properly, so I use IsDebuggerPresent plugin instead.

[/QUOTE]
I typed BP IsDebuggerPresent and pressed Shift+F9 and the API returns 0 as expected. I'll try the IsDebuggerPresent plugin anyway to see if this might help.
Can you send me a copy of your patched and packed Olly and .ini file via rapidshare (PM me with details). Thank you appreciate it.

UPDATE 1: The IsDebuggerPresent plugin doesn't change anything unfortunately.

UPDATE 2:Okay I've made some good progress since my last post.
I tried Archers packed and packed Olly (thanks) but the error remained.
In the end I gave up trying to load the DLL directly with LOADDLL.EXE and thought I'll just run the main EXE and debug the DLL from there.
That seems to work well. (phew)

I've found what I think is the OEP although I'm not certain does this look correct?
017E6221 55 PUSH EBP <--OEP?
017E6222 8BEC MOV EBP,ESP
017E6224 53 PUSH EBX
017E6225 8B5D 08 MOV EBX,DWORD PTR SS:[EBP+8]
017E6228 56 PUSH ESI
017E6229 8B75 0C MOV ESI,DWORD PTR SS:[EBP+C]
017E622C 57 PUSH EDI
017E622D 8B7D 10 MOV EDI,DWORD PTR SS:[EBP+10]
017E6230 85F6 TEST ESI,ESI

I found the IAT table, and patched the two jumps. I set a hardware BP on what I thought was an invalid entry(intuitive guess) and it broke in the IAT.

My question is what do you guys do to identify an invalid entry what are the "rules". My method was that I noticed pattern of the form XX XX DX 77 when this deviated I assumed it to be invalid.

This leads me to my next question. What am I looking for to find the start of the table? Again a break in the pattern or something else?

Thanks 5Alive.

[Archer]

Well, it may be OEP, looks like OEP. (BTW, I wrote to you in PM about 1 month earlier about OEP and import table. I don't remember exact addresses now.) As I remember there is only 1 jump that should be patched to get clear import table, but I'm not sure, it was too long ago. Well, good import entry usually looks like xx xx xx 77 or xx xx xx 7c, others are usually bad (invalid or edited by Arma). To find the beginning I usually look for zero entries (00 00 00 00) or many invalid entries. Anyway, when entering addresses in ImpRec it's not essential to enter precise address of beginning, you can substract for example 100 to be sure, that beginning is in the interval.

[5Alive]

Archer,

Originally Posted by Archer

Well, it may be OEP, looks like OEP. (BTW, I wrote to you in PM about 1 month earlier about OEP and import table. I don't remember exact addresses now.)

Yes, I've still got your PM, I found a later version of the DLL which I can load into olly directly without error. So the OEP and such has changed. I'm pretty sure this is the right OEP, it agrees with Lunars DLL stripper anyway.

Originally Posted by Archer

As I remember there is only 1 jump that should be patched to get clear import table, but I'm not sure, it was too long ago.

Originally Posted by Archer

As I remember there is only 1 jump that should be patched to get clear import table, but I'm not sure, it was too long ago.

I think the later DLL uses the same version of Arma (3.75), the tut describes a patch for the magic jump and one for GetTickCount. The GetTickCount patch must only apply to Arma 4.x. (Anyone confirm this?)

Originally Posted by Archer

Well, good import entry usually looks like xx xx xx 77 or xx xx xx 7c, others are usually bad (invalid or edited by Arma).

That's the sort of form I had reasoned on, I just need someone skilled in the art of unpacking to confirm this. Thanks for that.

Originally Posted by Archer

To find the beginning I usually look for zero entries (00 00 00 00) or many invalid entries. Anyway, when entering addresses in ImpRec it's not essential to enter precise address of beginning, you can substract for example 100 to be sure, that beginning is in the interval.

Okay, cool.

UPDATE: I think I am but one step away from getting this dumped now.
After patching the addresses:
$0173 5093 JNZ (RVA $9AF6D) <-- Magic jump (changed to NOP)
$0173 5214 JBE (RVA $9ADEC> <--Anti-dump (changed to JMP)

I think the DLL is ready to be dumped. I set a BP on the OEP and press Shift+F9, you can see the correct IAT table being wrtten in memory, the trouble is Olly says that the "debugged program was unamble to process exception". So I cannot attach to the DLL process with LordPE or ImpRec.

I made making a binary copy of the IAT and pasting it into a reloaded DLL and attached to with LordPE, dumped it. Then tried to fixed the IAT with ImpRec. The unpacked DLL still fails to load.

Please help! See my post in the request section of the forum for a link to this file.

Thankyou.

[5Alive]

Bump. See my update above. Thanks for looking.

hacnho described a very good way in his tutorials about IAT-Elimination to find the magic jump. This method also works very well here. I've unpacked the dll now, but my problem are the relocations...

Also make sure you don't use normal breakpoints on the APIs because Arma detects them and will then crash the program.

Then set a bp on the .text-section. Next time you break you should have reached the OEP. Dump with LordPE and fix Imports.

[5Alive]

Originally Posted by Messer

hacnho described a very good way in his tutorials about IAT-Elimination to find the magic jump. This method also works very well here.

Hi Messer, I take a look at hachnos methods of finding the magic jump. I was using Madman Hercules tut on unpacking a DLL packed with Arma 4.xx.
It describes patching two jumps, one to stop IAT destruction and one for anti-dump (GetTickCount).

I guess you must have used the same technique as Archer when he looked at an earlier version which I couldn't get to load without error on my system. He only me a single patch and then dumped it .

Originally Posted by Messer

I've unpacked the dll now, but my problem are the relocations...

Archer also had trouble with the relocs. Is the reloc table still there in the dump or has it been wiped? If it has been wiped, could it just be the option setting in LordPE is checked to Wipe Relocation. I've found some information on fixing relocs which I'll compile and post later.

Originally Posted by Messer

Also make sure you don't use normal breakpoints on the APIs because Arma detects them and will then crash the program.

I've only been using HW BPs when debugging the DLL.

Originally Posted by Messer

Then set a bp on the .text-section. Next time you break you should have reached the OEP. Dump with LordPE and fix Imports.

That's what I've been doing to find the OEP, only it crashes after I have made the patches. I can't have applied the right patches if it is crashing at OEP. Damn.

Thanks for you help.

Do you know what you want to patch in unpacked-dll? Maybe it is possible to create an inline patch. I've created some inline patches of Arma protected EXEs already. Maybe it is possible doing this with dll's too.

I've found magic jump with "he GetModuleHandleA". Then you just need to patch 1 long-jump.

Usually the program doesn't crash after setting bp on the .text-section. So if it does try to undo changes you have made with magic jump after the IAT is totally resolved. You may also try to check if dll is unpacked after it crashes, this happens with som programs. Then it is also possible to dump. Don't know what to do with the relocs but I will look what i can do to fix this problem