How to determine what type of encryption has been used?

Question

i play an android game which seems to send the player's high score in an encrypted format . some thing like (f11cca35236eebbdc26a0ce45876d117) a 32 character code tried MD5 but no result found. i wanna know is there any way i could decrypt it or at least find the encryption method? thanks

Answer 1

First of all, it sounds like you're trying to cheat at a game. Don't do that.

Now some background on what is going on. Lets first look at the difference between encryption vs hashing:

• Encryption is the process on encoding information in such a way that it can be decoded again given the right information about the encoding process (such as an encryption key). This is used for secure communications such that the recipient understands a message (and is able to retrieve the original) but third parties are not able to read the message. The process goes something like this:

  "Message" » {secret formula} » (scramble) » {reverse of secret formula} » "Message"

  In other words what goes in can be gotten out if you know the secret. Obviously in this scenario what the secret is is pretty important. In computer cryptography is is usually not the formula itself that is secret, it is the values used in the formula that are the secret keys. More on this in a second.

• Hashing is the process or reducing a blob of information down to a single value (usually of a fixed length much shorter than the original) that is unique to the given input. This is can be used to confirm the integrity of a message but does not actually contain the message. This looks something like this:

  [Value1] » 7a258c461b48c794c0b5110b35382d1e
  [Value2] » 926e0eddb765d66502eac40a4ead9409
  

  Hashing is often used to store passwords. Note that this is a one way operation. Given the same input you will always get the same hash¹:

  [Value1] » 7a258c461b48c794c0b5110b35382d1e
  [Value1] » 7a258c461b48c794c0b5110b35382d1e
  

  But one cannot know just from the hash what the input was².

That background aside, MD5 is a hash algorithm. It is not likely that your game sends hash data back to the server because the data would be uninterpretable. It wouldn't tell them what your score was! You can pretty much rule out anything that is a hashing algorithm.

Now there are two basic ways an encryption process like in the first bullet point above can work.

1. The same secret value can be used both to encrypt and decrypt the content.

   This is the usual pattern for things like password protected documents.

   • User A uses {password} to encrypt a document.
   • The encrypted document is passed around.
   • Only users that know {password} can decrypt and read the contents.

2. A matched pair of values can be generated such that one half of the pair is used to encrypt content that only the other half of the pair can decrypt.

   • User A generates a key pair.
   • They then pass around the public half of the key pair but keep the private half to themselves.
   • Any user may encrypt documents or values using the User A's public key, but the resulting data may only be decrypted by User A using their private key.

If you game uses a basic password model as in #1, the password and algorithm used will be hard coded somewhere in the source code and burred somewhere in the actual app. Anybody that does some dissection work will be able to figure out what that value is and decrypt any further messages they intercept. Hopefully your application did NOT do this!

The proper way would be for to public key cryptography as in #2 above. The software developer would have generated a key pair for their software. The public half would be built into the software somewhere and all values can be encoded using that key before being sent over the wire. Once they reach the developer's servers, the data may be decoded using the private half of the key.

Conclusion

If the developer has used the proper technology for the job, you will not be able to decrypt the data being sent because you do not have the private key needed to decode it. The public key may be buried in the software somewhere, but that will not get you the data.

If they have NOT done their job properly then there might be trace clues in the software itself that give you enough information to decrypt the data yourself.

Actually identifying the method and specific algorithm used in this case is beyond the scope of this answer and is left for the reader to do further research on. Hopefully this overview of the possibilities will provide a better understanding of what sort of things you are looking for.

_{² This is why using salted hashes is paramount to the security of password systems!}

_{² Note I said just from the hash because is is possible to guess or use pre-defined tables to know what input generated a hash, but a secure hash itself will not actually contain the data used to generate it.}

Answer 2

Okay. This is kinda cool. A great way to learn about encryption.

Few things, not really your answer.

Even if you know how it was encrypted, you wouldn't be able to do anything with it. The more important thing is the key used to encrypt it. What you have posted could be plain text hashed, encrypted bytes hashed or encoded.

If you just wanted to find out how its done, you can try running a dubugger on the android kernel and sift through the system calls to see what ssl lib they use if not builtin to their code. Im sure at that level, you can also try to run a debugger on their process and look at the system calls.

Look at this, and this and do some more google searches on that.

My other question for you is, how are you seeing that being sent? Wireshark, tcpdump etc...?

If so, you may be seeing the https packets and thats not telling the whole story.

Look into mitmProxy. They have a part on their site to do game hacking like you are saying. Something like this.

I'd recommend getting some experience with that.

All in all, if its being encrypted client side (your android) you can figure out how to undo it eventually. Might not be worth it for a game, but a great learning experience never the less.