[Nook HD+] Nook HD and HD+ rooting instructions (now permanent)

[verygreen]

How to root Nook HD+ (and Nook HD too, I guess).
(Thanks for some useful ideas to sparkym3: http://xdaforums.com/member.php?u=4411543 )

(tested only on 2.0.0 version (as comes out of the box), also works on 2.0.2

Get one of the attached files: root_win.zip if you are on windows, or root_unix.tgz if you are on Linux or Mac.

unpack the file to some dir and run "makeroot" on Windows or "sh makeroot.sh" on Mac/Linux

After a couple of reboots you should be able to do
adb shell and issue a "su" command in the shell and get the root prompt (#).

Thanks to someone0 for his prior investigations here.

Known bugs:
Superuser.apk does not really install because package manager could not be contacted.

Oh, and I think you'll find this interesting too:

 

[fattire]

Hai.

Kind of a two-fer, eh?

 

[verygreen]

I noticed that people see their Nook HDs restoring to factory settings after 8 unsuccessful reboots next time you boot after rooting, so possibly there's some extra check somewhere.
Very sneaky on the B&N side, I'd say.

 

[roustabout]

Hm, the 8 failed boot = wipe and restore has been true since the NC, and is valuable because it helps keep the device from getting bricked, also triggerable if the registration token doesn't match BN's reg token. I learned this early on by restoring a backup made before I'd erased and deregistered. I forget where the token lives, in /data/ somewhere.

I'll take a look at this on 2.0.2 this weekend - mine updated before I got ADB working so it restores to 2.0.2 now...

OK, so this approach does work with the 2.0.2 OS, and restarting the device does put it into a boot cycle. Very nasty.

Before I rebooted, I removed the post_boot_hook file and also got rid of the symlink; I'd say BN is doing some kind of inventory of what's in system and driving a reflash based on that.

My guess is it's not a very careful inventory, but it'll certainly be amenable to study now that we can get, at least temporarily, root.

Hm. Interesting -- my ability to mkdir /data/su is now gone after the restore. I wasn't able to do it the first time I tried, either - I suspect that there's something keeping some level of eye on that.

Oh, very uncool - in addition to resetting the system, they wipe personal data in the process. Losing the apps doesn't surprise me much. Losing the books I'd sideloaded surprises me.

 

[MrCamby]

Hm, the 8 failed boot = wipe and restore has been true since the NC, and is valuable because it helps keep the device from getting bricked, also triggerable if the registration token doesn't match BN's reg token. I learned this early on by restoring a backup made before I'd erased and deregistered. I forget where the token lives, in /data/ somewhere.

I'll take a look at this on 2.0.2 this weekend - mine updated before I got ADB working so it restores to 2.0.2 now...

OK, so this approach does work with the 2.0.2 OS, and restarting the device does put it into a boot cycle. Very nasty.

Before I rebooted, I removed the post_boot_hook file and also got rid of the symlink; I'd say BN is doing some kind of inventory of what's in system and driving a reflash based on that.

My guess is it's not a very careful inventory, but it'll certainly be amenable to study now that we can get, at least temporarily, root.

Hm. Interesting -- my ability to mkdir /data/su is now gone after the restore. I wasn't able to do it the first time I tried, either - I suspect that there's something keeping some level of eye on that.

Oh, very uncool - in addition to resetting the system, they wipe personal data in the process. Losing the apps doesn't surprise me much. Losing the books I'd sideloaded surprises me.

Do the new HD & HD+ still allow you boot from the external sd card ?

 

[krylon360]

Hm, the 8 failed boot = wipe and restore has been true since the NC, and is valuable because it helps keep the device from getting bricked, also triggerable if the registration token doesn't match BN's reg token. I learned this early on by restoring a backup made before I'd erased and deregistered. I forget where the token lives, in /data/ somewhere.

I'll take a look at this on 2.0.2 this weekend - mine updated before I got ADB working so it restores to 2.0.2 now...

OK, so this approach does work with the 2.0.2 OS, and restarting the device does put it into a boot cycle. Very nasty.

Before I rebooted, I removed the post_boot_hook file and also got rid of the symlink; I'd say BN is doing some kind of inventory of what's in system and driving a reflash based on that.

My guess is it's not a very careful inventory, but it'll certainly be amenable to study now that we can get, at least temporarily, root.

Hm. Interesting -- my ability to mkdir /data/su is now gone after the restore. I wasn't able to do it the first time I tried, either - I suspect that there's something keeping some level of eye on that.

Oh, very uncool - in addition to resetting the system, they wipe personal data in the process. Losing the apps doesn't surprise me much. Losing the books I'd sideloaded surprises me.

if you put your books into /system/media, it will back them up to the cloud

 

[leapinlar]

Is it possible to push a new recovery with adb after rooting? The 8 failed boot repair is only possible with the stock recovery. But then again you may end up in an endless bootloop without it there to finish it's task. But maybe you can find and delete the trigger flag that starts the process.

 

[krylon360]

Is it possible to push a new recovery with adb after rooting? The 8 failed boot repair is only possible with the stock recovery. But then again you may end up in an endless bootloop without it there to finish it's task. But maybe you can find and delete the trigger flag that starts the process.

stuff is best to be not mentioned. /sarcasm.....

 

[verygreen]

recovery is signed, so it's not super easy to replace it with anything that would run.
The unsigned bootloader trick at the moment requires a boot from sdcard.

 

[someone0]

shouldn't step 8 & 9 be outside the code block?

 

[roberc567]

verygreen:

I just want to thank you for your all your work on the Nook series. I've been using your "size-agnostic method ..." tools and process to run from the SD card on my Nook Color since you created the method, and now I'm excited to use your work on my new Nook HD+ (just received yesterday) !

 

[madsquabbles]

just got mine and got an update notification. turned off wifi so it didnt complete.any word if it breaks root ir bootloader?

 

[verygreen]

CWM is now possible too.

 

[someone0]

Something is interesting, eventhough mine originally got automatically updated to 2.0.2, but after the factory reset, it went back to 2.0.0. But for some weird reason I can't get root.

Maybe this will help, the build number is 2.0.0.1031.lithium01.ovation.rldp.s68403 with the manufactured date 10/22/2012
please compare mine to your.

I also rewrote your code into a batch file. You can double check it I guess.

@echo off
cls
@echo .
@echo wait for it
@echo .
adb devices
@echo .
@echo if you do not see you device listed above hit ctrl+c and exit the script
@echo then check adb on your PC and device then try again.
@echo .
@echo reroute /data/local/tmp
adb wait-for-devices shell rm -r /data/local/tmp
adb shell ln -s /data/ /data/local/tmp
@echo .
@echo Now rebooting
@echo .
adb reboot
@echo .
@echo waiting for reboot to finish and making directory /data/su
adb wait-for-devices shell mkdir /data/su
@echo uploading su
adb push su /data/su/
@echo uploading busybox
adb push busybox /data/su/
@echo uploading boot_complete_hoot
adb push boot_complete_hook.txt /data/boot_complete_hook.sh
adb shell chmod 755 /data/boot_complete_hook.sh /data/su/*
@echo .
@echo Now rebooting again
@echo .
adb reboot
@echo .
@echo waiting for reboot to finish and getting shell
adb wait-for-devices shell

 

[verygreen]

Something is interesting, eventhough mine originally got automatically updated to 2.0.2, but after the factory reset, it went back to 2.0.0. But for some weird reason I can't get root.

Maybe this will help, the build number is 2.0.0.1031.lithium01.ovation.rldp.s68403 with the manufactured date 10/22/2012
please compare mine to your.

I also rewrote your code into a batch file. You can double check it I guess.

so, when you run this, after the final adb shell, what are the permissions on /system/xbin/su?

run su and you should get the root prompt.

 

[someone0]

I don't get root prompt, su never get copied to /system/xbin/su
here is the list of my finding.

/data/
-rwxr-xr-x shell    shell         167 2012-11-10 05:52 boot_complete_hook.sh
/data/su
-rwxr-xr-x shell    shell      586212 2012-11-10 06:07 busybox
-rwxr-xr-x shell    shell       22364 2012-11-10 06:07 su
/data/local
lrwxrwxrwx shell    shell             2012-11-10 06:20 tmp -> /data/

cat boot_complete_hook.sh
#!/system/bin/sh
/data/su/busybox mount /system -o remount,rw
/data/su/busybox cp /data/su/su /system/xbin/su
chown 0.0 /system/xbin/su

everything is in place and correct, but no dice. either boot_complete_hook.sh didn't get executed or it did but never get launched with root permission.

 

[verygreen]

I don't get root prompt, su never get copied to /system/xbin/su
here is the list of my finding.

/data/
-rwxr-xr-x shell    shell         167 2012-11-10 05:52 boot_complete_hook.sh
/data/su
-rwxr-xr-x shell    shell      586212 2012-11-10 06:07 busybox
-rwxr-xr-x shell    shell       22364 2012-11-10 06:07 su
/data/local
lrwxrwxrwx shell    shell             2012-11-10 06:20 tmp -> /data/

cat boot_complete_hook.sh
#!/system/bin/sh
/data/su/busybox mount /system -o remount,rw
/data/su/busybox cp /data/su/su /system/xbin/su
chown 0.0 /system/xbin/su

everything is in place and correct, but no dice.

well, there should be more stuff in the shell file, you miss the final chown line: chmod 06755 /system/xbin/su

 

[someone0]

It did, I just didn't copy and paste the output correctly. But regardless, since the foulder /system/xbin don't have the su file, this mean as I suspected earlier, either it wasn't executed or lauched w/ root permission.

 

[verygreen]

It did, I just didn't copy and paste the output correctly. But regardless, since the foulder /system/xbin don't have the su file, this mean as I suspected earlier, either it wasn't executed or lauched w/ root permission.

check if your /system/bin/clrbootcount.sh calls /data/boot_complete_hook.sh

 

[someone0]

check if your /system/bin/clrbootcount.sh calls /data/boot_complete_hook.sh

This is interesting, it look as if it won't launch the /data/boot_complete_hook.sh

cat /data/boot_complete_hook.sh
#!/system/bin/sh
/data/su/busybox mount /system -o remount,rw
/data/su/busybox cp /data/su/su /system/xbin/su
chown 0.0 /system/xbin/su
chmod 06755 /system/xbin/su
[B]shell@android:/data $ /data/boot_complete_hook.sh
/data/boot_complete_hook.sh
/system/bin/sh: /data/boot_complete_hook.sh: No such file or directory
1|shell@android:/data $
[/B]

Yub it does

cat clrbootcount.sh
#!/system/bin/sh
################################################################################
##
#
# File          clrbootcount.sh
# Description   Clear the bootcount variable to 0 on successful boot
#
##
# Run potential hook first.
[B]/data/boot_complete_hook.sh[/B]
# Zero the boot count
cat /system/etc/zerobootcnt > /bootdata/BootCnt