Dillo protected DLL
 

Hi,
I am taking my first steps in trying to unpack a DLL protected with Arm 3.75b. I tried using Lunar's DLL Stripper 1.6 and it finds the OEP okay, but was unable to recover the IAT.
Will this version of Arma use code splicing?

I attached to the running DLL with ImpREC and enter the OEP, pressed IAT AutoSearch and ImpREC reports an invalid OEP.

Can anyone point me to a tutorial on DLL dumping, I can find plenty on protected EXEs not DLLs. Thanks for any help.

5Alive.

I read that DLL Stripper 1.6 works on Armadillo up to 3.6, then Lunar stopped writing for its as far as I know. Anyone know if it can be used with success on dumped but not fixing the IAT?

I also tried the Olly scripts:
MEPHiST0s - ARMADiLLO DETECTiVE v1.00 for olly script
Armadillo Standard+Strategic Code Splicing Script by AvAtAr

Neither of which appear to find the OEP. What I was hoping to do was make a working dump after running either script, then study the script to see how to do it by hand then hopefully write a tut for other noobs.

Hmm, okay I found the call EDI part of the code which should reveal the OEP.
Olly reports that I am trying to place a BP outside the code section.

What am I doing wrong please?


5aLIVE

ollydbg puts out that warning based on its analysis
ollydbg during analysis has marked that page as data not code
so data are not supposed to be executed in normal course of things
so ollydbg warns when you are trying to set a break point
which it assumes to be data

you can ignore that warning if you are sure it is code and sure it would be executed click yes and set break point there :)

now if it was not code and was data
like "helloWorld" and you wrongly set up a break point a messagebox
using that data can look like
hell#world 0 replaced by 0xcc and shown as it is :)

or may be you have push 401057 and you set a bp on the byte 57

now if this was used as code some where else
mov r32,this bytes
mov thatplace,r32

it would become push 4010cc (coz 57 was replaced by your break point 0xcc
and it was copied verbatim and it will bring disastourous results
like ollydbg warns

hope you understand what i say :)

Hi JuneMouse, I think I understand what you are saying. Her's what I found.

Here's the call I was speaking about:
00398228 3348 38 XOR ECX,DWORD PTR DS:[EAX+38]
0039822B 3348 30 XOR ECX,DWORD PTR DS:[EAX+30]
0039822E 2BF9 SUB EDI,ECX
00398230 FFD7 CALL EDI
00398232 8BD8 MOV EBX,EAX
00398234 5F POP EDI

If I place a BP @ 00398230h and ignore the warning, the debugger doesn't break.
Instead I land here:
10137567 >/$ 55 PUSH EBP
Olly says that this is the module entry point. How can I be sure of this? I dump from this address and then?

This packed DLL has a time trial based protection too. Will it be possible to unpack without a valid name and key?

You'll understand why I don't want to be spending time on something that can be broken.

5aLIVE

If this program runs OK, it can be unpacked, but if it asks for name and key at first and then runs (if key valid) then this prog may be crypted=>you won't unpack it without valid key.

IF the DLL runs perfectly (unpack in memory completely) then you can unpack it (you must be in the trial time. But if the trial is ended and you see the name/key window, then you can not unpack it. Use then trialreset (you can find this tool in this forum).

Regards.

5Alive:

You are SETTING A VERY BAD EXAMPLE for the newbies by constantly answering your own Posts when no one has responded. :eek: I have combined several of your Posts.

THIS IS THE REASON THERE IS AN EDIT BUTTON!

Use the EDIT BUTTON to add comments to your previous Post if there have been no Replies.

Regards,

Apologies for my for poor etiquette JMI. I was just exercising my train of thought, I'll seek to do this in smaller confines from now on.

@taos thanks for replying. I understand what you are saying about dumping within the time limit.

I have since managed to find the OEP using AvAtArs script and dump the DLL. I need to look into fixing the IAT as I understand that this has been destroyed.
The dump certainly doesn't work at the moment.
UPDATE:I attached to the DLL using impREC and it already has the correct OEP displayed? I wasn't expecting that to be the case.

There are no invalid thunks. I selected fix dump and try to run it, and it fails saying that the program is damaged with a bad sector or virus.

Any suggestions where I'm going wrong?



I have already tried using the John Who's Trial Doctor 1.3, it doesn't find any registry entries but it does find and delete a .tmp file. This isn't enough to reset the trial period.

For the moment, I just restored an image that was created before installing the target. I read that I need to use a reg snapshot tool of some sort and monitor the Win folder to find what is being changed.

5aLIVE

I believe taos was refering to this tool:
http://www.exetools.com/forum/showthread.php?t=7785.
Trial Reset 2.8

This should remove the Arma keys for you. Just make sure if you have purchased any products protected with arma that you backup your registry info. So you don't accidently delete your reg info.

Thanks gabri3l, I tried the trial reset tool but it doesn't work either. I'll look into this after I have a working dump.

UPDATE:I have an OEP which I don't know for sure is correct. The OEP the script reached is 10137568, can somebody confirm this is correct?

I've dumped the DLL and cut the invalid thunks and fixed the dump. I no longer get the corrupt message but it doesn't run.
I'll send a copy of the file to those interested in taking a look at this.


Thanks,
5aLIVE.

This is a CRC check, so if you've removed all dillo code and like DLL code can not checksum itself (because you can not read your code AFTER dillo protect it) it sounds like a lenght file check.
you must trace DLL and search for createfilea or another similar api (use search button in this forum, this topic has been posted several times).

Regards.

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.

Okay here's a summary of things I found.
If you load the protected DLL in to PE Explorer it shows the OEP as 0137567h, running Avatar's script it shows the OEP as 0137568h, a difference of one byte.

How can the OEP of the protected DLL be one byte away from the security DLL?
Does this suggest to me that the init/unpack is called from entry itself = DllMain()?
I tried using 0137568h with ImpRec a second time, and there were no invalid thunks this time. I fixed the dump again and it still fails to run with no error message.

@taos/Archer from what I understand from reading the archives is that this CRC happened before because I used the OEP $xxxxxx7 instead of $xxxxxx8. I notice the there is a entry to the CreatFilea API so I'll have a look at that anyway. EDIT: Nope I tried $xxxxxx7 as OEP again and it behaves the same, no error message and no run. :confused:

Is likely that IAT of the dumped file is being destroyed?
I've read that I need to patch a magic jump to prevent the IAT from being destroyed.
Sorry for all these question, but I'm finding most of the info out there is about packed EXEs not DLLs.

I'm almost sure that OEP can't be 1 byte away from EP of the protected DLL (if it is so, something is wrong, maybe script or you misunderstand something). And how can PE Explorer show OEP of the protected DLL? AFAIK it can show EP, but not OEP. And if you enter EP in ImpRec maybe it's trying to restore Arma's import table, but you need real dll's table. Try to look for it with hands and manually enter table's address (do it on OEP).

You are right, and at this point I don't have enough experience to know what is wrong - perhaps both!

Yest it's shows the EP only, I was just using this to illustrate that EP and OEP differ by one byte.

I'll see if I can find the start and size of the table manually, I still need to confirm I've got the right OEP address first.

5aLIVE.

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

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.

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. :)

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

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?

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

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

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.

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

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.

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

[/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.

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.

Archer,
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.

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


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.

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.

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.

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 .

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.

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

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

The "IAT" magic jump is after a Virtual Protect call. You'll know you are in the right spot if you BPX on VirtualProtect, and then take a look at the instruction that the code returns to after the call to VirtualProtect. If it's a PUSH 1, then you are right on top the IAT redirection code and the magic jump is down below a little ways.

You can't put a BPX or any breakpoint anywhere near the magic jump since it's decrypted at runtime. BPX'ing on the API call is the only way to get there. Also, once you've patched the magic jump, put another BPX after the IAT redirection code, and when you hit that BPX, then repair your Import Table (since it will now be complete in memory). And then change the magic jump back to original instruction. It's optional, but if you don't change the instruction back then Arma goes to re-encrypt the IAT redirection code and it will crash since the code is different.

-Lunar

Sorry for the late reply I've been busy with work recently.
Being new to the art of unpacking I thought that one the file is unpacked no patching would be needed. One of the other VIP forum members kindly unpacked the file for me.

It has all the relocs intact and it loads, running the file reports an invalid or corrupt serial number so it needs to be patched.

I found that the DLL is trying to load the armaccess.dll and then make a call to check the serial, I patched this and it runs. Upon running the patched DLL for the first time it displays the registration info, activating again runs the DLL as expected. Can anyone tell me if this is how unpacked Arma DLLs normally behave?

How do you guys tackle the armaccess.dll reference? Just patch it out as I have?

I'll need to look at this again. If anything, I have learned more about how to use Ollydbg, ImpRec and LordPE than anything else which can't be a bad thing. Still I'll need to read more on the PE format and so on if I am to progess.

I'll PM the forum member who unpacked this and ask if can can explain how he did it. I'll reply here with any information I get.

Hi Lunar, thanks for the explanation of what needs to be to be done and why, things are starting to make much more sense to me. Perhaps you can answer the burning question about restoring the relocation table, what method (if any) do you use?

I've read that loading the unpacked file at different base addresses into Relox is what is needed to recover the table. I've also read that they don't need to be rebuilt as they are in there original state in the dump. Can you clarify this please?

I'm quite enjoying the whole learning experience of it all. Thanks, 5Alive.

Hey,

I've never had to rebuild a relocation table in Armadillo programs or DLL's.

-Lunar