Is there any option to set new icon for a signed PE executable in windows without re-signing it all over again?
This means that the icon image, although fully embedded into the PE file, won't change the hash value as it's appears in the file signature part.
perhaps there's a concept where one can sign only the code and data section of the file and avoid other parts ? or maybe there's an option to exclude unwanted parts from the signature cover ?
Maybe it's possible to place the icon somehow inside the certificate section itself which is created by SignTool, so that it would be excluded from signing?
thanks
No, the signTool provided by microsoft that is used to sign binary files is not able to partially sign files. And it wouldn't make much sense to sign a binary if anyone could just change the embedded resources - the application code might rely on the data in those resources. So if the resource's integrity is not covered by the signature, the executable code would also be untrusted, thus defeating the purpose of the signature.
A solution would be to externalize the resources, so it's not part of the signature. It just might be possible by specifying an external path to the icon in the application's manifest file - but I'm not sure.
Related
I want to create a workaround for the URL protocol file: in Chrome, as it's security doesn't allow you to open certain files or locations. This would be for a small app of mine that I designed.
I searched around, and while I've found a lot of potentially good answers (such as this answer), I don't fully understand what each line should do, and whether it would actually work in my application.
The end-result that I want for this is to have a protocol like ih-link: that would allow me to open up links in Windows Explorer or elsewhere, similar to how you can do so in say, Outlook or Microsoft Word (if you create local or network shortcuts to a folder or file, it'll open it up without issue). Attempting this in Google Chrome gives varied results, either a browser-generated directory, or an error ususally.
I'd like to know, assuming the answer I linked to would work for me...
Is "URL Protocol"="" where I'd define the name of the protocol, so I'd use "URL Protocol"="ih-link", or something like that? I remember reading something about leaving that blank, so would I replace IntranetFileLauncher with whatever protocol name I want (in this case, it'd be ih-link?)
The next part that references explorer.exe seems to just reference the icon.
After that, what do the following two lines do?
[HKEY_CLASSES_ROOT\IntranetFileLauncher\shell]
[HKEY_CLASSES_ROOT\IntranetFileLauncher\shell\open]
The last lines of that script appear to just have it strip the protocol from the URL and pass the file path to explorer.. am I correct on this? I take it I would need to format the path as I would do for windows (using \ instead of /)?
I'm afraid to experiment without knowing more, mainly because I know that many things with the registry can be very dicey, so any clarification on this would be helpful.
Reading the actual documentation is better than trying to guess what some random code sample does.
URL Protocol is just a marker, it does not need a value. The default value (#) is where the name of your protocol is stored.
Yes, that entry (incorrectly) specifies the icon.
Those two lines are pointless. They create two empty keys but only the ...\shell\open\command line is required to properly build that registry path.
Yes, you might have to change / to \, add: call set url=%url:/=\% to the command.
Using cmd.exe to parse untrusted input is not ideal, it would be better to write a custom application.
I have two executable files, the first one should run the second one. The second one comes with different types of manifests: asInvoker, requireAdministrator, etc.
Is it possible to change the manifest of executable file? I'm searching a simple solution on C.
I would like not to keep few copies of executable with different types of manifests, and not to keep third party tool that could change it. BTW, it is possible and this tool exists: MT (manifest tool) from visual studio package, link.
Yes, you can change the manifest file using mt.exe from the Win32 SDK. But that is only something you should do during development or testing. You cannot deploy this tool to customer's machine, so you can't use it to dynamically change the manifest back and forth.
But that's okay, because you don't ever need to change the manifest file back and forth at runtime. The executable's manifest file should specify the minimum required privileges for that EXE. Thus, if it's possible for the user to run the EXE without administrative privileges (i.e., without elevation)—even if it means the app runs with limited functionality—the app's manifest should specify "asInvoker". The user can always choose to run the app with administrative privileges if they need those extra features.
And, of course, you can launch the EXE programmatically with elevation. You do this using ShellExecuteEx, specifying the "runas" verb for the lpVerb parameter. This will have the same effect as setting the permissions level in the application's manifest to "requireAdministrator".
It is not entirely clear from your question how your application is set up. Normally, the first EXE has "asInvoker" set in its manifest so that any user can run it. It doesn't need administrative privileges in order to do anything. However, if there is something it might need to do that requires administrative privileges, it displays some bit of UI with the UAC shield icon, and clicking on that will launch a second EXE (with "requireAdministrator" set in its manifest) that performs whatever task requires elevation. This second app doesn't need to be distributed in an "asInvoker" form because what it does always requires elevation. You'll notice that this is how all of Microsoft's apps are set up, including the bits shipped with the operating system.
Thanks #RbMm for his comment.
Also I found later that my question is duplicate. Sorry for that, I haven't found this earlier.
So, the solution (error handling and includes omitted):
HANDLE handle = BeginUpdateResourceW(file, TRUE);
UpdateResourceW(handle, RT_MANIFEST, CREATEPROCESS_MANIFEST_RESOURCE_ID, MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT), manifest, strlen(manifest));
EndUpdateResourceW(handle, FALSE);
Notes for further generations:
Manifest should be in short chars - char * instead of wchar *
Errors (e.g. incorrect XML syntax) could be tracked in Event Viewer, section Windows Logs -> Application
Some tools (Resource Hacker) could open and show manifests, but they show unicode manifests without error too...
I have embedded an EXE as a resource in my Win32 application.
I'm looking to the registry for a certain value. If the value is there and correct, then i copy the embedded EXE to the local file system an execute it from there.
I don't want it to be extracted from my EXE.
Should i do anything to prevent this, or is it impossible already?
Thanks.
but you could inbed the exe as an .obj or an static array rather than as a resource. That would make it harder for an attacker to find in your code, but still not impossible.
You can use the unix objcopy tool to convert your exe into a .obj file and then link to that in your c code. someone would have to decompile your code in order to find the .exe, which is quite a bit harder than using a resource extractor.
Embed data in a C++ program
Nothing is impossible, and in fact it is quite easy to strip resources out of an executable. Here's the first link from a Google search, for example. On the other hand you're already stripping the exe out and saving it to a file on the user's system, anybody sophisticated enough to find the embedded resource will also be able to find your extracted file. I wouldn't spend too much time worrying about it.
I have to secure an application. I can't modify the application. All i can do is writing small utilities around it, like creating an online serial system, unique hardware information hash storing, a loader exe etc.
But now i see that my intentions are almost useless without modifying the original applications. I'd be apprecieted any help on this.
My windows co-workers were asking me if I could modify my non-windows binary files such that when their "Properties" are examined under Windows, they could see a "Version" tab like that which would show for a Visual Studio compiled exe.
Specifically, I have some gzipped binary files and was wondering if I could modify them to satisfy this demand. If there's a better way, that would be fine, too.
Is there a way I could make my binaries appear to be exe files?
I tried simply appending the VS_VERSION_INFO block from notepad.exe to the end of one of my binaries in the hope that Windows scans for the block, but it didn't work.
I tried editing the other information regarding Author, Subject, Revision, etc. That doesn't modify the file, it just creates another data fork(what's the windows term?) for the file in NTFS.
It is not supported by windows, since each file type has their own file format. But that doesn't mean you can't accomplish it. The resources stored inside dlls and exes are part of the file format.
Display to the user:
If you wanted this information to be displayed to the user, this would probably be best accomplished with using a property page shell extension. You would create a similar looking page, but it wouldn't be using the exact same page. There is a really good multi part tutorial on shell extensions, including property pages starting with that link.
Where to actually store the resource:
Instead of appending a block to the file, you could store the resource into a separate alternate data stream on the same file. This would leave the original file stream non corrupted on disk and not cause its primary file size to change.
Alternate data streams allow more than one data stream to be associated with a filename. Each stream is identified by a colon : at the end of the filename and an identifier.
You can create them for example by doing:
notepad test.txt:adsname1
notepad test.txt:adsname2
notepad test.txt
Getting the normal Win32 APIs working:
If you wanted the normal API to work, you'd have to intercept the Win32 APIs: LoadLibraryEx, FindResource, LoadResource and LockResource. This is probably not worth the trouble though since you are already creating your own property page.
Can't think of any way to do this short of a shell extension. The approach I've taken in the past is a separate "census" program that knows how to read version information from any kind of file.
Zip files can be converted into exe files by using a program that turns a zip file into a self-extracting zip (I know that WinZip does this, there are most likely free utilities for this also; here's one that came up on a search but I haven't actually tried it). Once you've got an exe, you should be able to use a tool like Resource Hacker to change the version information.
It won't work. Either Windows would have to know every file format or no file format would be disturbed if version information were appended to it.
No, resource section is only expected inside PE (portable executable; exe, dll, sys).
It is more then just putting the data inside the file, you have a table that points to the data in the file header.
What you can do if you have NTFS drive, is to use NTFS stream to store custom properties this way the contact of the binary file will remain the same, but you will need to use a custom shell extension to show the content of the stream.
My installer build "signs" a DLL using a Code Signing certificate during the build process.
I've noticed that if I try to build twice in succession, the second build fails because the DLL is already signed so signcode chokes. Obviously I can fix this by signing a copy of the DLL in the build, but the problem intrigued me:
Is it possible to "unsign" a DLL, and if not, why not...?
signtool remove /s C:\path\to.exe.or.dll
signtool is available in Windows SDK, and must be at least from Windows 8 SDK kit (version 6.2.9200.20789) to have the remove command supported.
You can use delcert.exe from the this XDA Forum post.
here is a small tool that strips (removes) digital sign (Authenticode)
from PE executable files like *.exe, *.dll, *.mui, etc.
It's fairly easy to remove the signature from a .dll file using the ImageRemoveCertificate API.
You don't have any language specified in your tags but this article shows how to implement it in C#. Remove digital signature from a file using C#
Other than that, if you are looking for a simple tool to do the work for you, you can use FileUnsigner.
Another possible option is to switch to the SignTool.exe. It comes with the Windows SDK and signing a binary that has already been signed does not generate an error. I use signtool.exe in my build process and haven't any difficulties with it, even when something is already signed.
Also, check out the question What's the main difference between signcode.exe and signtool.exe?
Sure it's possible, but not trivial.
Although it would be easier to save a copy of the presigned DLL.
This digital signature is little more than an extra section appended to the end of a PE file. You could write a program that deleted the signature, if you want.
It's not quite as simple as truncating the file; you have to remove references to the signature in the file header. It could get complicated if the DLL has multiple signatures and you just want to remove one.
The format of a PE file is publicly documented here
Check if your build tool supports "Re-signing". This should replace all existing signatures.
If not, you can use Stud_PE to remove the signature block.
Open the DLL or EXE in Stud_PE, go to the sections tab, right click the digital signature section and select "Delete section". However, this needs user interaction. Old versions of the tool could destroy the file.