We have moved to a new Sailfish OS Forum. Please start new discussions there.
11

Forensic Challenge: Recovering Data From A Jolla Smartphone

asked 2016-09-29 22:44:04 +0300

launchpad gravatar image

updated 2016-09-30 10:20:31 +0300

jiit gravatar image

Just stumbled across this interesting assessment, while looking for something completely different [resolving a volume header corruption ;) ] :

https://articles.forensicfocus.com/2016/09/14/meeting-a-forensic-challenge-recovering-data-from-a-jolla-smartphone/

edit retag flag offensive close delete

Comments

1

Thanks for a good read. But I got confused in the middle when they initially said it had a qualcomm chip and then later on kept saying it was MTK? What did I miss?

sifartech ( 2016-09-30 10:28:13 +0300 )edit

4 Answers

Sort by » oldest newest most voted
5

answered 2016-09-29 23:05:11 +0300

updated 2016-09-29 23:05:33 +0300

Since the phone disassembly revealed the use of an MTK processor

It should be Qualcomm, but nevermind.

edit flag offensive delete publish link more
5

answered 2016-09-29 23:33:19 +0300

dmnk gravatar image

that's "funny". shouldn't the device lock code be queried at the recovery / telnet session?

edit flag offensive delete publish link more

Comments

yep, clearly statet in https://jolla.zendesk.com/hc/en-us/articles/201440487-What-are-the-Device-Lock-and-Security-code-

3 Functions that require entering lock code to use them

As explained in the previous chapter, you can set a lock code to your Jolla that is only asked when certain functions are used:

   Make changes to the Device Lock settings (note: there is no specific button to accept the changed settings - another lock code dialog appears, instead)
    ...
   -  Use the Recovery Mode
dmnk ( 2016-09-29 23:35:59 +0300 )edit
4

answered 2016-09-30 14:01:41 +0300

juiceme gravatar image

updated 2016-09-30 14:32:24 +0300

Yes, I too think that there is something hazy in the way the article presents the use of recovery mode.

If I remember correctly it has always been so that when recovery mode is activated and user connects to the device via telnet it only presents a numeric menu where such actions as "shell" and "btrfs balance" can be selected byt any of the options require entering the device lock code.

However, in the beginning of the article it was clearly stated that the device had 5-digit lock code activated...

---- Edit ---

OK, now when reading the article through with the comments at the end I believe the device probably did not have security code enabled. The way it is said in describing the device lead me to believe so, but in fact it probably meant "The device had a 5-digit pin code before, and then it was factory reset"

After the reset there was no active security code, and the forensics team was attempting to retrieve information from the user data that had been in the device before reset....

To me a more valid case should have been to try to break into a non-factory-resetted device with an active security code.

edit flag offensive delete publish link more

Comments

1

always isn't correct. very early versions where unlocked, but due to outlook / exchange policy that came (at least it was argumented that way). but the 2.something that was in the test is definitely in the "covered" version range of that behavior.

edit: it is correct if you refer just to the "oh and then we've been in the shell and copied the whole partitions" easy going part. no word about how they circumvented the code or got that shell. which would be the only interesting part on this, as i don't care if their fancy software still doesn't support BTRFS and they where clever enough to mount them...

dmnk ( 2016-09-30 14:17:36 +0300 )edit

exactly; it is stated thet the SFOS version of the device was 2.0.1.11 which surely implements the device lock code in recovery mode.

The first recovery in SFOS 1.x.x-something did have it open but it was fixed in the next release.

juiceme ( 2016-09-30 14:21:26 +0300 )edit
1

For accessing the internal storage, the device must be unlocked, and therefore the passcode is required.

so they didn't access it via MTP because of the passcode, but than removed it and prouded themselves with "now we can access the data via a telnet session" ???

dmnk ( 2016-09-30 14:43:05 +0300 )edit
1

@dmnk, actually what they say makes full sense if the device did not have a security code;

They are able to access the device with MTP (which they could not if it was locked) but state that since MTP only exports "files and folders" they are not able to do any forensic analysis of unallocated space, the thing they are really attempting.

juiceme ( 2016-09-30 14:48:54 +0300 )edit
3

ok, so this is just "hey we can restore data from a not erased partition" :)

dmnk ( 2016-09-30 15:08:10 +0300 )edit
4

answered 2016-11-18 23:32:53 +0300

mattiaep gravatar image

Hi dmnk and juiceme, I am one of the author of the experiment we did with the Jolla Phone.

I am very pleased that you read the article and I'd like to provide you some answers to your questions and doubts.

First of all, the experiment was a "challenge" to try to demonstrate how it is possibile to recover data from a smartphone also when the owner thought to have deleted all the contents. The test was made during an hacking camp in an absolutely informal environment so it is not in any way intended as to be a tested and complete digital forensics methodology to analyze a Jolla phone, neither a security assessment of the phone.

Personally I have never delt with a Jolla phone in a real case so it was an interesting test to perform.

First of all there was an error in the article: now it is corrected with the Qualcomm chip. Sorry for that.

Secondly, as explictly cited in the article the phone WAS protected with a 5 digits pin code BEFORE it was reset twice, so when we got it it was WITHOUT a pin code. We didn't made any test with an actually locked device.

Third point: the encryption was not activated by the user before the reset.

With these two points in mind, I agree with dmnk "hey we can restore data from a not erased partition": this is exactly what we wanted to obtain.

With the experiment we understood that:

a) Encryption is not activated natively

b) It is possible on a reset phone to have access as root and obtain a full physical dump

That means, in general, that reset a Jolla phone is not enough to "cover the tracks" or "protect my privacy".

Just to make a comparison with other phones, this is not the case with the iPhone and with the latest Android version.

In any case, I think that having new operating system in the mobile world is alwyas a good thing and this kind of tests from us as "forensic guys" can help to enforce the security of the operating system.

Anyway, I am available to go on with the discussion if you like!

Thanks a lot

(Sorry for some typos and errors, I am writing from my phone :)) )

edit flag offensive delete publish link more

Comments

Thanks for your explanation, @mattiaep.

I do get your experiment and the case is valid; currently SFOS does not encrypt the content of user's home directory. If you want encryption you need to implement it yourself :)

Still, I'd like to see an attempt to break into an active (meaninig, non-wiped) device which is locked, and comparision of that against similar-state iOS, Android and WP devices.

juiceme ( 2016-11-19 11:33:19 +0300 )edit
3

Hi @juiceme! I agree with you that doing more research and tests is a really interesting topic, but unfortunately I don't have anymore the Jolla: we gave it back to the owner after telling him something about his personal life :) I will try to find a similar model to go on with further researches! I will let you know in this thread in case I find it and the results! Thanks

mattiaep ( 2016-11-19 17:18:06 +0300 )edit

thanks for the feedback and additional information.

dmnk ( 2016-11-21 00:08:27 +0300 )edit
Login/Signup to Answer

Question tools

Follow
4 followers

Stats

Asked: 2016-09-29 22:44:04 +0300

Seen: 1,187 times

Last updated: Nov 18 '16