I am trying to learn more about web security through looking into how various iOS native apps work under the hood. I have been using Burp Suite as the MITM tool to sniff out the network traffic sent and received from the apps, and on the iPhone I have SSL Kill Switch 2 installed to bypass any certificate pinning. It's very interesting and amazing to see how everything works under the hood, for a beginner like myself.

I had no trouble at all with most of the apps, this includes some apps that are supposed to have high security, such as several mobile banking apps - as soon as the SSL is lifted, everything is visible in plain text. Interestingly, some mobile games are giving me a hard time.


The intercepted traffic appears to be encrypted JSON files. For example,

"a3vSYuq2: {"Kn51uR4Y":

What I have done

If I understand correctly, I am now in the realms of decryption. Using some analytical approaches I have found from Googling, here are some of my findings (some may seem very obvious and trivial to the experienced):

  1. All requests sent from the app are in this exact format/structure. The encrypted key names are always the same, only the values differ.

  2. The value to the key aV6cLn3v seem to correspond to some sort of timestamp, as it is ever-increasing.

  3. I previous suspected that the value corresponding to the key Hhgi79M1 would be some check-bits based on the timestamp, but it is not. Performing the same action in the game will lead to the same value, despite different timestamps. However, different actions will yield different values.

  4. The value for the key Kn51uR4Y is where the actual payload is. I believe it is a JSON beneath the encryption, but I am not sure.

  5. The / signs in the payload seem to be separators for segments of data. The second segment /6vy61RFO/ seems to be the check-bits based on the timestamp. Because performing two identical actions in game results in two almost identical JSONs, except for the timestamp and this particular section in the payload.

  6. The payload's encryption has got something to do with Base64 or AES, because of the signature trailing =('s), and different payloads' lengths are always multiples of 4. I am not sure if the latter means anything.

  7. The encryption key used seems to be constant. It does not change from different sessions and on different devices.


Am I right in my analysis so far? Where should I go from here? With my almost-null knowledge in these fields, I am not sure what's the next step to take. I am think I might need to decompile the app and look into the binaries to try to see if I can find the decryption key/function lying around. But I am not sure.

I am aware that there will be a lot of learning ahead, but I don't mind it since I am enjoying it very much and I would appreciate greatly some help, even if it's just a quick list of the topics and URLs I should look into.

Update 2015/11/23

I dumped out the decrypted binaries of the app and ran a strings command on them, then I made a Python script to successfully pick out the encryption key. Thanks to all that have helped!

  • 2
    Certainly looks like a base 64 representation of an encrypted data structure. Assuming it is a fixed encryption key, it'll probably be embedded in the executable somewhere, so you would need to decompile, although sometimes the strings command can work wonders. Make sure you don't fall foul of local computer misuse laws - passive observation is usually fine, but sending data can cause problems in some jurisdictions!
    – Matthew
    Commented Nov 13, 2015 at 13:51
  • Thank you Matthew, for your input and words of caution. I will definitely keep that in mind. I have only the intention for passive observation, and I will not actively send any modified data. It's not even a game that I am interested in :P I will report back here if I have any success with the strings command. Thank you again! Commented Nov 13, 2015 at 14:06
  • 1
    Does this help at all? github.com/bsuh/bfdb/blob/master/util.py Commented Nov 13, 2015 at 18:38
  • @SteveSether that's actually surprisingly helpful. I can't believe I never tried just google the encrypted keys themselves. Turns out other people have already been working on it. The repo confirmed that the encryption method being used is AES with 128-bit key and PKCS5 padding. That's a very good breakthrough. I will now only have to look for the encryption key inside the binaries. Thank you! Commented Nov 14, 2015 at 7:22
  • Should there be a closing quote on "a3vSYuq2"?
    – Patrick M
    Commented Apr 18, 2016 at 15:12

2 Answers 2


I would say you are right so far, but this is just guessing so far (probably right though :)).

Yes, I think reverse engineering the application binary is your next step. If you identify the encryption function and the key, then you can reimplement the crypto functions in say, python, and decrypt/encrypt your values as you like.


  1. Get your hands on the application binary. (either extract it from the phone (might need to jailbreak it), or download the IPA from iTunes, more info here)

  2. Run a "strings" on the application. It can results in many interesting strings, it might even list you the encryption key or some clues about what algorithm is used.

  3. Use a static debugger, such as IDA Pro or Hopper (need to support ARM) to peek into the binary. If you are lucky it has the function names, which could help you greatly to find what you are looking for. If not, you could try to search for known crypto constants in the binary. Check out my answer about that here. Also check out this and this. If you found a constant used in the crypto function, you can cross-reference where that constant is accessed/used, and eventually you will find the key as a parameter or static variable used by the crypto function.

  4. If all else fails, you will have to use a dynamic debugger (such as GDB), and attach to the process running on the phone and work from there. Find a piece of data that you know for sure that it will be eventually encrypted, and trace the function calls accessing that data until it's encrypted.

Don't forget about the Reverse Engineering and Crypto stackexchange sites, and of course google a lot! ;)

  • 2
    Thank you, Dominik, for the detailed information. Debugger like IDA, GDB, even cycript have come under my radar in my previous googling attempts. It's good to know I'm heading towards the right direction. Will keep posted if I have any success. Cheers Commented Nov 13, 2015 at 16:38
  • 1
    Hi Dominik, please see the update on the question. I have set your answer as the correct answer as it helped me the most along the way. Thank you for your help! Commented Nov 23, 2015 at 13:15

I think you're on the right track. Unpacking and analysis of the app binaries is definitely the next step though. Being an app developer, I'll throw some theories out there and maybe they'll help you.

Because of the fact that this looks like metadata json containing a fully encrypted request, I would guess that the aV6cLn3v value is perhaps some sort of either transaction ID (referring to a previous transaction. Looks too small to be a useful timestamp, also timestamps can be in the HTTP headers which would make it redundant to put in JSON request metadata). The other field might perhaps be either the app's current generated hash for the state of particular data it already has, which is useful for requesting deltas (saves mobile data usage), or it could be some sort of method identifier.

If I had to take a wild guess, I'd say unencrypting at least the keys in this JSON would look like:

    "metadata" : {"transactionId" : "542668", "delta" : "ynB7X5P9"},
    "request" : {"body": "encrypted data goes here"}

Taking a look at the app could not hurt at all, but ensure you do not make any requests to the server manually (depending on your local laws).

  • Thank you Justin. Your answer confirmed my preliminary analysis. I will keep the post updated after I dig deeper. Commented Nov 13, 2015 at 15:41

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .