Intro

Fridump is an open source memory dumper tool, used to retrieve data stored in RAM from all different devices and operating systems. It is using as base Frida (excellent framework, if you don’t know it you should give it a look!) to scan the memory from the access level of a specific application and dump the accessible sectors to separate files.

Why?

During several penetration testing assessments I have performed on mobile apps, there were several instances were I needed to perform a memory dump of the device. This is due to the fact that in cases were cryptographic storage is used, if the access controls are not implemented correctly, then the decryption key may be preloaded in memory and potentially be stolen. This can only be performed on a jailbroken device, as root access is required to gain access to the memory space. During my search for a sufficient tool that would perform this operation, I couldn’t find anything easy to use and all guides needed to manually use gdb/lldb. The only guide that got closer to achieving this operation was this post from the guys in Netspi (excellent resource, again check them out!), however I wanted something that would be more automated.
Here is where Frida comes in. Frida injects itself into a process and can read and scan the memory from the perspective of that process. It is fairly reliable and it has proper documentation that keeps expanding with new functionalities all the time. What’s more, it can be scripted using its Python API and can be run standalone on a jailbroken device or potentially built-in an application as a library (haven’t checked it, so I can’t really comment).

The only negatives that I have found while using Frida (and you should keep in mind) are:

Both frida-server and frida-client must be running the same version, as significant changes happen between releases, and there is no direct error to point the difference out.
Frida can check the memory for address spaces with specific permissions, similar to how it works with linux.
It can search the address space for access ‘r–‘,rw-‘ or ‘rwx’. However it is looking for exact matches. Therefore, if there is an address space with only read permissions (‘r–‘), it will not be picked up by a search for read & write privileges (there is no OR statement). Therefore if you want to find all addresses that have read or write privileges, you have to scan the memory separately.
If the address space is big enough (that depends on device), trying to read the whole memory chunk in one go can crash the application.

Other than these really small negatives, Frida is an awesome tool and that’s why I decided to use it for the memory dumper.

How to use Fridump

To use Fridump, you can call

fridump [-h] [-o dir] [-u] [-v] [-r] [-s] [--max-size bytes] process

The following are the main flags that can be used with fridump:

positional arguments:
process            the process that you will be injecting to

optional arguments:
-h, --help        show this help message and exit
-o dir, --out dir provide full output directory path. (def: 'dump')
-u, --usb         device connected over usb
-v, --verbose     verbose
-r, --read-only   dump read-only parts of memory. More data, more errors
-s, --strings     run strings on all dump files. Saved in output dir.
--max-size bytes  maximum size of dump file in bytes (def: 20971520)

I will go through all of these flags and provide also some example uses.

process: This is the only mandatory argument when calling Fridump. It refers to the name of the process that Frida is going to be injected to dump the memory address.
You can fin the name of the process by using frida-ps, which is installed by default when installing Frida.
To find a process running on a device running over USB, you have to run frida-ps -U
-h: Show the help message
-o dir: Provide a directory where all the memory dump files will be placed. The default directory is CurrentWorkingDirectory/dump
-u: This is a mandatory argument if the target application is running on a device connected over USB
-v: Turn on DEBUG mode, which will show a lot more information in console.
-r: Performs a scan looking for memory spaces that allow only read permission (‘r–‘) for the app. This will return far more information than the default read&write scan (‘rw-‘), however it will possibly touch on memory addresses that shouldn’t, causing memory violations errors. This is not something that catastrophic, however it may potentially lead to a crash from the application (rare).
-s: Runs a really simplistic version of the linux strings command against all dump files and creates a new strings.txt file in the output directory. As this is a simple version of strings, it is advised that if running on a linux host, to use the built-in command as well.
–max-size: The maximum size of a chunk that Fridump is going to dump from the memory at a time

Some more information regarding the –max-size flag. I have mentioned before that if a device can’t handle the size of the memory space that is being read by Frida, this can result to a crash of the application (and a crash to Frida as a result). To get around that issue, I have implemented a splitter method inside Fridump. If the memory space is bigger than the default max size (20MB), then the specific memory address space will be split into smaller 20MB chunks and will be read consecutively. The –max-size flag can be used to set any number of bytes that the maximum size of a chunk will be, replacing the default 20MB value.

So if while using Fridump you see the application crashing and restarting, try to different values of max-size. You may have to go as low as 1MB at a time, to ensure that the application will not crush.

To find the value, you can use a MByte to Byte converter like this one here.

Some sample values are the following: