How Do I Password Protect (or Encrypt) My EXE Files to Prevent Decompilation...?

[bm3racer]

Basically, I just want to password protect my exe's using some form of encryption (like MoleBox does) BUT I do not want my users to be password-prompted to be able to use the software. To re-explain, I do not want to LOCK my exe from use using a password (which is what the _password.dll extension does I believe), I just want the internals of my EXE encrypted (also known as Obfuscation, Obfuscating or using an Obfuscator).

There really was not even a post (I registered and searched using relevant terms) on this forum or on the web. There are references to cipher1.dll and cipher2.dll but there is rarely even a description of what it does and how it works and if it even serves the purpose of an Obfuscator...?

If someone could just tell me what I need to do to be able to do this using PECompact, then I would be eternally grateful. Because, if I use PECompact for compression, other applications are not able to encrypt my exe because it's been modified by PEC, and if I try to do it the other way around, using another app to encrypt EXE then PEC for compression, I imagine PEC would also reject this modified EXE... for that reason, one application needs to do BOTH things, otherwise each application prevents the other application from doing the second part of the job. My needs are simple, Compression & Encryption of EXE using one program only, I am hoping it would be PEC - can this be done? Also, I am maintaining a legacy EXE here, it's written in Visual Basic 6.0 SP6 (latest VB6 version/release).

I think all I really need to know is what extensions I need to run and in what order, then I am good to go...? Here are my list of options in the Codecs section, where lzma2.dll is selected by default.

I have attached this image, not sure how to make it display in the message, but I'm sure it would be attached for your viewing.

Thank you, any replies are welcome.

[Jeremy Collake]

I apologize for the lack of documentation. Probably a decade ago now we had a forum full of PECompact related stuff, but it got wiped through some incidents and .. well, it's gone.

There really was not even a post (I registered and searched using relevant terms) on this forum or on the web. There are references to cipher1.dll and cipher2.dll but there is rarely even a description of what it does and how it works and if it even serves the purpose of an Obfuscator...?

These both are obfuscators. Each is a slightly different obfuscation algorithm. They can be used together (chained) or independently. Just be SURE not to obfuscate BEFORE compression, else the compression ratio may be hurt.

PECompact can sometimes compress already compressed or encrypted modules, but be sure to use JCALG1 as the compressor, as it handles uncompressible data very well. HOWEVER, it depends greatly on what the first compressor/encryptor does, so the success of an operation like that varies.

Of course, compression inherently obfuscates things to a large degree, though in some cases a bit of plaintext is visible here and there.

I'm not sure if this answers your question or not ... Please continue on and ask any specific question and I'll be as helpful as I can, as I move as 100mph ;p.

[bm3racer]

Hello Jeremy,

First I wanted to thank you for your quick response and healthy interest in answering my question (I'm sure many others would benefit from this thread as well). Secondly, I wanted to say that the exe file size of the output from your exe packaging tool is the best I’ve ever seen. Normally, other apps that encrypt add anywhere between 50KB's to 1.2MB's to the output exe, defeating the purpose of packaging for many scenarios. I noticed the cipher1 and cipher2 doesn't add much to the final exe to decrypt the exe at all (I'm assuming its decrypted in memory only). This factor alone nails it for me, in terms of choosing PECompact over anything else. I wanted to say, great work for the detail to attention provided in your application, it's perfect, and I understand you've taken it to this level because a packager at this level does not really exist. So, just wanted to give props where due.

Now, on to my follow-up question, I wanted to ask you, if I package in this particular order, would all of my strings (including strings that can uniquely identify my application) be encrypted?

Codec/Processing Order Proposed:

lmza2
cipher1
cipher2

If I add JCALG1 to the end (after cipher2) it errors out, I tried this on two different VB6 Exe's (the program/code being the same), one Exe was compiled to native code and the other Exe compiled to p-code (same project/program/code). So, JCALG1 (when added anywhere) creates an error. However, I think you meant to tell me to use JCALG1 _IF_ I compress/encrypt my Exe's with a different program, to use JCALG1 on the already compressed and/or encrypted Exe done with another Exe packager, so that would be use of JCALG1 codec on its own after use with other utility...? Problem with most utilities are the added bytes, some packagers even add the loaders for options that you don't even use or select (ie: adding the binary code/data to output Exe for unused features), some are graceful and will only add the loaders/interpreters for the options that you are actively using.

On to my actual question, if I compress & cipher in the order above, what will be protected and how much protection will it receive? Basically, will my VB6 Exe's function names, constant names, variable names or other strings be visible? Will people be able to decompile my Exe or deduce or produce anything useful out of it? I may be using p-code to production release, and I understand this is much easier to decompile and reverse engineer, so this is why it is especially important to me to have the Exe protected (encrypted & compressed). Basically, I use the "uniquely identifiable string" yard stick as a way to measure the effectiveness of an Exe encrypter, since the less uniquely identifiable strings that exist, the more difficult it is for anyone (or anything) to get useful information out of it. If I compress & encrypt in order stated above, how many or what sort of uniquely identifiable strings will remain? By "uniquely identifiable strings" I really mean anything that can be uniquely tied to my application, as opposed to generic strings which may exist in all/most Exe's and will only give away what language the Exe is written in (as opposed to the specific things I'm using/doing, which is what would be given away if it's a uniquely identifiable string). Also, regarding generic string, how many or what sort of generic strings would/could exist if I use the compression & encryption order above? Are the headers encrypted etc., or is the .data sections the only parts that are encrypted?

Additionally, you mentioned compression being an ad-hoc encrypter, but compression is de-compressible if compression method is visible in header information, how difficult would it be for someone to decompress a compressed Exe if we just use lzma2? Also, since we use lzma2, cipher1 & cipher2 in the order above, does this mean the compression symbols/data (the symbols produced by compression of the Exe binary data) are also encrypted? So, to even have the opportunity to attempt decompressing the Exe, they would have to decrypt it first...? Which brings me back to the first part of this question, how effective is lzma2 compression as a tool to encrypt data in PECompact? Is compression method known to crackers or decompilers via its header data or anything?

Finally, since I am not aware what most of these codecs do and how they do it, in order for me to protect my VB6 Exe's, which are compiled to p-code (I'm compiling to p-code mainly because its smaller), what codecs should I use and in what order (especially given that p-code binaries are much less protected/secure than native code compiled Exe’s in VB6)? If there is an order or method other than cipher1 & cipher2, please do tell me, assuming decompression & decryption time is not of importance to me (and it isn't), what codecs or extensions should I use and in what order to provide me the best possible protection against people trying to figure things out. Most importantly decompilation, then uniquely identifiable strings, then generic strings. These are the things I want protection for, so what codecs or methods (or even options from your options panel on PECompact) should I use and in what order to provide the best encryption/protection for as much of my Exe as possible (this is most important) while of secondary relevance, to keep my Exe small where possible (but without compromising protection for smaller file size, as protection is most important, and file size is completely secondary to protection)...?

Thank you for reading, really, if you don't have enough time to answer these questions, the most important question for me is the last one. If you could give me the order of the codecs to use (and which codecs) for greatest protection, and let me know how much protection your proposed setup would provide (ie: what portion of the Exe will be protected, all, most, some/partial etc... and how effective will this protection be, in your opinion) then this would be fantastic, as this is the information I am most interested in and was unable to find on the internet.

Looking forward to speaking to you, and I will let you know how it all turns out if you are interested.

Speak to you soon.

[Jeremy Collake]

The reason for the JCALG1 failure is because the data is so uncompressible. While it can handle uncompressible data, once data is passed through the ciphers they become totally uncompressible and this apparently creates an error condition. With the ordering you have, all strings will be obfuscated in the on disk image, both by the compressor, then by two additional ciphers. Experimentation with PEHideText would be another option as well, if you can recreate the fairly simple decoder (must be linked to your app). I could alternatively provide a DLL, but this makes it very easy to hack the strings you want to hide. The difference with using PEHideText vs not is that your strings also remain encrypted in virtual memory until you go to use them, at which point you decrypt them on demand, then dispose of the decrypted allocation as needed.

The order you have is fine. Always compress first, then you can do whatever afterwards.

PECompact is one of the classic executable compressor, and perhaps the most robust ever created. It does need some maintenance though, and PEBundle needs resurrected - two things I'm working on now based on increased customer interest in packers once again. I also have to add support for the new taggant system to help security software weed out the malware abusers (though a good digital signature history will be about as effective, if not more so). Sadly, any executable, packed or otherwise, without a digital signature that has a good history is prone to false positives. Anyway, point is that the problem of malware authors wanting to use packers to hide their payloads has been dealt with, or is being dealt with, industry wide.

[newuser]

The picture on the first post is missing.

I do need a nice tutorial on this topic, its mention the pecompact related stuff is wipe alongtime ago.
Any way to rebuild its content that is still useful/available?

And two more things,
1)pesuite download link is missing recently.

2)any method to use pesuite contents together with pecompact?

Im not with this kind of stuff, is there a gui for pesuite?

Thank you