Delphi 11.3, issue after encrypting exe file -> bad symbols @ GUI

[o815 0]

Hi there,

 

I've noticed some issue since we upgraded from Delphi 10.3 to 11.3.

Currently after compiling our software as a "release", we encrypt the exe file with "WibuKey" (a USB Dongle for copy protection).

Now (since Delphi 11.3) I have a strange issue with encrypted Delphi exe files, meaning that my GUI suddenly shows chinese / unreadable symbols f.e. on a simple TPanel.Caption.

The thing is, TPanel.Caption isn't any resourcestring or something, also there is no localization file used.

 

To double check it isn't an issue with the "release", we compiled it as "debug" an encrypted the exe file - same issue.

In my understanding, there must be a difference between Delphi 10.3 - to 11.3 in the compiled exe file, especially with strings. So the encrypted exe file seems to read from the wrong "string-address" of the TPanel.Caption.

 

Perhaps someone else has similar issues with encrypted delphi 11.3 exe files?

[David Heffernan 2300]

Probably the issue is in your code to do this encryption. We don't know what that code is. 

[Cristian Peța 94]

If not encrypted is working (it is?) then must to be the encryption-decryption that is changing something.

[o815 0]

Yep, the not encrypted exe is working.

I am using an external "wibukey" encryption, so the complete encryption is done by an external exe provided by WibuKey.

[Fr0sT.Brutal 897]

Make minimal reproducible sample and send it to Wibukey support. You paid them money, let them do their job

[David Heffernan 2300]

Yeah, don't understand why you think that this is a Delphi issue. The executable that Delphi produces is fine. You then mangle it and it fails. Speak to the developer of the code that mangled your exe.

 

It's common, and always has been, for such so-called protection schemes to fail. It's the risk you take on when you start mangling executable files like this.

[o815 0]

Yeah you are right. I just had a little hope that someone else is having similar issues...

Turns out the problem appears only when using an additional Delphi-DLL, so I'll contact wibukey.

 

Sorry to bother you.

[Daniel 417]

19 minutes ago, o815 said:

Sorry to bother you.

Oh, relax. 😉 It's no bothering at all. In the end, there is now the information, that wibukey seems to be imcompatible to certain constellations with newer Delphi-projects. Not a Delphi-issue, but maybe an useful information for other wibukey-users.

[Fr0sT.Brutal 897]

1 hour ago, o815 said:

problem appears only when using an additional Delphi-DLL

Hmm, so you have encrypted Delphi exe and unencrypted Delphi DLL? I hope no runtime packages involved?

Anyway the answer remains the same - protectors hook into normal loader mechanism so their devs are the 1st to ask.

[PeterBelow 218]

5 hours ago, o815 said:

Hi there,

 

I've noticed some issue since we upgraded from Delphi 10.3 to 11.3.

Currently after compiling our software as a "release", we encrypt the exe file with "WibuKey" (a USB Dongle for copy protection).

Now (since Delphi 11.3) I have a strange issue with encrypted Delphi exe files, meaning that my GUI suddenly shows chinese / unreadable symbols f.e. on a simple TPanel.Caption.

The thing is, TPanel.Caption isn't any resourcestring or something, also there is no localization file used.

 

To double check it isn't an issue with the "release", we compiled it as "debug" an encrypted the exe file - same issue.

In my understanding, there must be a difference between Delphi 10.3 - to 11.3 in the compiled exe file, especially with strings. So the encrypted exe file seems to read from the wrong "string-address" of the TPanel.Caption.

 

Perhaps someone else has similar issues with encrypted delphi 11.3 exe files?

D11.3 uses some additional linker option by default to enable the address space layout randomization (ASLR) feature. Try to disable that and see if it fixes the issue.

[Fr0sT.Brutal 897]

4 hours ago, PeterBelow said:

D11.3 uses some additional linker option by default to enable the address space layout randomization (ASLR) feature. Try to disable that and see if it fixes the issue.

That's likely the case. I guess they already have regretted thousand of times for enabling this feature by default

[Vandrovnik 202]

2 minutes ago, Fr0sT.Brutal said:

That's likely the case. I guess they already have regretted thousand of times for enabling this feature by default 

Why? Can this be a problem for a correctly written application?

[Fr0sT.Brutal 897]

2 minutes ago, Vandrovnik said:

Why? Can this be a problem for a correctly written application?

If by "correctly written" you mean "the one that had foreseen all features MS and Emba and whoever would introduce in nearest 10 years" then no, this won't be a problem.

ASLR breaks things if an app needs to know its internal layout and MS haven't provided an API to know current base address (at least I know none).

[Vandrovnik 202]

51 minutes ago, Fr0sT.Brutal said:

If by "correctly written" you mean "the one that had foreseen all features MS and Emba and whoever would introduce in nearest 10 years" then no, this won't be a problem.

ASLR breaks things if an app needs to know its internal layout and MS haven't provided an API to know current base address (at least I know none).

But it does not change internal layout, does it? Just the address of code, data and stack segments is randomized.

Edited July 11, 2023 by Vandrovnik

[Fr0sT.Brutal 897]

16 hours ago, Vandrovnik said:

But it does not change internal layout, does it? Just the address of code, data and stack segments is randomized.

Yes but you still have to find where to start from.

[David Heffernan 2300]

26 minutes ago, Fr0sT.Brutal said:

Yes but you still have to find where to start from.

Stack location has never been repeatable. And as for the module, it starts at HInstance. As it always has. And DLLs have always needed to be relocatable. It's just Windows EXEs that previously could be relied upon to have a known start address. So yeah, change $00400000 to HInstance and it's all good.

[Fr0sT.Brutal 897]

27 minutes ago, David Heffernan said:

And as for the module, it starts at HInstance. As it always has

This would be cool but I haven't found any mentions that HInstance is in fact a pointer to module in MSDN.

[David Heffernan 2300]

An HMODULE has always been the base address of the module, as loaded into its process. 

 

And it's documented here: https://learn.microsoft.com/en-us/windows/win32/winprog/windows-data-types#HINSTANCE

Edited July 12, 2023 by David Heffernan

[Fr0sT.Brutal 897]

4 hours ago, David Heffernan said:

An HMODULE has always been the base address of the module, as loaded into its process. 

Yep but the fact must be documented or it could change without notice

4 hours ago, David Heffernan said:

And it's documented here: https://learn.microsoft.com/en-us/windows/win32/winprog/windows-data-types#HINSTANCE

Damn, I searched in GetModuleHandle and LoadLibrary but forgot about the description of the type itself. Thank you!

[David Heffernan 2300]

3 hours ago, Fr0sT.Brutal said:

Yep but the fact must be documented or it could change without notice

Well, true, but everything would break. So it's not going to change. And I think that's why it has been documented. I think it wasn't originally documented but at some point MS realised that this has become a contract that can't be broken. 

[Fr0sT.Brutal 897]

16 hours ago, David Heffernan said:

Well, true, but everything would break. So it's not going to change. And I think that's why it has been documented. I think it wasn't originally documented but at some point MS realised that this has become a contract that can't be broken. 

MS does really good job keeping backward compat but sometimes they just break things, just like it was for CreateProcess that started requiring the string to be mutable. I suppose usage of CreateProcess is MUCH larger than reading hInstance as starting point of the module image. So - everything is possible. But currently the solution is usable