I noticed that I forget to update the Windows Live CD plugin for UserAssist.
From now on, I’ll update it each time I release a new version of my UserAssist utility.
You can download the plugin for the latest version here (https).
Monday 28 January 2008
Wednesday 23 January 2008
Quickpost: The Digital Signature of a Cryptographic Service Provider
This post is the result of additional research started by this comment. A Cryptographic Service Provider (CSP) must be digitally signed by Microsoft before it can be installed and used on Windows. But this digital signature is technically very different from AuthentiCode and serves another goal.
AuthentiCode uses digital certificates, a certificate is a digitally signed document which links a public key to an identity. Code signing is performed to link software to its author and to allow detection of program alteration. AuthentiCode is also used by Microsoft to digitally sign device drivers. In this case, the signature is used to show that the driver passed Microsoft’s testing program (the signer is Microsoft Windows Hardware Compatibility Publisher)
A CSP must also be signed by Microsoft, but the technique is different from AuthentiCode. Microsoft will sign the hash of the CSP. This signature can be stored inside the file as a resource (ID 0x29A or 666) that is 144 bytes long, or inside the registry as a blob of 136 bytes. When I looked at several signatures inside CSPs, I noticed that the first 8 bytes were almost always identical and hence are probably not part of the actual signature (144 – 8 = 136).
Since the length of the signature is constant and very short, it cannot be a certificate. Neither can it be decoded as a certificate. My educated guess is that this signature is nothing more than the cryptographic hash of the file encrypted with a private key kept by Microsoft. Checking the signature is thus done in Windows by calculating the hash of the file, decrypting the signature with the public key and comparing the hash with the decrypted signature. Equality shows that the signature is valid. The use of the cryptographic hash ensures that is virtually impossible to modify the file while keeping the same hash, and the use of the private key guards the hash from forgery.
This is an example of the signature inside CSP rsaenh.dll viewed with the free XN Resource Editor:
A signature for a CSP can only be obtained by providing documents to Microsoft promising to obey various legal restrictions and giving valid contact information. Thus the goal of the signature is to proof that Microsoft and the CSP author promise to obey the restrictions on cryptography. But I’m not a lawyer, the formulation of this goal is the result of my inadequate legal skills.
I was also told that Microsoft will perform some testing, but I haven’t yet received confirmation or details about this.
Wednesday 16 January 2008
XORSearch V1.3.0
Maarten Van Horenbeecks’s post gave me the idea for a new feature for my XORSearch tool: searching for a list of strings. This is achieved with the -f option, like this:
XORSearch -f urls malware.exe
urls is a text file containing a list of URLs to search for.
You’ll still have to use a script if you want to search in more than one file.
And there is something new about the XORSearch.exe in the ZIP file. First one to post a comment with the correct answer gets an honorable mention 😉
Monday 14 January 2008
Quickpost: GUI vs. CUI
Sometimes I read the following programmer’s question:
When I launch my program from the command line, I get a new prompt immediately. What API should I call to let my program display a new prompt only when it is done?
This is often related to scripting: calling this kind of program from a BAT file is a problem, because the BAT file will continue executing while the program is still running.
In fact, this behavior is not defined through coding in the program itself, but by a setting in the header of the program. For WIN32 applications, the value of the SUBSYSTEM parameter is 2 (IMAGE_SUBSYSTEM_WINDOWS_GUI) for a GUI application and 3 (IMAGE_SUBSYSTEM_WINDOWS_CUI) for a console application. A programmer can change this setting by selecting the appropriate option for his compiler. And if one can’t recompile the program, just use a binary editor or a PE file editor. It’s important to understand that console applications are not limited to console interaction, and GUI applications are not limited to GUI interaction. A console application can create windows and a GUI application can create consoles.
It is the shell (cmd.exe) that decides if it waits for the end of the launched program or not, based on the value of the SUBSYSTEM parameter. Take a look at the source code of cmd.exe for ReactOS (this is Open Source):
After your program is successfully started (CreateProcess), the shell will check if the new process is a console or GUI application (IsConsoleProcess). If it’s a console application, the shell will wait for the program to terminate (WaitForSingleObject), and then it will set the ErrorLevel to the return code. But if it’s a GUI application, it will not wait and it will set the ErrorLevel immediately to 0. That is why you immediately get a new command prompt when you launch a GUI application from the shell: it’s the shell itself that decides not to wait.
So if a programmer wants cmd.exe to wait for the end of its program, he has to declare it as a console application, even if it uses a GUI. There is a drawback however, because when this program is launched from explorer.exe (and not cmd.exe), a console will be automatically created by Windows. The only trick I found to avoid this is to hide the console programmaticaly (but it will still appear briefly when your program is stared).
You can try the following experiment to better understand the SUBSYSTEM parameter without resorting to programming:
- take a copy of notepad.exe
- change the SUBSYSTEM parameter of this copy from 2 to 3
- launch the copy from Windows Explorer
- launch the copy from cmd.exe
- launch the copy from a BAT file
Friday 11 January 2008
The Case of the Missing Digital Signatures Tab
The title of this post is inspired by Mark Russinovich‘s posts. I explain why there is a category of executables with a digital signature that don’t show a “Digital Signatures” tab in the properties dialog, and I release a tool to manipulate digital signatures.
Executables (PE files) can have a digital signature, Microsoft calls this signature AuthentiCode. There are 2 different ways to sign a PE file: by adding a digital signature to the PE file (embedded digital signature) or by adding a hash of the PE file to a security catalog file (filetype .CAT).
The Properties dialog of a file hosts a Digital Signatures tab when the PE file has an embedded digital signature, like this Windows patch from Microsoft:
But when a file is signed via a security catalog file, the Digital Signatures tab is not displayed. Notepad is a good example:
To check the digital signature of this category of files, one uses Microsoft’s signtool or Mark’s sigcheck utility:
These tools will calculate the hash of the file, look it up in the appropriate security catalog file and check the signature of the security catalog file. One can find security catalog files in directory C:\windows\system32\catroot:
For an embedded digital signature, the location of the signature is at the end of the signed file. Look for DATA_DIR Security in IMAGE_DATA_DIRECTORIES of the optional PE header. It has a pointer (4 bytes) to the signature and the length (4 bytes) of the signature. The pointer is just the offset in the binary file. When these bytes are all zero (0x00), the PE file has no embedded digital signature.
Here is the PE header of another Windows patch:
In this patch, the signature entry can be found at offset 0xF4E00 in the file and is 0x2428 bytes long:
The first 4 bytes of the signature entry is the size, the following 4 bytes is a constant (0x00020200), and the rest is the PKCS7 signature. This signature can be extracted with a binary editor and parsed with openssl:
Finally, I wrote a small Python program to manipulate embedded digital signatures. Features of disitool:
- delete a signature: disitool.py delete signed-file unsigned-file
- copy a signature: disitool.py copy signed-source-file unsigned-file signed-file
- extract a signature: disitool.py extract signed-file signature
- add a signature: disitool.py add signature unsigned-file signed-file
Tuesday 8 January 2008
Quickpost: Windows Server 2008 UserAssist Keys
My first post for 2008 has to be about Windows Server 2008.
It looks like the UserAssist entries for Windows Server 2008 have the same format as for Windows Vista, my UserAssist tool can also extract the data from Windows Server 2008:
Like Vista, the Windows Server 2008 browserui.dll file (version 6.0.6001.17051) contains only 5 UEME strings:
UEME_RUNPATH
UEME_CTLCUACount:ctor
UEME_CTLSESSION
UEME_RUNPIDL
UEME_RUN
Didier Stevens 