Dillo protected DLL

[5Alive]

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.

[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 warns bp not on code section

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

[5Alive]

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

[Archer]

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.

[taos]

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.

[JMI]

5Alive:

You are SETTING A VERY BAD EXAMPLE for the newbies by constantly answering your own Posts when no one has responded. 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,

[5Alive]

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

[gabri3l]

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.

[5Alive]

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.

[taos]

Originally Posted by 5Alive

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.

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.

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

[5Alive]

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.

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.

[Archer]

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

[5Alive]

Originally Posted by Archer

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

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

Originally Posted by Archer

And how can PE Explorer show OEP of the protected DLL? AFAIK it can show EP, but not OEP.

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

Originally Posted by Archer

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

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.