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: 1319
Registered: March 2007
|
Ultimate 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: 1310
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: 1319
Registered: March 2007
|
Ultimate 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: 1319
Registered: March 2007
|
Ultimate 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: 1319
Registered: March 2007
|
Ultimate 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: 1310
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 1171 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: 1310
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Protect package - A starting copy protection system [message #49918 is a reply to message #49917] |
Tue, 05 June 2018 20:22 |
Tom1
Messages: 1319
Registered: March 2007
|
Ultimate Contributor |
|
|
Sure! I'll try it tomorrow!
I have two or three different MSC compilers (x86 and x64) installed along with a quite recent nightly upp build, so I can get some useful coverage on the test. Some documentation on the changes required on my code would be useful too. Do you have working ProtectTest and ProtectEncrypt packages available for easy testing?
Best regards,
Tom
|
|
|
|
| Re: Protect package - A starting copy protection system [message #49920 is a reply to message #49918] |
Tue, 05 June 2018 20:32 |
mdelfede
Messages: 1310
Registered: September 2007
|
Ultimate Contributor |
|
|
Tom1 wrote on Tue, 05 June 2018 20:22Sure! I'll try it tomorrow!
Do you have working ProtectTest and ProtectEncrypt packages available for easy testing?
Tom
Of course!
I'll attach here the 3 packages.
Let me know if it's all ok for you... by now I'm trying to semi-fix the old web package, as the protect server and my paypal IPN server both rely on it 
BTW, if you know some other ScgiServer implementation that doesn't rely on old web package you're more than wellcome...
(docs are NOT updated!!!)
[Updated on: Tue, 05 June 2018 20:33] Report message to a moderator |
|
|
|
|
|
|
|
| Re: Protect package - A starting copy protection system [message #49928 is a reply to message #49925] |
Wed, 06 June 2018 08:31 |
Tom1
Messages: 1319
Registered: March 2007
|
Ultimate Contributor |
|
|
Hi Max,
Here are the results from testing Release builds with different compilers:
Without PROTECT flag:
2 * X = 10
2 * X = 20
S is : Hello
S is : Massimo
<--- Finished in (0:01.40), exitcode: 3221225477 --->
With PROTECT flag:
2 * X = 10
2 * X = 20
S is : Hello
<--- Finished in (0:12.26), exitcode: 3221225477 --->
For protected version, the ProtectTest.log file looks like this:
* C:\upp-11979\out\MyApps\MSBT17x64.Protect\ProtectTest.exe 06.06.2018 09:27:24, user: tom
START DECRYPT
JMP NOT FOUND
START DECRYPT
JMP NOT FOUND
START DE-OBFUSCATE
JMP NOT FOUND
START OBFUSCATE
1. On protected version "S is : Massimo" did not print out.
2. Neither 32-bit nor 64-bit version printed out the encrypted data.
3. Please note the 12 second execution time on protected version. It started out fast but took quite a while to complete.
The behavior was exactly the same with MSVS15, MSVS15x64, MSVS17, MSVS17x64, MSBT17 and MSBT17x64.
I think obfuscation needs some tuning as well as encrypted data processing.
In addition to present-day compiler and U++ support, I'm especially pleased to see that the 64-bit variant is now emerging! Good work Max!
Thanks and best regards,
Tom
Update: The 12 second long execution time was revealed in Task Manager to involve running "Windows Error Reporting"... I guess this is some sort of a crash and Windows 10 calls home immediately.
Update2: Data encryption/decryption works OK. The problem is entirely in obfuscation; When both obfuscated calls are commented out, encrypted data prints out OK and exit code becomes zero.
[Updated on: Wed, 06 June 2018 08:42] Report message to a moderator |
|
|
|
| Re: Protect package - A starting copy protection system [message #49931 is a reply to message #49928] |
Wed, 06 June 2018 09:04 |
mdelfede
Messages: 1310
Registered: September 2007
|
Ultimate Contributor |
|
|
Hi Tom,
I just fixed it for multithreading, but on my application it seems to work good.
BTW, I don't use obfuscation on it, just encryption.
Could you please do a couple of tests for me ?
1) comment out all calls besides the FIRST obfuscated() one
2) run it, check if it runs ok and look at log file
3) de-comment also the SECOND obfuscated() call
4) run it again
I'm attaching here the modified files for MT safe version
EDIT: please enable the PROTECT_DEBUG macro, if it's not enabled. You should get the assembly listing of code being encrypted
inside the log file
EDIT2: without the PROTECT flag the data decryption is obviously disabled, you just get an empty string... maybe I could return the
original string.
-
Attachment: Protect.zip
(Size: 4.36KB, Downloaded 398 times)
[Updated on: Wed, 06 June 2018 09:16] Report message to a moderator |
|
|
|
| Re: Protect package - A starting copy protection system [message #49932 is a reply to message #49931] |
Wed, 06 June 2018 09:30 |
Tom1
Messages: 1319
Registered: March 2007
|
Ultimate Contributor |
|
|
Hi,
First I applied your MT patched files.
Now calling only 'obfuscated("hello");'
S is : Hello
<--- Finished in (0:12.26), exitcode: 3221225477 --->
So it prints out, but crashes on exit. Log looks like this:
* C:\upp-11979\out\MyApps\MSVS17x64.Protect\ProtectTest.exe 06.06.2018 10:21:40, user: tom
START DE-OBFUSCATE
JMP NOT FOUND
START OBFUSCATE
After enabling both obfuscated -calls I still get:
S is : Hello
<--- Finished in (0:12.43), exitcode: 3221225477 --->
And log looks like this:
* C:\upp-11979\out\MyApps\MSVS17x64.Protect\ProtectTest.exe 06.06.2018 10:25:41, user: tom
START DE-OBFUSCATE
JMP NOT FOUND
START OBFUSCATE
So it crashes again when re-obfuscating the code of first call.
Best regards,
Tom
|
|
|
|
|
|
|
|
| Re: Protect package - A starting copy protection system [message #49937 is a reply to message #49934] |
Wed, 06 June 2018 10:12 |
Tom1
Messages: 1319
Registered: March 2007
|
Ultimate Contributor |
|
|
Max,
Here's the log:
* C:\upp-11979\out\MyApps\MSVS17x64.Protect\ProtectTest.exe 06.06.2018 11:10:34, user: tom
START DE-OBFUSCATE
------------------------------
SOME BYTES AROUND HEADER START
-10 - 48
-9 - 8d
-8 - 4c
-7 - 24
-6 - 70
-5 - e8
-4 - fc
-3 - 19
-2 - 03
-1 - 00
00 - e8
01 - f7
02 - 73
03 - 01
04 - 00
05 - e8
06 - f2
07 - 73
08 - 01
09 - 00
10 - e8
11 - ed
12 - 73
13 - 01
14 - 00
15 - e8
16 - e8
17 - 73
18 - 01
19 - 00
------------------------------
JMP NOT FOUND
START OBFUSCATE
Best regards,
Tom
|
|
|
|
|
|
| Re: Protect package - A starting copy protection system [message #49941 is a reply to message #49939] |
Wed, 06 June 2018 11:49 |
mdelfede
Messages: 1310
Registered: September 2007
|
Ultimate Contributor |
|
|
Hi Tom,
here the last Protect files.
It should work in all cases now... when you test it, please take note at the ProtectEncrypt log when you build
the test package. It should show the number of encrypted and obfuscated chunks of code and data.
The problem was (as usual...) the Microsoft linker, that threw away the empty functions in release mode, and also
replaced the last function call in a function with a jmp.
Ciao
Max
EDIT : if it tests ok I'll update it on Bazaar!
-
Attachment: Protect.zip
(Size: 4.60KB, Downloaded 399 times)
[Updated on: Wed, 06 June 2018 11:49] Report message to a moderator |
|
|
|
| Re: Protect package - A starting copy protection system [message #49942 is a reply to message #49941] |
Wed, 06 June 2018 12:16 |
Tom1
Messages: 1319
Registered: March 2007
|
Ultimate Contributor |
|
|
Max,
32-bit is now OK on all my compilers (MSVS15, MSVS17, MSBT17).
However, regardless of compiler, 64-bit executable crashes now immediately. Here's the MSVS17x64 ProtectEncrypt log on TheIDE compiler console:
Linking...
ProtectTest.exe
ENCRYPTION KEY : aabbccddeeff00112233445566778899
LEN:5 e8 b4 26 03 00 call 0x326b9
LEN:3 8d 04 1b lea eax, ptr [ebx+ebx*1]
LEN:4 89 44 24 50 mov dword ptr [esp+0x50], eax
LEN:5 e8 08 2d 00 00 call 0x2d0d
LEN:1 48 dec eax
LEN:2 8b d8 mov ebx, eax
LEN:1 48 dec eax
LEN:6 8d 15 1e 4f 17 00 lea edx, ptr [0x174f1e]
LEN:1 48 dec eax
LEN:2 8b c8 mov ecx, eax
LEN:5 e8 e6 41 00 00 call 0x41eb
LEN:1 48 dec eax
LEN:4 8d 54 24 50 lea edx, ptr [esp+0x50]
LEN:1 48 dec eax
LEN:4 8d 4c 24 28 lea ecx, ptr [esp+0x28]
LEN:5 e8 37 fb ff ff call 0xfffffb3c
LEN:1 48 dec eax
LEN:2 8b d0 mov edx, eax
LEN:4 0f b6 40 0e movzx eax, byte ptr [eax+0xe]
LEN:2 84 c0 test al, al
LEN:2 75 07 jnz 0x9
LEN:1 44 inc esp
LEN:4 0f be 42 0f movsx eax, byte ptr [edx+0xf]
LEN:2 eb 04 jmp 0x6
LEN:1 44 inc esp
LEN:3 8b 42 08 mov eax, dword ptr [edx+0x8]
LEN:2 84 c0 test al, al
LEN:2 74 03 jz 0x5
LEN:1 48 dec eax
LEN:2 8b 12 mov edx, dword ptr [edx]
LEN:1 49 dec ecx
LEN:2 63 f8 arpl ax, di
LEN:1 48 dec eax
LEN:3 8b 4b 18 mov ecx, dword ptr [ebx+0x18]
LEN:1 48 dec eax
LEN:3 8d 04 39 lea eax, ptr [ecx+edi*1]
LEN:1 48 dec eax
LEN:3 3b 43 28 cmp eax, dword ptr [ebx+0x28]
LEN:2 77 0e jnbe 0x10
LEN:1 4c dec esp
LEN:2 8b c7 mov eax, edi
LEN:5 e8 11 76 15 00 call 0x157616
LEN:1 48 dec eax
LEN:3 01 7b 18 add dword ptr [ebx+0x18], edi
LEN:2 eb 09 jmp 0xb
LEN:1 48 dec eax
LEN:2 8b 03 mov eax, dword ptr [ebx]
LEN:1 48 dec eax
LEN:2 8b cb mov ecx, ebx
LEN:2 ff 10 call dword ptr [eax]
LEN:1 90 nop
LEN:5 80 7c 24 36 00 cmp byte ptr [esp+0x36], 0x0
LEN:2 74 0b jz 0xd
LEN:1 48 dec eax
LEN:4 8d 4c 24 28 lea ecx, ptr [esp+0x28]
LEN:5 e8 61 14 00 00 call 0x1466
LEN:1 90 nop
LEN:1 48 dec eax
LEN:6 8d 15 a5 4e 17 00 lea edx, ptr [0x174ea5]
LEN:1 48 dec eax
LEN:2 8b cb mov ecx, ebx
LEN:5 e8 71 41 00 00 call 0x4176
LEN:5 e8 89 25 03 00 call 0x3258e
LEN:5 e8 e4 2b 00 00 call 0x2be9
LEN:1 48 dec eax
LEN:2 8b f8 mov edi, eax
LEN:1 48 dec eax
LEN:6 8d 15 0a 4e 17 00 lea edx, ptr [0x174e0a]
LEN:1 48 dec eax
LEN:2 8b c8 mov ecx, eax
LEN:5 e8 c2 40 00 00 call 0x40c7
LEN:4 0f b6 43 0e movzx eax, byte ptr [ebx+0xe]
LEN:2 84 c0 test al, al
LEN:2 75 07 jnz 0x9
LEN:1 44 inc esp
LEN:4 0f be 43 0f movsx eax, byte ptr [ebx+0xf]
LEN:2 eb 04 jmp 0x6
LEN:1 44 inc esp
LEN:3 8b 43 08 mov eax, dword ptr [ebx+0x8]
LEN:2 84 c0 test al, al
LEN:2 74 03 jz 0x5
LEN:1 48 dec eax
LEN:2 8b 1b mov ebx, dword ptr [ebx]
LEN:1 49 dec ecx
LEN:2 63 f0 arpl ax, si
LEN:1 48 dec eax
LEN:3 8b 4f 18 mov ecx, dword ptr [edi+0x18]
LEN:1 48 dec eax
LEN:3 8d 04 31 lea eax, ptr [ecx+esi*1]
LEN:1 48 dec eax
LEN:2 8b d3 mov edx, ebx
LEN:1 48 dec eax
LEN:3 3b 47 28 cmp eax, dword ptr [edi+0x28]
LEN:2 77 0e jnbe 0x10
LEN:1 4c dec esp
LEN:2 8b c6 mov eax, esi
LEN:5 e8 fc 74 15 00 call 0x157501
LEN:1 48 dec eax
LEN:3 01 77 18 add dword ptr [edi+0x18], esi
LEN:2 eb 08 jmp 0xa
LEN:1 48 dec eax
LEN:2 8b 07 mov eax, dword ptr [edi]
LEN:1 48 dec eax
LEN:2 8b cf mov ecx, edi
LEN:2 ff 10 call dword ptr [eax]
LEN:1 48 dec eax
LEN:6 8d 15 a3 4d 17 00 lea edx, ptr [0x174da3]
LEN:1 48 dec eax
LEN:2 8b cf mov ecx, edi
LEN:5 e8 6f 40 00 00 call 0x4074
ENCRYPT RESULTS:
Code sequences : 1
Data sequences : 2
Obfuscate sequences : 1
C:\upp-11979\out\MyApps\MSVS17x64.Protect\ProtectTest.exe (3476480 B) linked in (0:03.04)
OK. (0:34.67)
The ProtectTest.log looks like this:
* C:\upp-11979\out\MyApps\MSVS17x64.Protect\ProtectTest.exe 06.06.2018 13:06:22, user: tom
START DECRYPT
LEN: 5 - e8 b4 26 03 00 call 0x326b9
LEN: 3 - 8d 04 1b lea eax, ptr [rbx+rbx*1]
LEN: 4 - 89 44 24 50 mov dword ptr [rsp+0x50], eax
LEN: 5 - e8 08 2d 00 00 call 0x2d0d
LEN: 3 - 48 30 d8 xor al, bl
LEN: 1 - 5e pop rsi
LEN: 1 - 50 push rax
LEN: 2 - 65 1e invalid
LEN: 1 - 6c insb
LEN: 1 - a5 movsd dword ptr [rdi], dword ptr [rsi]
LEN: 3 - 0a 6b 39 or ch, byte ptr [rbx+0x39]
LEN: 1 - 2f invalid
LEN: 1 - fc cld
LEN: 1 - 54 push rsp
LEN: 5 - b8 00 00 af 93 mov eax, 0x93af0000
LEN: 5 - 2d 24 50 fa 74 sub eax, 0x74fa5024
LEN: 2 - b0 24 mov al, 0x24
LEN: 5 - bd 91 37 fb ff mov ebp, 0xfffb3791
LEN: 2 - 70 b4 jo 0xffffffffffffffb6
LEN: 2 - 3b d0 cmp edx, eax
LEN: 1 - 56 push rsi
LEN: 3 - 49 40 0e invalid
LEN: 1 - 5f pop rdi
LEN: 6 - 12 a3 07 bb f1 be adc ah, byte ptr [rbx-0x410e44f9]
LEN: 2 - 8a 0f mov cl, byte ptr [rdi]
LEN: 2 - cd 04 int 0x4
LEN: 3 - f2 7f 42 bnd jnle 0x45
LEN: 2 - 13 fa adc edi, edx
LEN: 1 - f4 hlt
LEN: 5 - 15 03 7c f1 12 adc eax, 0x12f17c03
LEN: 2 - 49 ce invalid
LEN: 1 - 55 push rbp
LEN: 4 - 48 23 4b 18 and rcx, qword ptr [rbx+0x18]
LEN: 2 - 4e aa stosb byte ptr [rdi]
LEN: 1 - aa stosb byte ptr [rdi]
LEN: 1 - 1e invalid
LEN: 2 - 48 f8 clc
LEN: 3 - 80 28 89 sub byte ptr [rax], 0x89
LEN: 3 - f0 34 a8 lock xor al, 0xa8
LEN: 5 - bf 51 11 76 15 mov edi, 0x15761151
LEN: 4 - 23 4c 80 7b and ecx, dword ptr [rax+rax*4+0x7b]
LEN: 9 - a1 69 09 c6 2b 03 3a 92 cb mov eax, dword ptr [0xcb923a032bc60969]
LEN: 1 - 6e outsb
LEN: 1 - 91 xchg ecx, eax
LEN: 2 - 77 7f jnbe 0x81
LEN: 3 - f2 24 36 and al, 0x36
LEN: 9 - a0 b5 0b 87 40 4c 24 28 2d mov al, byte ptr [0x2d28244c40870bb5]
LEN: 3 - 13 14 00 adc edx, dword ptr [rax+rax*1]
LEN: 3 - 19 65 f2 sbb dword ptr [rbp-0xe], esp
LEN: 6 - f3 15 a5 4e 17 00 adc eax, 0x174ea5
LEN: 2 - df 29 fild st, qword ptr [rcx]
LEN: 2 - 34 7d xor al, 0x7d
LEN: 2 - b0 41 mov al, 0x41
LEN: 1 - cf iretd
LEN: 2 - cd eb int 0xeb
BTW: Should I use 64-bit ProtectEncrypt to process 64-bit executables or is it OK to use the same 32-bit version as for 32-bit executables? (Now I used 32-bit ProtectEncrypt for 64-bit executables, but that's the way I did before too.)
BR,
Tom
EDIT: Yes, answering my own question: ProtectEncrypt must be 64-bit version for 64-bit executables. Now it works beautifully!!! Congratulations Max! This is an excellent step forward!!!
[Updated on: Wed, 06 June 2018 12:24] Report message to a moderator |
|
|
|
|
|
| Re: Protect package - A starting copy protection system [message #49944 is a reply to message #49942] |
Wed, 06 June 2018 12:32 |
Tom1
Messages: 1319
Registered: March 2007
|
Ultimate Contributor |
|
|
Max,
One question: Do you know if there is a way to configure the post-link step to use 32-bit ProtectEncrypt for 32-bit executables and 64-bit ProtectEncrypt for 64-bit executables? WIN64 flag does not seem to work for that purpose. (Tried to add separate post-link steps to run correct ProtectEncrypt.exe)
Thanks and best regards,
Tom
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Protect package - A starting copy protection system [message #49950 is a reply to message #49948] |
Wed, 06 June 2018 13:32 |
Tom1
Messages: 1319
Registered: March 2007
|
Ultimate Contributor |
|
|
Hi Max,
I have tried to update Protect on one of my own applications and it seems the ProtectEncrypt gets in trouble somehow.
Is it now forbidden to return; between PROTECT_START_FUNC and PROTECT_END_FUNC?
I recall it was only forbidden in OBFUSCATE before.
Best regards,
Tom
UPDATE: I removed all return;s from between PROTECT_START_FUNC and PROTECT_END_FUNC and now it gets processed properly.
UPDATE2: There is still something strange going on with OBFUSCATE. I replaced all OBFUSCATEs with PROTECT and then it works. This is only true with my own software. The ProtectTest works with both.
[Updated on: Wed, 06 June 2018 14:24] Report message to a moderator |
|
|
|
Goto Forum:
Current Time: Mon Apr 27 00:06:02 GMT+2 2026
Total time taken to generate the page: 0.02664 seconds
|
U++ framework
Search
Help
Members
Register
Login
Home
