We have an exe file delivered by an ASP.NET application. This binary is actually modified on the fly in memory. Is there any way to sign the modified exe with authenticode in memory without writing to disk? There's probably no way to sign the original exe and still keep the signature valid after modification. We thought about using ram disk to help on disk i/o if we have to, but just wondering if there are any other options.
The problem is really how to get rid of the unknown publisher warning. So if there is any other way that does not involve signing or changing policy settings on the client's computer, please let me know as well.
I don't know the answer to this offhand, but I've seen it done by Just Great Software. They make customized installers for RegexBuddy and every time I've downloaded mine it's got its signature.
I'm curious though - why don't you want to persist the file to disk? You don't need to leave it there - persist it, sign it, load it back into memory and delete it. Or, persist it, and have an agent or cron job delete it after a couple days.
Related
With Apple it used to be able exempt some files from code signing. They later changed this, but made it possible to place some data in an extended attribute, so I could change that data when an user downloaded from my server. The use case was to keep the session alive, so when he started the app it could gather user-specfic information from the website and set it up.
Now I'm trying to do the same thing on Windows, but I find no way to do this. It's trivial to change the data within the binary (an NSIS-based installer), but then I have to resign everything upon delivery. Which is precisely what I want to avoid.
Is this even possible? And if so, where is the place to start?
Being able to change 64 Bytes would be best, but I guess the process could be tweaked wo work with a 128 bit UUID.
How do applications like CloneDVD2 or AnyDVD know that the free phase is over, even if the application was uninstalled and then re-installed? Those applications don't require the user to login so that they could identify the user again.
Also on deinstalling them a window pops up asking whether the "registration files" should be kept or not. Even if they are not kept, the re-installed application knows the demo-time is over.
How is that technically realized?
Could be everything...
You might reverse the algorithm to find out.
But to name an example:
It's possible to generate a hash, based on unique hardware identifiers, of your hardware configuration and send that over the internet to a database.
If your hash exists over there, the software knows you ran it before.
An other option is leaving tracking information inside of your OS. So the checkbox: delete register information, isn't deleting everything.
To test:
1) Switch GPU or CPU :P
2) Format & Reinstall computer
On certain programs you can run them on a demo period for say 'ten tasks' or '5 hours' before you need to decide to purchase them to keep using them, but if you delete and uninstall the program then reinstall it, it knows that its been previously installed and wont let you run the demo again.
How does it do this ? When you download it does it send a identifiing number (ip ?) to the cdn to let it know youve downloaded it before, or when the program itself installed does it check to see traces of previous installation ?
Most "demo" software does this by a feature borrowed from malware: Incomplete deinstallation. A file or registry key belonging to the software is not removed on deinstallation. On reinstallation the software sees the remainder and can act on it.
Often-used hiding places for such a remainder were the system directory (before UAC arrived), but many register some class GUID - nobody I know of has a real overview of which classes in the registry are or are not genuine.
There are many ways this can be implemented.
The easiest way to implement (and also the easiest way to bypass)
On first run, create a registry (or text file) entry somewhere
Add 1 to the counter every time the task (or the app) is run
Do not include this file/registry in the installer app (so it will persist after uninstallation)
If at any time the count is too high, notify the user that the trial has expired.
Using image diff tools this method is pretty easy to identify and overcome.
The hardest method to overcome or bypass is to use a server. On the first run, generate a hash code based on the users computer name, drive serial number, etc, and post this to your server. The server then tracks this as a unique installation, and allows the app to run. Each time you run the app, you update the server. This way, the user cannot find the breadcrumbs and delete them, since they are on your server. The down side, is that this method will require an Internet connection.
There are probably much more sophisticated methods to achieve this result, but the above are both implementations I've run across.
My software drops breadcrumbs within the users system which is used to check for previous installations. This is a little harder to get around (assuming you don't know what you are looking for, or where) than an internet check against your IP. As you can always spoof your connection information, or just disconnect from the internet while installing.
I saw this question in a forum about how an application can be developed that can keep track of the installation date and show trial period expired after 30 days of usage. The only constraint is not to use the external storage of any kind.
Question: How to achieve this?
Thanks
Bala
--Edit
I think its easy to figure out the place to insert a question work. Anyway, I will write the question clearly. "external storage" means don't use any kind of storage like file, registry, network or anything. You only have your program.
Use the file-modified date of the file containing the program as the installation date.
I like Doug Currie's idea of the file-modification date. But if the application is downloaded from the web, every night at midnight it gets relinked with new initialized data containing the new expiration date. Then any binary downloaded that day expires on the date given.
If you like, sign the date with a private key so it can't be hacked. Include a public key in the app and decrypt the date. If not correctly signed, hasta la vista, baby.
I don't know if this is possible, as most work I've done has been with embedded systems in which I don't even need to touch the operating system. But would the following be possible?
When compiling your program, leave some extra space at the end (say, 8 bytes), all set to 0. When your application is run, it fetches those bytes and if they're all 0, replaces them with the current time (That's the part I'm not sure about. Does the OS let you do that? If not, there might be some work-arounds using multiple processes.), otherwise, if the time difference is greater than 30 days, it notifies the user that the trial period has ended.
Of course, that method would be vulnerable to resetting the system clock.
If you can't use any external storage at all (not even config files or anything like that), you would need to code it into the app itself so the app's main method (or some method) checks if the current date is less than some expiration date. Part of your installer could actually compile that code on the fly and then it would be set to the installation date. This could be easily defeated by reinstalling the app, but then again, it's not realistic to have no external storage either.
I think the only way to do this generally would be to have your application spawn something off in a separate process that would continue to run and keep track of the date/time even if the main application were closed. When it was restarted, it would then connect to the running process to see if the trial period had expired.
Of course, this would only work if the computer was never restarted and the user never hunted down your spawned process and killed it, which is pretty unlikely. If your application does not do anthing IO-related (file system, registry, something on the network etc.), then a simple restart will wipe away anything that you've done.
So, to summarize: it's not really possible.
When I defragment my XP machine I notice that there is a block of "Unmovable Files". Is there a file attribute I can use to make my own files unmovable?
Just to clarify, I want a way to programmatically tell Windows that a file that I create should be unmovable. Is this possible, and if so, how can I do it?
Thanks,
Terry
A lot of system files cannot be moved after the system boots, such as the page file and registry database files.
This utility runs before Windows boots to defragment those files. I have it set to run at every boot, and it works well for me on several machines.
Note that the very first time you boot up with this utility set to run, it may take several minutes to defrag. After that first run though, it finishes in just 3 or 4 seconds.
Edit0: To respond to your clarification- that link says windows has marked the page file and registry files as open for exclusive access. So you should be able to do the same thing with the LockFile API Call. However, that's not an attribute of the file itself. You'd have to actually run some background program that locks the file for exclusive access.
There are no file attributes that you can place on your files to mark them as immovable. The only way that a file cannot be moved (I think) during defragmentation is to have some other process have the file open (for read or write, I'm not even sure that you need to have the file open in exclusive mode or not).
Quite frankly, I cannot think of a reason that you'd want your files not to move, unless you have specific requirements about where on the disk platter your files reside. Defragmentation should generally lead to faster disk access and that seems to be desireable in all cases :-)
This usually means that the file is in use by some process. If you're defragmenting, you'll likely see this with a lot of system files. If the file should legitimately be movable and is stuck (it's being held by a process that runs at startup but shouldn't be, for example), the most useful way of resolving the problem is to remove all permissions on the file, reboot, restore the permissions, and then get rid of the file/run the program that's trying to use it.
I suppose the ugly way is to have an application boot on startup, check every few seconds if defrag is running and if so open the file in exclusive mode.
This is really ugly and I don't recommend it unless there is no cleaner solution.
Terry, the answers all mention ways to prevent files from becoming unmovable during defragmentation. From your question it appears that you are in fact wanting to make your personal files unmovable. Can you please clarify what is appealing about making your files unmovable.
I assume you're using the defragger that comes with Windows. Some commercial ones like DiskKeeper can move some of these files (usually system files). You can try their trial versions.
Contig might serve your purpose http://technet.microsoft.com/en-us/sysinternals/bb897428.aspx
I'm relatively certain I ran across some methods/attributes you could access programatically to do exactly what you want. This was back in NT4 days though and my memory isn't that good.
For a little more complete solution try Raxco's PerfectDisk. While it is a commercial product it does a very good job and supports boot time defrag of system files. The first defrag takes longer than say DiskKeeper but its a single pass defragger and supports defragging with very little free space left on the drive. Overall its a much smarter defrag program then any other I've seen and supports systems of any size.
http://www.raxco.com/
first try to move(or delete) the files within safe mode. If can not, try to move(or delete) the files with linux.
But be careful if those are the windows system files, then you are failed to boot up your windows.
Some reason why the files are unmovable are : the file size is too big, the files are being in open/in use condition, insufficient security privileges, being access by other computer/s, and many other things.