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.
