🔐Using Frida to decrypt sensitive information in mobile applications requests pt 1

Using Dynamic instrumentation to decrypt information developers thought you wouldn't

TL:DR

There's always a encrypt/decrypt function at the android/IOS code that will enable you to hook it and get the unencrypted string

Encrypt - Always hook the arguments of the functions that will be something like: (Decrypted_string, key, iv) in case of AES.
Decrypt - Always hook the returning value.

If the Code is ofuscated use native Hooks to

javax.crypto.spec.SecretKeySpec
javax.crypto.spec.IvParameterSpec
javax.crypto.Cipher

Introduction

Mobile applications may use client-side cryptography for various reasons, including:

Security: Client-side cryptography can provide an additional layer of security to protect sensitive user data. By encrypting data on the client-side, the data is protected even if the server or network is compromised.
Privacy: Client-side cryptography can be used to protect user privacy by ensuring that sensitive data is not transmitted in plain text over the network. This can prevent unauthorized access to sensitive user data.
Offline functionality: Client-side cryptography can be used to enable offline functionality in Android applications. By encrypting data on the client-side, the application can store encrypted data locally and decrypt it when needed, without requiring network connectivity.
Performance: Client-side cryptography can improve the performance of Android applications by reducing the amount of data that needs to be transmitted over the network. By encrypting data on the client-side, only the encrypted data needs to be transmitted, reducing the amount of network bandwidth required.

But this could be an issue for us pentesters as in an assessment if we intercept encrypted data we would not be able to modify it in any way, we would not even know what are the parameters and it's values.

Luckily we have Frida to assist us in this case, even if the application is completely ofuscated we have some ways to intercept and decrypt the information that is passed though our devices.

The Situation

Let's take a look of what it looks like to have a encrypted POST request Payload.

As you can see we have no access to what is inside of this request making it impossible for us to test any of the parameters that are being passed.

The Task

So we need to be able to decrypt this payload, as it's a AES CBC payload, we need to discover the Secret key and the IV that was used so we can decrypt, modify (to test the parameters), and send it again to the server.

There are several ways to approach this Task, we will be approaching the straight forward method at this part, and in the next one we will try to dig deeper in what we discover around here.

You always need to know that when creating a cryptographic mechanism to mobile "client side" functions such as remember password (without querying the server side) or even sending encrypted HTTP requests it will always be possible to bypass it by using dynamic instrumentation.

What we need to know here is WHERE in the application code it's occouring the encryptand decrypt mechanisms.

The Action

We then proceed to reverse engineer the application to find out where it's happening.

Normally i would start by searching some imports that are inerent to the cryptographic proccess of Java, some of them are

```
javax.crypto.KeyGenerator
```
```
javax.crypto.Cipher
```
```
javax.crypto.SecretKey
```
```
javax.crypto.SecretKeyFactory
```
```
java.security.Key
```
```
javax.crypto.spec.IvParameterSpec
```
```
javax.crypto.spec.SecretKeySpec
```

Those are just some of them that could be used to find where are those pesky encrypt/decrypt methods are.

And when searching for decrypt or encrypt methods in ofuscated applications we should pay attention to the arguments and the return values of the methods, as they will have patterns that could distinguish them of the others

For the encrypt functions you should have mainly 3 arguments, (if the encryption you're dealing with is AES CBC):

Unencrypted String
Secret Key
IV

Return Value:

Encrypted string

This is very important as you can get the decrypted string before it's sent to the server in which you could use the Secret Key and the IV to automate the request encryption in order to do attacks such as brute forcing or any payload oriented attacks, such as sqlis and ssrf and others.

The Same applies to the decrypt function, but you can expect obviously that the arguments should contain:

Encrypted String
Secret Key
IV

Return Value:

Decrypted String

So in this case for the responses that come from the server you will need to intercept the return value of those functions as those will return the decrypted string. you could also decrypt the requests and encrypt afterwords to abuse client side security issues by changing the http response.

Example of what the code would look like

encrypt(final SecretKeySpec key, final byte[] iv, final byte[] message)

decrypt(final SecretKeySpec key, final byte[] iv, final byte[] decodedCipherText)

With that in mind we then should begin to use our frida to instrument the android application in order to progress into the pentest.

The Challenge:

One pretty common Lib that is used for this is the Scottyab AESCrypt Android, which is the one that we will be studying here, but the same applies to all the solutions that use AES to encrypt HTTP payloads.

the piece of code that we are dealing with:

The Bypass:

For the sake of our time we will use a super powerful tool, known as objection, in which we will use the command

android hooking watch class method [path.to.method.decrypt] --dump-return --dump-args

This should intercept the return values and the arguments of the methods giving you results such as these

You could use the same technique as the decrypt one with the encrypt method, but the return values would not be useful to us, so you could simply use:

android hooking watch class method [path.to.method.encrypt] --dump-args

Hope this helped in the assessments that you may come across :)

In the next part i will show you how to bypass this same protection using native methods making it generic so you can use it in any assessment.