Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » Developing U++ » U++ Developers corner » Considering different approach to Win32 release
Re: Considering different approach to Win32 release [message #45385 is a reply to message #45376] Tue, 03 November 2015 09:52 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
mdelfede wrote on Mon, 02 November 2015 18:10

Or, better said, a possible solution would be to leave fixups unencrypted, but then we'd need a table somewhere to tell decrypter to leave them alone. Not an easy task either, and would entail the complete PE header analysis.


Maybe you could limit crypting only to specific opcodes... I believe that only "absolute address" opcodes are 'dangerous'.

You could use ndisasm for testing (although it is a bit disgusting to use opensource to close the source Smile

Mirek
Re: Considering different approach to Win32 release [message #45386 is a reply to message #45384] Tue, 03 November 2015 11:33 Go to previous messageGo to next message
Tom1
Messages: 1212
Registered: March 2007
Senior Contributor
mirek wrote on Tue, 03 November 2015 10:48
Tom1 wrote on Tue, 03 November 2015 09:27
Hi,

Thanks for your effort on Protect. I can confirm that the last working MS compiler environment is MSC9 32 bit.

Mirek: I just tested 9142 with MSC15 and the updated ProtectTest still crashes on CryptedTest() function. Commenting out the call to CryptedTest() enables the rest of the demo to run correctly. So obfuscation actually works properly even with MSC15 while keyed protection crashes. My wild guess is that obtaining the key is the unwanted static/global reference.


Well, that '2' constant actually seems to be a problem... It gets stored in memory and is loaded.

Quote:

Is it possible to make a decision to keep U++ source code compatible with MSC9 until there is a working replacement for the current Protect package?


I have not changed anything in Protect package(s). Just added a bit to docs.

Mirek


I mean, I wish the entire U++ to be kept MSC9 compatible until Protect can be made to work with current compiler(s) e.g. MSC15. I just want to point out this need for backward compatibility when we are simultaneously talking about eventual switch to C++11, and therefore, MSC15.

Best regards,

Tom
Re: Considering different approach to Win32 release [message #45507 is a reply to message #45386] Wed, 25 November 2015 13:14 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Well, as much as I am in fact sort of uncomfortable about this feature (a little by the mere fact that we have have such copy protection tool, but much more by how it is fragile by definition), I nevertheless continued thinking and digging....

Now here seems to be the function to determine the length of x86 instruction:

http://stackoverflow.com/questions/23788236/get-size-of-asse mbly-instructions/23843450#23843450

Using this, I suggest to encrypt only the FIRST BYTE of each instruction. Should solve the problem...
Re: Considering different approach to Win32 release [message #45510 is a reply to message #45385] Thu, 26 November 2015 09:35 Go to previous message
mdelfede is currently offline  mdelfede
Messages: 1307
Registered: September 2007
Ultimate Contributor
mirek wrote on Tue, 03 November 2015 09:52

.... (although it is a bit disgusting to use opensource to close the source Smile
Mirek


Well, I find it funny, indeed Razz
Anyways, I normally don't like closed source apps, but sometimes is a must....
I have an app that costed me tons of ours to develop and to make it user friendly.
Knowing my country's customers (in building design field) having it opensource would mean zero
money earned for it....

BTW, your way of encrypting only the first byte is not bad. I'll look at it when I've a bit spare time.
I hope it will not require too much code.

Ciao

Massimo
Previous Topic: mingw/gdb troubles
Next Topic: Ideas on U++ as library
Goto Forum:
  


Current Time: Fri Mar 29 12:43:44 CET 2024

Total time taken to generate the page: 0.02288 seconds