In fact, there is only one way to tell Windows that the program should be upgraded, and that through the manifest file. The manifest files can be embedded in the assembly (exe / dll) or can be in a separate file with the name <YOUR_APP>.exe.manifest . This is really the only way and probably the only way you can safely check. Officially.
Windows also contains a gigantic database used for application compatibility. If Microsoft checked the application and found that it crashes when updating the OS, sometimes an entry is created in the database to significantly crack the application. Sometimes they lie about the current version of the OS, sometimes they automatically start as an administrator, sometimes they do a bunch of other things. You can view the database using the Application Compatibility Toolkit . I don't know if there is an official way to query the database using code. This blog post talks about a tool that a blogger has made, but apparently never released.
The last automatic elevation mechanism is an algorithm that tries to determine if this application is an installer. According to MSDN, these attributes are marked:
- The file name includes keywords such as “install,” “configure,” “upgrade,” etc.
- Keywords in the following fields Resources for versions: vendor, company name, product name, file description, original file name, Internal name and export name.
- Keywords are a side-by-side manifest built into an executable file.
- Keywords in specific string entries associated with an executable file.
- Key attributes in RC data associated with an executable file.
- Target byte sequences in the executable.
Keywords and byte sequences were derived from common characteristics observed in various installation technologies.
Finally, the application can work as a regular user, but spawns a child process that requires elevated privileges . I don't know if there really is any way to detect that it is not decompiling the application.
Chris haas
source share