InstallAware

John,
It's not a matter of redistribution or personal concern. It's a matter of corporate security not allowing any program to exist on a corporate issued machine unless it has the appropriate modern security features (ASLR, DEP, signed, etc.). Since we need to install InstallAware, those files exist on our machine, and corporate security doesn't like it.

Then, as a wholly separate matter, the installs that we create via InstallAware are put on our customer's machine. Their corporate security doesn't like having files that don't have modern security, and so on (in addition to the risk that we take on for our installer running on their system). I can control my files that are dropped, but what about the files that InstallAware creates or drops (even as temp files) to handle some process or another during an install? This includes everything from the Setup.exe that the IDE generates to the DLL's that are put in the temp folder during an install that come from InstallAware.

Additionally, the licensing file that another user mentioned in this thread doesn't have good security on it. I would think that would be beneficial to InstallAware to fix to reduce their risk.

In short, every single file that InstallAware gives to a customer should have the maximum security features available to it.

-Bond

That's a lofty goal but one that is impossible to realize.

InstallAware includes tens of gigabytes of runtimes (so much so that they no longer fit in a single file installer [reaching the hard 4 GB Windows executable limit when 32-bit-extraction compatible compression is employed]), none of which we could modify, if you're interested in runtime integrity, that is.

That said, we take what could be described as the "cold-chain" approach to this problem - as long as your development device is uncompromised, InstallAware itself and setups you build with InstallAware shall remain uncompromised. All setup engine components are fully mitigated and hardened against ASLR/DEP attacks.

JohnGaver wrote:

pfennig wrote:Thankfully, the newly created setups are DEP and ASLR enabled, InstallAware and most of its "sub"-programs still are not.
InstallAware PESecurity Checks.png
Also, neither the wrong version number of the main program nor the missing DPI-awareness of it and the created setups are solved.
miae.exe.png
miae.exe_properties.png

Why are you concerned about the other, literally private parts?

You are not allowed to redistribute them at any rate - that's not what you're doing, is it?

Sorry, I'm late.
No, I'm not redistributing them, but I have to work with them. The main program looks blurry on HighRes monitors, no other of my tools does. And not caring about correct version numbering is just poor work attitude.

BTW, the display of the release date on the download page is still not system-conform.
Currently ist says "Released to Manufacturing on: 3.14.2024" on a German system. It has to be 14.3.2024 or just use the ISO format 2024-03-14 to be on the safe side.

Thank you in advance for keeping your posts on-topic!

ASLR/DEP: We have resolved the concerns raised in this thread successfully.

High DPI Support: I understand we have followed up with you several times regarding the discovery of the broadest applicable solution for the issues you have been reporting. Please update that thread directly; OR, please respond to the emails our teams have sent you.