They also monitor for apps that drop payloads into the Windows System folder as well as into the various %TEMP% folders. That’s a standard bypass method for many malware apps to drop executable onto a system.
As I mentioned elsewhere, in my company any executable packer, in any configuration, would be flagged immediately and the company blacklisted. This is all automated and getting anyone whitelisted is a pain, so asking about this is standard before any installation. This is unavoidable with the software we use, and monitored centrally and out of our control.
I don’t think it’s worth it, considering the supposed benefits this would provide.
I also wanted to comment something else:
This wouldn’t make the app “lightweight”. There might be a level of compression at play but a 50MB application won’t suddenly become a 2MB one, and will become slower (at least at startup).
I’ve never seen a UAC related flag for including the ramdisk command-line app and passing it a Shell command to create a ramdisk (can even include in the libs folder and rename with dll extension (still executes)). Generally I always flag apps that will create any files as administrator, so they must be run as administrator (which bypasses UAC)… Otherwise even simple software that creates a database file or saves a settings file to specialfolder.ApplicationData doesn’t work. If I know the user doesn’t want to get prompted by annoying UAC popups, I allow the installer of my “single exe” app to automate the following
http://www.sevenforums.com/tutorials/11949-elevated-program-shortcut-without-uac-prompt-create.html
When the program shortcut is created. Since you must create the uac-free elevated shortcuts as an admin (a simple script of the above link would do), you allow the installer to do that for you since it already asks for elevated privileges at startup, or make your app prompt the user saying “this application requires admin privileges”… then the user uses the shortcut to open the program as usual (or runs as admin) and the bound together app creates the ramdisk, extracts, runs, and destroys itself on close. You can even encrypt ramdisks to secure private data that may be included in the application. This ensures prodders don’t go memory sniffing your application to obtain that sensitive data that has been reassembled into readable strings in memory, after you worked so hard to obfuscate them in the built binary itself.
- Maybe because the system loader IS used
- Not at all - they were IN the EXE and loaded directly from memory which the system loader doesn’t do (for very good reasons)
100% wrong Matt
We never used static libraries with the old single file exe form for a plugin (the plugin itself MAY have used a static lib but the plugin used by the built app was a dylib/dll)
They were dll’s loaded directly from memory using a custom loader
Since the system loader does lots of special magic NOT using the system loader IS a huge security problem & also can cause other issues (like the C++ runtime not being properly initialized, OS shims not being loaded etc)
And MS advised that trying to write a loader that could / would duplicate all these behaviors is NOT something to be undertaken - they have a whole team that works on this part of the OS.
Their advice is / was “Use the system loader” which means dll’s next to the exe or subfolder
I think they now actually recommend a sub folder next to the exe (a private assembly) if I recall correctly as there are certain attack vectors that are not available when you do this