Dissecting the GoDaddy email notifier - Part 3

It’s been sometime since I made a post and that kinda sucks. I’ve been a bit swamped with work and have not had any real time to do my own stuff. Presently out in Cairo. Pyramids are phun.

You must be wondering why the hell I chose OllyDbg to make a simple hex edit in the previous post. The truth is, I was using it to try and study at exactly what point the SSL protocol is chosen and I found it at 0×414356.



By changing the CMP operation as in the picture above with 0×2E instead of 0×00, I can get the client to select plain old HTTP to speak to the main server. This is good, because I can now look at all the Web Service calls it makes and hopefully try to write a Linux version.
One other reason I chose OllyDbg is to study what the client actually does. My next quest is to study where my credentials are stored. Since this is Windows, I figure the first place to look would be the registry. By sniffing around the “string references” of the client, I did notice a specific registry key which is referenced: “HKEY_CURRENT_USER\Software\Starfield\WBEN\Settings”
 
Examining this registry key with regedit, I see the following:



That looks interesting. If I count the characters, it equates to the exact number for both my email address and password*. This means that their encryption algorithm generates fixed length cipher text. This most likely means that they’re using a substitution algorithm. Tsk, tsk, tsk. Substitution algorithms rely on some form of calculation (if any) and lookup in order to generate cipher text. Again, by looking at the encrypted strings, it is possible to determine the fact that a calculation involving the string length is also done. How do I deduce this? By looking at the last two characters in my email address (d1). They are both “qq” for “om” the last two letters in “.com”. This means that both “o” and “m” are equal to “q”. Not possible in direct lookups with calculation.

Another good thing is the fact that I know the credentials are stored in the registry. This shortens my hunt significantly because I only have to trace any specific registry calls to find out where the Encryption/Decryption algorithms are lurking. If I trace any references or calls to the specific registry key, then I will most likely find where the algorithms exist.

Using the “search for all string references” in Olly, I try to pull up all the calls to “HKEY_CURRENT_USER\Software\Starfield\WBEN\Settings”. I end up with this list:



The column “Called from” is what I’m interested in. This list contains all the addresses where the call to this registry key is made. I now have to follow each one and see if there is a “RegistrySetValue” call made. I look through each call one by one until I stumble upon this one:



It’s interesting because of the entry I have highlighted. This Unicode “d1” that’s on the stack is the registry entry for my email address. I follow this one to see where it goes and wind up discovering both the encryption and decryption algorithm. I will list them in the next part of this series. I think this post is dragging on long enough and I think it is about time I wrap it up. I will do just that in the next post and save everyone a lot of misery. I have successfully reversed the encryption/decryption algorithm and will post the python source code in my next post.