#1
|
|||
|
|||
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. |
#2
|
|||
|
|||
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 |
#3
|
|||
|
|||
Quote:
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 |
#4
|
|||
|
|||
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 |
#5
|
||||
|
||||
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.
|
#6
|
||||
|
||||
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. |
#7
|
|||
|
|||
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,
__________________
JMI |
#8
|
|||
|
|||
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 Last edited by 5Alive; 08-27-2005 at 06:40. |
#9
|
||||
|
||||
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.
__________________
-=RETIRED=--=http://cracking.accessroot.com=--=RETIRED=-
|
#10
|
|||
|
|||
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. Last edited by 5Alive; 08-27-2005 at 18:04. |
#11
|
||||
|
||||
Quote:
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. |
#12
|
||||
|
||||
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.
|
#13
|
|||
|
|||
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. Last edited by 5Alive; 08-28-2005 at 03:04. |
#14
|
||||
|
||||
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).
|
#15
|
|||
|
|||
Quote:
Quote:
Quote:
5aLIVE. |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Why can't I re-Dillo it? | Flagmax | General Discussion | 8 | 07-31-2004 03:30 |