Friday, May 22, 2020

App Nandbox Messenger on Android

With this post I will give an overview on the app "Nandbox messenger" for Android.
Information on the app is available from

I've used Android 6 and Nandbox 1.6.485 for my analysis.

To use the messenger you need to register via mail or phone number. Only one is possible.


The path of the application data is:


Used Account

The used account can be found in the following file (sqlite-database):

Table: Profile

The earliest entry is the account used in the app.

You can get the username, MSISDN (for this app this is either the mail address or the phone number), the time the account was created (time in unix epoch ms UTC).
Also you can find the ACCOUNT_ID. This is the primary key in the table and is used as identifier for e.g. messages.

Additionally to the way above you can get the used MSISDN from another file:


It is a XML-file. The key "msisdn" holds the value.


The contacts can also be found in the main database:

Table: Profile

All entries except the earliest one.


All messages are stored in the main database:

Table: Message

Timestamps are in Unix Epoch (ms) UTC.
In the table you can also find the path to the media files sent/received (Column LOCAL_PATH)

Media Files


The sent/received images are stored at:


The name is unique and can be mapped to the message in the database "courgette".

Additionally the images are stored in the cache folder:


Here the images have the name [LID]_base64.jpg. LID is the id of the message in the database "courgette"

Audio Files

Audio Files are called Voice Notes in this App. They are stored at:


The files have unique names and are m4a files. The names can be mapped to the messages in the database "courgette".

What happens when deleting messages?

Additionally I've tested what happens if a user deletes the message. One of the features of this app is the recall of messages even on the device of the communication partner.

I tested both sides. What happens on the side of the user who deletes and what happens on the device of the communication partner.

Local device

When deleting a message on the own device, the message is removed from the database. One can see that a message is missing because a LID is missing. I've not tested the recovery of the entry via carving.
If there was a media file in the message this file would be deleted in the file systems media folder. For an image this was


But the image is still available in the cache folder.


Remote Device

On the remote device you will see a message with the text "**message has been recalled**".
This is also the content in the database.
But: for media files the data is still available in the entry of the database. The path to the image/audio file is in there. And the files itself are also still in the filesystem

Finally, when the user on the remote device now deletes the message with the content "**message has been recalled**" the entry is deleted in the database. But a media file would not be removed from the file system.


Nandbox in hte used version doesn't use any encryption which makes the analysis simple. And the cache is a goldmine for media files sent or received.

I have not tested the group feature and also not tested the multiple profile feature. So a bit more testing can be done.

Hope you had a fun and informative read.

Thursday, May 21, 2020

App SKOUT on Android

What is it about?

HEy everyone, this post is about the app "SKOUT" on Android. It is a really short post just the basics I found while doing a quick analysis related to a case. And because my last post is a long while ago I decided to quickly share my results.

Part of the results in here were extracted from the published Android 10 image by @josh_hickman1. Kudos to him for his great work! (Source:

SKOUT is a Social Network and the app offers features like chatting, meeting via video chat and broadcasting. More info can be found or

Used App Version: 6.17.0
Used Android Version: 10

Where can the information be found?

Android path:


Used Account:

Here you can find the userid and the username:

And here you can find the used mail address and the used password in clear text. (Yeah, really - clear text):


The contacts can be found in the following database:

Table: skoutUserTable

The timestamp stored for the last message of a user is in epoch milliseconds UTC.


The messages can be found in the following database:

Table: SkoutMessagesTable

The timestamps stored for the messages are in epoch milliseconds UTC.

Media Files:

I was not able to find the media files sent/received on the device. Some images are in the cache folder

But I was not able to map any of them to a message.

Additional Files/Info:

You can find the last logged location in the following file:


Thursday, January 30, 2020

How to handle Bitlocker Encrypted Volumes

The question

You are on-site. PC is on. You recognize an open Bitlocker drive. What now?
Just take a physical image of the drive because it is open and everything is fine, and then you have all the data? Well, short answer -> no. You would have a bad day the moment you want to analyze the data because you would see that the content of your created image is encrypted.

I will explain in this post what you can do on-site to get all data from the Bitlocker Volume. And I will explain how to handle created images when the data is Bitlocker encrypted on it on Windows and Linux with free tools.

IMPORTANT: I will only focus on the data in the Bitlocker Volume. Not the other volatile data in a running system. So, when I write you can shutdown the machine without data loss I only mean the stored data in the Bitlocker volume!

First: On-Site

To do what I explain here you need Administrator permission on the machine and you need an imaging tool. I use FTK Imager Light. It's free to download from

You find in the Explorer something like this:

An open Bitlocker drive. Good, data is accessible. But, if you now just create a physical image of the drive, the data will be encrypted in your image.

I tested this with FTK Imager, selected the physical drive and created an image. See the result below:

Unrecognized File System. To be sure, I also added the image to Autopsy 4.14. Same there, no data from the inside of the encrypted volume.

Get Recovery Key

Okay, so I would first get the Recovery Key from the drive. With this you can decrypt the encrypted data later if necessary.

1. Open an elevated power shell
2. Type in the command manage-bde.exe -status

As you can see above the drive only encrypted the used space and a numerical password is used.

3. Type in command manage-bde.exe -protectors -get F:
Where "F:" is the corresponding drive letter.

From the above output you can find the recovery key:

Create Image?

Now the question: Shall we create an image directly from the running system? We could. I see four possibilities:

1. Create image from the physical drive, then you need to decrypt it later with the Recovery Key

2. Create image of the logical drive.
One could say that when imaging the logical drive you won't get deleted data. That's not correct. You get the same data like from the physical drive but not the files outside of the encrypted partition. So you only get the data in the encrypted partition, nothing else.

3. Don't create an Image.
Shut down the machine and create the image later. You have the recovery key so no problem.

4. Decrypt the volume on the machine and then create a Physical Image.
This could take a long time. I don't recommend this way but it is possible.

What would I do? If I can take the computer with me, I would shut it down and image it later, so I don't loose time On-Site. But this really depends on the case. As I stated at the beginning, I only focus on the Bitlocker part here. Please don't get me wrong. I definitely would backup data like Passwords from Browser, running processes, open Network Connections etc. and create a RAM dump before I shut down the machine.

Second: At lab, physical image of Bitlocker Volume, Windows

As already written, when having a physical image of a Bitlocker volume the data is encrypted. But, if you have the recovery key, no problem. So how to handle the encrypted image on a Windows machine?

What do you need:

1. An E01-Image from the disk.
2. A Windows System that can handle Bitlocker (Professional Version or Enterprise Version at least Windows 7)
3. The Recovery Key

You can mount the E01 with Arsenal Image Mounter ( Don't try to mount it with FTK Imager, that won't work.
After it's mounted you can open the volume via the Windows Explorer.

When that is successful you can then create an image of the logical drive via FTK Imager.
You can than analyse the data e.g. in Autopsy.

As you can see, no paid software needed.
With e.g. Magnet AXIOM or EnCase you could directly open the images with the Recovery Key. But, under the hood they will first decrypt the data.

One other way, just to mention it:
You could also mount the image with a write through file in Arsenal Image Mounter. Than it would be writeable. After this you could decrypt the volume and than create a physical image via FTK Imager.

Third: At lab, physical image of Bitlocker Volume, Linux

I used Tsurugi Linux ( for this. All necessary tools are installed in this great distro.

What do you need:

1. An E01-Image from the disk.
2. A linux system with the following tools:
a) xmount
b) sleuthkit
c) libbde-utils
d) guymager
e) dd
f) mount

Step 1: Use xmount

First we take the E01 and use xmount to create a raw image that we can later use with bdemount.

sudo xmount --owcache /tmp/bitlocker_test --in ewf ~/Desktop/Bitlocker_physisch_test.E01 --out raw ~/xmount_pount/


I use the option "owcache" that creates an overlay file to make the image writable. For this example this is optional.
Please use the help function to find all options.


--owcache: Overlay file, content will be overwritten if file already exists.
--in ewf: Type of the image is ewf
--out raw: I want a RAW image as output.

Step 2: Use Sleuthkit

We need the offset of the encrypted partition in the image, for this we use the tool "mmls" from the sleuthkit.

mmls ~/xmount_pount/Bitlocker_physisch_test.dd


You could also use the command directly on the E01-Image.

You can see the partition table of the image. The NTFS partition starts at sector 2048. This is the encrypted partition.

We can check this with the tool "fls" from the sleuthkit.

fls -o 2048 ~/xmount_pount/Bitlocker_physisch_test.dd


Sleuthkit cannot recognize the file system type because of Bitlocker. Bitlocker is not support by the Sleuthkit.

We can take a look at the hex values to see if it is really Bitlocker:

dd if=~/xmount_pount/Bitlocker_physisch_test.dd skip=2048 count=1 | xxd


With the values EB 58 90 2D 46 56 45 2D 46 53 2D "ëX¬|-FVE-FS-" we now know that the partition is Bitlocker encrypted with Windows 7 or higher.

Step 3: Use bdeinfo

Okay, let us get the information of the bitlocker volume with the tool "bdeinfo" from libbde-utils.

bdeinfo -o $((512*2048)) ~/xmount_pount/Bitlocker_physisch_test.dd


We use the offset 512 * 2048 because the tool wants as offset the bytes. One sector for our images has 512 bytes and this times the 2048 sector offset.

We get information like the identifier of the recovery key and the used encryption algorithm and the volume identifier.
But, that's the most important: We now know that we are correct with the offset and that there is the bitlocker volume.

Step 4: Use bdemount

Now we want to get access to the data in the volume.

sudo bdemount -p 12345678 -o $((512*2048)) ~/xmount_pount/Bitlocker_physisch_test.dd ~/bde_mount/


No error message means it has worked.
I used "-p 12345678" because that is the user password.
If you want to use the recovery key you would use "-r [RECOVERYKEY]" instead.
The created file with the unencrypted data in it is now at "~/bde_mount"

Step 5: Let's mount it

Okay, last step, than we have access to the data.

sudo mount -o loop,ro ~/bde_mount/bde1 ~/decrypt_mount

Nothing, no error means everything went well.

We mount the data to "~/decrypt_mount".
We mount it read-only ("ro") and use a loop device ("loop")

If yo have an older system with an older mount command you cannot use the option "loop". Than you would need to use the tool "losetup". I won't explain how to do this here, fell free to contact me if you need help.

Step 6: Look at the data

We can now go through the data at the mount point. E.g. list the content.

ls -al ~/decrypt_mount/


Step 7: Create image of unencrypted data

Now we can create an unencrypted image with guymager. Similar procedure than under Windows with FTK Imager. Just start the application "guymager".

When finished you can check the content e.g. with the tool "fls" from sleuthkit.

fls decrypted_bitlocker.E01


You don't need to give any offset, because the image is a partition image.

Now you can also analyse the data. e.g. load it into Autopsy.

All tools used are free.


Okay, this post was getting much longer than I thought. Thx for reading.

1. Keep in mind that just creating a physical image from an open Bitlocker Volume won't give you access to its data later. But, if you have the recovery key that's not a problem. So it seems to be a good idea to get the recovery key asap from the system.

2. On Windows you can mount an Image of a Bitlocker volume with Arsenal Image Mounter and create than an image of the decrypted data. If you have the Recovery Key.

3. On Linux you need a few steps in the terminal and a few tools. With Tsurugi Linux they are all onboard. But when having everything you can access the data without a problem.

4. You don't need to pay for the tools used here. They are free.