Dumping AutoIt overlay data

Started by Ruhe, May 09, 2010, 03:54:21 AM

Previous topic - Next topic

Ruhe

FYI ... good to know. This also applies for PECompact :-\

http://myauttoexe.angelfire.com/Doc/Dumping_OverlayData_of_Armadillo.htm

BoB

What has this to do with PECompact? :)
PECompact doesn't encrypt the overlay data, you can use my PEiD plugin or many other means to extract overlay.  If you want to store sensitive info, don't put it in the overlay, and if you do, encrypt it! :)


Ruhe

Quote from: BoB on May 09, 2010, 11:22:10 AMand if you do, encrypt it! :)

That is what PECompact should do, or at least offer it. Like the way it is done by *peep*


And by the way, how and where should I store data by using AutoIt? The script is always attached as overlay.

BoB

Quote from: Ruhe on May 09, 2010, 11:26:36 AMThat is what PECompact should do, or at least offer it. Like the way it is done by *peep*

PECompact is a compressor, not a protection system, like Armadillo and others mentioned in that article.
If you were to compare compressed sizes you would see the difference.

It sounds like the feature should be in AutoIt really, but should PECompact encrypt overlay?
Well, the process of reading any overlay data from any executable is basically the same.  The overlay data is not in memory when the executable is executed, so it must always be read from the disk.

Therefore, as the article suggests, hooking CreateFileW API will at some point lead you to the executable reading itself from disk, SetFilePointer will show where in the file the overlay data starts, ReadFile will show the length and destination buffer for the data.

In order to encrypt the overlay data with PECompact, one would have to hook at least CreateFileA + CreateFileW + SetFilePointer + SetFilePointerEx + ReadFile + ReadFileEx APIs, so that all calls to these functions from the compressed executable would be handled by the decryption routine, which would then decrypt and return the original overlay data.

It's really not that hard to do, but I don't think there is any way to do this (as no access to overlay) from a hook plugin currently, and as you can see, it's not hard for a determined person to steal the data. :)


Quote from: Ruhe on May 09, 2010, 11:26:36 AMAnd by the way, how and where should I store data by using AutoIt? The script is always attached as overlay.

Then you have no choice but to use overlay, or use some other program.  Having never used AutoIt or anything like that, I cannot give any more specific answer than that.
If you were doing it from your own program I could give you more help.

Have fun!
BoB

Ruhe

My personal conclusion so far: the "easiest" and best is to rewrite my current AutoIt project in Delphi...

BoB

I agree ;)
I can also help you with this too, should you need help.

Have fun!
BoB

newuser

Quote from: Ruhe on May 09, 2010, 12:16:04 PM
My personal conclusion so far: the "easiest" and best is to rewrite my current AutoIt project in Delphi...

Too bad, I'm not familiar with Delphi :'(.(if only theres a converter that can convert autohotkey/autoit scripts to delphi, that would be great :)).
I wonder whether theres any programming language thats similar in syntax to autoit or autohotkey...

Due to mass user base, autoit and autohotkey seem to be getting the unneeded/unwanted attention....

Currently, there are protection tools being develop for autohotkey, just go to autohotkey forum, search for "ironahk" or "hotkeycamo".

Not haven't heard any such protection tools exist for Autoit yet. :'( If theres one, let me know.

Another option might be Enigma, but not sure whether any autoit/autohotkey users use it to protect their files/exes and whether, it can be done successfully or not.


BoB

QuoteI wonder whether theres any programming language thats similar in syntax to autoit or autohotkey

Looks like Basic to me :)

Having finally looked at AutoIt, and it's overlay data, I don't see what the problem is.  The overlay data appears to be a compiled version of the script, not a plain-text script.
You can extract overlay, but unless there is some decompiler for the data, it's hardly useful for anybody to do this.

It did amuse me somewhat that the compiled stub for executing the scripts is over 600k when unpacked!
Also, there is an AutoItX.DLL you could use with your own software, but strangely there seems to be no Api for executing a script, unless I missed that.

Ruhe

There are decompilers for AutoIt executables, thats the problem. It took me 2 minutes of searching in google to download a decompiler and another one to decompile a foreigen executable created by AutoIt. The result: an usuable and readable source code of the script.

Jeremy Collake

For at least the last 5 years I've planned to implement something like this. The idea is simple: Hook file API calls and redirect reads to the module's own physical image so that an overlay/extra-data is made available at the same physical offset that it existed at in the uncompressed physical image. It can all be done automatically, if implemented right.

This technique could be implemented in the loader, API hook plug-in, or external DLL. In the latter case, I would develop a DLL that - when loaded - applies the API hooks. I have traditionally planned to implement it in an API hook plug-in.

So, when will I ever get to this? Well, that's a good question. At times my todo and commitment list is already so overwhelming that I don't know where to start. That said, it is not very difficult, and would be quite useful to many people.
Software Engineer. Bitsum LLC.

newuser

I almost forgot about this thread, I hope you dont forget about it,  jeremy. :)

BTW, out of topic question, when will the pecompact 64bit column download section be fill? :o

Legend

Quote from: support on May 12, 2010, 02:51:17 PM
For at least the last 5 years I've planned to implement something like this. The idea is simple: Hook file API calls and redirect reads to the module's own physical image so that an overlay/extra-data is made available at the same physical offset that it existed at in the uncompressed physical image. It can all be done automatically, if implemented right.

This technique could be implemented in the loader, API hook plug-in, or external DLL. In the latter case, I would develop a DLL that - when loaded - applies the API hooks. I have traditionally planned to implement it in an API hook plug-in.

So, when will I ever get to this? Well, that's a good question. At times my todo and commitment list is already so overwhelming that I don't know where to start. That said, it is not very difficult, and would be quite useful to many people.

Any news regarding this?