Hi everyone :-)
It's now a few years ago that I've written my last post here. But now, finally, I decided to restart my work and sharing here.
Today I want to share my knowledge or better analysis results on the app K-9 Mail for Android.
It's a nice, open source, multi-account mail program - developed by Mozilla - so the Android version of Thunderbird . In the last few years I had a few cases, where this app was used as mail app on Android devices.
Android-Version: Android 13
App-Version: 6.802
Used tools for analysis: DB Browser for SQLite, 010 Editor, File Browser, Python (for developing parser for aLEAPP)
Path
The path of the application data is:
/data/data/com.fsck.k9
I checked all folders inside this one.
The most interesting is the folder databases.
Let's see if I am correct, first I'll take a look into the preferences_storage file.
Accounts
In this database I find the table preferences_storage with the following content (column1 = primkey, column2 = value):
The other account (UUID begins with 37e364a0), that is a Gmail account, uses OAUTH for connection, there is no Password in the JSON because of the different used authorization mechanism.
Okay, so I know that the UUIDs relate to the accounts, let us see what is in the other databases.
Messages
This table gives an overview of all messages for an account including a preview of the messages, the number of attachments, etc.
There is also a table folders - with that we can also see in which folder the mails are stored.
IN the database there are a lot more tables. For me most interesting was the table message_parts, that, like the name says, holds the Content parts of the messages.
I can also see attachments, or at least the reference to them, in this table. But where are these attachments stored?
Attachments
As I could see in the folder structure of the folder databases there are two folders, starting with the already known UUIDs and ending with "db_att". Well, it could be, that the attachments are in these folders.
There are a lot of files, just with an id. This id corresponds with the field id in the table message_parts.
I tested sending a png-file to one of the mail accounts. Finally the file landed there, but base64 encoded. So yes, attachments, but also message parts that are too big to store directly in the database, can be found in this folder.
When testing sending the png file I recognized when exactly the png was stored in this folder. I will explain now:
Handling of Mails and Attachments
I did a four step process:
1. E-Mail is just received on the device and opened.
2. The content is downloaded (by default K-9 Mail won't download any attachments or inserted images automatically, that's a security and privacy feature)
3. The attachments is additionally saved
4. The mail is deleted
Step 1: E-Mail received and opened
In the table messages the is the message itself and in the table message_parts there is the content and a row for the attachment, but the attachment content is not on the device.
Step 2: Content downloaded
Now the attachment is on the device in the folder for the attachments.
In the table message_parts the field data_location has changed from 0 to 2 for the attachment entry.
Step 3: Attachments locally saved
When saving an attachment the user can choose where to save. The png file is than saved there (base64 encoded). But in the app context I could not find any traces of this. So at least for now I would not know, the an attachments was stored in a different location on the device.
Step 4: E-Mail deleted
Finally I deleted the mail.
The file of the attachment in the attachment folder is gone. I did not try to recover it.
And the entries in the database are gone.
I can only see the now missing id in the table messages. So I would at least know, that one message is missing.
Important to say: It is possible, that the deleting mechanism is dependent on the server settings. I had thought, that the deleted message would first be moved into the "deleted" folder of the account, but at least for my account here, this did not happen.
The field data_location
When testing I could see changes in the field data_location in the table message_parts.
For now I can say the following:
Value 0 = The attachment is not downloaded and so not on the device
Value 1 = The message part and/or attachment is stored directly in the table, field data
Value 2 = Attachment/message part is stored in the attachment directory
Value 3 = I don't know yet - it seems there is something left on the server but already something stored on the device - but for the moment I just cannot say more
Parsing and decoding
So, after my analysis I also wanted to automate the parsing of this data based on my analysis.
For this I decided to write a plugin/parser for aLEAPP. If you don't know it already -> pretty nice tool, created by Alexis Brignoni and maintained by a lot of cool people from the DFIR field.
You can find the code and the releases following this link: https://github.com/abrignoni/ALEAPP
My pull request with this plugin/parser can be found here: https://github.com/abrignoni/ALEAPP/pull/485
My parser will get out the accounts, including the password and the server settings. And than will get the messages per account.
At the moment it is a bit tricky with the decoding of the message content - I am not very familiar with mail encoding - but I will get it work soon - it is just another thing I need to understand how it works. Too many different encoding formats :-D
What is currently missing:
The content of the attachments are not shown. The parser currently only give hint, that there are attachments.
But also here - refinement will come as soon as I have some more time to code it.
Conclusion
K-9 Mail is an app than be found on Android devices.
From my current knowledge not all commercial tools in the DFIR field can decode this app.
When doing analysis it is now much easier to also create a parser/decoder, because aLEAPP (and also the other "LEAPPs") exist and give an easy way to decode and than visualize the data.
I am just at the beginning. I already pushed my parser for the Withings Health Mate App last week - and now I created the next pull request for aLEAPP with this parser.
I want to get better - especially in the frontend - how to show the data in a better way, not just tables everytime ;-). It's everything there I need - now I just need to develope it. ;-)
Thx for your time, hope you had a nice read.
Special thanks to the developers/contributors of ALEAPP.
For any questions and suggestions, do not hesitate to contact me or leave a comment.
No comments:
Post a Comment