I am trying to retrieve a decrypting/deconing logic from a program. Unfortunately I have virtually no experiencing in reverse engineering.

I am building an alternative controller application for a multimedia device. The original controller is available for Windows (which I target) as well as for mac, ios and android. Most of the communication between the device and the controller application is similar to the UPnP protocol, therefor teransmitted in XML and readable in cleartext. There is one instance however where the device sends some sort of token to the controller (which the controller uses subsequently to authenticate against other services) and this transmission seems to be encoded/encrypted/obfuscated (referred as "encoded" in the text). This encoded form is transmitted in an XML field of a normal UPnP response.

I have made the following observations while monitoring several transmissions of the encoded form:

  • It always starts with 2: and is followed by what seems to be a base64 encoded string
  • When transmitted multiple times the sting changes even though the content supposedly did not change (this is under the assumption that no other variables like a timestamp are included before encoding). So some kind of salt could be present.
  • The length of the string remains the same if the data is not changed
  • If removing all tokens from the controller there is still some encoded data transmitted in this field. This leads me to thinking that either padding takes place, or (more likely) the encoded string decodes to some serialized from of data structure (maybe even XML).
  • The token that is used for authentication (so the decoded form) does remain the same even though the encoded version differs.

The application itself is written in c# but all the security related stuff (including decoding/handling the token) seems to be called using pINVOKE from a DLL which was not written in .net.

I ran signsrch on the dll where I suspect the encoding to take place however a lot of possible hits are returned (30+). When taking a look at the dll it seems that the openssl library is compiled into it so there might be a lot of false positives. The DLL also handles HTTPS communication so openssl is not necessarily related to the encoding method I am looking for.

I've tried to look into ida pro and windbg however what I read from tutorials this mainly revolves around setting breakpoints before clicking on a button that activates e.g. a check routine. However in my case the controller application receives this data once on application start (with dozens of other UPnP packets) and my guess is that decoding takes place on receiving the packet so there is no possibility to set an breakpoint to e.g. a button. What I was able to figure out however is that the decoded tokens are present in memory (however offsets differ each time the application is started). The encoded version does not seem to be present in memory at runtime.

Some examples: Encoded String when no token is configured:


Three strings representing (supposedly) the same data:




I'd love to hear suggestions how to approach this problem to get more insight.

  • Did you try to decompile the .net part ? Is it obfuscated ? – w s Jan 27 '14 at 7:30
  • I can open the .net part with dotPeek without issues. The problem is that receiving/decoding and using the string is completely handled within the non-.net DLL – leepfrog Jan 27 '14 at 12:34

Cant comment, so an answer it is :)

-- If you know what dll it is you need to look at and its written in .net, IDA will probably not be the best option (from personal experience).

If however you are still looking for a dll which you need to decompile, you might want to give APImon and procmon a shot to find what exactly needs decompiling.

I would suggest try using a .net decompiler, for example dotPeek or any other. You can generally read code as is from any .net program (not obfuscated / encrypted) If a dll is obfuscated, you can try deobfuscating it with de4dot or dump from memory and analyze that instead.

Above strings are definitely base64 encoded, so you are probably going to be looking for object.binary.base64

  • Sorry I did not make this clear. The general program is written in .net which I already took a look at with dotPeek. However everything related to receiving the encoded string, decoding it and using it for authentication against the remote service is done in the non-.net DLL. From my analysis it seems as the decoded string never leaves this DLL. – leepfrog Jan 27 '14 at 12:35
  • 2
    Got it :) I would start by looking at the exports of this dll to see if the names would be suggestive enough and do a bit of googling on these. Also, you may be able to pass the encrypted string as a parameter to a dll export (try ollydbg) and debug through it to see the whole thing in operation. – Sigtran Jan 27 '14 at 14:26

Have a look at the plugin for IDA Pro called IDA Scope. It has a crypto-identification facility that I think will help you.

enter image description here

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.