Puzzle by Finnish National Bureau of Investigation - write up

Finnish National Bureau of Investigation had a couple of positions open for “crime engineers” last summer. It was said in the job description that you would work with electronic devices that could be damaged or encrypted which make them difficult to investigate. In addition to get data out of these devices, you would analyze the data. This data could be then used in the related crime investigations.

As a part of this job announcement, there was also a puzzle to solve. It wasn’t mandatory to solve to apply for these positions, but by doing this puzzle you could understand what kind of work crime engineers are doing.

In this blog post I will walk through all of the tasks. If you think I've missed something relevant or something else that could be interesting, you can drop me a message on Twitter.

Task 1:

“Investigate the data dumped from a memory stick and arrange sectors into the right order. You need to get a working file system and find FLAG-1.”

After extracting the given file “part-1-image.bin.gz” there is a one file named “part-1-image.bin”. Its size is 139.1 megabytes. The file is opened in a hex editor and quickly viewed. There is data containing a string “FAT16” so it’s probably a FAT16 file system. It makes sense because we know the data is from a memory stick. There is also a very clear, repeating pattern in the data that's illustrated in the image 1.

Image 1. A sector.

These 512 bytes create a sector. All of these sectors need to be rearranged but we don't know the order.

What you should know is that it's flash memory inside a usb memory stick. It’s time to take a look into a structure of flash memory array that's illustrated in the image 2.

Image 2. A flash memory array. Src: https://bit.ly/2GWD0PV

 
There are a data area and a spare area in a page. In our data we’ve eight logical sectors per page. The size of data area is 512 bytes and the spare area is 16 bytes.

The spare area stores many kind of information. In our spare areas we need to look at logical block numbers (LBN). A memory controller is using the logical block numbers to create a file system.

All you need to do now is find every block with help of the logical block numbers starting from zero and write blocks without spare areas to a new file in the sequential order. Actually, there is one more thing. You need to understand that the correct data is found above the offset like illustrated in the image 3.

Image 3. The correct data.

I coded a Python script (not shared) to rearrange all blocks. In the image 4 it has just finished the job.

Image 4. All blocks rearranged.

As all blocks are now rearranged, you can take a look of your file system in a
hex editor again. The first piece should be a master boot record. If it's then the file system can be mounted. The offset in the image 5 is pointing to a boot sector.

Image 5. The mounted file system and FLAG-1.

FLAG-1: HALUAISITKO

Task 2:

“Investigate the file image of arranged usb memory to recognize the victim. You need to find the name of victim, the victim’s date of birth and FLAG-2.”

After extracting the given file “part-2-image.bin.gz” there is a one file named “part-2-image.bin”. Its size is 134.2 megabytes. Next, the file system image is mounted. The directory/file listing looks like the one in the task 1, but without the photo of FLAG-1.

When the file image is viewed in a hex editor, you can recognize some familiar files like images based on the file headers. But those images weren’t in the directory/file listing of the file system. To see if the files were deleted, we need to take a look into a root directory.

FAT file system has a root directory which contains entries for each file and directory in the file system. The structure of FAT16 file system is illustrated in the image 6.

Image 6. Fat file system. Src: https://bit.ly/2IAmgLM

The root directory (also known as a root folder) can be found after file allocation tables (FATx). The structure of root directory of part-2-image.bin is seen in the image 7.

Image 7. Root directory.

Each entry is 32 bytes in the root directory. If marked area is 64 bytes it contains also the entry of long file name. All the entries are marked in orange color in the image 7. The first byte tells us the status of filename. If it’s “E5”, it means the file has been deleted. Those entries are interesting, so I marked them red. To find the data of those file names, we need to see what’s the starting cluster where data resides. The blue balloons are indicating the locations. The file size is following after that.

To find the starting cluster three, the size of root directory must be known. In the FAT16 systems the size 512 entries – 16 kilobytes. You can also confirm this value from the data of boot sector. So, 16 kilobytes can be skipped from the start of root directory. Now we’re in the data section.

There is still a one thing to understand. To get the actual file allocation unit for the data, we need to subtract two (2) from the value of starting cluster. And we have the following formula:

data location = (starting cluster – 2) * 2048 + start of data section

If we go to the location of the first deleted entry (starting cluster is 03 00), we can see from the file header that it’s a JPEG image. This is illustrated in the image 8.

Image 8. Deleted data of an image.

I dumped the data manually from the hex editor. It’s an identify card (image 9) with day and month of birth and also name of the victim. The year is still needed.

Image 9. Identity card.

The next two entries with deleted file names had no data. The fourth root directory entry was interesting. It was pointing to a directory named “info”. It’s the same one seen in the picture 5. Start of the cluster is “C3 02” (707 in decimal). There is a sub directory in this location. A sub directory is like a root directory, but for files, which aren’t in top level of the file system.

In the sub directory we can see that a file named “happy.odp” has been removed (the first byte is E5). This is illustrated in ithe image 10. The file extension “.odp” refers to Openoffice presentation file. I dumped the bytes  to a file.

Image 10. Deleted data of a presentation file.

Opening the file using Libreoffice Impress gives an error – the file is corrupted. Maybe we're missing some data. Impress can try to repair it. It’s repaired successfully and we have a presentation with a smiling object. If we move the smiling object and other elements aside, more interesting elements appear. This is illustrated in the image 11.

Image 11. The deleted presentation file.

There are instructions in the presentation how to find the FLAG-2:

-       Find out the victim’s date of birth.

-       Count FLAG-2 -> DOB ^ 4352445E5955

The character "^" means xor operation. Currently there are two options: find the year of birth or brute-force it. Because this is a learning experience the year is searched – but also brute-forced!

There weren’t references to deleted files anymore. We’ve seen that the previous details were in an image, so we could try to search the file system for image files.

With a PNG file header, there are 14 occurrences. Only one of those is promising because it isn’t inside the Openoffice presentation document. But the all the data isn’t there. The rest can be found by searching for the footer of PNG image. I believe this wasn't probably the way the image was meant to be found. Anyway, I dumped all the data to a file and now we have the year of birth in the image 12.

Image 12. An another identity card.

We can now just xor the data according to the instructions. The result is in image 13.

Image 13. FLAG-2.

FLAG-2: ratkoa

To brute-force the year, we can just guess a range like 1950-1980 and let the script print all xored values. The results are illustrated in the image 14.

Image 14. Brute-forced results.

It was too easy. I think we could try to brute-force the full date of birth also. With a range 01-01-1950 to 31-12-1980 we already have over 11000 possible values. That's too much to browse manually, but if a Finnish dictionary is used we can ignore the amount of results. Of course the dictionary doesn’t have all the words but we could try anyway.

I did a Python script to xor 0x4352445E5955 with every date from 01-01-1900 to the date of writing this post. That makes over 43000 possible values. The results are then compared to the dictionary. It took under a second to get all possible hits including the correct date of birth. The results are illustrated in the image 15.

Image 15. More brute-forced results.

Task 3:

“Search all SMS messages from the files of mobile phone. Search contact details of senders and receivers. You need to find out the person who has sent messages with our victim. Find FLAG-3.”

After extracting the given file “part-3-files.tar.gz” we have three files:

MP0C_003 – 18 kilobytes

MP0H_006 – 19 kilobytes

MPA3_001 – 37 kilobytes

A search from Google revealed that these files are from mobile phone’s file system. According to this web page, file “MP0C_003” contains all the names, file “MP0H_006” all the phone numbers and file “MPA3_001” all the SMS messages.

After looking into the files in a hex editor, we can easily recognize a pattern in all the files like illustrated in the image 16.

Image16. xored data.

This usually means that xor operation was done to the data. If we xor the file MP0C_003 with a key “0x 7DCF0CD58548A57F66A6A0B9EA6D64125BAF53679CA56E62D49CD72A29DEFC14A4D333F1”, we can see that the victim had a one contact in his phone – “Jone” (image 17).

Image 17. Contacts.

 The same operation for the file “MP0H_006” with a key "0x7DCF0CD58548A57F66A6A0B9EA6D64125BAF53679CA56E62D49CD72A29DEFC14A4D35D9E908F" where all the phone numbers are (image 18).

Image 18. Phone numbers.

And the last file with a key:

"0x7DCF0CD58548A57F66A6A0B9EA6D64125BAF53679CA56E62D49CD72A29DEFC14A4D35D9E94071F9B4B286F2BC5AF2DCAA42731ED0455DC819439B0A4346754959185722AC0FB71BEB2A4666974AF0624AA7D0FE02727FDA41B5F7C5E228B2C7FE740F78BFBDFBCAC50F6918B73FA43D8CAF4FD4DE7381AF01C60EFAB0D2AEFDEE9E924FA261206A8B7BBF0A09957DFE5184C499B6ED937E87087B7A4D4877B64C30BBA3DB8A4FF0ED7DEEF688C639C6AAFB13EAFFF1BB8358DCB".

The xored data looks better now but I can’t recognize the format. A search from Google gave us back a link to a SMS carver tool. In the readme it’s said the data is partly in PDU format. PDU (Protocol Data Unit) is encoded format for SMS messages which are sent over GSM network.

This web page has an example of PDU format. In our file we've byte sequences starting with “0x0791” like in the example. If all that data is pulled  from the last file and converted using the PDU converter in the web page, the following SMS messages are revealed:

SMSC#+48790998250

Sender:115

TimeStamp:30/10/16 17:27:14

TP_PID:00

TP_DCS:00

TP_DCS-popis:Uncompressed Text

class:0

Alphabet:Default

Play wita w Finlandii. Koszty polaczen: do Polski i lokalnie - 0,54 PLN, polaczenie przychodzace - 0,05 PLN/min. Koszt SMS - 0,19 PLN, MMS - 1 PLN

Length:146

SMSC#+358508771010

Sender:+358504176871

TimeStamp:07/03/17 15:17:31

TP_PID:00

TP_DCS:00

TP_DCS-popis:Uncompressed Text

class:0

Alphabet:Default

I need that 10000 today!

Length:24

 

SMSC#+358508771010

Sender:+358504176871

TimeStamp:07/03/17 15:21:13

TP_PID:00

TP_DCS:00

TP_DCS-popis:Uncompressed Text

class:0

Alphabet:Default

Ok. 3000 today 9000 friday. 21:01 P train front.

Length:48

SMSC#+358508771010

Sender:+358504176871

TimeStamp:10/03/17 15:23:36

TP_PID:00

TP_DCS:00

TP_DCS-popis:Uncompressed Text

class:0

Alphabet:Default

9000 today

Length:10

SMSC#+358508771010

Sender:+358504176871

TimeStamp:10/03/17 15:25:12

TP_PID:00

TP_DCS:00

TP_DCS-popis:Uncompressed Text

class:0

Alphabet:Default

?????? Meet busstop 18:00

Length:25

Next we can go through the remaining data in the file. Only one of the byte sequences gave us a properly formatted PDU message. The result is in the image  19.

Image 19. FLAG-3.

FLAG-3: tällaisia

Task 4:

“Find out what’s the password used to lock and encrypt phone. Somehow we know that the password contains five lowercase letters and one number in the end. You need to find out the password which is also the FLAG-4.”

After extracting the given file “part-4-image.bin.gz” we have a one file called “part-4-image.bin”. Its size is 15.76 gigabytes. Based on the details seen in a hex editor it looks full disk image of Android operation system.

The instructions given to this task indicate that the password needs to be brute-forced. Hashcat is the best for this job but we also need crypto footer from the disk image. There are good instructions how to do this in Forensics wiki.

In the image 20 we've the crypto footer from our disk image.

Image 20. The crypto footer.

The Marked bytes are the hash of password that we need in Hashcat. Because we know how the password looks like, an attack called “mask attack” can be used. It can be defined that Hashcat only tries passwords with a pre-defined template. In our case we want it to try only passwords with five letters and one number in the end.

Hashcat also needs to know a hash mode to be used. From here we can see Android FDE (Samsung DEK) is “12900” and attack mode is “3” (brute-force).

The full command to crack the password is the following one:

hashcat.exe –m 12900 –a 3 hash.txt ?l?l?l?l?l?d

Cracking the password with Nvidia Geforce 660 GTX took about an hour. The result is illustrated in the image 21.

Image 21. Cracked password.

FLAG-4: pulmi4

Task 5:

“The password from Samsung S3 phone is now known and file system is decrypted. Investigate is there messages between the victim (0504176853) and the suspect in the backup made from data partition. You need to find their discussion. It’s known that the suspect has sent an SMS message to a third person. What does the message contain? Find FLAG-5.”

After extracting the given file “part-5-backup.gz” we have all the files from data partition. We’re looking for SMS messages. A search from Google revealed that all SMS messages can be found from the following path:

data/com.android.providers.telephony/databases/mmssms.db

The file is SQLite database:

data/com.android.providers.telephony/databases/mmssms.db: SQLite 3.x database

DB Browser for SQLite was downloaded to investigate the database file.

All SMS messages are in the image 22. They're in a table called “sms”.

Image 22. SMS messages.

There is also the message to the third person (0503711114):

“Ei se meinaa maksaa. Tuun hakeen sua viideltä. Poimitaan jätkä kuudelta.”

Translated: “He isn’t gonna pay. I will pick you up at five. We gonna get him at six.”

We’ve everything else but the flag. The other tables don’t have anything interesting. Next, we could have a name for this third person by looking into the contacts database located in the following path:

data/com.android.providers.contacts/databases/contacts2.db

All contact names can be found from a table named “data”. From there we can see that the third person is called “Pera”. In this same table the details for Pera and our victim are pretty identical, but there is data set (blob) in the column “data15” for Pera (image 23).

Image 23. Data in a column.

 This data can be exported from the DB viewer or viewed from the following path:

data/com.android.providers.contacts/files/photos

The image 24 shows the content of this file.

Image 24. FLAG-5.

FLAG-5: TYÖKSESI ?

I did take a look into some other files that might be interesting. A couple of details to be mentioned: the phone was turned on in a city called “Tikkurila”. Well, that’s pretty obvious because the HQ of Finnish National Bureau of Investigation is located there. And the other detail – it was a cloudy out there.

All flags together form a sentence:

“HALUAISITKO ratkoa tällaisia pulmi4 TYÖKSESI ?” (pulmi4 = pulmia)

Translated: “Would you like to solve puzzles like these for your work?”

I think the whole puzzle was a very nice addition to the normal recruiting process. No, I didn’t apply. I just completed the puzzle for fun. Usually you learn new stuff by solving things and this case wasn't an exception.

You can find all the files and instructions from the description of this video.