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 #45306 is a reply to message #45304] Thu, 29 October 2015 14:17 Go to previous messageGo to next message
Tom1
Messages: 1212
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 #45307 is a reply to message #45306] Thu, 29 October 2015 14:22 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Do you have

C:\Program Files (x86)\Windows Kits/10

folder?

(If not, then it looks like you do not have current SDK installed).

Mirek
Re: Considering different approach to Win32 release [message #45308 is a reply to message #45307] Thu, 29 October 2015 14:33 Go to previous messageGo to next message
Tom1
Messages: 1212
Registered: March 2007
Senior Contributor
I 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

Re: Considering different approach to Win32 release [message #45309 is a reply to message #45308] Thu, 29 October 2015 15:04 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Tom1 wrote on Thu, 29 October 2015 14:33
I 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 #45311 is a reply to message #45309] Thu, 29 October 2015 15:26 Go to previous messageGo to next message
cbpporter is currently offline  cbpporter
Messages: 1401
Registered: September 2007
Ultimate Contributor
This code helped me to correctly find the SDK, but I confess that last time I tried it was on the pre-release VS. Then I saw the single .lib file and decided not to support it Smile.

void TestLib() {
		if (create) {
			if (FindFile(sdk + "\\lib\\*.lib"))
				sdklib = "\\lib";
			if (FindFile(sdk + "\\lib\\x86\\*.lib"))
				sdklib = "\\lib\\x86";
			else if (FindFile(sdk + "\\lib\\win8\\um\\x86\\*.lib"))
				sdklib = "\\lib\\win8\\um\\x86";
			else if (FindFile(sdk + "\\lib\\winv6.3\\um\\x86"))
				sdklib = "\\lib\\winv6.3\\um\\x86";
		}
		if (create64) {
			if (FindFile(sdk + "\\lib\\*.lib"))
				sdklib64 = "\\lib";
			else if (FindFile(sdk + "\\lib\\x64\\*.lib"))
				sdklib64 = "\\lib\\x64";
			else if (FindFile(sdk + "\\lib\\win8\\um\\x64\\*.lib"))
				sdklib64 = "\\lib\\win8\\um\\x64";
			else if (FindFile(sdk + "\\lib\\winv6.3\\um\\x64"))
				sdklib64 = "\\lib\\winv6.3\\um\\x64";
		}
	}


If the lib paths are empty even though apparently the SDK has been found, I ignore it.
Re: Considering different approach to Win32 release [message #45312 is a reply to message #45309] Thu, 29 October 2015 15:48 Go to previous messageGo to next message
Tom1
Messages: 1212
Registered: March 2007
Senior Contributor
Hi,

I think dir /s covers it quite well. Please find attached the listings for both Windows Kits/8.1 and Windows Kits/10.

Best regards,

Tom
  • Attachment: listings.zip
    (Size: 60.00KB, Downloaded 229 times)
Re: Considering different approach to Win32 release [message #45313 is a reply to message #45312] Thu, 29 October 2015 16:45 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Tom1 wrote on Thu, 29 October 2015 15:48
Hi,

I think dir /s covers it quite well. Please find attached the listings for both Windows Kits/8.1 and Windows Kits/10.

Best regards,

Tom


Thanks. I have fixed 'instant setup' for your tree, however, I have a very strong feeling that you really do not have SDK 10 installed: Notice that there e.g. are no win32 system includes anywhere. Only part I can see is standard C library.

Mirek
Re: Considering different approach to Win32 release [message #45314 is a reply to message #45308] Thu, 29 October 2015 16:46 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Tom1 wrote on Thu, 29 October 2015 14:33
I 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



P.S.: Mine ...Kits/10 has 1.8G...
Re: Considering different approach to Win32 release [message #45315 is a reply to message #45314] Thu, 29 October 2015 18:18 Go to previous messageGo to next message
Tom1
Messages: 1212
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 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Tom1 wrote on Thu, 29 October 2015 18:18
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


I wish I knew Smile

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 Sad
Re: Considering different approach to Win32 release [message #45325 is a reply to message #45321] Fri, 30 October 2015 10:13 Go to previous messageGo to next message
cbpporter is currently offline  cbpporter
Messages: 1401
Registered: September 2007
Ultimate Contributor
Great idea with separating the nightly MINGW from the nightly UPP. Now at least one can update in a reasonable time.

So the "porting" to MINGW is done for both my console and GUI apps. The GUI optimal mode one do crash on startup on Windows 7, but otherwise I am fine and running out of the box UPP. Once MINGW is fixed for GUI, I'll use MINGW. But in some early testing, it is a bit slower.

Out of he box except for CodeEditor. But I found a "hack" for it. I copied it over from uppsrc to MyApps and merged my custom changes into it and I'm linking with it. CodeEditor is really great and the bread and butter for one of my GUI apps, the IDE, but it is not exactly customizable, so I was not able to provide general patches for it.

But I do have plans for it. I want to refactor it and instead of having languages and hard coded behavior for each, it will have about 6-7 new flags. A language will set keyword and a combination of flags, allowing CodeEditor to be decoupled from knowing about languages.
Re: Considering different approach to Win32 release [message #45326 is a reply to message #45325] Fri, 30 October 2015 12:17 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
cbpporter wrote on Fri, 30 October 2015 10:13
Great idea with separating the nightly MINGW from the nightly UPP. Now at least one can update in a reasonable time.

So the "porting" to MINGW is done for both my console and GUI apps. The GUI optimal mode one do crash on startup on Windows 7, but otherwise I am fine and running out of the box UPP. Once MINGW is fixed for GUI, I'll use MINGW. But in some early testing, it is a bit slower.


For now, the fix is just replacing -O3 and -Os with -O1...

I consider MINGW just to serve two roles: Ability to test U++ without installing anything else and testing against GCC compiler.

Mirek
Re: Considering different approach to Win32 release [message #45328 is a reply to message #45321] Fri, 30 October 2015 14:39 Go to previous messageGo to next message
Tom1
Messages: 1212
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 #45329 is a reply to message #45328] Fri, 30 October 2015 17:05 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Tom1 wrote on Fri, 30 October 2015 14:39
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.


Well, after the hypothesis that you do NOT have in fact SDK installed, I have reverted changes for your tree (with missing SDK) - I think it is better that it is not installed than installed and not working (because of missing SDK).

Quote:

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?


EDIT belongs to ProtectTest?

Mirek
Re: Considering different approach to Win32 release [message #45330 is a reply to message #45329] Fri, 30 October 2015 17:51 Go to previous messageGo to next message
Tom1
Messages: 1212
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 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
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 #45375 is a reply to message #45374] Mon, 02 November 2015 17:34 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
P.S.: Example and docs updated...
Re: Considering different approach to Win32 release [message #45376 is a reply to message #45156] Mon, 02 November 2015 18:10 Go to previous messageGo to next message
mdelfede is currently offline  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 Wink
Re: Considering different approach to Win32 release [message #45382 is a reply to message #45376] Tue, 03 November 2015 09:27 Go to previous messageGo to next message
Tom1
Messages: 1212
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
Re: Considering different approach to Win32 release [message #45384 is a reply to message #45382] Tue, 03 November 2015 09:48 Go to previous messageGo to previous message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
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
Previous Topic: mingw/gdb troubles
Next Topic: Ideas on U++ as library
Goto Forum:
  


Current Time: Thu Mar 28 13:54:34 CET 2024

Total time taken to generate the page: 0.01407 seconds