ActiveM***

[MEPHiST0]

yea dumping at the 2nd layer EP.. or licence layer EP... is probly the best..

i dumped at the 2nd EP.. and my game runs, with the trial stuff.. i patched the trial stuff to just run the game....
all the fake CALLS are working ok...
but the exe is still messd up from somthin, cause it is crashing, all my targets are crashing, just minor stuff, almost got one fixed completly, everytime i fix somthin, somthin else is broke.. :|

but ive yet to get a completly unpacked exe.. i cant code much so coding a pluggin for imprec is outa the question

although i did some research on teh fake calls..
not ONLY are some CALLS faked.. jump dwords to API are faked as well.. inbetween FF25 there is 90E8xxxxxx
but they are all simular..
(in my dumped at OEP.. the fake calls dont execute the right code, due to a long jump in every fake code process)
in mine, all the fake calls take me to a CALL DWORD.. to GetModuleFileNameA..
then a bit after this is the API that it really fucked... (but in dumped at OEP this real API doesnt get executed because of a long jump)

mm still yet to play my gamewithout trial :|

[Nacho_dj]

Another issue of AM protection is the one related to functions and dll's.

AM protection removes some of the functions provided in the import table by the original program. So, in order to rebuild the program, you will need adding these lost functions (api's), or even, some dll.

It happens in functions such as Direct3DCreate8, belonging to d3d8.dll. When a nop + call is referencing to it, the rebuilding of this function has to include the insertion of the function in the import table, and, if no present, of the dll.

I do not know whether there is a tool doing this. I have included this function in the rebuilder I am developping, but it has been a difficult task.


When tracing the nop + call redirection, you can get a LoadLibrary "d3d8.dll", and then, GetProcAddress of "Direct3DCreate8".

So, another issue that has to be fixed...


Cheers

Nacho_dj

[Nacho_dj]

Because of adding a new API, deleted by the AM protection, in the action of rebuilding the program, you will find at least two possibilities:

- Adding it following the last name of function in the import table. This is only possible whether the dll owner of the function has to be added too, because previously did not exist in the file.

- Inserting it in the middle of the import table. This case is when the dll owner of the function exists in the import table.


The first case is more or less easy to solve. But it is necessary rewriting all the values of IAT and Original First thunk, and adding a new function name. It has to be done with a lot of care in order to get the rebuild working.

The second case means that you need to rewrite all values of first thunk, IAT and original first thunk, plus modifying the function names list. It involves the appropriate changes in a lot of calls to api's, in order to remain calling to the original api.

This is another issue that a rebuilder of this protection needs to fix.

I have found in internet some tools "doing" this, but none of them working totally.


Cheers


Nacho_dj

[Nacho_dj]

Talking about sections, one issue necessary to fix in the rebuilded program is deleting the useless sections, because the AM protection increases the number of these, and consecuently, the size of the file.

If you unpack and fix all the things that the AM protection touchs, when you have rebuilt the file, it seems to be too big. Ok, just think there are several sections working for the protection, and thus useless to the rebuilded unprotected program.

So, the task is trying to choose the parts of these sections that are working only for the original program.

At least, the first section remains as is, because it has the code of the executable. The parameters, such as size and offset, could remain the same. So this section could receive the .text name.

The section that has to be converted to .rdata is the one that holds the import table.

As I said in another post, this has been rebuilt in order to get active all the correct api's. So, one way of rebuilding this is putting the IAT just behind the First Thunk of the import table, as you can find normally. I say this because a lot of times, AM protection reallocates the IAT in other area of the file.

Ok, then section .rdata must be the one that holds the rebuilt import table.
In the dumped you know some ways of getting the offset of the import table. ImpRec uses the OEP to find it.


You normally find another two sections in an executable: .idata and .rsrc.

Recovering both sections is the task where I am at the moment.


If anybody could add some in this sense i would be great!


Cheers

Nacho_dj

[Nacho_dj]

Does anyone here have got a protected program by the new release 6 beta of AM?

I would like it in order to include in the generic unpacker/rebuilder, still in developping/testing status.

If you go to the trymedia URL you will see they are announcing this new version of the protection, with the possibility of maybe trying it.


At the moment, I am trying to let the size of the rebuilded program as the original had. It involves the fix of the .rsrc section.


Cheers!

Nacho_dj

[Nacho_dj]

03-16-2005 post corrections:

I'm testing a fix to the 5.3.1071 AM release.

Ok, that is a mistake, it is the 5.3.1078.
Now, I am testing with the tool all releases I have found.

But it is a very good beginning getting the "18 Wheels of Steel - Pedal to the Metal". This is the only one (I have found till today) of the 5.3.1071 AM release that keep in the dumped code the equivalences for the AM calls that you can find inside the dumped code as:

Ok, that has changed. I have found lots of targets that keep the AM equivalences table.

The 'PEStub' string an then six 0 bytes, then the equivalence table begins. If not try point 2

Well, in the 5.3.1078 you always find the AM equivalences table following the PEStub string plus six zero bytes. The other options work for another previous AM releases to this 5.3.1078.

And in the same post, some "not call" that are to be "nop call".


Cheers!

Nacho_dj

[Nacho_dj]

Hello:

As I have mentioned in Thread:
http://forum.exetools.com/showthread.php?t=7784

there is the possibility of finding a "second PE header" in the dumped.exe from an AM protected target.

Ok, as far as I know, the rebuilding of sections in order to get the original unpacked and unprotected program remains as follows:

- From 5.0.900 AM release till now AM releases, if a second PE Header does not exist, the rebuilt target PE Header is exactly the dumped.exe PE header, but choosing only the four first sections.

- If a second PE header exists, then the rebuilt PE header has the virtual values (offset & size) as in PE header, and Raw values as the virtual values of second PE header. The names of the sections have to be these of the second PE header.

The following thing to do is deleting all the unuseless sections for the rebuilt target. The sections that normally you find in a .exe file are:
.text
.rdata
.data
.rsrc

.text is the first section, it remains as is.

.rdata contains the first thunk. You have to write there the rebuilt first thunk of the import table. This involves recalculate all the calls to api's.

.data contains the data that the program uses, and normally the IAT. So, you have to rebuild the IAT there. The offset of the IAT comes following the OEP value in the dumped.exe, found with the "_com_err" string searching.

.rsrc is the resources section. You have to "transport" the resources of the dumped.exe to that section, deleting the AM resources, such as "AMTOOLBAR", and so on.

All those operations have to be done modifying conveniently the PE header, because there is where the .exe keeps the information of IAT offset, Import Table offset, Resources virtual address and the size of all of them. Without this fix, the rebuilt target is certainly crashing or even the system does not recognize it as a valid .exe.

I will follow in another post explaining how to delete the unuseless sections.

Cheers

Nacho_dj