Imaging and Examini...
 
Notifications
Clear all

Imaging and Examining a Chromebook

10 Posts
4 Users
0 Likes
7,277 Views
(@mark-hibb)
Posts: 4
New Member
Topic starter
 

Afternoon,

I have been tasked with the Imaging and Examination of an Acer Chromebook, model CB5-311P (Chromebook 13) and I am after any advice if possible, please. I'm grateful!

So, my understanding of Chromebooks is that generally, they are a cloud based device and so the majority of any storage, data etc will be on the cloud accounts. I was previously a POLIT Investigator and so I am aware of the RIPA issues that brings.

I am also told that there may be some data left on the internal memory the device has.

The device itself is owned by the organisation but used by the suspect and I am confident that we will be provided with login details to the device.

What I'd like to know is - what, if anything can I use to obtain a forensic image of this device prior to logging in to the device? I understand that due to its Operating System, TD3's, FTK etc won't work and I'm told nor will CAINE.

If there is nothing I can use prior to logging on, what would be best to obtain an image of the device once I am logged in?

I want to have as little impact as possible on the device and I'm looking at all avenue's before I have to resort to a manual examination of the device, logged in as the user.

I appreciate the below post, which I have cast my eye over https://www.forensicfocus.com/Forums/viewtopic/t=8400/postdays=0/postorder=asc/highlight=chromebook/start=0/

With my thanks

 
Posted : 21/02/2018 1:01 pm
(@patrick-bell)
Posts: 9
Active Member
 

There is not much you can do other than manual examination/screen recording (so long as you have the password). The following is based on research I did in 2015 but I believe it still holds true.

You're right in that there is local storage. This is typically a 16Gb SSD, and will contain downloaded files, cache browsing data, bookmarks, ssh connections etc.

Unfortunately you are not bale to removed this SSD (even if it's not solder on) and image it, as it has drive level encryption and is tied to a Trust Platform Module (TPM) on the motherboard. Meaning this drive can only be decrypted in combination with the TPM. Attempting to remove the device can cause the system to delete the keys stored in the TPM

CAINE, KALI, Paladin or any other bootable media isn't an option either. ChromeOS has secure-boot, which ensures only an OS cryptographically signed by Google will boot on the device. Developer mode can be enabled which will allow for booting to a USB stick. To enable developer mode, usually a physical switch under the battery has to be switched, requiring the device to be turned off, and upon reboot the device will make the user wait an arbitrary 5 minutes while it wipes itself and factory resets. (If developer mode is already enabled you have more options, see below)

Another pit fall, is that having the administrator's password, will not give you access to any other users' account/files. ChromeOS is again encrypted with eCryptfs, with per user encrypted directories; therefore a password for one user will only give you the data for that user.

During my research I created a 'what to do' if encountered guide which is as follows

If a Chrome OS device is seized and is turned off, always attempt to get the user’s password. Without their password no data can be recovered.

If a Chrome OS device is encountered at a scene and is powered on and logged in, first attempt to record the password (or if you are given the password). Then determine if the device
is in Developer Mode with these steps

1. Open the crosh with Crtl+Alt+t

2. type “shell” and enter
a) If “Unknown Command” is returned move to section 3
b) If the prompt changes to “Chronos@root” move to section 4
c) If a password is prompted move to section 5

3. Developer Mode is not enabled - No Linux commands can
be run and the file system cannot be explored. The best option is to
record the screen and show what tabs are open and what files exist
locally.

Files can be copied and pasted onto removable storage. Internet
history can be exported to a file by opening the history menu
(chrome//history/) and right clicking and selecting “Save as”, this
can be saved as a .html file to removable media. Bookmarks can be
exported browsing to the bookmark manager
(chrome//bookmarks/) and exporting them to a file.

This is not very practical nor ACPO compliant, so I would recommend
recording the screen while you work, and hashing the files you obtain.

4. The system is in Developer Mode - Many more options are
available. Including all of the actions from section 3. First attempt
to gain the user’s password. Next the best course of action is to live
image the mounted encrypted volume, the mounted user directory
in /home/. Directories outside of /home/ can be statically imaged in
a lab, however they contain no user data. User’s names are
obscured through hashing so they are represented via 32 character
strings. To identity the mounted one, you can browse into them.
The unmounted and encrypted user directories will be empty.
However for speed and to make as little changes to the system, a live
image of the entire /home/ is recommended; with this command
sudo cp -r /home/chronos/* /media/chronos/EXTERNAL_DRIVE

Where ‘EXTERNAL_DRIVE’ is the removable media.

5. Developer Mode is enabled but the shell is password
protected. First attempt the user’s password. Next attempt
common passwords such as “password” “toor” “facepunch”
“test0000”. If you succeed, go to section 4. If not, return to
section 3.

I hope this help, any questions, let me know.

 
Posted : 21/02/2018 4:08 pm
BraindeadVirtually
(@braindeadvirtually)
Posts: 115
Estimable Member
 

This is an interesting one. Your choice is going to boil down to whether you live boot it - as in, truly live boot into the native OS (ugh) and do videos/photos as you go - nobody's favourite option - or you pull the motherboard, desolder the chip and get a .bin of its contents through direct eMMC.

Obviously in the latter scenario the company isn't getting its Chromebook back in one functioning piece and you might brick the chip and get nothing. I would be really surprised if such a cheap consumer grade piece of kit had a TPM and default drive level encryption, but surprises are the stock in trade of such procedures.

If you go down that route and get your .bin or whatever and it's not encrypted, then you are golden. The fact that some commercial tools may struggle to automatically carve the filesystem should be the least of your worries, and you will only have 16GB to run some custom carvers over.

This is all going to be dictated by proportionality - you make no mention of what you are looking for - and whether you are allowed to destroy the exhibit. Personally, what with it being a Chromebook, I would expect to find more of value in the right area of Google's servers.

 
Posted : 21/02/2018 8:44 pm
(@mark-hibb)
Posts: 4
New Member
Topic starter
 

Morning,

I have read both replies with interest, but not with joy.

This is an indecent images job and I am a Police analyst. Chip off's/destroying the device will be avoided at all costs unless necessary.

I am chatting with the Officer in Charge, and with friends I've met from other forces and organisations, it appears that I'm being directed towards a manual examination.

Thank you.

 
Posted : 22/02/2018 7:52 am
BraindeadVirtually
(@braindeadvirtually)
Posts: 115
Estimable Member
 

Didn't realise you were fellow UK LE, for some reason I had it in my head that this was corporate work. Is this a key exhibit for the job? A manual might have its own pitfalls, in my experience such devices do not give up their local storage easily - they are all about going onto WiFi to give the user the 'full experience'.

Can you get an intereference warrant lined up beforehand? Then there would be no delay in connecting it up if necessary and you could pull his (or her) entire Google account on one of your other systems, too. Chances are the SoI wouldn't want to lose their collection of images and videos so they might well reside on Google's servers.

Another avenue I would want to explore if it's a key exhibit is getting a test Chromebook of ideally the same exact model. Then you can test all of these scenarios and pull it apart and know exactly what will work best. Probably looking at £150 cost to do it. Whether your force will find that money is another issue as I know only too well…

 
Posted : 22/02/2018 8:19 am
(@patrick-bell)
Posts: 9
Active Member
 

I would be really surprised if such a cheap consumer grade piece of kit had a TPM and default drive level encryption, but surprises are the stock in trade of such procedures.

Surprising I know, but my understanding was that Google required ALL Chrome OS devices to have one and it is integral to the OS.

After a bit of Googling trying to find the spec list to confirm it, I found this on the Chromium.org website, listing all devices that have the Infineon SLB 9635 TPM and the Acer Chromebook 13 (CB5-311) (code name nyan-big) is listed.

I really think, keeping the device isolated, powering it on and determining if the device is in Developer mode is the best way to go (excluding obtaining cloud sources). Any binary dump from the chip you could get, will be encrypted, and not with the user's password.

 
Posted : 22/02/2018 8:37 am
(@mark-hibb)
Posts: 4
New Member
Topic starter
 

Another avenue I would want to explore if it's a key exhibit is getting a test Chromebook of ideally the same exact model. Then you can test all of these scenarios and pull it apart and know exactly what will work best. Probably looking at £150 cost to do it. Whether your force will find that money is another issue as I know only too well…

Morning,

Warrant executed at the search, this Chromebook and the phones appear to be linked in that it's all Cloud, Cloud, Cloud.

I'm currently examining a Dell at the moment, that was seized after, to see if anything can be identified there, but I can see the Chromebook being examined too.

I have raised the "buy a Chromebook and practice" question with Supervision so we'll see if they'll part with the cash for one.

I agree, I can see me working in isolation, Wi-Fi free and filming the screen.

I await some response from colleagues in other forces, but we all appear to have the same insight.

Chromebooks appear to be a pain.

Thank you and Pat for the help.

 
Posted : 22/02/2018 8:45 am
BraindeadVirtually
(@braindeadvirtually)
Posts: 115
Estimable Member
 

Surprising I know, but my understanding was that Google required ALL Chrome OS devices to have one and it is integral to the OS.

After a bit of Googling trying to find the spec list to confirm it, I found this on the Chromium.org website, listing all devices that have the Infineon SLB 9635 TPM and the Acer Chromebook 13 (CB5-311) (code name nyan-big) is listed.

I really think, keeping the device isolated, powering it on and determining if the device is in Developer mode is the best way to go (excluding obtaining cloud sources). Any binary dump from the chip you could get, will be encrypted, and not with the user's password.

Thanks for the link. That really does surprise me - and to think that Apple make so much noise about them being the only company that really does teh securiteez right.

That said, I have done some more digging on chromium.org and this seems to suggest FDE isn't enabled on Chromebooks

Chrome OS uses the TPM for these tasks

Preventing software and firmware version rollback
Maintaining information to detect transitions between normal and developer modes
Protecting user data encryption keys
Protecting certain user RSA keys (‘hardware-backed’ certificates)
Providing tamper evidence for installation attributes
Protecting stateful partition encryption keys
Attesting TPM-protected keys
Attesting device mode
The TPM is not directly available outside of Chrome OS for any purpose; that is, no remote computer has access to the TPM.

Chrome OS does not use the TPM for the following

Trusted boot - the TPM is not used as part of the Chrome OS verified boot solution.
Hardware-strength platform configuration reporting. See Attesting Device Mode for more details.
Whole-disk encryption or similar. In particular, the TPM is not used to unwrap an encryption key during the boot process.

Somebody needs to pull one of these devices apart to know for sure one way or the other. I would definitely be pushing for a test Chromebook - even a dead one from your favourite auction site should be enough to know whether is it encrypted or not.

 
Posted : 22/02/2018 1:35 pm
(@jpw16201)
Posts: 1
New Member
 

Hello,
I'm working on a very similar job and have had the chance to play with a test chromebook. Fortunately my exhibit came to us already in developer mode so I had quite a few options and I will summarise what I got and where it was for you as best I can.

Do not pull the chip off, you will not achieve anything useful to my knowledge. The user profiles appear to be stored within encrypted containers, once logging into the user profile it decrypts and mounts into the directory /home/chronos.
Within terminal if you explore around this area / other /home/xx directories you will find there are no readable files of sorts.
Once logging into a user and exploring the same directories you will be able to find the user profile in its decrypted state.
If you were to log out of one user and into another, it would still mount the user profile within the directory /home/chronos. The fact it does this combined with the potential of wear leveling (not sure if it does or not) would render any 'unallocated' space pretty much useless. Correct me if I am wrong!

When copying the user area out within terminal I was using the command 'sudo cp -a' the -a is to attempt to preserve any attributes with the file.

Files that are in the 'offline' section of the google drive/ marked for available offline (not the files in Downloads) are available within the directory '~/gcache/v1/files' however their metadata seems to be stored in DB files also within the gcache location, I have not had the chance to examine these yet.

 
Posted : 20/03/2018 10:23 am
(@mark-hibb)
Posts: 4
New Member
Topic starter
 

Hello,
I'm working on a very similar job and have had the chance to play with a test chromebook. Fortunately my exhibit came to us already in developer mode so I had quite a few options and I will summarise what I got and where it was for you as best I can.

Do not pull the chip off, you will not achieve anything useful to my knowledge. The user profiles appear to be stored within encrypted containers, once logging into the user profile it decrypts and mounts into the directory /home/chronos.
Within terminal if you explore around this area / other /home/xx directories you will find there are no readable files of sorts.
Once logging into a user and exploring the same directories you will be able to find the user profile in its decrypted state.
If you were to log out of one user and into another, it would still mount the user profile within the directory /home/chronos. The fact it does this combined with the potential of wear leveling (not sure if it does or not) would render any 'unallocated' space pretty much useless. Correct me if I am wrong!

When copying the user area out within terminal I was using the command 'sudo cp -a' the -a is to attempt to preserve any attributes with the file.

Files that are in the 'offline' section of the google drive/ marked for available offline (not the files in Downloads) are available within the directory '~/gcache/v1/files' however their metadata seems to be stored in DB files also within the gcache location, I have not had the chance to examine these yet.

I read this with interest, thank you. If you can, please keep the updates coming.

 
Posted : 20/03/2018 3:49 pm
Share: