Bootloader unlocking

[Guest vampirefo]

What is needed is a pic of your bootloader, and pic of some other hudl 2 owner bootloader.

If they are the same, that for one proves taking the tablet a part and making modifications did nothing, which is what I really suspect.

The two bootloader images should be different cause your claim is the bootloader was locked and you unlocked it.

That info will show clear as day on the two different bootloader pics.

I think the bootloader is already unlocked, odd not one person asks the company that makes the tablet.

Hey is the booloader locked? If they say yes, then it's locked, then ask can we have unlocking software? This tablet is soon to be old and no more updates to come, so why not provide us with unlocking software.

Edited July 5, 2015 by vampirefo

[Guest badger1729]

As stated previously, I haven't changed the eMMC at all, including any loader on there so I expect the contents of the eMMC are the same as any other hudl. 

 

What changing the SPI ROM does is stop the UEFI from verifying the signature on the .efi loader which is essentially the first stage in the boot process. That means the EFI loader and all subsequently loaded software can be replaced with anything, hence it's possible to load other OSs.   

 

Secure boot is supposed to work like this: 

1) UEFI firmware verifies .EFI TE is genuine, and if it passes, loads it 

2) .EFI TE verifies the subsequent image (loader?), and if it passes, loads it 

3) That image verifies the kernel and, if it passes, loads it

4) The kernel at runtime verifies all kernel-mode modules 

(we haven't yet verified what checking, if any, occurs during step 2 onwards on the hudl) 

 

Breaking the verification at 1) - i.e. stopping the FW from verifying the EFI loader, will allow anything to run afterwards as that's the most critical step in the boot security chain. While this won't magically unlock a bootloader in the eMMC, it does allow that BL to be completely replaced with one that is "unlocked".

Edited July 5, 2015 by badger1729

[Guest vampirefo]

As stated previously, I haven't changed the eMMC at all, including any loader on there so I expect the contents of the eMMC are the same as any other hudl. 

 

What changing the SPI ROM does is stop the UEFI from verifying the signature on the .efi loader which is essentially the first stage in the boot process. That means the EFI loader and all subsequently loaded software can be replaced with anything, hence it's possible to load other OSs.   

 

Secure boot is supposed to work like this: 

1) UEFI firmware verifies .EFI TE is genuine, and if it passes, loads it 

2) .EFI TE verifies the subsequent image (loader?), and if it passes, loads it 

3) That image verifies the kernel and, if it passes, loads it

4) The kernel at runtime verifies all kernel-mode modules 

(we haven't yet verified what checking, if any, occurs during step 2 onwards on the hudl) 

 

Breaking the verification at 1) - i.e. stopping the FW from verifying the EFI loader, will allow anything to run afterwards as that's the most critical step in the boot security chain. While this won't magically unlock a bootloader in the eMMC, it does allow that BL to be completely replaced with one that is "unlocked".

Your posts are well, entertaining in the end your bootloader image is the same as everyone else's.

 

It's cool, anyway I downloaded Fedlet, my writer(Startup Disk Creator) refuses to write it, yet it write Ubuntu iso just fine,.

on Ubuntu I boot to choice screen 

try Ubuntu without installing

and so on, I guess it wants a keyboard.

 

I would like to try Fedlet, cause my understanding touch works, I don't have a hub to connect keyboard, so I am out on getting into Ubuntu.

[Guest badger1729]

That thing you call a "Choice Screen" is a bootloader. It's called GRUB (GRand Unified Bootloader). You could boot an android image from it without even touching the original bootloader in the MMC.

 

I said from the outset that my goal was to run other OSs on the hudl (i.e. non-Android). I've been looking at the wider boot security in an attempt to help others who want to boot different android images and because I'm interested to understan how it works.

 

I think I'll call it a day here as this has stopped being enjoyable.

[Guest vampirefo]

That thing you call a "Choice Screen" is a bootloader. It's called GRUB (GRand Unified Bootloader). You could boot an android image from it without even touching the original bootloader in the MMC.

 

I said from the outset that my goal was to run other OSs on the hudl (i.e. non-Android). I've been looking at the wider boot security in an attempt to help others who want to boot different android images and because I'm interested to understan how it works.

 

I think I'll call it a day here as this has stopped being enjoyable.

Yes I know it's grub as I only use Linux, none the less have a good day. I can scroll up and down but can't select, as keyboard must be needed. I was trying to see if a modified recovery.img could be installed on hudl2 tablet, seems we are never going to get there, no interest in it.

Edited July 5, 2015 by vampirefo

[Guest bbthebeard]

You both have your own ideas and i think its great you are both working on this to everyones benifit and i find it very interesting viewing your individual thoughts. I hope badger1729 carrys on and the 2 of you can work things out individually or together. I say again great work!

[Guest vampirefo]

You both have your own ideas and i think its great you are both working on this to everyones benifit and i find it very interesting viewing your individual thoughts. I hope badger1729 carrys on and the 2 of you can work things out individually or together. I say again great work!

Oh, we are fine, I have started booting different distros on my tablet, so far Lubuntu seems to be the best for my tablet.

Needs some work need to get wifi and touch working.

Trying to find android device that uses same wifi and touch that has released kernel source.

[Guest dennissingh99]

Has anyone got further into solving this problem? There haven't been any updates since the past month.

[Guest dennissingh99]

I have attached the Bios file that was found in the latest OTA, so that someone with the expertise of editing these sort of files can have a crack at it.

BIOSUPDATE.zip

[Guest Myshkin Gleb]

HUDL2

KOT49H.rel.android-build.20150529.110309 release-keys

help to find the firmware

[Guest dennissingh99]

Could someone please tell me what this setting for the secure boot represents?

[Guest mole62]

 

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. 

Thanks for the info!  I've read the pdf linked in your post, re "Attack 1: Via Platform Key in SPI NVRAM" which shows a single character change needed to disable secure boot... but I really don't understand the steps you've taken. Assume there's a pin that needs earthing / two pins bridging or similar, then the root files can be downloaded, modified and reflashed? I've checked your link re the Telcast X98 Air 3G, but didn't see details of what soldering was required... 

Would you be able to explain the steps, and what hardware/software is needed? Already have android-tools on gentoo (provides adb, fastboot) and a rooted Hudl2. Apologies if the info is around elsewhere, I have tried searching without luck... 

[Guest dennissingh99]

Thanks for the info!  I've read the pdf linked in your post, re "Attack 1: Via Platform Key in SPI NVRAM" which shows a single character change needed to disable secure boot... but I really don't understand the steps you've taken. Assume there's a pin that needs earthing / two pins bridging or similar, then the root files can be downloaded, modified and reflashed? I've checked your link re the Telcast X98 Air 3G, but didn't see details of what soldering was required... 

Would you be able to explain the steps, and what hardware/software is needed? Already have android-tools on gentoo (provides adb, fastboot) and a rooted Hudl2. Apologies if the info is around elsewhere, I have tried searching without luck... 

I know that the software that you will need is flashrom which you can install on a raspberry pI or a beaglebone black and then connect the chip to the gpio pins and use flashrom to dump the data and then flash back. I've got a bit of an idea of how to connect the chip the the beaglebone black but don't have access to it. I do have a raspberry pi though so if someone could help me to connect the chip to that, it would help me alot.

[Guest mole62]

I know that the software that you will need is flashrom which you can install on a raspberry pI or a beaglebone black and then connect the chip to the gpio pins and use flashrom to dump the data and then flash back. I've got a bit of an idea of how to connect the chip the the beaglebone black but don't have access to it. I do have a raspberry pi though so if someone could help me to connect the chip to that, it would help me alot.

Flashrom is available on Gentoo, wonder it it would be possible to use a PC, laptop or netbook running Linux? Have scanned the man pages and FAQ but they are more about options, etc, using the software than how to connect the hardware up... although it does say "No physical access needed, root access is sufficient (not needed for some programmers)" on the homepage. This post probably shows how little I know about the subject..... :-)

[Guest dennissingh99]

It is possible to use Flashrom on a device running Linux. I have tried it myself but as badger1729 has already said in a previous post, it will lead to an error with /dev/mem not existing if we try to run it stright from the Hudl 2 by pusing the flashrom that we have compiled onto the hudl 2 through adb and then running it using the shell as su. But it will work fine if we flash just the chip  itself when it is outside the tablet.

[Guest dennissingh99]

This is how you would install it on linux:

$ sudo apt-get install pciutils-dev
$ sudo apt-get install zlib1g-dev
$ sudo apt-get install libftdi-dev
$ sudo apt-get install libusb-dev

$ sudo apt-get install build-essential

$ sudo apt-get install subversion

$ svn co svn://flashrom.org/flashrom/trunk flashrom
$ cd flashrom
$ make
$ sudo make install

[Guest dennissingh99]

You can also get some information on how to use Flashrom from this website.

http://linux.die.net/man/8/flashrom

 

[Guest mole62]

You can also get some information on how to use Flashrom from this website.

http://linux.die.net/man/8/flashrom

Yes, I'd scanned the man pages but I'm stuck a little earlier than the info there....   so as I understand things:

flashrom could be used from a linux pc, but the Hudl2's lack of /dev/mem is a problem unless direct access is obtained by soldering.... and a Pi or Beaglebox has exposed pins to connect to?

From badger1729's post I'd guess (though it's just a guess and might be totally wrong) that he created /dev/mem, it didn't work and he moved on quickly. Would it be worth looking at this more closely? Maybe issues with user/group/permissions, conflict of major device number? mknod /dev/mem c 1 1 creates /dev/mem crw------, user and group root. On my pc it's crw-r-----  1 root kmem    1,   1   Nothing on my hudl2 in /dev/has major 1 minor 1, there's no /etc/group or /etc/shadow on the hudl2 so I've no idea what group the node should be set to. Would be nervous using major 1, minor 1...

Also grepping the flashrom code for /dev/mem shows:

#if defined (__sun) && (defined(__i386) || defined(__amd64))
#  define MEM_DEV "/dev/xsvc"
#else
#  define MEM_DEV "/dev/mem"
#endif

in physmap.c.   ...so MEM_DEV doesn't have to be set to /dev/mem...  so could it just be hardcoded to a device node which suits the hudl2?

I admit to floundering around in the dark here with little Android  or flashing knowledge!

 

Edited August 10, 2015 by mole62
thought about it a bit more

[Guest dennissingh99]

flashrom could be used from a linux pc, but the Hudl2's lack of /dev/mem is a problem unless direct access is obtained by soldering.... and a Pi or Beaglebox has exposed pins to connect to?

Yes this is true.

From badger1729's post I'd guess (though it's just a guess and might be totally wrong) that he created /dev/mem, it didn't work and he moved on quickly. Would it be worth looking at this more closely? Maybe issues with user/group/permissions, conflict of major device number? mknod /dev/mem c 1 1 creates /dev/mem crw------, user and group root. On my pc it's crw-r-----  1 root kmem    1,   1   Nothing on my hudl2 in /dev/has major 1 minor 1, there's no /etc/group or /etc/shadow on the hudl2 so I've no idea what group the node should be set to. Would be nervous using major 1, minor 1... 

 

Yes, when I had read that line that badger1729 had written, I was also thinking of the same thing, but because I didn't want to brick my hudl 2 just yet, I didn't try to plow on further. I also do think that the permissions may be just the problem.

Also grepping the flashrom code for /dev/mem shows:

#if defined (__sun) && (defined(__i386) || defined(__amd64))
#  define MEM_DEV "/dev/xsvc"
#else
#  define MEM_DEV "/dev/mem"
#endif

in physmap.c.   ...so MEM_DEV doesn't have to be set to /dev/mem...  so could it just be hardcoded to a device node which suits the hudl2?

Yes, Ill try to do some research to see where the hudl 2's MEM_DEV may be and then post back to show the results.

I admit to floundering around in the dark here with little Android  or flashing knowledge!

I also don't have much knowledge of these topics. I'm just a 15 year old kid messing about in his summer holidays :)

also don't tthink that we will need to solder onto the chip as we could just use one of those clips to connect to the chip. If you have opened your Hudl 2 then could you please send me a closeup of that chip. Thanks for your help anyways.

 

Edited August 11, 2015 by dennissingh99

[Guest]

Just as a pointer there is this post http://www.modaco.com/forums/topic/373754-teardown/ on this forum that has some internal hudl2 pictures which maybe of use to you both. Unfortunately the more interesting part is probably under the metal RF shield. 

[Guest mole62]

Yes, think the most interesting parts are under the shield or on the underside of that board! Helpful for disassembling though, shows the catches

Looking into /dev/mem, I've not found any kernel options required for it to work (ie to be a character device file that is an image of the main memory of the device) or to disable it completely, but the CONFIG_STRICT_DEVMEM kernel option restricts access:

"If this option is switched on, the /dev/mem file only allows userspace access to PCI space and the BIOS code and data regions. This is sufficient for dosemu and X and all common users of /dev/mem"

Though that sounds like the access flashrom needs is allowed anyway? Seems to be limiting access to RAM.

so creating it with mknod -m 660 /dev/mem c 1 1, chown root:kmem /dev/mem should work if kmem is the correct group? Permissions of /dev/mem on my linux systems are set at 640 and (I assume) it's working OK. Will try setting permissions at 666 on the hudl2 so the group name doesn't matter, and then try and test /dev/mem - this might be useful  http://www.wiki.xilinx.com/Linux+User+Mode+Pseudo+Driver if I can compile it to run on the hudl2, but there's examples with dd around.

No more time now but will be back on this in a day or two

...and a lot of 15 year olds are better at IT than most old farts my age :-) 

Edited August 11, 2015 by mole62

[Guest dennissingh99]

Yes, think the most interesting parts are under the shield or on the underside of that board! Helpful for disassembling though, shows the catches

Looking into /dev/mem, I've not found any kernel options required for it to work (ie to be a character device file that is an image of the main memory of the device) or to disable it completely, but the CONFIG_STRICT_DEVMEM kernel option restricts access:

"If this option is switched on, the /dev/mem file only allows userspace access to PCI space and the BIOS code and data regions. This is sufficient for dosemu and X and all common users of /dev/mem"

Though that sounds like the access flashrom needs is allowed anyway? Seems to be limiting access to RAM.

so creating it with mknod -m 660 /dev/mem c 1 1, chown root:kmem /dev/mem should work if kmem is the correct group? Permissions of /dev/mem on my linux systems are set at 640 and (I assume) it's working OK. Will try setting permissions at 666 on the hudl2 so the group name doesn't matter, and then try and test /dev/mem - this might be useful  http://www.wiki.xilinx.com/Linux+User+Mode+Pseudo+Driver if I can compile it to run on the hudl2, but there's examples with dd around.

No more time now but will be back on this in a day or two

...and a lot of 15 year olds are better at IT than most old farts my age :-) 

Thanks for all of that Info, but I was thinking, could we just create the kmem user ourselves as I tried to create it using the adduser command in Busybox, but that didn't work. I will try to look more into it. I'm also bidding on an old broken Hudl 2 that I will try to flash a new bios onto. Also, yes, that is the only access that flashrom really requires as it only needs to dump the bios code for us, which we can then edit and flash back.

EDIT - I have tried to set the permission to 666 but that didn't work either. I've also noticed that when you reboot the hudl 2, the /dev/mem previously created gets deleted.

Edited August 11, 2015 by dennissingh99

[Guest mole62]

Thanks for all of that Info, but I was thinking, could we just create the kmem user ourselves as I tried to create it using the adduser command in Busybox, but that didn't work. I will try to look more into it. I'm also bidding on an old broken Hudl 2 that I will try to flash a new bios onto. Also, yes, that is the only access that flashrom really requires as it only needs to dump the bios code for us, which we can then edit and flash back.

EDIT - I have tried to set the permission to 666 but that didn't work either. I've also noticed that when you reboot the hudl 2, the /dev/mem previously created gets deleted.

I've taken the back off the hudl, but having trouble with the connectors to remove the mainboard.... tried tilting the grey part of the connectors both ways, sliding them back and also sliding the white part the other way, but no luck. Don't want to use too much force and damage a connector. Perhaps anyone seeing this who knows about these specific clips could give some advice? I've stripped Samsung i9100 S2, i9300 S3 and Huawei Y300 phones with similar looking clips without any problem.

From Googling around, looks like it's not possible to just dd /dev/mem, but I'll give it a go, as the posts refer to kernel 2.6 onwards, which is when the RAM restriction on /dev/mem was introduced. The only other option would be using the fmem module, but looks like Android uses a monlithic kernel, which I'd expect to be unable to load modules.

[Guest mole62]

Tried dd after mknod'ing /dev/mem, the tried with /dev/kmem, just the same

root@HTF8A4:/dev # dd if=/dev/kmem of=/storage/emulated/legacy/mem bs=4096 count=20
/dev/kmem: cannot open for read: No such device or address

 

Everything online about kernel modules for Android requires a custom kernel so I assume module loading is disabled, have downloaded the hudl2 kernel but there's no .config file in there to quickly check....

Another Modaco post links to this teardown -https://www.pentestpartners.com/blog/first-hudl2-teardown/ the flash chip is on the motherboad underside, boxed in pink. Doesn't look that hard to solder on to the pins...

Edited August 14, 2015 by mole62
added link

[Guest dennissingh99]

I've taken the back off the hudl, but having trouble with the connectors to remove the mainboard.... tried tilting the grey part of the connectors both ways, sliding them back and also sliding the white part the other way, but no luck. Don't want to use too much force and damage a connector. Perhaps anyone seeing this who knows about these specific clips could give some advice? I've stripped Samsung i9100 S2, i9300 S3 and Huawei Y300 phones with similar looking clips without any problem.

From Googling around, looks like it's not possible to just dd /dev/mem, but I'll give it a go, as the posts refer to kernel 2.6 onwards, which is when the RAM restriction on /dev/mem was introduced. The only other option would be using the fmem module, but looks like Android uses a monlithic kernel, which I'd expect to be unable to load modules.

I'm sorry but I didn't understand what grey connector you are talking about. If its the battery one then if u pull the opposite direction to the connector it would come out but you'll probably need to use alot of force.

EDIT-EDIT- I think that i have figured out what grey connectors you are talking about, you just need to pull the white bits up

Edited August 14, 2015 by dennissingh99