XORStrings is best described as the combination of my XORSearch tool and the well-known strings command.
XORStrings will search for strings in the (binary) file you provide it, using the same encodings as XORSearch (XOR, ROL, ROT and SHIFT). For every encoding/key, XORStrings will search for strings and report the number of strings found, the average string length and the maximum string length. The report is sorted by the number of strings found, but can also be sorted by the maximum string length (use option -m). By default, the string terminator is 0×00, but you can provide your own with option -t, like the space character (0×20) in this example:
I’ve used XORStrings to identify the encoding used in TeamViewer traffic.
There are more options than the ones I mentioned here. I’ll create a dedicated page for this tool, but for now, I invite you to discover the options yourself.
I will give a talk on network forensics at my local ISSA chapter.
I’m preparing it with a couple of PoCs.
First PoC is how changing the canary value 0xFD0110DF to another value can provide defense against exploits like FX explained in this paper. I changed the appropriate instructions so that IOS uses canary value OxFC0220CF. You can see it at the bottom of this memory dump:
Second PoC is how I can change the behavior of an IOS command for offensive purposes. Topo mentioned this idea at Black Hat. The verify command checks the embedded MD5 signature in an IOS image. I patched the appropriate instructions so that the verify command always reports a valid signature, regardless of the actual embedded value:
I did not change CCO hash. This is the MD5 hash of the complete IOS image. I did not change this on purpose, but it would be as easy as changing the embedded hash. If you lookup this CCO hash with Cisco, you will not find it.
Sorry for the lack of recent posts, I’ve been ill and had to catch up with a lot of work.
Braden Thomas wrote an interesting series of posts on reversing the TeamViewer protocol.
I want to add my own observation: when TeamViewer is forced to communicate over an HTTP proxy, it will issue GET statements with parameter data that can be decoded in a similar way as Braden describes for the direct protocol (i.e. without proxy).
First of all, to identify TeamViewer traffic in proxy logs, you look for this User Agent String: “Mozilla/4.0 (compatible; MSIE 6.0; DynGate)”.
You will see HTTP GET requests like this one:
When you decode the value of the data= parameter as base64, you can identify the version of the protocol (first 2bytes) and the command (3rd byte):
0×12 is a CMD_MASTERCOMMAND. By left-shifting the data from the 5th byte with 1 bit, you can decode the arguments of a MASTERCOMMAND, like this:
When parameter f (the function) is RequestRoute2, you know that the TeamViewer user issued a command to connect to another TeamViewer client. Parameter id identifies the originating client (123456789 in my example), and parameter id2 identifies the destination (987654321 in my example).
The ISSA Journal featured my article on Network Device Forensics, making it available to everyone.
And I’m giving a 2-day training on PDF at Hack In The Box Amsterdam 2013.
I added several new fields to the output produce by my new tool AnalyzePESig:
- issuer unique id
- subject unique id
I made a very small change to XORSearch’s source code (dropped malloc.h) so that it compiles on OSX.
You can find the new version on XORSearch’s page.
You probably know by now that Adobe will revoke a compromised code signing certificate in a couple of days. As we seem to have more code signing related security incidents recently, I started to develop a couple of new tools.
AnalyzePESig is a tool to check signatures in PE files, just like Sysinternals’ sigcheck. But with a couple of differences.
First, when a signature is not valid, AnalyzePESig will tell you why and still display information about the invalid signature and related certificates. Second, AnalyzePESig displays more information and third, it is open source.
Here is how you use AnalyzePESig to look for executables signed with that Adobe certificate that will soon be revoked:
analyzepesig -e -v -s -o windows.csv c:\windows
This will produce a CSV list of all executables found in the c:\windows directory.
Filter this list for lines including string fdf01dd3f37c66ac4c779d92623c77814a07fe4c (this is the fingerprint of the compromised certificate):
As you can see, I’ve Flash components signed with this compromised certificate. Now, this does not mean that these executables are compromised. To get a better idea, I can use my virustotal-search tool to search VirusTotal.
And here is another example, JP2KLib.dll, a DLL of Adobe Reader X:
I’ve worked on a couple of new tools to analyze the digital signature found in PE files. In this post, I’m sharing some invalid signatures I found on my machines.
This signature is invalid because the certificate expired:
Normally, the fact that it expired shouldn’t cause the signature to become invalid, but here it does because the author forgot to countersign the signature with a timestamping service:
I also found several files where the root certificate used in the signatures uses a signature algorithm based on the MD2 hash:
And last a signature with a revoked certificate:
Remember Realtek Semiconductor? Their private key was compromised and used to sign Stuxnet components.
I had some problems with a Windows XP prefetch file, so I wrote a 010 Editor template using the Forensics Wiki’s information on prefetch files.
I finally took the time to merge UserAssist version 2.4.3 and UserAssist version 2.5.0 (Windows 7) into UserAssist version 2.6.0.
Thus version 2.6.0 supports all versions of Windows starting with Windows 2000 up to Windows 8. Support for Windows 8 is experimental.