I'm trying to unpack a target which is protected with Armadillo 2.60 beta 1 according to peid.

First off i ran target through dillodumper, it creates a dump and i fix IAT with imprec, but target does not run. so now i am at point where i must learn why it's not working.

I have gotten hold off Ricardo tutes and following them through, now i find a strange thing. I set bp WriteProcessMemory and according to Ricardo i expect to land where arma is about to copy a decrpted block to child process, but instead of block that is 1000h bytes in size, aram is only copying 2 bytes, it is writing to entry point of protected file (not OEP of unpacked child), but to child process, it is writing EB FE, ie jmp eip.

So i tihnk, i will run till next break on WriteProcessMemory, next break is writing back 55 8B to where it had just written EB FE, so it must start writing decrypted data soom, but next time i run, i no longer hit anymore breaks on WriteProcessMemory. This is strange, i look at protected target in IDA, and i clearly see 3 references to WriteProcessMemory, 2 ref's only write 2 bytes, the 3rd is the one i want, which writes 1000h bytes, but i can not break on this?

--
bedrock

hmm.

Does the program create two seperate processes when it runs? If so, then it's protected by CopyMEM and will act as you describe..so make sure it is.

Dillodumper really only works on 2.65 (I think) or 2.75 (for sure!) to 3.01a.

You said the program wont run - what exactly happens? Do you get a clean IAT? How about OEP? Does it look correct?

One more thing: Is the program written in VB?

-nt20

nt20,

Yes there are 2 seperate processes when it runs.

The dump fails to run by crashing with an 'unhandled exception in dumped_.exe (NTDLL.DLL): 0xc0000005: Access Violation'

OEP and IAT look correct as far as i can tell, app if an MFC dialog app, not VB.

--
bedrock

It may be that the app is simply protected by Debug Blocker (which only calls WriteProcessMemory twice), and not CopyMem-II (which calls WriteProcessMemory for each 4096-byte chunk requested by the protected application).

Exactly as Squidge has hinted here and talked about quite a bit on this other thread (sorry i didn't find this before)

http://www.woodmann.net/forum/showthread.php?t=4836&highlight=armadillo+debug+blocker

I have read ricardo's tut's but I am still having problems. My target does indeed only appear to be protected with Debug Blocker and not Copymem II, i would of thought that this would of made it easier for me to get a working dump, but still no joy

Also there doesn't seem to be any sign of nanomites, but my dump crashs with unhandled exception when trying to access invalid memory location.

I have packed some known apps with Arm 2.60c (closest i can find to 2.60 beta1 at the moment) and verified that i have correct OEP (also same OEP as dillodumper finds) and i have gone through IAT but cant find problems.

Anybody got any more ideas on what i can try to get a working dump?

--
bedrock

One other thing I can think of is to perhaps check the IAT Section itself, in the PE header, to make sure it has write permissions. YOu can do this with LordPE or PEditor, just look at the section's characteristics. Being that the crash appears in NTDLL.DLL this could be the problem (the windows PE loader tries to access the IAT and doesn't have write permission) The easiest thing to do is just set characteristics for all sections to be writable, since you may not know for sure which is the IAT section.


The other thing also, is that the program is most likely dumped fine, but it tries to use one of Armadillo's environment variables, and since it's not there anymore, the program crashes.

Can you disassemble the program ok with windasm? If so, it means the PE file structure is correct and should work. Then search for any string references the might be armadillo environment variables, such as DAYSINSTALLED, etc.

"Unpacking", or dumping, the program, is really only the first step. Some targets still need some work afterwards. If you know the OEP is good, and the IAT looks right in ImpREC, then the problem is most likely something like I stated above.

-nt20

I check the PE header section characteristics, cant find any problems?

I can disassemble the dump using IDA fine and there are references to arma environment vars, but my dump never get's this far. My target comes as a 10 use trial version, as a temory solution i have tracked down the relavent registry and .tmp files to remove to reset the trial.

When i execute my dump and step through with olly, i get past the normal stuff at OEP, like GetVersion and GetCommandLineA etc... and eventually get to this code:

00417188 56 PUSH ESI
00417189 8B7424 08 MOV ESI,DWORD PTR SS:[ESP+8]
0041718D 3B7424 0C CMP ESI,DWORD PTR SS:[ESP+C]
00417191 73 0D JNB SHORT Dumped_.004171A0
00417193 8B06 MOV EAX,DWORD PTR DS:[ESI]
00417195 85C0 TEST EAX,EAX
00417197 74 02 JE SHORT Dumped_.0041719B
00417199 FFD0 CALL EAX ;Dumped_.00415C95
0041719B 83C6 04 ADD ESI,4
0041719E ^EB ED JMP SHORT Dumped_.0041718D
004171A0 5E POP ESI
004171A1 C3 RETN

My assembler isn't brilliant and i don't really know what this is doing, each time round EAX contains a valid adress within the dump, i thought it might be something like the MFC message map possibly, but eventually it will execute a CALL EAX and land here:

0043261F E8 72A50000 CALL Dumped_.0043CB96
00432624 8B4C24 04 MOV ECX,DWORD PTR SS:[ESP+4]
00432628 85C9 TEST ECX,ECX
0043262A 8848 14 MOV BYTE PTR DS:[EAX+14],CL <---- CRASH
0043262D 75 08 JNZ SHORT Dumped_.00432637
0043262F 6A FD PUSH -3
00432631 E8 E255FEFF CALL Dumped_.00417C18
00432636 59 POP ECX
00432637 6A 01 PUSH 1
00432639 58 POP EAX
0043263A C2 0800 RETN 8

At the point above i've marked CRASH, CL contain 0 and EAX contains a memory address we cant write to, game over.

--
bedrock

Hmmm, well i have some news to report, i have now got a working dump, but i still dont understand why? I am hoping someone can help my learn why.

First off, i must say a big thanks to Lunar_Dust (and nt20 ) I have gone back to older dillodumper (2.34 i think, a version that has lunars own IAT rebuilding code) with this version i have made a working dump, so all along dump was good and OEP was good, but the difference is the IAT, all function pointers in Lunar's IAT and ImpREC's IAT are same? but difference seems to be to do with Original First Thunk's, this is something i am still learning about.

If i look at import directories in lordPE, my non working dump (IAT fixed with ImpREC) has Original First Thunk as 0x00000000, and Thunk RVA as 0x41000 (this is address dillo told me to enter in ImpREC)

If i look at import directories for working dump i see Original First Thunk as 0x001045f1, i dont know this address, but obviously Lunar does?

I had looks at nt20 First Thunk Rebuilder program long ago, but i tried download link this afternoon and it wasn't working, i need to do some more searching, but i wanted to report what i was finding.

--
bedrock

Ah, I have some info. Firstly , whenever I've used ImpREC, its actually rebuilds the FirstThunk table, and not the OriginalFirstThunk table. The "FirstThunks" are the actual thunk RVA's that will be used by the PE loader. The "Original First Thunks" is a backup copy that the loader will use first if it sees an entry. Dillodumper's IAT engine, at its time, rebuilt the "Original First Thunks", and would leave the FirstThunks table alone.

So here this might be a problem however, the dump will work, since the FirstThunks are valid (since DilloDumper disables Import Redirection), so when the program is dumped from memory all the FirstThunks are actually hard addresses to the API functions already. Which means the program will run, but it might not be portable to other windows boxes. However, if the Original First Thunk table is there, the PE loader will usually load that first, so if the file's working now, it's probably correct...

Well, anyway, funny how an older version of DilloDumper actually worked better - haha..the IAT support was pretty good, it just had some bugs that would crop up now and then and hose everything. Basically, Lunar told me that the biggest problem was handling all the nuances that imports can have, for example, forwarded imports, import by ordinal, etc. Forwards were the biggest problem. So the IAT engine usually would work fine on most common files, but still had some problems with small files, or files that used special DLL's.

Another note: The FirstThunk rebuilder will only work if you have an OriginalFirstThunk table present (like, for example, a program fixed with Revirgin or with DilloDumper). It won't work on ImpREC'd programs, because ImpREC already fixes the FirstThunk table itself.

-nt20

I describe this problem so:
Under Xp(or w2k?),
Even if OrigFirstThunk presents, FirstThunks must NOT be Null;
or NTDLL will crush.