In addition to the current 32/64-bit installer, this new version brings a new full 64-bit installer. Except the 32-bit versions of imdisk.exe and imdisk.cpl that are still installed in SysWOW64, everything is in 64-bit, including the 7-Zip SFX module that is now compiled by myself.
This means that the x64 version should work on a system with the WoW64 subsystem removed.
The new 7-Zip SFX modules now have a manifest, which avoids the extractor itself to be elevated by the UAC. This reduces the scope of a "DLL hijacking", and avoid the load of a malicious external manifest (on Vista and later).
Along with the name change of setup.exe, this also should avoid the Program Compatibility Assistant of Windows to be displayed in most cases.
These modules also support DEP and ASLR. As there is a few small changes in the code, the source is provided.
After being compiled, they have been compressed with UPX (--ultra-brute).
Some months after the first version of ImDisk Toolkit, I wanted to remove the support of the Itanium CPUs, because I cannot do a single test, and I never had any feedback about that. I was forced to restore it because some stupid antiviruses were complaining.
It seems to be no longer the case, so in order to make the installer smaller, I removed it. As the package provided by Olof still supports it, this should not be an issue.
About the antiviruses, as expected, there are more false alerts than before. With a custom extractor, some stupid antiviruses do not even attempt to extract the content and therefore they mark it as suspect.
The 32-bit version currently has 6 false positives, and I will not make a bigger or less secure extractor just to avoid that.
The installer now creates the shortcuts in a different way. Instead of using the IShellLink interface, a temporary INF file is now generated.
This method is a bit slower but saves 25KB of the executable size.
Technical note: even after being reconfigured by a 64-bit process to use a 64-bit executable, a service remains marked as "WOW64". This can be seen, for instance, if you use a ramdisk at startup, in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ImDiskRD.
No matter the bitness of the service, this does not affect it. However, this value is used before the process is created: if the value exists and is 1, redirections are applied to locate the executable of the service.
So, it only matters if you install RamDiskUI and ImDiskTk-svc in the System32 or SysWOW64 folder. Otherwise, this changes nothing, and you can safely remove this value.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I just did a new analysis on VirusTotal: there are now 8 false alerts for the 32/64-bit version, including Avast and the 2 editions of McAfee (the same code in 64-bit: only 2 false alerts).
If my professional life was depending on that, this would be disastrous. But fortunately, it's not the case.
Given the "alerts", there is nothing I can do. So we'll have to deal with it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In addition to the current 32/64-bit installer, this new version brings a new full 64-bit installer. Except the 32-bit versions of imdisk.exe and imdisk.cpl that are still installed in SysWOW64, everything is in 64-bit, including the 7-Zip SFX module that is now compiled by myself.
This means that the x64 version should work on a system with the WoW64 subsystem removed.
The new 7-Zip SFX modules now have a manifest, which avoids the extractor itself to be elevated by the UAC. This reduces the scope of a "DLL hijacking", and avoid the load of a malicious external manifest (on Vista and later).
Along with the name change of setup.exe, this also should avoid the Program Compatibility Assistant of Windows to be displayed in most cases.
These modules also support DEP and ASLR. As there is a few small changes in the code, the source is provided.
After being compiled, they have been compressed with UPX (--ultra-brute).
Some months after the first version of ImDisk Toolkit, I wanted to remove the support of the Itanium CPUs, because I cannot do a single test, and I never had any feedback about that. I was forced to restore it because some stupid antiviruses were complaining.
It seems to be no longer the case, so in order to make the installer smaller, I removed it. As the package provided by Olof still supports it, this should not be an issue.
About the antiviruses, as expected, there are more false alerts than before. With a custom extractor, some stupid antiviruses do not even attempt to extract the content and therefore they mark it as suspect.
The 32-bit version currently has 6 false positives, and I will not make a bigger or less secure extractor just to avoid that.
The installer now creates the shortcuts in a different way. Instead of using the IShellLink interface, a temporary INF file is now generated.
This method is a bit slower but saves 25KB of the executable size.
Technical note: even after being reconfigured by a 64-bit process to use a 64-bit executable, a service remains marked as "WOW64". This can be seen, for instance, if you use a ramdisk at startup, in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ImDiskRD.
No matter the bitness of the service, this does not affect it. However, this value is used before the process is created: if the value exists and is 1, redirections are applied to locate the executable of the service.
So, it only matters if you install RamDiskUI and ImDiskTk-svc in the System32 or SysWOW64 folder. Otherwise, this changes nothing, and you can safely remove this value.
I just did a new analysis on VirusTotal: there are now 8 false alerts for the 32/64-bit version, including Avast and the 2 editions of McAfee (the same code in 64-bit: only 2 false alerts).
If my professional life was depending on that, this would be disastrous. But fortunately, it's not the case.
Given the "alerts", there is nothing I can do. So we'll have to deal with it.