Root on bmw i3?

[I3root]

So I have the hard drive to the brains of an i3 ( no, not the ecu - the other brain as robin williams would say! ;-)). It's a sata 200gb drive. The partition layout is documented in bmw's technical dicumentation. I've reverse engineered the firmware update: it's a linux os with updates aes encrypted with a key in a known location on the file system (the bash script is signed, but in clear text).
So I thought I'd just plug the drive in a sata bay and clone it for further analysis... Here's the rub: the drive (confirmed functional) is not turning on :-(
Help! I'm sure there's a hardware option to get to the content, but I'm a software guy! Anybody up for a challenge?

Thanks

-i3root

[TheCotMan]

A simple question:

The SATA connection, does it also provide power? Many laptop-sata connections are a little wider than the conventional data-only SATA interface, and provide power to the drive. Is this connected, in addition to the data conductors?

I do not work for amazon or this vendor, and my listing this specific product is not an endorsement for this brand, but it is an example:

http://www.amazon.com/StarTech-18-In...dp/B000V72AQ4/

You can see how this is wider than a conventional SATA data-only connection... in addition to support data, it supports power.

If you have something like this, but are relying on USB3.0 or USB2.0 power to power your SATA device, the drive may require more than the USB port is capable of providing to power the drive.

Beyond this, the next guesses would be on them using a "data-only" SATA-sized connection that also provides power.

Another thought, perhaps the drive has different power requirements from conventional SATA drives. If you are able, properly hook up and ammeter/voltmeter to the power leads when it is connected and working to see how many amps and how many volts on each +/- are being passed through, and then compare that to your assembly outside its working environment.

As with any electrical work, be safe, and understand you risk your tech any time you work on it.

-Cot

[I3root]

Cot, thanks for the thoughts....
Confirmed I have data & power cables.
Confirmed the drive advertises same voltage and lower amps than the drive that was previously used in the enclosure....

I'll have to rephrase my initial statements: osx does see a drive & does get the appropriate drive description info. So it is not a pure black & white powering issue. Would have been so much easier!

[TheCotMan]

For the purposes of security research and education...

If the disk does power up and is recognized by the OS, then the next step would be to see what you can find out about the drive. If this was linux, some of the command-line tools I would start using:
* dmesg (check logs to see what hardware as recognized and actions taken by the system/kernel on their being recognized. Is it rejected? Why?)
* lsusb (if connected as a USB HDD)
* hdparm
* gparted / parted
* smartctl

less helpful, but maybe useful if your controller is to blame for lack of access:
* dmidecode
* lspci

From these, see if the drive is detected and a geometry is reported. You can see if the drive is still connected to the OS, just not mounted, see any details about the drive that would gove you hints about accessing it.

If it is still connected to the OS, maybe you can see what partitions if any are detected, and what types they are.

Once you know the types of partitions you have, then it may help you to narrow down the type of filesystem that may be used, and if you know that, if encryption is being used.

Once you know the partition type, filesystem used, and any encryption used, that should direct you to which tools you can use to mount it if you have the legitimate key to mount/decrypt the data.

Another useful tool is "dd" to allow you to efficiently image entire devices, or partitions for analysis of data without keeping the drive connected.

As far as breaking crypto on such a device (if you do not have the key) the methods for that fall into two basic categories:
* repetitive guessing (intelligent (dictionary attack, likely words, known reduced key-spaces) or brute-force)
* crypto weaknesses (known plain-text, leakage of secrets, crypto-protocol weaknesses/failures, etc.)

Much of crypto relies on an assumption that the encrypter and decrypter are "secure" from being observed while working, and all evidence of their work (including their copy of any private keys in memory, etc. except the final product: encrypted text) are destroyed when they are finished. Much of crypto is designed to create a "secure" document to travel across hostile environments and remain secure. Because of this, many modern attacks focus on violating that assumption. We see attacks based on RFI generated by the CPU/system to try to guess instructions being used processed, data being examined, images on CRT (see tempest devices) and attacks that look at tiny changes in power supplied to a computer when it is encrypting data, generating keys, etc. We also see attacks that look at hibernate files OS/hardware sometimes keep around, which may have secrets to help decrypt data.

I am not legally allowed to help you actually break any of the crypto on this specific device, and I do not think I have sufficient skills to help in this space anyway, but the above is the general approach i would take if I wanted to try to recover data from a drive that I found.

Hopefully, someone from the car hacking village with experience with these drives and their methods for encryption will be able to help you further. Sadly, the forums are not used as much as they once were, so people don't visit them as often to discuss things like this. If you get no action here, try asking on twitter to see if they can suggest a better place to ask:
https://twitter.com/carhackvillage

They have a site with links to a book, too: http://www.carhackingvillage.com/

If you do find a good place to discuss these things, please follow-up here with where you went, so other people can benefit from your experience.

HTH,
-Cot

[I3root]

Made some progress! I suppose this means the hard drive is locked?


~$ sudo hdparm -I /dev/sdb

/dev/sdb:

ATA device, with non-removable media
Model Number: HGST HEJ423220H9E300
Serial Number: **************
Firmware Revision: F62OA180
Transport: Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6; Revision: ATA8-AST T13 Project D1697 Revision 0b
Standards:
Used: unknown (minor revision code 0x0028)
Supported: 8 7 6 5
Likely used: 8
Configuration:
Logical max current
cylinders 16383 16383
heads 16 16
sectors/track 63 63
--
CHS current addressable sectors: 16514064
LBA user addressable sectors: 268435455
LBA48 user addressable sectors: 390721968
Logical Sector size: 512 bytes
Physical Sector size: 4096 bytes
Logical Sector-0 offset: 0 bytes
device size with M = 1024*1024: 190782 MBytes
device size with M = 1000*1000: 200049 MBytes (200 GB)
cache/buffer size = 8192 KBytes (type=DualPortCache)
Form Factor: 2.5 inch
Nominal Media Rotation Rate: 4260
Capabilities:
LBA, IORDY(can be disabled)
Queue depth: 32
Standby timer values: spec'd by Standard, no device specific minimum
R/W multiple sector transfer: Max = 16 Current = 16
Advanced power management level: 128
DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=120ns IORDY flow control=120ns
Commands/features:
Enabled Supported:
* SMART feature set
* Security Mode feature set
* Power Management feature set
* Write cache
* Look-ahead
* Host Protected Area feature set
* WRITE_BUFFER command
* READ_BUFFER command
* NOP cmd
* DOWNLOAD_MICROCODE
* Advanced Power Management feature set
Power-Up In Standby feature set
* SET_FEATURES required to spinup after power up
SET_MAX security extension
* 48-bit Address feature set
* Device Configuration Overlay feature set
* Mandatory FLUSH_CACHE
* FLUSH_CACHE_EXT
* SMART error logging
* SMART self-test
* General Purpose Logging feature set
* WRITE_{DMA*MULTIPLE}_FUA_EXT
* 64-bit World wide name
* IDLE_IMMEDIATE with UNLOAD
* WRITE_UNCORRECTABLE_EXT command
* {READ,WRITE}_DMA_EXT_GPL commands
* Segmented DOWNLOAD_MICROCODE
* Gen1 signaling speed (1.5Gb/s)
* Native Command Queueing (NCQ)
* Host-initiated interface power management
* Phy event counters
* NCQ priority information
Non-Zero buffer offsets in DMA Setup FIS
DMA Setup Auto-Activate optimization
Device-initiated interface power management
In-order data delivery
* Software settings preservation
* SMART Command Transport (SCT) feature set
* SCT Write Same (AC2)
* SCT Error Recovery Control (AC3)
* SCT Features Control (AC4)
* SCT Data Tables (AC5)
Security:
Master password revision code = 43981
supported
enabled
locked
not frozen
not expired: security count
supported: enhanced erase
Security level maximum
78min for SECURITY ERASE UNIT. 80min for ENHANCED SECURITY ERASE UNIT.
Logical Unit WWN Device Identifier: ****************
NAA : 5
IEEE OUI : 000cca
Unique ID : *********
Checksum: correct

[TheCotMan]

You have ~24 hours where you can edit a post from the date/time you create it. You may want to edit it to remove item-specific information like "serial number", "unique id" and "Device Identifier" . I can't immediately think of a way an evil user might abuse having this information, but I am betting there is at least one.

From what you have provided, let's check with google...

ATA device, with non-removable media
Model Number: HGST HEJ423220H9E300
Serial Number: [redacted]
Firmware Revision: F62OA180

So, this appears to be from drive manufacturer "HGST".
Asking google JUST the Model number (Google for HEJ423220H9E300) gives us more specific links, and the top one is directly to the same claimed vendor's site.

"Endurastar J4K320 Datasheet - HGST" which is a PDF, so let's make another google search with that:

Google Search: 'Endurastar J4K320 Datasheet HGST type:pdf'

A search like this can be helpful, since different versions of specs published will sometimes provide different information, and the differences sometimes expose cases where a removal (or addition) highlights something "we" would like to learn more about. The most common reasons for addition or removal in docs is clarity, or revision of bad information, but sometimes the differences expose information useful for learning more about a device.

[This is nothing new. It has been used by people to compare FOIA requests at different times to see which portions are redacted under each administration to uncover changes in risk/exposure in what was exposed but no longer is. It is also used by "evil hackers" that have access to source code repositories to look for changes checked-in. Find a recent change in a piece of code in a service that is widely used, and a security risk, then create an exploit against that before the fix goes to the public.]

So, two likely prospects:
https://www.hgst.com/sites/default/f...4K320_ds_0.pdf
https://www.hgst.com/sites/default/f...SJ4K320_ds.pdf
And in another language, probably Japanese, what looks like a specs sheet summary of specs:
https://www.hgst.com/sites/default/f..._new_Rev00.pdf

and much less likely:
https://www.hgst.com/sites/default/f...s-03242016.pdf
https://www.hgst.com/sites/default/f...s-12022015.pdf


Considering only the first two docs, use in "Automotive" and 200GB availability (as yours) help support this as a likely candidate.

So, assume you have an "Endurastar J4K320" made by "HGST"...

A search of both of the top two PDF, i do not find any matching words on page for:
* secur[irty*e]*]
* FDE
* encrypt[ion*ed**]

It is possible for feature like disk-supported, hardware-based FDE with something like AES256 to be added to models for large orders, but not common or likely; this is expensive, and its added complexity increases risk for down-time, maintenance and drops in customer satisfaction and like any manufacturer, extra costs for things that won't increase sales are difficult to justify.

Another possibility is for it to be connected to a "RAID Controller" or drive controller and even if it is by itself (JBOD), may have firmware/code installed at the beginning of the disk to identify it as proprietary in such a way that:
* When inserted in a generic SATA controller, it is not recognized as an available disk, or is recognized as a disk, but part of an unrecognized/unsupported "foreign array"/LD.
* When a generic disk is inserted into the the vehicle's drive bay, the vehicle's controller can recognize it is not a "Genuine, $Company_named part" , forcing customers to only replace (or upgrade) the provided drive with one bought from the car manufacturer.

I doubt either one of those is in play here. Either one adds cost. Corps gain greater advantage in removing even tiny costs from many different parts and parts of a process, since they all add up and make their product cost more than the competition, causing them lost sales.

A search for the firmware version with google shows nothing. Maybe you are the first to get that far with a disk in analysis and then post it in a place where google can index, or maybe this is the first to write about a disk with this level of detail with this version of firmware.

Looking at more of the data you provided...

Security:
Master password revision code = 43981
supported
enabled
locked
not frozen
not expired: security count
supported: enhanced erase
Security level maximum
78min for SECURITY ERASE UNIT. 80min for ENHANCED SECURITY ERASE UNIT.
Logical Unit WWN Device Identifier: [redacted]

From the above, I would guess that:
* A user password has been set on the drive ["enabled"] and is presently "locked" with that password protection: https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase
* Changes are allowed to the present state but not all security settings [ "SEC4" = "Security: enabled" + "locked" + "not frozen"] : http://www.t13.org/documents/Uploade...ifications.pdf
* "Secure Erase" and "Enhanced Erased" are supported and time for each in minutes are for how long to erase the whole device

ATA_PDF_URL = http://www.t13.org/documents/UploadedDocuments/docs2006/e05179r4-ACS-SecurityClarifications.pdf

State SEC4: Security Enabled/ Locked/ Not Frozen:
This state shall be entered when the device is powered-up or a hardware reset is received with the Security feature set enabled.
In this state, the device shall respond to all commands except those indicated as Command Aborted in “Locked” column. With the exception of the SECURITY commands, execution of these commands does not cause a transition from state SEC4.
When entering this state from power-on or hardware reset, the device shall set the password attempt counter to five.
The device shall report IDENTIFY DEVICE or IDENTIFY PACKET DEVICE field values in accordance with Table 6 .

So, now what will you do? You should review the risks of trying an invalid password "too many times" on a drive that is "security enabled" and "locked" but SO FAR "not frozen" and understand the risks and implication of it becoming "frozen".

There may be additional layers of encryption or security beyond this, but it is doubtful they would use software-based encryption from linux for the cost/support/reliability issues mentioned above AND performance issues if they want to use a cheap processor. For similar performance without software-based encryption, they would have to pay for a faster CPU or at least one more core.

You have made significant progress on your own. What will you do next?

I do not know the legal risks you may face here in trying to bypass their password. I am not a lawyer. If I were discussing this on a public forum with intent to bypass the security of a device like this, I'd probably find what my legal exposure is before posting too much. As a non-lawyer, it seems some legal protections have been provided to people that own the hardware to break it apart for the purpose of research and education. In my view, that is what you are doing, but again, I am not a lawyer. (Provide a circumstance for anything to a lawyer and ask if there is a way it could be found legal, and then ask them if there is a way for it to be found illegal, and if you pay enough money to a lawyer that is sufficiently skilled, they will probably say yes to both questions and provide ways to make each one true.)

Again, I am not part of the hardware hacking village or car hacking village. Nothing I wrote or have written represents them or their opinion.

I don't speak for anything at DEF CON. :-)

[I3root]

TheCotMan,
Thanks for jumping in with both feet!

So based on http://www.t13.org/documents/Uploade...ifications.pdf, it looks like there are "only" 65k master password options :-)
Theoretically, it is doable to brute force it as long as I can easily power off/on the drive via software...
The big question is how will the drive react if I lock it: lock up until reboot or erase. The latter would be real bad as I am not going back to the dealer with an "unexplained catastrophic failure"!

Maybe the strategy is to get a similar drive to replicate the behavior . I can throw $30 at this: http://www.amazon.com/Hta422020f9atj.../dp/B00DH3OJ5Y

btw, got some pictures of the different chips. The biggest baddest chip is a Xilinx Spartan-6 XACSLX451... a frigging FPGA! The others are Radio, AV & sdram.
I did look for markings on the boards for console, rt/tx or even jtag but the boards are not silkscreened. +1 for BWM.

[TheCotMan]

TheCotMan,
Thanks for jumping in with both feet!

So based on http://www.t13.org/documents/Uploade...ifications.pdf, it looks like there are "only" 65k master password options :-)
Theoretically, it is doable to brute force it as long as I can easily power off/on the drive via software...
The big question is how will the drive react if I lock it: lock up until reboot or erase. The latter would be real bad as I am not going back to the dealer with an "unexplained catastrophic failure"!

Maybe the strategy is to get a similar drive to replicate the behavior . I can throw $30 at this: http://www.amazon.com/Hta422020f9atj.../dp/B00DH3OJ5Y

btw, got some pictures of the different chips. The biggest baddest chip is a Xilinx Spartan-6 XACSLX451... a frigging FPGA! The others are Radio, AV & sdram.
I did look for markings on the boards for console, rt/tx or even jtag but the boards are not silkscreened. +1 for BWM.

Short answer: I do not know.

The result of poorly guessing a password would vary from device to device. It could be like USB-based smartcards with a PIN. With many of these, you get 3 tries to enter a PIN, then the device enters a state of being "locked" where you can submit a PUK and get 3 tries, and then after that if the PUK fails 3 times? The key is lost. In some cases, the device is bricked, and others the device can be re-inited and a new key can be used. For many of these devices, the counter is reset to zero once the password/PIN is properly entered.

There is probably a counter or a timer or both. What action is taken when this threshold is reached is unknown. Finding any online docs on the drive which explains the action it takes would be your best bet. Guessing wrong could mean losing your data on the drive and result in a drive that can't be used again.
A timer would allow multiple attempts to re-enter the password within the given time before an action is taken.
A counter would increment failed attempts until some maximum is reached, and then take action.

If you find there is a counter, and you can see the value of the counter increment after the first try, you could reconnect it to the car, and let it "enter the right password/PIN" for you and you can see if that resets the counter to zero.

If there is a timer, that is more risky. You probably won't have time to reconnect it to the original controller to send the right password/PIN before it expires.

Find docs that detail this drive's actions when incorrect password is guessed, and see if the docs refer to a timer, counter, both, or none of these.

[Cannect]

So I'm just jumping in here. I haven't read the spec, but I wonder if there is a way start the drive while in the vehicle and piggy back the power and then do a hot swap between the vehicle and your computer. This will allow the drive password to be bypassed and then you can just slip through afterwards? Not sure if there are some initialization issues that would prevent this. Just a quick thought?

[I3root]

Cannect, excellent idea! I've ordered a sata extension cable :-)
Seems it is doable, but google has not shown people using that to unlock a cable. Worse the specs explicitly support hotswap triggering documented events.
If the hd firmware does it right, it should relock when the data cable is pulled out of the car...

But a bigger concern is how the car reacts to that event: it would be on acc when I pull the data cable. There is a chance it could be writing to disk at that point, but I am ready to take a chance. Worse, it could send that event back via telemetry...:-(
I'll mull over it while waiting for the cable.


Further reaserch is promissing:
https://www1.informatik.uni-erlangen...s-at-risks.pdf