|
|
Home » Developing U++ » U++ Developers corner » Considering different approach to Win32 release
Re: Considering different approach to Win32 release [message #45306 is a reply to message #45304] |
Thu, 29 October 2015 14:17 |
Tom1
Messages: 1216 Registered: March 2007
|
Senior Contributor |
|
|
Hi,
Here's a very tiny portion of the log (mostly filled with "&area ="):
&area = 0x025dc4e4
&area = 0x025dc418
&area = 0x025dc36c
&area = 0x025dc2a0
&area = 0x025dc534
vc = c:/program files (x86)/microsoft visual studio 14.0/vc
bin = c:/program files (x86)/windows kits/8.1/bin/x86
inc =
lib =
vc = c:/program files (x86)/microsoft visual studio 14.0/vc
bin = c:/program files (x86)/windows kits/8.1/bin/x64
inc =
lib =
&area = 0x025dc838
&area = 0x025dc800
&area = 0x025dc7f0
&area = 0x025dc7b4
&area = 0x025dd0a4
Hope this helps...
Best regards,
Tom
|
|
|
|
|
Re: Considering different approach to Win32 release [message #45309 is a reply to message #45308] |
Thu, 29 October 2015 15:04 |
|
mirek
Messages: 13980 Registered: November 2005
|
Ultimate Member |
|
|
Tom1 wrote on Thu, 29 October 2015 14:33I have both C:\Program Files (x86)\Windows Kits\10 (about 490 MB) and C:\Program Files (x86)\Windows Kits\8.1 (about 532 MB).
Tom
Hm, would it be somehow possible to list all dirs/files in ..Kits\10, recursively with subdirs, and post here as attachment? (If not, I will ask about specific files, but that will take longer...)
Mirek
[Updated on: Thu, 29 October 2015 15:04] Report message to a moderator
|
|
|
|
|
|
|
Re: Considering different approach to Win32 release [message #45315 is a reply to message #45314] |
Thu, 29 October 2015 18:18 |
Tom1
Messages: 1216 Registered: March 2007
|
Senior Contributor |
|
|
Hi Mirek,
Thanks, I will try it tomorrow when back at the office.
I have not explicitly installed SDK 10 for sure. What I have, came with Visual studio community 2015. I can't check it here, but I have a strong feeling that I just installed the "Programming Languages > Visual C++ > Common Tools for Visual C++ 2015", which gives a tip: "Tools for creating Windows applications using the Visual Studio 2015 Visual C++ compiler toolset (v140). Also includes the Visual C++ 2015 libraries and project templates for Windows Desktop development."
Should I have selected something additional in order to make it work? Could you list the minimum set of items required for U++. Or is SDK 10 a separate download somewhere? If so, could you post a link to that?
Best regards,
Tom
|
|
|
Re: Considering different approach to Win32 release [message #45321 is a reply to message #45315] |
Thu, 29 October 2015 20:16 |
|
mirek
Messages: 13980 Registered: November 2005
|
Ultimate Member |
|
|
Tom1 wrote on Thu, 29 October 2015 18:18Hi Mirek,
Thanks, I will try it tomorrow when back at the office.
I have not explicitly installed SDK 10 for sure. What I have, came with Visual studio community 2015. I can't check it here, but I have a strong feeling that I just installed the "Programming Languages > Visual C++ > Common Tools for Visual C++ 2015", which gives a tip: "Tools for creating Windows applications using the Visual Studio 2015 Visual C++ compiler toolset (v140). Also includes the Visual C++ 2015 libraries and project templates for Windows Desktop development."
Should I have selected something additional in order to make it work? Could you list the minimum set of items required for U++. Or is SDK 10 a separate download somewhere? If so, could you post a link to that?
Best regards,
Tom
I wish I knew
There seems to be separate SDK here:
https://dev.windows.com/en-us/downloads/windows-10-sdk
Frankly, it is some time since I have installed 2015, not sure whether I had installed this separately or not
|
|
|
|
|
Re: Considering different approach to Win32 release [message #45328 is a reply to message #45321] |
Fri, 30 October 2015 14:39 |
Tom1
Messages: 1216 Registered: March 2007
|
Senior Contributor |
|
|
Hi,
I tried with 9114 with not much luck. It did not detect MSC15.
I installed step-by-step more features from Visual Studio Community 2015 until after installing "Windows and Web Development > Universal Windows App Development Tools > Tools (1.1.1) and Windows SDK (10.0.10240)" TheIDE finally found MSC15 and MSC15x64.
Compiling ProtectTest on MSC15 (32bit) succeeds, but running results in message "Bad key !!&Do you want to continue anyways ?", which is pretty strange since the key is correct and intact. Does this work correctly on your machine?
EDIT: In fact many times the result is 'crash on start'. Seems a bit unstable behavior -- how is that possible?
Best regards,
Tom
[Updated on: Fri, 30 October 2015 15:20] Report message to a moderator
|
|
|
|
Re: Considering different approach to Win32 release [message #45330 is a reply to message #45329] |
Fri, 30 October 2015 17:51 |
Tom1
Messages: 1216 Registered: March 2007
|
Senior Contributor |
|
|
Hi,
Yes, absolutely. Of course it should reject a partial/non-functional SDK. And now that I actually have the SDK, that part works well. ☺
The edit belongs to ProtectTest. This is the last big issue. Wonder if clang could have anything to offer here on the Windows side yet.
Best regards,
Tom
|
|
|
Re: Considering different approach to Win32 release [message #45374 is a reply to message #45330] |
Mon, 02 November 2015 17:17 |
|
mirek
Messages: 13980 Registered: November 2005
|
Ultimate Member |
|
|
OK, so I have digged deep into the protect and found the problem...
...well, the problem is that it cannot work the way it is designed...
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;
}
The problem here is that ProtectEncrypt absolutely ignores any linker fixups. This means that literal string constant in PromptOK gets encrypted 'raw'. Then, when program is run, .exe loader relocates *encrypted data*, and they get decrypted only after relocation, resulting in wrong address (that is why it crashes) and possibly broken decryption.
So, for now, if you need to use Protect, the only code it might be able to handle is the one that does not reference static data or other functions.
|
|
|
|
Re: Considering different approach to Win32 release [message #45376 is a reply to message #45156] |
Mon, 02 November 2015 18:10 |
mdelfede
Messages: 1307 Registered: September 2007
|
Ultimate Contributor |
|
|
mhhhhh... I don't remember all the work done, but IIRC at least up to MSC9 the linker fixups were not an issue.... or I never stumbled on them, and I have quite big functions encrypted in my app, which of course access other functions too.
Probably up to MSC9 the compiler/linker insert relative addressing and do not need fixups, ant that changed from version 10 upwards, I don't know.
Anyways, fixing such an issue is not trivial at all, if even possible.
The encrypter now do its job on executable on disk and the decrypter does it in memory when the fixups are (wrongly) applied, so there's no simple solution other than rethink the whole stuff.
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.
Anyways, the package doesn't work either on 64 bit M$ compilers, which do not support online assembly.
So, I guess for now the package will stay as it is.... I'm using it on my app, and I'll stay with MSC9 too, for now, or for linux compilers which up to now behaves good with it.
For a more "professional" solution I'd need monthes to code it, and have no time now
|
|
|
Re: Considering different approach to Win32 release [message #45382 is a reply to message #45376] |
Tue, 03 November 2015 09:27 |
Tom1
Messages: 1216 Registered: March 2007
|
Senior Contributor |
|
|
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.
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?
Best regards,
Tom
|
|
|
|
Goto Forum:
Current Time: Wed May 15 05:26:11 CEST 2024
Total time taken to generate the page: 0.02801 seconds
|
|
|