How-To write an exe packer in VB ?

[u.jerks]

Well, first... an exe packer/wrapper is a program that packs an exe file in a third party exe. Just like zip files with the exception that the archive will be an exe file and that the third party exe can automatically extract/unpack the first (packed file) to memory (RAM) without even extracting it to disk first. If you don't understand a word of what i am saying then just go to www.aspack.com and find out! (aspack is a very famous and powerful exe wrapper/packer but it is written in delphi).

The whole meaning of this post is to brainstorm about designing an exe wrapper/packer in VB! It may be impossible to write one in VB but we are gonna find out soon enough! (i hope!). I have thought of lots of ideas but the most of them suck so i will explain the best one till now.

exe(1) = exe that we wanna pack in our packer

exe(2) = our packer

So, my thinking is to open the exe(1) in binary... read all the bytes and add them in an array... afterwards we will use a compression methode on the array, (so we can minimize the size of our data) and then add the compressed array in exe(2). So far so good! Now exe(2) after execution must read the added compressed data from its self; load them up in an array... decompress the data and write them to memory (RAM). My difficulty was (and still is :huh: ) - how - can we write it to memory and executing afterwards! (cause we wanna execute it after extraction) anyway, i have ended to the solution to use an api call to write our decompressed array to memory. ("Private Declare Function WriteProcessMemory Lib "kernel32" Alias "WriteProcessMemory" (ByVal hProcess As Long, lpBaseAddress As Any, lpBuffer As Any, ByVal nSize As Long, lpNumberOfBytesWritten As Long) As Long

"). But the question is... would that work? I've been too busy lately to try this and of course TOO lazy! :shifty:

I hope we can end up at a possible solution of this "exe wrapper/packer" soon! or we can just admit that VB is not able to write such programs! but I'm almost 100% sure that there - must - be a way to write this proggie in VB.

By the way... all the exe wrappers/packers I've seen or heard ar written in delphi, assembly or C/C++.

cheerz,

-thelord

[James Rose]

The first issue that I (as a pro VB dev for the past dozen years) have is that it basically impossible to send out JUST a VB EXE - it tends to need associated DLLs, etc. To create a package program the deal is that it, usually, needs to run without any associations.

Not to be a naysayer... just want to get that point out there. I'd be happy if someone can prove me wrong. (not like I've never been wrong before :blush: )

[u.jerks]

Thanks for the remark jameswjrose, but I already knew that! my goal is to write such a proggie to protect any other of my applications from reverse engineering. I don't want to write a packer and distribute it... I just wanna make a more safe protection for my proggies. Not that I care that much but I consider this as a challenge.

cheerz,

-thelord

[James Rose]

Ah, I miss construde your point. My appologies.

Have you even tried Decompilers? More often than not they suck (big time!) It seems a big deal to go to this length to protect your intelectual property. Simply copyrighting your software gives you the legal protection you'll need if someone does steal it.

I know, that wont help when/if someone does in the effect that now you have to take time/money and other resources to deal with this issue...

Again, not to be a naysayer... just trying to make sure you're putting your efforts where they can be of best use. I'll think about code-encryption issues and the like over the next few days and see if I can get anything back to you.

[u.jerks]

Well, I know about decompilers but I was not able to find one for VB6. I've been looking for more than a year and still no result! So I guess there must not exist one for VB6 and if it does then its waayy too difficult to find or they cost toooo much money! :pinch: And Copyrighting your software is not enough! In conclusion... we are screwed unless we use a more powerful way to protect our apps from being reversed angineered! Aspack is a greeaat choice to protect your apps although older versions have been cracked, but in my opinion having your own packer with your own encryptions compression types and lots of other protections would be more difficult for crackers cause it will not be a common external protection.

cheerz,

-thelord

[MaxMouse]

Hi,

Came across this thread while i was trying to write protection from

reverse engineering, since then i have written an application that does

just that :)

Files & Executables:

You can pretty much just append data to any executable file.

For Example:

Public function AppendExec(ExePath as string, FilePath as string) as boolean
on error goto Err

open ExePath for binary access write as #1
open FilePath for binary access read as #2
put 1, filelen(exepath), "[START]" & input(lof(2),1)
close #1
close #2

AppendExec = True
Exit function
Err:
AppendExec = False
End Function

with that in mind we now have a method of inserting files into

executables in a retrievable manner.

Public function ReadAttatched(Path as string) as string
Dim DTA as string

open path for binary access read as #1
DTA = input(lof(1),1)
close #1

ReadAttatched = mid(DTA, instr(DTA, "[START]") + 8, len(DTA))
end function

IE:

ReadAttatched app.path & "\" & app.exename & ".exe"

Now, the data returned by ReadAttatched could be compressed, encrypted or whatever, you just need to undo whatever changes you made to the data before you can do anything with it, in my project the data was compressed first using an LZW algorythm and then encrypted using a cipher based on the Sandorf Cipher (SCX) which i designed myself.

The Hard Part:

Ok so you have your file(s) in a variable, say for arguments sake its just a single executable, what do you do with it? well you could just dump it to a file and shell it, but then it'd be in "The Wild" again and packing it into your own executable was pointless, so we need to load it directly into memory (im not going to release source for this, as it can be used maliciously)

You load it into memory by starting another instance of your application with the thread frozen, you then over-write the new threads memory with the image of the executable in the variable and finaly resume the thread.

You now have an executable running in memory that doesn't exist on the hard drive and windows thinks the executable's path is that of your application.

Further Protection Ideas:

You could beef up security by adding debug protection, there are several ways to do this, including the win api IsDebuggerPresent, i have a few ideas of my own.

Enumerate hWnds:

Loop through all window handles and get their window titles, if they contain Soft Ice or whatever then thats a debugger, take appropriate action (Close Softice, end your application, end your app and make it delete itself)

Enumerate Process Memory Space:

Get all process ID's (System snapshot) and read their process memory space, if it contains Soft Ice or any other string associated with debugging or disassembling take appropriate action.

You could also scan your own process to check if any key functions have been changed.

Junk math algorythms & Junk function names:

Create a low resource impact math algorythm with many facets, with a function name like "IsKeyvalid" or "Generate Key" it'll waste the time of anyone trying to crack a key within your application, they will be trying to figure out where the junk math takes them, and what its use is within the application, when infact its just pointless, if you do a good job of this it could put all but the most hardy crackers off.

Break-point detection:

When a debugger is attatched to your process and a break-point is set, certain functions may take longer, but its not a good idea to measure this within your application, so we could link two files together and use them to monitor eachother

Security Application + Our application hook together using Memory Mapped files for communication, they then ask eachother "Questions" and time the response.

Security Application: "Are you ok?"

Our application: "Yes thanks, how about you?"

Security Application: "I'm Fine, and you?"

etc etc.

Obviously the questions wouldn't be plain text like that but unique encrypted strings based on changing data, like the time, or X & Y positions of the mouse.

If the security application doesn't respond within say one second then its being debugged and is currently within a break-point so take appropriate action, the same with our application if it doesn't respond its within a break point.

This security executable could be contained within our application as a resource, or appended to the end just like all the other files, and extracted and executed at runtime (to make it even harder it could be memory loaded too)

Compilation:

Some debuggers don't like p-code, so compile it in that, you could also use some compiler strings to change certain things when the executable is created, at least it'll look weird and confusing to anyone snooping around, at most it'll crash the debugger / disassembler.

I used all of that and now i can create packaged Compressed + Encrypted executables which are impossible to disassemble, debug or view in any way, yet execute perfectly normaly.

Hope this helps

Max

[Andareed]

If it can be executed, it's not impossible to break.

[Ultra Frosty]

The actual execution stub is usually in assembly because of size and speed, and because you can directly execute memory in assembly.

You can write the excryption code in VB, and if you follow the PE file format correctly, you could rebuild the PE file correctly, but it is probably more painful than you think. PM me if you want some help.

Edited January 21, 2006 by b0b

[MaxMouse]

Actually, my stub is written in plain VB infact all of the methods i posted above are written in VB for my project :)

Although if you wanted to use InlineASM or C in your VB IDE or create true StdCall DLL's with VB instead of ActiveX Hybrids have a look at ThunderASM :)

Strange enough, over the years iv'e managed to do all sorts of things with VB, Port it directly to PalmOS, Symbian and even Linux with various addins, and tweaks. Now writing asm directly into VB Functions EG:

Public function SomeAsmCode(VarHere as string) as string
' asm ' .586
' asm '
' asm ' mov eax, 10
end function

seems the way to go, they even managed to hijack vb's left, right, instr, mid etc etc functions and code ASM counterparts which are much faster, aswell as using VB's IntelliType when coding ASM in the IDE.

Anyway thats off topic.

Andareed quite correct it probably isn't impossible to break, but its deffinately not easy, you cannot change core functions in memory (they are checked) you do not have access to the executable on disk (Compressed and Encrypted, neither algorythm is documented) and you cannot (easily) debug the stub as it is protected by various methods, and if you did manage to strap a debugger two it (and somehow defeat/emulate the encrypted comms between the SecExe and the Stub loader you'd get lost inside garbage functions)

It'd be a pain-in-the-proverbial to do anything meaningfull too with any reverse engineering applications, it will never be "Impossible" but you get the idea.

the point is, its more than possible (iv'e done it) to create a packer/loader, with some very nice security features built into it using no more than VB.

Regards

Max

Edited January 23, 2006 by MaxMouse