I'm using Olly under Windows Vista. I'm trying to unpack an application packed with armadillo (PEID says 3.78-4.xx). I found the OEP, found start and end of the IAT and now I'm trying to find 'magical jump'. The problem is, under VISTA, everytime I reload the application in Olly, the address of the section where IAT is, changes and I can't put breakpoints on IAT addresses. If I use the same application in Windows XP, the addressess are always the same, but not in Vista. Maybe someone faced the same problem and have ideas about the solution. I tried to find the answers in this forum and internet, but no clues. Thanks.

Simple but not the most elegant solution is to do your unpacking in WinXP. An unpacked PE executable is an unpacked executable is an unpacked executable, and should run in most windows versions, within reason.

The most elegant solution is a solution that works. Obviously, I already did it in XP. Actually I unpacked the application in XP and it is running smoothly in XP and in Vista. My point is: how to do it in Vista? Thanks

read about aslr address space layout randomisation

vista randomises address space

if you need full source code access for similar schemes goto paxsecurity and read ,download. cvs, svn, thier linux hardening projects sources

vista has implemented this kind of layout randomisation

iirc this has been there for about a decade now in unix flavours

there are attacks to deal with randomisation if it was implemented weakly

for example in the earliest form of unix aslr the address space randomisation was linked to getpid() results which used to wrap around at some point and if the wrap around was identified then you can turn it to static implementation

ok this is vista for you from almost horses mouth a probablity of 1/256



http://blogs.msdn.com/michael_howard/archive/2006/05/26/address-space-layout-randomization-in-windows-vista.aspx

read the comments lots of biggies in the field have responded and there are various hints links and stuff below

Very helpful. Thank you.

...although, instead of spending time and code to randomise the address space, the developers could've spent their efforts on actually finding and fixing those exploits.

Also, isn't the IAT address supposed to be determined by a fixed value in the PE header?

Yes. Two problems:
-The PE header entry is a raw offset, ergo in the memory image it gets randomized along with all addresses within the executable, while olly, at least in its simplest implementations, require absolute addresses for effective breakpoint placement.

- In an Armadillo (or any) packed file the PE header value points to the IAT of the unpacker stub. The IAT address of the underlying app is not explicit.

This suggests a solution to the problem cps530 proposes:

I would make the assumption that the relative addresses remain constant, if not within the whole exe at least within the segment that contains the scrambled IAT.

So in run 1 (Packed PE under Olly):
-Find the base address (Of the PE or of the IAT containing segment).
-Find the address of a unique byte signature within the segment of interest.
-Store the absolute addresses of the BP you are interested in re-placing from run to run

In Run 2
-Find the new base address (From the PE header).
-Find the Address of the byte signature by binary searching.
-Compare the distances between old base address and old byte signature versus new base address new byte signature. I'd assume is constant.
Even if not, you have enough information to calculate a correction offset you need to add or subtract to the BP absolute addresses you stored before to find the corresponding locations and place correct BP in the new instance of the PE.

The whole process can be implemented in a Olly script.

You know you can find the magic jump by setting a breakpoint on the "ret" instruction of GetModuleHandleA? Just keep checking where it is called from, when there is a call to LoadLibraryA a few lines further you've hit the jackpot.

or you can simply hook msvcr!stricmp to return <> 0 when APIs are scaned. This should do the trick no matter where dll is loaded.

@LLXX: true but here it is IAT of protector. maybe he is facing IAT elimination in armadillo or he found break but on next run armas virtual dll is located on different memory address.

doesn't sound like this has anything to do with aslr, since things are only "relocated" between boots.


1. See http://en.wikipedia.org/wiki/Defense_in_depth#Defence_in_depth_.28computing.29
2. It's not a fair assumption to make that developers would have been able to find any vulnerabilities in the time it took to design and develop ASLR in Vista. And don't forget about classes of vulnerabilities that haven't even been discovered yet. This is why defense-in-depth (see above) is important.