Log in

View Full Version : OEP of Arm 1.xx to 2.x protected Targets


TempoMat
February 15th, 2008, 20:55
Hi All,

I am having a tough time finding the OEP to Programs protected with Armadillo versions lower than 2.5.

I am talking about the version were Arma creates temp files in the form Progie*.xxx.tmp.

What I have done so far:

Methode 1.
I have analyzed the programs a lot and know that after showing the splash screen some chunks of actual code are copied using WriteProcessMemory into some buffers. After these copies the resulted dump will be exact the size of the replaced XXX in the tmp file (childs process) starting from offset 1000. So the remaining XXX junks before this offset can be zeroed without a problem.

So using a HexEditor I can open the primary memory of the father process and copy the chunk code to the saved copy of the child process (tmp file) I had made. Unfortunately this does not work like some tuts explained. Then the resulting file still contains some Arma codes.

After these copy and paste procedure I try to open the tmp file with W32Dasm and try to find location of common API that are called most around the OEP like GetCommandLineA and GetModuleHandleA. There are mostly at least two of these calls within the area that look very promising. But all tests with suspected OEPs either failed to lunch the file or they crash with access violation. Sometimes Olly even refuses to load them.

At first I thought it had to do with my Computer so I did change to another and the same problem was there, even with different Ollys (Molded and none molded ones)

After trying for about two nights I suspended this method and went on to Method 2

Method 2.
These Programs just terminate when I put a bp on WaitForDebugEvent and CreateThread doesn’t work either.
So I used bp ResumeThread. After the second break I just step over the Call and then dump the tmp file with LordPe and try to fix the dump with ImpRec. The fixed dumps can though be loaded in Olly but the OEPs are not correct.

Some observations I made by analyzing the dumps:
1. Imports tables are in the forms
00404D0C - FF25 90A24600 JMP DWORD PTR DS:[<&kernel32.CloseHandle>] ; kernel32.CloseHandle
00404D12 8BC0 MOV EAX,EAX
00404D14 - FF25 8CA24600 JMP DWORD PTR DS:[<&kernel32.CompareStringA>] ; kernel32.CompareStringA
00404D1A 8BC0 MOV EAX,EAX
00404D1C - FF25 88A24600 JMP DWORD PTR DS:[<&kernel32.CreateEventA>] ; kernel32.CreateEventA

2. Interestingly the tables are scattered in chunks at up to but not limited to 4 different locations.
My idea was to get them all to one location before firing ImpRec to grab them.
So I binary copied all the chunks to an empty location in the dump and directed ImpRec to use the RVA for grabbing the imports. The Gurus here would say straight away this will not work. Of course it did not work because ImpRec sort of tried to read like 4 bytes which mostly included the 8BC0s such that the resulting addresses were garbage hence irresolvable.

If I allow ImpRec to auto search for the IAT it grabs them from locations around 000A04xxx which are the locations of some embedded data. With this the dumps are at least loadable in Olly.

The biggest problem is still finding the OEP.
I have tried attaching the tmp file with another instance of Olly when I had stepped over the second ResumeThread, then placed a bp on the Code section of the attached tmp file. After that with Shift+F9 I could land in the area around the OEP. With this method I was able to find an OEP (I believe) by checking the stacks and back tracing the calls.

After this fix of the OEP the program could attempt to start but crushes after some seconds with access violation error. I have traced traced to the location of the crash but could not resolve it.

I think I am not been successful maybe because I am dumping the files at the wrong time and/or not been able to find the correct OEP.

Any hint and/or suggestion is highly appreciated.

PS: the Programs are old around 1999 and 2001 and were downloaded some years back when I started reversing and realized I could not handle Arma with two process (CopyMemI or II) at that time so I left them there sitting for brighter days.


I have also used the same methods on UnpackMes from tuts4you with more or less the same results.

Ragards,
TempoMat

Hopcode
February 19th, 2008, 11:12
If you look well enough, there are tutorial hosted on woodmann, one of them is:

http://woodmann.com/theanalyst/tutor35.txt

This is Arma 1.75, but the techniques was working on various versions and it gives you some ideas..

TempoMat
February 20th, 2008, 19:10
Thanks a bunch for the link Hopcode.

I thought I had almost all the old Tutz from ACiDBURN, but apparently this was missing in the collection. Those I found until now were among others those from Krobar’s collection. The decisive hint from the Tutz was the about the first section from the dump file.

With the tutorial from the link on these earlier versions of Armadillo, I have been able to unpack several of them within a short time including most of those unpackmes from tuts4you. I believe I made things more difficult for myself.

With some of them the correct OEP has to be found after fixing the dump, but once the dump is loadable in Olly the rest was merely a matter of form.

In the mean time I have been able to unpack some higher versions up to 4.3x but mostly with Standard, Debug Blocker and IAT elimination or redirection options.
I will continue with a lot more and venture on the fields of Code Splicing before attempting to tackle Nanomites. So far I've done almost all manually, but I think sooner or later I will have to use scripts and other tools once I have matured in the manually unpacking of the standard ones.

Thanks and Regards,
TempoMat