Guest LightInDark Posted June 25, 2015 Report Share Posted June 25, 2015 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. Link to comment Share on other sites More sharing options...
Guest Daniel_Twigg Posted June 25, 2015 Report Share Posted June 25, 2015 (edited) 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 June 25, 2015 by Daniel_Twigg Link to comment Share on other sites More sharing options...
Guest badger1729 Posted June 25, 2015 Report Share Posted June 25, 2015 (edited) 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: http://ao2.it/en/blog/2014/11/21/teclast-x98-air-3g-cheap-intel-bay-trail-tablet-getting-acquainted 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). http://ao2.it/en/blog/2014/12/30/teclast-x98-air-3g-unbricking-bay-trail-tablet 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 June 25, 2015 by badger1729 Link to comment Share on other sites More sharing options...
Guest Daniel_Twigg Posted June 26, 2015 Report Share Posted June 26, 2015 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: http://ao2.it/en/blog/2014/11/21/teclast-x98-air-3g-cheap-intel-bay-trail-tablet-getting-acquainted 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). http://ao2.it/en/blog/2014/12/30/teclast-x98-air-3g-unbricking-bay-trail-tablet 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? Link to comment Share on other sites More sharing options...
Guest 4L0M Posted June 26, 2015 Report Share Posted June 26, 2015 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. Link to comment Share on other sites More sharing options...
Guest badger1729 Posted June 26, 2015 Report Share Posted June 26, 2015 (edited) 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 June 26, 2015 by badger1729 Link to comment Share on other sites More sharing options...
Guest LightInDark Posted June 27, 2015 Report Share Posted June 27, 2015 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 +. Link to comment Share on other sites More sharing options...
Guest LightInDark Posted June 27, 2015 Report Share Posted June 27, 2015 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! Link to comment Share on other sites More sharing options...
Guest vermillions Posted June 30, 2015 Report Share Posted June 30, 2015 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. Link to comment Share on other sites More sharing options...
Guest vermillions Posted June 30, 2015 Report Share Posted June 30, 2015 Also this looks interesting: http://ao2.it/en/blog/2014/11/21/teclast-x98-air-3g-cheap-intel-bay-trail-tablet-getting-acquainted Link to comment Share on other sites More sharing options...
Guest vampirefo Posted June 30, 2015 Report Share Posted June 30, 2015 (edited) 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 June 30, 2015 by vampirefo Link to comment Share on other sites More sharing options...
Guest vermillions Posted June 30, 2015 Report Share Posted June 30, 2015 I should have read post 4 better i see it has already been tried. Link to comment Share on other sites More sharing options...
Guest badger1729 Posted July 1, 2015 Report Share Posted July 1, 2015 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) ... Link to comment Share on other sites More sharing options...
Guest vampirefo Posted July 1, 2015 Report Share Posted July 1, 2015 (edited) 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 July 1, 2015 by vampirefo Link to comment Share on other sites More sharing options...
Guest vampirefo Posted July 1, 2015 Report Share Posted July 1, 2015 Heck, you might be able to start your own unlocking business. Link to comment Share on other sites More sharing options...
Guest badger1729 Posted July 1, 2015 Report Share Posted July 1, 2015 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. Link to comment Share on other sites More sharing options...
Guest vampirefo Posted July 2, 2015 Report Share Posted July 2, 2015 My Intel's are unlocked, clovertrail Dell gave us the software to unlock it, my newest Intel came unlocked, it's a baytrail. Link to comment Share on other sites More sharing options...
Guest arnookie Posted July 4, 2015 Report Share Posted July 4, 2015 hudl2 does not need unlock! Its not locked!! Link to comment Share on other sites More sharing options...
Guest CPN200 Posted July 4, 2015 Report Share Posted July 4, 2015 ... and your evidence for that is? Link to comment Share on other sites More sharing options...
Guest vampirefo Posted July 4, 2015 Report Share Posted July 4, 2015 (edited) 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 July 4, 2015 by vampirefo Link to comment Share on other sites More sharing options...
Guest badger1729 Posted July 4, 2015 Report Share Posted July 4, 2015 (edited) 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 July 4, 2015 by badger1729 Link to comment Share on other sites More sharing options...
Guest vampirefo Posted July 4, 2015 Report Share Posted July 4, 2015 (edited) 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. Edited July 4, 2015 by vampirefo Link to comment Share on other sites More sharing options...
Guest badger1729 Posted July 4, 2015 Report Share Posted July 4, 2015 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? Link to comment Share on other sites More sharing options...
Guest badger1729 Posted July 4, 2015 Report Share Posted July 4, 2015 Images of grub and fedora / fedlet on the hudl2 Link to comment Share on other sites More sharing options...
Guest vampirefo Posted July 4, 2015 Report Share Posted July 4, 2015 (edited) 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 July 4, 2015 by vampirefo Link to comment Share on other sites More sharing options...
Recommended Posts
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now