by Davide Gabrini, Andrea Ghirardini, Mattia Epifani and Francesco Acchiappati
Preface
During the hacking camp MOCA 2016, at the end of a talk held by Davide “Rebus” Gabrini on passcode circumvention methods on mobile devices, a bystander offered an intriguing challenge: he offered for research purposes a smartphone to find out if and how someone could crack it, overcome security and extract information.
The smartphone was a Jolla White 16GB JP-1301, equipped with the Sailfish 2.0.1.11 operating system. The device was previously reset twice by the owner and it was protected by a 5-digit PIN without encryption on the internal storage. Moreover, the developer mode was not active because it required a Jolla account that was not available.
The challenge was accepted during the following End Summer Camp 2016 (ESC 2016), where a dream team of Italian forensic experts addressed the problem at the Ville Forensics, among the curious eyes of other hackers. The team was composed of Davide “Rebus” Gabrini, Andrea “Pila” Ghirardini, Mattia “Lo Zio” Epifani and Francesco “Swappage” Acchiappati.
Acquisition
The phone did not expose a service similar to ADB like on Android devices, but only the internal data partition as a Mass Storage Device*. In this case it is possible to perform a logical copy of the visible files and folders, but we are bound to the MTP protocol limitations; although the user data exposed in this way can be significant, the method is still partial and unsatisfactory.
As expected, attempts to acquire the device using well known forensics products like UFED4PC and Magnet Acquire failed, as these tools couldn’t even detect the device at all.
*For accessing the internal storage, the device must be unlocked, and therefore the passcode is required.
Physical Examination
When tackling a challenge, the first step is to know your enemy, therefore the handset was dismantled in its entirety and the motherboard exposed. All connectors were ZIF and the shields were partially interlocking and partially attached using clips on the mainboard.
Two things stood out.
The first is that SOC is not visible since is a SOC with POP for RAM on top, so the big chip with 3TA78 D9QMM codes on top is a RAM chip (produced by Micron) which hides the Qualcomm SOC behind (kudos Andrea Barisani).
The second is that there are a plethora of test pads on the mainboard. From a certain point of view this helps, but on the other hand it does not allow to easily find and understand which are the ones needed for accessing at a service level (JTAG where are you? Please reveal yourself!)
We also tried to connect the phone without battery through the USB port the system to check if it has a behavior similar of a MediaTek SOC based device that, when connected over USB without battery, exposes a USB interface from which it’s possible to perform a system flash or memory dump.
By adopting a procedure found on the Internet:
- remove the battery
- insert the battery while holding the volume down button
- while holding the volume down, press power and keep it pressed until the phone vibrates
- release power and volume down
the system goes into recovery mode.
When connected in this mode, the device is being heralded as a new USB device named “Generic RNDIS device”. On Microsoft Windows 10 the driver is not loaded automatically, but if you proceed by manually installing a “Generic RNDIS device” driver among those written by Microsoft, the device is properly recognized as a network card.
By connecting the phone to a Linux operating system, the device is instead immediately recognized as a USB Ethernet adapter. We could then enable the interface and notice that the phone runs a DHCP daemon that assigns an IP address to the computer.
The phone only exposes the port 23 (telnet); once inside, without being asked for any kind of authentication, it provides the access to a shell with root privileges.
Running the mount command to check the list of file systems we realized that the main partition of the system is not mounted, and the device (/dev/ mmcblk0) has a GPT partitioning with 28 partitions.
A recovery system based on Linux is undoubtedly an aid, as it’s already equipped with the whole toolchain that is needed to perform a physical acquisition of the phone’s flash memory: there are both “dd” and “netcat”, and therefore the easiest method is to use the existing network connection between the computer and Jolla’s smartphone to perform a “dd over netcat” acquisition.
This procedure requires a netcat listening on the virtual Ethernet of the computer (there are also many ports for windows platform) on an arbitrary port (ex. 8888), and then to launch these commands:
first on the computer:
nc -lvp 8888 | dd of=/path/to/destination/image.raw
and then on the phone:
dd if=/dev/mmcblk0 conv=noerror,sync | nc [ip of the PC interface] 8888
The whole process takes about 3 hours, but the result is a full physical extraction of the internal device flash memory, which we can now analyze using our favorite tools.
CHINEX
Since the phone disassembly revealed the use of an MTK processor, we also attempted the acquisition through the Chinex kit that is available with UFED from Cellebrite, but we didn’t succeed since the device couldn’t successfully pass the MTK Pinfind procedure. We had the same behavior using the other methods available for generic MTK devices.
Analysis
Once the acquisition was successfully completed, we obtained a 16GB bit stream image.
The first thing we wanted to check out was the partitioning. To achieve this goal we opened the image with X-Ways Forensics. GPT partitioning was interpreted correctly by the software and 28 partitions were detected. That made us think: great, we are the champions! 😛
Another unlucky attempt was using UFED Physical Analyzer: predefined profiles, script chains configured for MTK processors and individual Python plugins were not able to extract useful information from the raw dump. The best result we get was with a generic profile for MTK device, which seemed to point out a few email messages and deleted messages but then we realized that most of them were false positives. Again a dry shot.
Another part of the team started analyzing the individual partitions with X-Ways Forensics and found out that the largest ones (and therefore potentially containing juicy information) were number 24 (Linux Swap, even if it was recognized as “Linux Filesystem”, as big as 500 MB) and number 28 (13.5 GB). Unfortunately, we had another issue: the partition is formatted with the bleeding edge BTRFS file system, which, while we are writing this document, is not supported by either X-Ways or UFED PA. We had the same outcome during image inspection with FTK Imager and Autopsy, but the same would also be achieved by Encase or FTK: none of the most popular forensic analysis software, yet, supports BTRFS. But Linux does!
We then decided to “split” the work: someone decided to mount the file system on a Linux workstation for pulling out a TAR archive containing all the allocated data, while the remaining team members started to carve at raw level searching for information and fragments of meaningful content.
The first activity was completed successfully and the TAR file was turned back to X-Ways Forensics: as we could have expected, existing files on the device do not contain any data because the device had been reset by the owner before the delivery.
So what was left to explore was the path of the unknown: the raw data. We started with a byte-level carving with X-Ways Forensics and PhotoRec, while seeking more structured information with Internet Evidence Finder (IEF) and Bulk Extractor.
After a few seconds X-Ways extracted pictures related to Internet browsing activities on medical websites and shortly after both IEF and Bulk Extractor provided a long series of keywords used on Google and related to a specific medical treatment. The carving continued and some SQLite databases were detected (569 by X-Ways, over 600 by PhotoRec). Among them we identify the Cookies database, which provided us with the URL to which the medical images belong: we were then able to pinpoint the Google search and medical web site access to a specific date and time.
We continued with the file carving and we found the screenshots of a GPS application, probably the one that was installed by default on the system. From these screenshots it was possible to figure out where and how the owner moved with the device and, in some cases, it was possible to determine exactly the origin and destination of the trip.
As a final activity we decided to try to trace communications with third parties in an attempt to uncover as much as possible about the identity of the device owner. We managed to extract a complete email in EML format: in this email we found the sender and the recipient, indicating the name, last name and, of course, the email address.
At this point we launched a keyword search using the address of the sender and recipient, and this allowed us to recover about 400 matches: a detailed analysis of the results allowed to recover about 200 email messages, only partially overwritten but full of information about the owner’s job and several customers’ names. We of course also found private and personal emails exchanged on the phone.
At this point we decided to stop as the collected results were enough to prove that even when a phone is not supported by common forensic tools and is subjected to reset, it is possible to successfully retrieve meaningful data useful during investigations!
Happy with the results, we decided that it was time to move on to the next beer, but not before enjoying the phone owner’s reaction and his face going pale, when we began asking him if he knew anything about the subject matter and whether he had been in certain places.
ESC “Ville Forensics” beats Jolla Phone 2-0 (at least!).
The SoC is very likely a Package-on-Package footprint with the RAM on top. The markings that you are highlighting in the first illustration belong to the DDR RAM therefore.
The M stands for Micron and the P/N can be found at https://www.micron.com/support/tools-and-utilities/fbga?fbga=D9QMM
Therefore chances are that the SoC is not only not custom but also a Qualcomm as originally suspected.
Jolla/Sailfish doesn’t allow shell access without first entering the PIN code of the device, which is prompted as soon as you try to enter the recovery.
So most likely the device did not have a PIN code setup after the resets as claimed in the beginning.
“The phone only exposes the port 23 (telnet); once inside, without being asked for any kind of authentication, it provides the access to a shell with root privileges.”
This is incorrect for SailfishOS.. if the device actually had pin-code enabled it would ask it before allowing user to access the shell in the recovery mode.
If you enter recovery mode menu on the phone the way you suggest – it does ask for the user set PIN before it lets you use the root shell. How did you circumvent this? That is the way it was starting with the earliest Sailfish OS delivered back when Jolla sold its phone.
Has this behaviour changed since? I have not heard reports of it yet.
Nice article, VERY challenge,but this smartphone is rare to find.
‘The smartphone was a Jolla White 16GB JP-1301, equipped with the Sailfish 2.0.1.11 operating system. The device was previously reset twice by the owner and it was protected by a 5-digit PIN without encryption on the internal storage. Moreover, the developer mode was not active because it required a Jolla account that was not available.’
How I read this, ‘the device had a password before doing a factory reset twice’, thus they could boot the phone to recovery, create an image and start carving. Surprise because Jolla does not support encryption yet, and apparently does not use trim.