Attend XDA's Second Annual Developer Conference, XDA:DevCon 2014!
5,786,868 Members 42,455 Now Online
XDA Developers Android and Mobile Development Forum

Bootloader cracked and next steps

Tip us?
 
nemith
Old
(Last edited by nemith; 18th January 2012 at 02:59 AM.)
#1  
Senior Member - OP
Thanks Meter 463
Posts: 218
Join Date: Jun 2010
Default Bootloader cracked and next steps

So now that we have found the leaking crack in the bootloader and proved it's usefulness fat-tire and others are going to start work on a couple of key projects that I could use a little help on.

This will also keep conspiracy theorists at bay who call me "extremely low IQ male rooster with social development issues" (Also I have no pies)

Here is how i see the next steps:
  1. Strip down uboot (or other bootloader) and teach it boot from it's own partition.

    For example install 2nduboot in /boot, hijacking the signature check and then setting a 1MB offset to look for the real, unsigned boot.img. Repeat for recovery.

    This is the real hold up and why there is nothing to "flash" as of yet. (still no pies)

  2. Finish CWM. 100% done.
    Completed. See recovery.img here: http://forum.xda-developers.com/show....php?t=1440645

  3. Work on CM9 for both SDcard and internal booting

    See Below



So instead of insulting me. I am looking for some people to help work on these things. We are going to be doing this is private respostories and a private irc channel due to the stupid reward that is out there.

If you are wanting to work with me. The reward (if we get done by the 22nd) goes to Doctors Without Borders. This is where we should all be donating. No negotiating.

So PM me or come to #nook-tablet @ freenode
The Following 112 Users Say Thank You to nemith For This Useful Post: [ Click to Expand ]
 
nemith
Old
(Last edited by nemith; 14th January 2012 at 08:33 AM.)
#2  
Senior Member - OP
Thanks Meter 463
Posts: 218
Join Date: Jun 2010
Default Reserved

Bootstrap-loader (Goal #1)
Here is some more details on my thoughts on bootstrapping /boot and /recovery to boot unsigned images.

Today we are only bootstrapping with a 2nduboot on the sdcard. This would allow custom kernels and ramdisks on emmc for things like easier root, overclocking, CM9, CWM, etc

So my thoughts were to bundle together a bootstrap bootloader (uboot obviously will work, but another project that was used for CM on the touchpad called, moboot, may be a nice option to get menus and such) and the unsigned kernel+ramdisk into one binary blob. The unsigned boot.img will be at a well known offset. This will allow us to act as "stock" as possible and do things like. Replace just the kernel with an OC one. Replace just the ramdisk with ro.secure=0, etc.



This would also allow us to completely replace recovery with CWM.

Current Status: Fattire working on a meny for SD booting. Still discussing best way to do internal booting although using bauwks bootstrap uboots will work for now for emmc but incorporating a possible menu is being looked into. Low Priority


CM9 (Goal #2) Inprogress
There is a lot here and I am going to go at it pretty methodically adding one feature at a time. So graphics first, then key/touchscreen, usb gadget, etc.

There is a number of kernel changes that need to be done:
  • Find the closest git repo/branch/revision from omap zoom to apply B&N changes as a patch.

    This will allow us to a) have revision history b) allow merging up to 3.0 easier

    This is pretty important and if anyone is handy with git and knows of an easy way. Let me know
  • Backport key changes (fattire probably has this already done)
  • Backport usb gadget
  • Backport a hwrenderer compatable sgx drives (maybe move to a 3.x kernel at this point instead)
  • Backport

Current Status:





Teasers:

The Following 57 Users Say Thank You to nemith For This Useful Post: [ Click to Expand ]
 
Loglud
Old
#3  
Senior Member
Thanks Meter 442
Posts: 199
Join Date: Jul 2011

 
DONATE TO ME
Wow. Thanks nemith for all the info. I will work with you and 100% will give the donation to them (verbal and writen agreement). From when I was building CWM on the GNex I remeber having to change one of the values in the .mk file to allow for adb.
Current list of devices:
HTC Rezound
Samsung Infuse 4G
Samsung Galaxy Nexus - CM10 Nightly
Barns & Noble Nook Tablet - CM9
Transformer TF201 - CM10 Nightly

Current projects:
[Dev] [NARS] [Mac & Linux] Nook Automated Rooting System
CASUAL

Quote:
If I have seen further it is only by standing on the shoulders of giants.
-Sir Isaac Newton
 
bauwks
Old
(Last edited by bauwks; 12th January 2012 at 02:04 AM.) Reason: results
#4  
Junior Member
Thanks Meter 149
Posts: 16
Join Date: Jan 2012
Hi nemith,

That is a nice plan which aligned with my plan for modding u-boot to boot off the internal partitions .

I pushed some changes into my git repository on github which looks like #1 on your list. git://github.com/bauwks/Nook-Tablet.git

So for example, to build a 2nd u-boot that will install to the internal flash partition "recovery" and try to load the next stage at offset 256K of the internal "recovery" partition one would do:

(cd to u-boot directory and switch to second-uboot branch first, then)
PATH=/usr/local/arm-2010q1/bin:$PATH
make nt2ndboot_irecovery
make
./tools/build_nt_2ndboot_img.py -f -o irecovery.img u-boot.bin
dd if=/dev/zero of=irecovery.img bs=1 seek=262143 count=1 # pads to 256K size


Then, you can cat your irecovery.img and your real recovery.img together and blast them onto the recovery partition.

There is also a nt2ndboot_iboot config that will do the same, but is used on the "boot" partition.

I have only done minimal testing with the recovery partition 2nd uboot. I'm about to write a full image onto my recovery partition and see what happens

Update:

I flashed my recovery partition with irecovery.img + a random twrp2 image I had and it boots solely from internal flash! No more SD card needed, no more USB connection needed, just holding down power+N

Quote:
Originally Posted by nemith View Post
So now that we have found the leaking crack in the bootloader and proved it's usefulness fat-tire and others are going to start work on a couple of key projects that I could use a little help on.

This will also keep conspiracy theorists at bay who call me "extremely low IQ male rooster with social development issues" (Also I have no pies)

Here is how i see the next steps:
  1. Strip down uboot (or other bootloader) and teach it boot from it's own partition.

    For example install 2nduboot in /boot, hijacking the signature check and then setting a 1MB offset to look for the real, unsigned boot.img. Repeat for recovery.

    This is the real hold up and why there is nothing to "flash" as of yet. (still no pies)

  2. Finish CWM. 100% done.
    Completed. See recovery.img here: http://forum.xda-developers.com/show....php?t=1440645

  3. Work on CM9 for both SDcard and internal booting

    Started on this one as well. I can boot but haven't got adb working and no graphics (expected at this point)



So instead of insulting me. I am looking for some people to help work on these things. We are going to be doing this is private respostories and a private irc channel due to the stupid reward that is out there.

If you are wanting to work with me. The reward (if we get done by the 22nd) goes to Doctors Without Borders. This is where we should all be donating. No negotiating.

So PM me or come to #nook-tablet @ freenode
The Following 33 Users Say Thank You to bauwks For This Useful Post: [ Click to Expand ]
 
fattire
Old
#5  
fattire's Avatar
Recognized Developer
Thanks Meter 4,393
Posts: 1,522
Join Date: Oct 2010
Lightbulb A bit on UI, cleanup, and various boot scenarios

Bauwks.. cool, glad emmc is is a go.

Quote:
Current Status: Fattire working on a menu for SD booting. Still discussing best way to do internal booting although using bauwks bootstrap uboots will work for now for emmc but incorporating a possible menu is being looked into
UB2 update from me: A fruitful night with lots of fun enhancements, some modest UI feedback, and a sprinkling of safety/sanity fixes and other tweaks. SD and emmc options should be more convenient/consistent now, with recovery selection effectively handled by UB2 not UB1 (though power+n will remain an option obviously). I'll let nemith elucidate.

Also, bauwks, nemith suggested, and I thought it wasn't a bad idea, to expand to 512K instead of 256K as a partition buffer just to be on the safe side. I think he said the partitions are 16MB in all, so a little extra padding for possible future bloat is probably not a bad thing to have-- especially if there's gonna be a 2nd-bootloader "standard" (ie, so that any UB2 or menu will work in the future...) now's the time to decide- what do you think? Is 512 reasonable? Adding a single new .rle pushes you over. (We actually can eliminate two .rles right now, as the "charging" and "plugin" ones are effectively useless. I got rid of them, then added two more for feedback so I'm back to even, though eventually I'll probably get rid of them too.) What are your thoughts?

Considering I don't have an NT and I'm working blind here with nemith testing... I think this could wind up pretty nifty.
The Following 13 Users Say Thank You to fattire For This Useful Post: [ Click to Expand ]
 
dhkr234
Old
#6  
Account currently disabled
Thanks Meter 157
Posts: 574
Join Date: Jan 2011
Quote:
Originally Posted by bauwks View Post
Update:

I flashed my recovery partition with irecovery.img + a random twrp2 image I had and it boots solely from internal flash! No more SD card needed, no more USB connection needed, just holding down power+N
Nice!!!!
I was loathing the idea of having to keep a bootable sdcard in the thing forever. From my understanding of this, this hardware is now "cured", and just needs a special blob appended to the front of the boot and recovery partitions, eh?
The Following User Says Thank You to dhkr234 For This Useful Post: [ Click to Expand ]
 
fattire
Old
#7  
fattire's Avatar
Recognized Developer
Thanks Meter 4,393
Posts: 1,522
Join Date: Oct 2010
Quote:
Originally Posted by dhkr234 View Post
Nice!!!!
I was loathing the idea of having to keep a bootable sdcard in the thing forever. From my understanding of this, this hardware is now "cured", and just needs a special blob appended to the front of the boot and recovery partitions, eh?
Yeah. Or more specifically, everything in those partitions will need to be shoved over by a set amount to make room for UB2.
The Following User Says Thank You to fattire For This Useful Post: [ Click to Expand ]
 
bauwks
Old
#8  
Junior Member
Thanks Meter 149
Posts: 16
Join Date: Jan 2012
Quote:
Originally Posted by fattire View Post
Also, bauwks, nemith suggested, and I thought it wasn't a bad idea, to expand to 512K instead of 256K as a partition buffer just to be on the safe side. I think he said the partitions are 16MB in all, so a little extra padding for possible future bloat is probably not a bad thing to have-- especially if there's gonna be a 2nd-bootloader "standard" (ie, so that any UB2 or menu will work in the future...) now's the time to decide- what do you think? Is 512 reasonable? Adding a single new .rle pushes you over. (We actually can eliminate two .rles right now, as the "charging" and "plugin" ones are effectively useless. I got rid of them, then added two more for feedback so I'm back to even, though eventually I'll probably get rid of them too.) What are your thoughts?
Hi fattire,

I guess it depends on how you look at it. I was looking at it like: an "image" is a concatenation of a 2nduboot and an Android kernel/ramdisk. To install, one would just dd the "image" to a partition. Then the 2nduboot wouldn't have to have a fixed max size that is predefined, if it needs to be increased you would just modify the partition offset in the bootcmd to load the stuff after the new size. It would also make updating the 2nduboot easier because it's part of the "image".

But, I have not worked with Android before so I do not have expertise in how images are typically deployed. If you always want the real image to be at a fixed offset then increasing to 512K makes a lot of sense. You are free to use the solution that best fits your problem.

By the way, the offset of the real image doesn't have to be a power of 2, it only has to be a multiple of the MMC sector size (512 bytes).
The Following 6 Users Say Thank You to bauwks For This Useful Post: [ Click to Expand ]
 
CelticWebSolutions
Old
#9  
CelticWebSolutions's Avatar
Senior Member
Thanks Meter 2,021
Posts: 736
Join Date: May 2011

 
DONATE TO ME
I can't really offer much as I am no android developer. I can modify basics and work thinsg out through educated trial and error but most of what you guys have been on about has been way out of my league. If it makes any difference I have 2 NTs one of which is brand new in a sealed box just sat waiting for the correct time to bother getting it out to play.

I'm quite happy to do testing, tweak things and do what I can where required.

Not sure what happened about the reward thing but as has been said before I think giving it to a good cause is a very decent and honest thing to do.

Doing it and donating the 'winnings' to a good cause is a far better idea and I commend you for following that route. Those that do it solely for the money aren't doing it for the reasons that I think XDA exists and from what I've seen before often get their money out of blatantly using other members hard work to make themselves look good, there always seems to be a lot of sitting on the fence then diving in at the last second and releasing something as their own when most of it isn't.

Anyway, enough babbling from me! Keep up the good work and when you think I can be of any help I will be more than happy to chip in where required.
 
dhkr234
Old
(Last edited by dhkr234; 13th January 2012 at 02:08 AM.)
#10  
Account currently disabled
Thanks Meter 157
Posts: 574
Join Date: Jan 2011
Quote:
Originally Posted by bauwks View Post
Hi fattire,

I guess it depends on how you look at it. I was looking at it like: an "image" is a concatenation of a 2nduboot and an Android kernel/ramdisk. To install, one would just dd the "image" to a partition. Then the 2nduboot wouldn't have to have a fixed max size that is predefined, if it needs to be increased you would just modify the partition offset in the bootcmd to load the stuff after the new size. It would also make updating the 2nduboot easier because it's part of the "image".

But, I have not worked with Android before so I do not have expertise in how images are typically deployed. If you always want the real image to be at a fixed offset then increasing to 512K makes a lot of sense. You are free to use the solution that best fits your problem.

By the way, the offset of the real image doesn't have to be a power of 2, it only has to be a multiple of the MMC sector size (512 bytes).
Presumably, the partition table is write protected along with the xloader and bootloader partitions, right? Now I guess that would be by power-on-write-protect rather than permanent write protect (which would obviously lock even THEM out of it...). Stupid question, but has anyone checked if the eMMC reset pin is connected to a test point on the board or on some gpio we can manipulate? I'm just wondering if we can pull something like a gfree on this sucker, especially since the eMMC is practically identical to the one on VISION/GLACIER/ACE, just larger. Bounce that reset pin and reinitialize the eMMC with write protect disabled, replace xloader and uboot with proper uncrippled ones, and BE GOD.

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes