EOF data

[giangnguyen]

So I am looking to make an anti-decompiling tool, and as a measure to secure it, I want it to use EOF data.

My script for the builder is something like:

$Stub = FileRead(@ScriptDir & "\base.exe")

$crypted is simply the encrypted code

$key is the encryption key
FileWrite(FileSaveDialog("Where to save your protected file ?", @ScriptDir, "Exe(*.exe)"), $Stub & "R3V3Z3^3b3f3j3n3r3v3R3V3Z3^3b3f3j3n3r3v3aa" & $key & "R3V3Z3^3b3f3j3n3r3v3R3V3Z3^3b3f3j3n3r3v3aa" & $crypted & "R3V3Z3^3b3f3j3n3r3v3R3V3Z3^3b3f3j3n3r3v3aa")

In the base.exe, it reads itself, and StringSplit is used to get the options. The protection uses AES encryption

However, after creating the custom app, it shows This App Can't Run on your PC.

 

Any ideas?

[RTFC]

Check out my CodeCrypter (link in signature).

[giangnguyen]

Codecrypter is for encrypting an AutoIt source, what I am looking for is to use AutoIt to encrypt any native windows app.

If this does not work out I will just print the source out and compile.

[giangnguyen]

Still looking for some help with this.

[jchd]

That's whishful thinking.

[giangnguyen]

3 hours ago, jchd said:

That's whishful thinking.

Currently I am using printing script out, but as I have seen other languages storing EOF data, I don't see why not.

[JohnOne]

8 minutes ago, giangnguyen said:

Currently I am using printing script out, but as I have seen other languages storing EOF data, I don't see why not.

Perhaps if you link to code you've seen that does this, you might get a bit of help implementing it in AutoIt.

[giangnguyen]

1 minute ago, JohnOne said:

Perhaps if you link to code you've seen that does this, you might get a bit of help implementing it in AutoIt.

I don't have those scripts, these techniques are taught by a friend of mine, and he works in C and C++.

I guess I will add some codes in AutoIt and some more infos here:
The base of the protected exe will use FileRead on itself, and store that into a variable that is called $raw. Base will StringSplit to seperate the base from the encrypted file and the encryption key. It will then proceed to decrypt the data and execute it.

[JohnOne]

Fair enough.

I cannot remember the thread, but I'm fairly certain I've seen something regarding this issue here in the past.

You should note though, before you spend time on this, that some decompilers do not need to rip your code directly from file, and instead rip it from memory when it is loaded, which has to occur at some point.

[AutoBert]

Protecting file(s) storing there own encryption key is unsafe and for 'Hello Word' apps a protection isn't needed.

Edited March 31, 2016 by AutoBert

[giangnguyen]

3 hours ago, JohnOne said:

Fair enough.

I cannot remember the thread, but I'm fairly certain I've seen something regarding this issue here in the past.

You should note though, before you spend time on this, that some decompilers do not need to rip your code directly from file, and instead rip it from memory when it is loaded, which has to occur at some point.

Yeah, I know about that. However, you also need to protect the base, and this especially helps since for those decompilers you need to find certain bytes to see what language it was coded in first.

3 hours ago, AutoBert said:

Protecting file(s) storing there own encryption key is unsafe and for 'Hello Word' apps a protection isn't needed.

The encryption key is encrypted with a hard coded key that will change in every version. And this can be a solution for higher grade applications as well.

[Mobius]

@0p Methods such as the utilization of PE overlay data are pretty much dead, anti productivity (security) software has done its work there.

With a bit of searching however you will find some examples that contain code that will help you understand how to parse the PE's section table information to calculate the correct offset in which the executable ends an overlay data begins.

Edited March 31, 2016 by Mobius

[giangnguyen]

13 minutes ago, Mobius said:

@0p Methods such as the utilization of PE overlay data are pretty much dead, anti productivity (security) software has done its work there.

With a bit of searching however you will find some examples that contains code that will help you understand how to parse the PE's section table information to calculate the correct offset in which the executable ends an overlay data begins.

Link me please, I am currently searching around but haven't found it yet.

[Mobius]

I think the depths of this thread contains most of what you need:

 

Of course it doesn't contain exactly what you need, and with a bit of searching and reading you will likely find much better or closer examples.

 

[Danyfirex]

Hi. A better reference about PE. 

 

Saludos

 

 

[Mobius]

7 minutes ago, Danyfirex said:

 

 

Saludos

 

 

Agreed, was kinda hoping the op would find this popular thread themselves if they actually were searching

Pertin

 

[Mobius]

Another nice external reference https://www.strchr.com/creating_self-extracting_executables

[quimao]

let's try a packer tool. here example project :http://www.ntcore.com/files/inject2exe.htm

[giangnguyen]

19 minutes ago, Mobius said:

Agreed, was kinda hoping the op would find this popular thread themselves if they actually were searching

Pertin

 

lol I was, but mostly about EOF data and how to add data without recompiling. I will look on it, but have to go to sleep now.

Bye!

[jchd]

EOF data isn't reliable and mostly useless in practice.