I used simple reversing to find the certificate. As reported by others, program is packed and self-encrypted (like typical adware/malware). The proper way to reverse engineer this is to run the software in a debugger (or IDApro), setting break point right after it decrypts itself. The goal is to set the right break point before it actually infects your machine -- reversers have been know to infect themselves this way.
The ghetto way is to just to run this on a machine, infecting yourself, and run "procdump" (by @markrussinovich) in order to dump the process's memory. That's what I did, by running the following command:
procdump -am VisualDiscovery.exe super.dmp
The proper reversing is to actually tear apart the memory structures, such as using VisualStudio:
The ghetto reversing is to run strings. This is an ancient (mid-1980s) program that simple extracts human readable strings out of a binary file, discarding the rest. It's really a stupid simple program.
The ghetto reversing is to run strings. This is an ancient (mid-1980s) program that simple extracts human readable strings out of a binary file, discarding the rest. It's really a stupid simple program.
strings super.dmp > super.txt
At that point, I load the file super.txt into a text editor and searched for the string "PRIVATE KEY". Sure enough, it popped right up. It's actually located several times in the memory dump.
At this point, I copied/pasted the certificate into a file super.pem. I them attempted to look at it using OpenSSL. However, I was presented with a password prompt. This file has been encrypted with a password.
Okay, that's annoying, but that just means we need to crack the password. However, I can't find a password cracker on the Internet that handles SSL PEM files, so I wrote my own certificate password cracker. It's pretty ghetto, using the OpenSSL decrypt API in a single thread, so it's not pretty. But it's sufficient for my needs.
The encryption is actually pretty good, meaning I can only do a couple hundred guesses per second. This means that there is no chance of brute-forcing any password longer than 5 characters (brute-force means to try all possible combinations), it'd take billions of years. Instead, I want to do a dictionary attack. This is where I load a file of common words and test them one-by-one to see if they work.
I tried the small dictionary john.dict that comes with John-the-Ripper, and it didn't find anything. But of course, I don't need a real dictionary. The password is probably also in the clear in the memory dump. I could just use the file super.txt as my dictionary! I tried this, but it was taking a long time, with 150k unique lines of text. It'd take many hours to complete. To speed things up, I filtered the list for just lower-case words
grep "^[a-z]$" super.txt | sort | uniq > super.dict
This leaves a dictionary of only 2203 words. I ran my cracking tool, and found the password in 10 seconds, "komodia".
Armed with this password, I continued where I left off with the openssl command-line tool and successfully decoded the certificate. I can now use this to Man-in-the-Middle people with Lenovo desktops (in theory, I haven't tried it yet).
Note that the password "komodia" is suggestive -- that's a company that makes an SSL "redirector" for doing exactly the sort of interception that SuperFish is doing. They market it as security software so you can spy on your kids, and stuff.
(BTW, thanks to @chigley101 for linking a download of the software. Also note that @supersat and @paul_pearce found the password before I did, though as far as I know they haven't published it).
(BTW, thanks to @chigley101 for linking a download of the software. Also note that @supersat and @paul_pearce found the password before I did, though as far as I know they haven't published it).
2 comments:
I strongly suspect Komodia's Redirector shares the exact same certificate.
Yes, I have very little faith left in mankind, why ask ?
That regexp looks like a good way to make your dictionnary very small. Very very small.
Post a Comment