|
|
Home » Developing U++ » UppHub » Protect package - A starting copy protection system
|
|
Re: Protect package - A starting copy protection system [message #31909 is a reply to message #31086] |
Wed, 06 April 2011 10:02 |
Tom1
Messages: 1212 Registered: March 2007
|
Senior Contributor |
|
|
Hi Max,
I tried the ProtectTest package on Windows. It worked beautifully when compiled with MSC9 but crashed when compiled with MSC10. Can you help?
(Also it turns out that 64-bit versions can not be compiled at all. However, this is not currently especially important for me.)
Best regards,
Tom
|
|
|
Re: Protect package - A starting copy protection system [message #31910 is a reply to message #31909] |
Wed, 06 April 2011 13:49 |
mdelfede
Messages: 1307 Registered: September 2007
|
Ultimate Contributor |
|
|
Tom1 wrote on Wed, 06 April 2011 10:02 | Hi Max,
I tried the ProtectTest package on Windows. It worked beautifully when compiled with MSC9 but crashed when compiled with MSC10. Can you help?
(Also it turns out that 64-bit versions can not be compiled at all. However, this is not currently especially important for me.)
Best regards,
Tom
|
Hi Tom,
I've just tested it and developed on windows32, MSC9 and on gcc (should work on both 32 and 64 bit of gcc).
The code is STRONGLY dependent on compiler's optimizations, so it's not easy to make it generic.
I've no time right now to test with MSC10, you can do it looking at the generated code; it's not so easy, indeed.
I had the same prolem with GCC in unoptimized vs. optimized mode; on latter the compiler rearranges the code.
On MSC9 there was no difference between optimized and un-optimized; probably MSC10 does it better.
Try to disable optimizations; if it works, you'll have an hint !
Ciao
Max
|
|
|
Re: Protect package - A starting copy protection system [message #31914 is a reply to message #31910] |
Wed, 06 April 2011 15:23 |
Tom1
Messages: 1212 Registered: March 2007
|
Senior Contributor |
|
|
Max,
It turns out disabling optimizations on MSC10 does not help in any way. (Maybe you can take a look at it sometime in the future??)
Now, I have a question: After reading the Protect documentation I was left with the impression that OBFUSCATE_START_FUNC and OBFUSCATE_END_FUNC should surround the code used to obtain the key in order to hide the key retrieval details. Well, I tried this modification with the ProtectTest sample application:
String GetKey(void)
{
OBFUSCATE_START_FUNC;
String key(ScanHexString("AABBCCDDEEFF00112233445566778899"));
OBFUSCATE_END_FUNC;
return key;
}
... and I got a crash. So, I must have misunderstood something vital. Can you tell me what did I do wrong here?
Best regards,
Tom
|
|
|
|
Re: Protect package - A starting copy protection system [message #31923 is a reply to message #31919] |
Thu, 07 April 2011 14:55 |
Tom1
Messages: 1212 Registered: March 2007
|
Senior Contributor |
|
|
Yes, with MSC9.
I kind of found a way around though: First I read the key using obfuscation and store it in a static String variable. Then Decrypt() uses that variable directly when calling PROTECT_DECRYPT(). Then again, I'm not sure if this is really a safe way to do this...(?)
// Tom
|
|
|
Re: Protect package - A starting copy protection system [message #32778 is a reply to message #31923] |
Wed, 08 June 2011 10:08 |
Tom1
Messages: 1212 Registered: March 2007
|
Senior Contributor |
|
|
Hi Max,
Do you have plans to make the Protect package work on MSC9x64 or MSC10x64? I found out that inline assembly is not supported by Microsoft compilers on x64 architecture, so this may not be easy to solve.
(My application runs out of memory at around 2.4 GB data allocation even with /LARGEADDRESSAWARE linker option, so I need to switch to x64 platform for that app, but still need Protect to work.)
Best regards,
Tom
|
|
|
Re: Protect package - A starting copy protection system [message #32779 is a reply to message #32778] |
Wed, 08 June 2011 10:11 |
mdelfede
Messages: 1307 Registered: September 2007
|
Ultimate Contributor |
|
|
Hmmmmm... I've still not tested MSC9/10 on 64 bit, but if they don't support assembly, we can't do anything about it.
Self decrypting code do need inline assembly.
The only thing I can think about would be to make some modules as 32 bit executables protected with protect and spawned by main app.
Not a very nice solution indeed.....
Max
Edit: thinking about it, it would be maybe possible to write a separate assembly routine which modify caller code, but that would require quite a bit of work.... If some assembly guru wants to jump into, he's wellcome
[Updated on: Wed, 08 June 2011 10:15] Report message to a moderator
|
|
|
|
Re: Protect package - A starting copy protection system [message #35014 is a reply to message #34092] |
Wed, 28 December 2011 10:54 |
|
ratah
Messages: 107 Registered: July 2010
|
Experienced Member |
|
|
Hello everybody,
I try to use Protect package with MingW on Windows but it seems it does not support assembler.
Here is my code
/*#include <CtrlLib/CtrlLib.h>
#include <Protect/Protect.h>
using namespace Upp;
void decrypt(byte *start, size_t len, byte const *nonce, size_t nonceLen)
{
return PROTECT_DECRYPT( start, len, "\xAA\xBB\xCC\xDD\xEE\xFF\x00\11\x22\x33\x44\x55\x66\x77\x88\x99", nonce, nonceLen);
}
void MyEncryptedFunction()
{
PROTECT_START_FUNC(decrypt);
PromptOK("solved");
PROTECT_END_FUNC;
}
GUI_APP_MAIN
{
ON_PROTECT_BAD_KEY(decrypt)
{
PromptOK("License error");
exit(1);
}
MyEncryptedFunction();
}
*/
#include <CtrlLib/CtrlLib.h>
#include <Protect/Protect.h>
using namespace Upp;
String GetKey(void)
{
return ScanHexString("AABBCCDDEEFF00112233445566778899");
}
void Decrypt(byte *start, size_t len, byte const *nonce, size_t nonceLen)
{
PROTECT_DECRYPT ( start, len, GetKey(), nonce, nonceLen );
}
double CryptedTest(double d, double e)
{
PROTECT_START_FUNC(Decrypt);
double f;
f = d * e;
PromptOK("CryptedTest DECRYPTED SUCCESFULLY!!!");
return 2 * f + e;
PROTECT_END_FUNC;
}
double ObfuscatedTest(double d, double e)
{
// WARNING -- DON'T PUT ANY return STATEMENT BETWEEN
// OBFUSCATE_START and OBFUSCATE_END
OBFUSCATE_START_FUNC;
double f;
f = d * e;
PromptOK("ObfuscatedTest DEOBFUSCATED SUCCESFULLY!!!");
OBFUSCATE_END_FUNC;
return 2 * f + e;
}
GUI_APP_MAIN
{
ON_PROTECT_BAD_KEY(Decrypt)
{
bool res = PromptYesNo("Bad key !!&Do you want to continue anyways ?");
if(!res)
exit(0);
}
double d = CryptedTest(3, 4);
d = ObfuscatedTest(3, 4);
d = ObfuscatedTest(3, 4);
PromptOK("FINISHED OK !!");
}
Here is the error
Do you have an idea?
Thanks and Best wishes for the New year 2012.
Ratah
-
Attachment: bug.jpg
(Size: 402.13KB, Downloaded 713 times)
|
|
|
|
|
|
Re: Protect package - A starting copy protection system [message #49903 is a reply to message #49900] |
Sat, 02 June 2018 12:34 |
mdelfede
Messages: 1307 Registered: September 2007
|
Ultimate Contributor |
|
|
By now I'm testing first code on GCC, 64 bit, both in debug and release mode and it works perfectly.
The only caveat is that I can't set a different encrypting NONCE for each function as before, because there's no
simple way to embed data into the code as I coud do in assembly.
Not a big concern, just a bit less secure and probably crackable if you have a ton of encrypted functions, but
strong enough for most purposes.
I'm fixing the obfuscation part, then I'll go to windows.
It has NO inline assembly code inside, and there are just 2 conditions:
- encrypted code should contain NO data (which AFAIK is always true)
- the compiler should not re-arrange the code so that marked end comes before marked start. This should also be
always true but, if not, the encryptor will notice and signal it.
Code is encrypted only on its first byte of each instruction; remainig bytes and data fields are left unchanged.
This is more than enough to make the program crash if incorrectly decrypted, and avoids fiddling with fields changed
by loader (as far addresses, for example).
It should work on any X86 / X86-64 compiler with minor changes.
|
|
|
|
|
|
|
|
Goto Forum:
Current Time: Thu Apr 25 19:31:19 CEST 2024
Total time taken to generate the page: 0.03426 seconds
|
|
|