Jul 02, 2013, 04:30 pm EST
There are a number of reasons that make SIM card forensics an interesting topic; here are a few of them:
Popularity: almost everyone has a SIM card, some of us use several of them on a daily basis; thus there is a lot to gain by possessing some knowledge on the subject.
Difference: extracting data from SIM cards is done with methods that differ from those that correspond to magnetic storage or flash memory; thus this is appealing to one’s curiosity.
Challenge: SIM cards are designed to withstand unauthorized attempts of accessing their contents; what’s the first thing that you do when someone gives you a new gadget and explicitly says “do not disassemble it”? Not disassembling it is probably the last thing that comes to mind.
This story will cover some of the basics of SIM card forensics and provide practical tips that can be used by people who have to collect evidence from such cards. The same information can also be used by the “bad guys” to find ways to conceal data, so make sure your moral compass is well-calibrated.
First of all, you need to know that a SIM card is a smart card, that little chip contains a processor, a file system and an operating system that runs on top of that and controls the activity of the card. These cards were designed with security in mind, such a self-contained design implies that you cannot access the raw data of the SIM card in order to make a dump, as you normally do with hard drives or flash memory. File system ACLs (access control lists) are enforced and you will only be able to retrieve the data that you are allowed to access. You can think of it as of a black box that can answer questions, you can only ask, but you can never open it and see what’s inside.
The permission to access certain data are granted when a right access code is supplied. The ones we typically deal with are PIN1 and PIN2, but if you read the specifications[1] that standardize the structure and behavior of a SIM card, you will learn that there are a lot of other codes too. These security codes cannot be guessed by brute-forcing; the smart card has a built-in counter of remaining code entry attempts, which is decremented every time a wrong code is provided. When the counter reaches zero, the card is blocked and further access attempts will be rejected.
You can “talk” to the card using APDU commands, which are sequences of bytes that the card interprets and reacts to. The card’s response can be the data you are looking for, or a negative answer such as “access denied”. Remember, the card is a tamper-proof black box that offers answers when it knows you’re allowed to hear them; but you cannot override that by breaking the box and getting the information out of it by force.
To interact with the card, you need to use a PC/SC-compatible smart card reader, it acts as a physical interface between your computer and the card. Since smart cards are not a typical memory storage device, do not expect a new volume letter to show up in “My computer” or a new mount point to be created in somewhere in /mnt or /media.
In order to get some data out of it, you need some software that can talk to the card using APDU commands or allows you to type them by hand.
[1] GSM 11.11 for 2G SIM cards, ETSI 131 102 for 3G USIM cards.
All the data on the card are stored in files; you will run into such terminology: MF – master file (the root directory), DF – directory file, EF – elementary file. File names are hexadecimal numbers such as 0x6F3A or 0x6F3C, they also have human-readable names such as EF ADN (elementary file “abbreviated dialing numbers”, where the phonebook is kept) or EF SMS (elementary file SMS). The hierarchy of the file system is defined in the aforementioned specifications, if you study it you will find out that, for example, the phonebook is stored in 0x3F007F106F3A in a 2G SIM card. The specifications also explain the format of the data, with that knowledge you can transform the raw data into something meaningful.
In fact, this is what mobile phones and SIM card management applications do – they send certain commands to the card, read the response, interpret it according to the predefined rules, and then display the results in a human-readable form, such that we see a person’s name or phone number instead of a bunch of ones and zeroes.
Now that the basics were covered, I shall focus on some practical matters.
You need to know exactly what you are looking for. The operating system of a smart card does not provide commands such as dir or ls, which give you a list of files and directories on the card. You need to explicitly say something along the lines of “go to directory X”, “select file Y” and “give me the first record of that file”.
The standard clearly states that what the file names should be and where they ought to be located, without that – how would a phone know where to look in order to dial a number from your phonebook?
A good forensics tool is aware of the file system hierarchy for different types of cards used in mobile phones and will retrieve all those files for you.
Where on the SIM would I hide my data if I were a bad guy? There are several ways to answer this question.
Deleted SMS: if you read the specification carefully, you will realize that the standard states that when a message is erased, it is only marked as such, leaving the rest of its contents intact. When a new SMS is received, it will be written to the records that are available, and when all of them are in use, the phone will begin overwriting the ones that were marked as “erased”. Records marked as unused are not going to be displayed by the phone, but you can easily retrieve them by reading the raw data of EF SMS (after providing a valid PIN1, of course). If the first byte is 0x00, the record is free, if it is 0x07 – it is in use. Look for records that begin with 0x00 and see what is stored in the remaining bytes.
Beyond the end: text data are stored on the SIM card using a special encoding. If you review the specifications, you will see that unused bytes must be set to 0xFF. For example, if the address-book file has enough room for 50 letters in each name, but only the first 10 letters are used, the remaining space will be padded with 0xFF bytes. The phone “knows” that too, so when it displays your phone-book, it reads each record until it bumps into the first 0xFF byte and discards the remainder. You normally expect that once you find the first 0xFF, there will be nothing but other 0xFF bytes beyond it. However, there is no force in the universe that prevents me from writing some actual data beyond the “end marker” – that data will not be visible when viewed via a phone’s interface, but it will be visible to those who look at the raw data of the record.
Orphaned phone-book records: this method can be used on 3G USIM cards, as they have a more complicated phone-book structure that allows not only the storage of a name and a number, but also an email, a secondary name and a secondary number (among other things). These attributes are not stored in a single file, instead they are distributed among a group of files. However, they are visualized as a unified set of attributes corresponding to a person, so a user doesn’t know what happens under the hood.
These files are correlated using a table that gives you information such as “entry #5 in EF ADN is linked to entry #89 in EF EMAIL[1]”; when the phone reads the SIM cards, it figures out how to correlate these records and displays everything on the same screen. If, for example, you delete an email address, the phone will not only remove the record from EF EMAIL, but it will also update the “correlation table”, such that it doesn’t say that there is an email entry that is linked to one from EF ADN.
Of course, there is no force in the universe that prevents me from deleting the link in the “correlation table”, but leaving the record in EF EMAIL intact. Effectively, I have created an orphaned record – it is physically on the card, but there is no phone-book entry that points to it, thus it will not be displayed in the phone’s GUI, yet it will be readable by those who know where to look.
In the meantime, I must point out that this method is mostly theoretical, rather than practical. The reason behind that is that once the SIM card is issued to a consumer, its file system is fixed and cannot be changed. Remember – smart cards are secure and intelligent systems, when I say “cannot be changed” I mean that they were specifically designed to prevent that. Thus, the only entities capable of altering the structure of a card are the mobile operator or the card manufacturer.
There are a lot of other interesting details that can be extracted from a SIM card – feel free to delve into the specifications to see what other files exist on the card, what their format is and what the access permissions are.
This was a simplified, plain-English introduction into the world of SIM cards. Now that you know where the bad guys would most likely hide data, you know where to look. Good luck! www.dekart.com
(Source : By Alex Railean – Dekart )
;
We are in our 11th year, and Global InfoSec Awards are incredibly well received – helping build buzz, customer awareness, sales and marketing growth opportunities, investment opportunities and so much more.