Jump to content
LightInDark

Bootloader unlocking

Recommended Posts

Thought I'd start a thread about it but anyone experimented with this yet? What happens when trying to get into fastboot to do it like with the tegra tablets it just took the line fastboot OEM unlock to do it.

I'm gonna mess around with my fastboot see where I can get since there's not many devs yet for the hudl so I'll play my part too.

  • Upvote 1

Share this post


Link to post
Share on other sites

Thought I'd start a thread about it but anyone experimented with this yet? What happens when trying to get into fastboot to do it like with the tegra tablets it just took the line fastboot OEM unlock to do it.

I'm gonna mess around with my fastboot see where I can get since there's not many devs yet for the hudl so I'll play my part too.

 

Have you done anything with this yet? Is the bootloader locked? Is that why we can only run a tethered recovery?

 

Edit, I did some digging and by checking in 

/dev/block/platform/intel/by-label

It will show you the partitions

 

Here is the output

lrwxrwxrwx root     root              2015-06-25 15:01 ESP -> /dev/block/mmcblk0p2
lrwxrwxrwx root     root              2015-06-25 15:01 boot -> /dev/block/mmcblk0p3
lrwxrwxrwx root     root              2015-06-25 15:01 cache -> /dev/block/mmcblk0p11
lrwxrwxrwx root     root              2015-06-25 15:01 config -> /dev/block/mmcblk0p10
lrwxrwxrwx root     root              2015-06-25 15:01 data -> /dev/block/mmcblk0p15
lrwxrwxrwx root     root              2015-06-25 15:01 factory -> /dev/block/mmcblk0p8
lrwxrwxrwx root     root              2015-06-25 15:01 fastboot -> /dev/block/mmcblk0p5
lrwxrwxrwx root     root              2015-06-25 15:01 logs -> /dev/block/mmcblk0p12
lrwxrwxrwx root     root              2015-06-25 15:01 misc -> /dev/block/mmcblk0p9
lrwxrwxrwx root     root              2015-06-25 15:01 panic -> /dev/block/mmcblk0p7
lrwxrwxrwx root     root              2015-06-25 15:01 recovery -> /dev/block/mmcblk0p4
lrwxrwxrwx root     root              2015-06-25 15:01 reserved -> /dev/block/mmcblk0p1
lrwxrwxrwx root     root              2015-06-25 15:01 reserved_1 -> /dev/block/mmcblk0p6
lrwxrwxrwx root     root              2015-06-25 15:01 rom -> /dev/block/mmcblk0p14
lrwxrwxrwx root     root              2015-06-25 15:01 system -> /dev/block/mmcblk0p13
Edited by Daniel_Twigg
  • Upvote 1

Share this post


Link to post
Share on other sites

I've been messing around with this for a couple of days now so thought I'd join to add my observations and progress so far (some from searching and some my own). 

 

The hudl uses a signed process with tesco certificates programmed into the UEFI/BIOS NVRAM as a trust anchor. The contents of /sys/firmware/efi/vars shows UEFI secure boot is enabled. The relevant items are: 

KEK-8be4df61-93ca-11d2-aa0d-00e098032b8c/data
KEKDefault-8be4df61-93ca-11d2-aa0d-00e098032b8c/data
PK-8be4df61-93ca-11d2-aa0d-00e098032b8c
PKDefault-8be4df61-93ca-11d2-aa0d-00e098032b8c
SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c
SecureBootEnforce-59d1c24f-50f1-401a-b101-f33e0daed443
SecureFlashInfo-382af2bb-ffff-abcd-aaee-cce099338877
Setup-a04a27f4-df00-4d42-b552-39511302113d
SetupMode-8be4df61-93ca-11d2-aa0d-00e098032b8c
 
As secure boot is enabled, I tried copying the whole of mmcblk0 to an extenal sd card (and USB stick) and booting from that. I expected this would work as the signatures should still be correct, however, it fails with a different error to the "security violation" reported elsewhere here - e.g. when you try to run fedlet etc. from USB stick. Does anyone have any ideas why? 
 
I tried randomising the disk and partition GUIDs on the SD image using sgdisk (as they overlap the the mmcblk0 image) but this results in booting the eMMC image without any useful error message from the UEFI.
 
Dumping the contents of the ESP fat partition (EFI/Intel/efilinux.efi) possibly explains this as the guids of the boot partitions are embedded in there: 
<hexdump from eflinux.efi> 
7073 2c010100c06a000042010100803b000058010100b03b0000700101000036
7074 000092010100e03b00000000000000000000000000000000000000000000
7075 0000000000000000f402010086808680868086808086000000000100fe02
7076 0100000000001403010086808680868086808086000000000100fe020100
7077 0c0000002403010086808680868086808086000000000101360301000e00
7078 00004c030100868086808680868080860000000001025e0301000e000000
7079 78030100868086808680868080860000000001025e0301000f0000008e03
7080 010086808680868086808086000000000104980301000a000000ae030100
7081 86808680868086808086000000000100c003010014000000da0301000000
7082 000000000000000000000000000000000000504f0000604f0000704f0000
7083 804f0000904f0000a04f0000b04f0000c04f0000d04f0000e04f0000f04f
 
The guids from the main boot partitions are in here (with some weird sizes / endianness going on) - here are the partition guids 
 
1 80868086-8086-8086-8086-FFFFFFFFFFF0 130.0 MiB reserved
2 C12A7328-F81F-11D2-BA4B-00A0C93EC93B 33.0 MiB ESP
3 80868086-8086-8086-8086-000000000100 16.0 MiB boot
4 80868086-8086-8086-8086-000000000101 16.0 MiB recovery
5 80868086-8086-8086-8086-000000000102 16.0 MiB fastboot
6 80868086-8086-8086-8086-0000000000FF 32.0 MiB reserved_1
7 80868086-8086-8086-8086-000000000001 32.0 MiB panic
8 80868086-8086-8086-8086-000000000002 128.0 MiB factory
9 80868086-8086-8086-8086-000000000003 128.0 MiB misc
10 80868086-8086-8086-8086-000000000004 128.0 MiB config
11 80868086-8086-8086-8086-000000000005 1.5 GiB cache
12 80868086-8086-8086-8086-000000000006 1024.0 MiB logs
13 80868086-8086-8086-8086-000000000007 2.0 GiB system
14 80868086-8086-8086-8086-000000000103 2.0 MiB rom
15 80868086-8086-8086-8086-000000000008 9.4 GiB data
 
It might be worth noting that there are some files hidden in the ESP partition that can be undeleted / recovered. These contain Tesco x509 certificates but unfortunately I can't find the private key ;) - shame they weren't that dumb. You can find those by mounting the ESP partition and running some forensics. 
 
100 (boot) 101 (recovery), 102 (fastboot) and 104 (???) are specified in the efi loader. I expect this is to do with signature verification and I don't think it's possible to change these partitions without the signing key or hacking the UEFI...
 
So, I tried to dump the bootrom (winbond SPI) using the technique described here: 
 
 
Unfortunately, I couldn't get this to work because /dev/mem didn't exist. creating this with busybox mknod didn't work either. Getting this technique working could facilitate a software attack on the hudl2 secure boot strap process but I resorted to disassembling the tablet and dumping the contents of the SPI rom using a beaglebone black instead (see this link for an idea how).
 
 
This required soldering to the hudl's motherboard - the pins around the SPI boot flash are clearly labelled on the solder mask and it's possible to read (at least - haven't tried writing yet) the winbond SPI device in-circuit.   This attempt was a success and I have an image of the hudl2's SPI boot flash. I'm now looking to modify it to disable secure boot or enable the setup screen (if there is one). Next step is to make sense of the dumped bios.
Edited by badger1729
  • Upvote 1

Share this post


Link to post
Share on other sites

 

I've been messing around with this for a couple of days now so thought I'd join to add my observations and progress so far (some from searching and some my own). 

 

The hudl uses a signed process with tesco certificates programmed into the UEFI/BIOS NVRAM as a trust anchor. The contents of /sys/firmware/efi/vars shows UEFI secure boot is enabled. The relevant items are: 

KEK-8be4df61-93ca-11d2-aa0d-00e098032b8c/data
KEKDefault-8be4df61-93ca-11d2-aa0d-00e098032b8c/data
PK-8be4df61-93ca-11d2-aa0d-00e098032b8c
PKDefault-8be4df61-93ca-11d2-aa0d-00e098032b8c
SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c
SecureBootEnforce-59d1c24f-50f1-401a-b101-f33e0daed443
SecureFlashInfo-382af2bb-ffff-abcd-aaee-cce099338877
Setup-a04a27f4-df00-4d42-b552-39511302113d
SetupMode-8be4df61-93ca-11d2-aa0d-00e098032b8c
 
As secure boot is enabled, I tried copying the whole of mmcblk0 to an extenal sd card (and USB stick) and booting from that. I expected this would work as the signatures should still be correct, however, it fails with a different error to the "security violation" reported elsewhere here - e.g. when you try to run fedlet etc. from USB stick. Does anyone have any ideas why? 
 
I tried randomising the disk and partition GUIDs on the SD image using sgdisk (as they overlap the the mmcblk0 image) but this results in booting the eMMC image without any useful error message from the UEFI.
 
Dumping the contents of the ESP fat partition (EFI/Intel/efilinux.efi) possibly explains this as the guids of the boot partitions are embedded in there: 
<hexdump from eflinux.efi> 
7073 2c010100c06a000042010100803b000058010100b03b0000700101000036
7074 000092010100e03b00000000000000000000000000000000000000000000
7075 0000000000000000f402010086808680868086808086000000000100fe02
7076 0100000000001403010086808680868086808086000000000100fe020100
7077 0c0000002403010086808680868086808086000000000101360301000e00
7078 00004c030100868086808680868080860000000001025e0301000e000000
7079 78030100868086808680868080860000000001025e0301000f0000008e03
7080 010086808680868086808086000000000104980301000a000000ae030100
7081 86808680868086808086000000000100c003010014000000da0301000000
7082 000000000000000000000000000000000000504f0000604f0000704f0000
7083 804f0000904f0000a04f0000b04f0000c04f0000d04f0000e04f0000f04f
 
The guids from the main boot partitions are in here (with some weird sizes / endianness going on) - here are the partition guids 
 
1 80868086-8086-8086-8086-FFFFFFFFFFF0 130.0 MiB reserved
2 C12A7328-F81F-11D2-BA4B-00A0C93EC93B 33.0 MiB ESP
3 80868086-8086-8086-8086-000000000100 16.0 MiB boot
4 80868086-8086-8086-8086-000000000101 16.0 MiB recovery
5 80868086-8086-8086-8086-000000000102 16.0 MiB fastboot
6 80868086-8086-8086-8086-0000000000FF 32.0 MiB reserved_1
7 80868086-8086-8086-8086-000000000001 32.0 MiB panic
8 80868086-8086-8086-8086-000000000002 128.0 MiB factory
9 80868086-8086-8086-8086-000000000003 128.0 MiB misc
10 80868086-8086-8086-8086-000000000004 128.0 MiB config
11 80868086-8086-8086-8086-000000000005 1.5 GiB cache
12 80868086-8086-8086-8086-000000000006 1024.0 MiB logs
13 80868086-8086-8086-8086-000000000007 2.0 GiB system
14 80868086-8086-8086-8086-000000000103 2.0 MiB rom
15 80868086-8086-8086-8086-000000000008 9.4 GiB data
 
It might be worth noting that there are some files hidden in the ESP partition that can be undeleted / recovered. These contain Tesco x509 certificates but unfortunately I can't find the private key ;) - shame they weren't that dumb. You can find those by mounting the ESP partition and running some forensics. 
 
100 (boot) 101 (recovery), 102 (fastboot) and 104 (???) are specified in the efi loader. I expect this is to do with signature verification and I don't think it's possible to change these partitions without the signing key or hacking the UEFI...
 
So, I tried to dump the bootrom (winbond SPI) using the technique described here: 
 
 
Unfortunately, I couldn't get this to work because /dev/mem didn't exist. creating this with busybox mknod didn't work either. Getting this technique working could facilitate a software attack on the hudl2 secure boot strap process but I resorted to disassembling the tablet and dumping the contents of the SPI rom using a beaglebone black instead (see this link for an idea how).
 
 
This required soldering to the hudl's motherboard - the pins around the SPI boot flash are clearly labelled on the solder mask and it's possible to read (at least - haven't tried writing yet) the winbond SPI device in-circuit.   This attempt was a success and I have an image of the hudl2's SPI boot flash. I'm now looking to modify it to disable secure boot or enable the setup screen (if there is one). Next step is to make sense of the dumped bios.

 

 

Wow, that's a lot of information. I didn't think anybody was interested in hacking the Hudl 2.

 

What are you trying to gain from this? 

 

Do you know if we are able to flash our own custom recovery onto recovery -> /dev/block/mmcblk0p4 ?

What happens if this is attempted currently? 

Share this post


Link to post
Share on other sites

Wow, that's a lot of information. I didn't think anybody was interested in hacking the Hudl 2.

 

What are you trying to gain from this? 

 

Do you know if we are able to flash our own custom recovery onto recovery -> /dev/block/mmcblk0p4 ?

What happens if this is attempted currently? 

 

If you try and flash custom recovery that isn't signed correctly, when you attempt to boot into recovery, you just boot into droidboot instead.

 

I have tested this with TWRP and Clockwork. You can even unpack and repack the original recovery without editing anything, but this breaks the digital signature unfortunately.

Share this post


Link to post
Share on other sites

Wow, that's a lot of information. I didn't think anybody was interested in hacking the Hudl 2.

 

What are you trying to gain from this? 

 

Do you know if we are able to flash our own custom recovery onto recovery -> /dev/block/mmcblk0p4 ?

What happens if this is attempted currently? 

 

My goal was to get dual-boot working (android on eMMC and Linux on SD card). I managed to do that this morning by editing the UEFI SPI flash (as per "attack 1" here: http://www.intelsecurity.com/resources/pr-bios-secure-boot-attacks-uncovered.pdf). My hudl now runs fedlet and ubuntu.   

 

This approach will allow other (unsigned) android images to be loaded. However, I don't know if it's possible to write to the SPI flash without soldering to the hudl's motherboard (which is what I did)

 

If someone can get SPI flash writing from software then it would be possible to disable secure boot using this method without any soldering. This would allow booting any image - it just needs a single bit to be changed in the SPI flash, this invalidates a signing cert and disables secure boot. I don't plan to work on doing this. 

Edited by badger1729
  • Upvote 1

Share this post


Link to post
Share on other sites

I'm guessing there is a way from Software as I've seen tesco take some into store, they go into the back to the tech bit, do some stuff come back like 15 minutes later and its reset from a brick and such. There must be ways to reflash from software (not all tesco's did this, some said they had to send it away so I'm guessing its something that only specific engineers can do which are only in select locations).

 

My guess is maybe it's similar to how UEFI in laptops are, many laptops with UEFI are locked or severely limited in functionality, only way to get passed the limitations is by flashing the UEFI partition with a custom bootloader and BIOS. Obviously on laptops this is easy since Windows can directly communicate with the BIOS. So I'm guessing the first thing that we'd need to do for the Hudl2 is the boot/UEFI/BIOS, without somehow hacking that first we won't be able to do anything. But just my guess.

 

So it would take a lot of digging to find a way to access the UEFI to reflash it, I couldn't even find a "recovery menu" like many tablets do when you hold things like Power and Vol +.

  • Upvote 1

Share this post


Link to post
Share on other sites

I'd love the Hudl2 to get more dev love, it's an amazing tablet, and it's perfect for devs, modern hardware that competes with most mid-high end tablets, great build quality and great size 8.3inches. Cheap and affordable, SD support, HDMI, and a 1920 x 1200 screen :) More than my gaming laptop!

  • Upvote 1

Share this post


Link to post
Share on other sites

 

 

If someone can get SPI flash writing from software then it would be possible to disable secure boot using this method without any soldering. This would allow booting any image - it just needs a single bit to be changed in the SPI flash, this invalidates a signing cert and disables secure boot. I don't plan to work on doing this. 

Is it possible to use a compiled Flashrom ( http://flashrom.org/Flashrom ) then use tethered CWM adb to load to target and read and write.

Share this post


Link to post
Share on other sites

Is it possible to use a compiled Flashrom ( http://flashrom.org/Flashrom ) then use tethered CWM adb to load to target and read and write.

No, there is one way and only one way to unlock an Intel devices, ask the company who makes your device to give you the software to unlock it.

There is really no good reason for them not to give you the software except they don't want to.

Edited by vampirefo

Share this post


Link to post
Share on other sites

No, there is one way and only one way to unlock an Intel devices, ask the company who makes your device to give you the software to unlock it.

There is really no good reason for them not to give you the software except they don't want to.

 

I disagree, any number of other possibilities exist which don't require access to the private key for a manufacturer cert. 

 

1) You can open the tablet up, modify and reprogram the boot flash. I can confirm this because I've done it and it works. The soldering required isn't that bad and the hudl is easy to disassemble. You don't even have to remove the SPI flash chip from the PCB to change its contents. 

2) You might be able to open up the tablet and get access to GPIO_SO_SC[065]  - "Security Flash Descriptors" and disable secure boot (depends on the PCB and implementation). 

3) Or get into the UEFI setup somehow to disable secure boot (The hudl's bootrom contains a setup utility - "SetupBrowser"). As of now, I haven't worked out if this is accessible. 

4) Or otherwise find a weakness in the UEFI

5) Break any other part of the boot security chain for a signed build - bootloaders, kernel etc. 

6) ... 

Share this post


Link to post
Share on other sites

Yeah, or get the software as I already said. Less than 3 users will try hardware way.

However it's your tablet do as you like, Now if someone who knows or has contacted the company in the passed would just request the software, everyone would profit not just the 3 people willing to dissemble their tablets.

Edited by vampirefo

Share this post


Link to post
Share on other sites

I agree that getting the signing key(s) would be great. I expect the answer would be 'no' but if someone has the energy and inclination to try that approach then why not. 

 

A company over here pen tested the hudl 1 and noted it was possible to read the internal storage over USB. This made the national press and it's possible the additional boot security in the hudl2 is intended to address this weakness. Why the singled out the hudl I don't know - it must be possible to retrieve the internal flash on many laptops phones and tablets in a similar manner. I think the bad press from this issue may make them reluctant to release information that would allow a similar attack on the hudl2. Allowing anyone to create bootable code would put them in a similar position and they'd lose control over the bundled bloatware...

 

I think there are a couple of software approaches to unlocking the hudl2 that might be worth exploring:

 

1. Is it possible to enter the setup utility somehow (and disable secure boot). It's an Insyde H20 bios and the utility is in there. Maybe it can be made to load on next boot using UEFI OsIndications. Perhaps some kind of fast boot process similar to windows 8 fast boot is preventing the keyboard from being initialised in time to access setup. I'm no UEFI expert but I found a string to that effect in the dumped rom.  

 

2. Flashrom doesn't seem to work as it does on other bay trail tablets (Teclast x99 threads). This could be because the SPI flash is locked and inaccessible at runtime, or some other reason (e.g. Linux kernel configuration). Verifying this would help us rule this in/out as a potential avenue of attack.

 

3. It's possible one of the files that can be undeleted from the ESP boot partition was a development utility that could be useful somehow. One file appears to be a firmware volume from a UEFI rom binary. One (or more - can't remember) of the others contain tesco certs. 

 

4. Trawling through the boot rom using a disassembler may hold some clues but there's a lot in there - this would be time consuming. 

Share this post


Link to post
Share on other sites

My Intel's are unlocked, clovertrail Dell gave us the software to unlock it, my newest Intel came unlocked, it's a baytrail.

  • Upvote 1

Share this post


Link to post
Share on other sites

hudl2 does not need unlock!

Its not locked!!

This is very possible, the recovery.img provided had no signature so it's not done via signature.

I have never seen a pic of bootloader, that should narrow it down.

Are you able to flash modified boot.img or recovery.img?

I have not seen any proof the bootloader is locked, sure people say it is, but that doesn't mean a thing.

Edited by vampirefo

Share this post


Link to post
Share on other sites

The .efi loader almost certainly has some secure boot protection and it's most probably verified using one of the certs in the boot ROM. I say this because attempting to boot other efi loaders resulted in a "security violation" until I changed a single bit in the boot ROM that disables secure boot. After making that change, I can boot Linux live images with 32-bit efi loaders as well as a grub efi image I built.

 

So, I'm sure the secure boot verification goes at least as far as verifying the EFI images in /dev/block/mmcblk0p2 (both of which are identical).

 

However, that doesn't necessarily mean the .efi loader verifies subsequent images. As noted previously, the .efi loaders contain the GUIDs of the partitions containing the Linux kernels so it's possible some kind of verification of those partitions is occurring within the .efi loader.

 

Reverse engineering the efi loader would tell us exactly what's going on and I had a quick look at that in IDA. Unfortunately, it isn't the easiest code to analyse and doesn't decompile very nicely :(

Edited by badger1729

Share this post


Link to post
Share on other sites

Here is a pick of my bootloader unlocked,

 

 

Anyway badger1729  can you, flash custom recovery to your tablet, or modified boot.img, Post a pic of your bootloader.

 

 

andscreen_04_142911.jpg

Edited by vampirefo

Share this post


Link to post
Share on other sites
I can post a pic of grub / fedora / ubuntu running on the hudl if you like?
 
I haven't modified the eMMC at all yet (only the boot SPI) and I'm currently booting Linux over USB OTG. Booting other OSs was my goal with the hudl2 but I'm happy to help out with trying to boot other android images. 
 
Which image do you suggest flashing? I know Linux but am pretty new with android. There are three kernel / ramdisk partitions on the eMMC - mmcblk0p3, mmcblk0p4 & mmcblk0p5, and I have backup copies of them. I could replace one of those by dd'ing another image over it.
 
I guess modifying the contents of one of those partitions would check if the efi loader is verifying its contents or not - is this what you're looking to accomplish?

Share this post


Link to post
Share on other sites

While those pics are interesting, still not a pic of bootloader, dual booting has nothing to due with locked or unlocked bootloader, flashing modified recovery.img and or boot.img does.

 

If you can flash modifed boot.img or recovey.img, then yes your device is different than everyone else's if not then it is the same as everyone's.

 

The Ausu me176cx verified by pic of bootloader and via Ausu themselves that the bootloader is indeed locked, can dual boot windows.

Edited by vampirefo

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×

Important Information

By using this site, you agree to our Terms of Use.