yashsingh1/xdaforums huggingface dataset:
[Barnes & Noble Nook Tablet] AdamOutler:
Why don't you just try a port of that? We've got plans and testing them takes time. Go ahead.

This was dropped into my email this morning by Loglud

#include <stdio.h>
#include <stdlib.h>

/*
ramrunner
This program will read a file into memory and execute it.
Parameter 1: The file to read in
Parameter 2: The memory address to read the contents of the file into
*/

int main(int argc, char *argv[]) {
void (*funcptr)();
long destaddress;
char* filename;
FILE* infile;
int currdestptr;
int charbuff;

if(argc != 3) {
printf("Invalid number of arguments (%d).\nramrunner <filename> <memoryaddress>\n", argc);
return 1;
}

destaddress = atol(argv[2]);
filename = argv[1];

funcptr = destaddress;

printf("ramrunner: Loading %s into address %ld\n", argv[1], destaddress);

infile = fopen(filename,"r");
if(! infile) {
printf("Could not open %s\n", filename);
return 1;
}

currdestptr = destaddress;
while ( ( charbuff = fgetc(infile) ) != EOF ) {
// For debugging printf("[%d] %c\n", currdestptr, charbuff);
currdestptr++;
}
fclose(infile);

printf("Hold onto your hats. Calling the function now...\n");
funcptr();
printf("We just called the function. If you're seeing this, things might not have gone to plan. Or maybe they did.\n");

}

It's a good base, but we will need to rewrite it to access /dev/mem. Otherwise we are apparently will be accessing kernel memory. This will be a good way to get a custom U-Boot running.
[Barnes & Noble Nook Tablet] DeanGibson:
1.4.0 and 1.4.1

As some of you may know, B&N posted a "minor" update to 1.4.0 today (about 100 files changed).

Calendar.apk, CalendarProvider.apk, Calculator.apk, DeskClock.apk, and DownloadProviderUi.apk were removed.

The following files relevant to this thread changed:

u-boot.bin

boot.img

MLO did not change.

Anticipated FAQ:

No, I have not installed 1.4.1.

No, I do not know if B&N will auto-update my rooted 1.4.0 (but I will probably find out).

No, I do not know if the 1.4.1 bootloader is still locked.

No, I do not know if the "non-market APK hole" is still open in order to set "enable USB debugging" (and thus root).

These are all valid questions; I just don't know (except #1) the answers. Besides, such questions/answers (except #3) should be in a different thread. I just wanted to head off inevitable questions from being posted in THIS thread.
[Barnes & Noble Nook Tablet] hkvc:
MAYBE Exec_Anycode instead of kexec

*** MAY BE A POSSIBLE EXEC_ANYCODE logic instead of KEXEC***

NOTE: KEXEC tries to run another linux kernel, so may be its logic is more complicated, than if we are trying to run just any code in kernel or better privilage level. I haven't looked into kexec as of now, so I am only guessing about kexec complexity, beyond what I have mentioned below for my method (which again I haven't tried as of now, just a idea).

If one is trying to run something from memory when already in Linux, then one also has to worry about the privilage level at which the processor is running, as well as about page table mapping etc... If the other thing which we are trying to run is another kernel or x-loader or uboot or another bootloader for that matter.

So if kexec doesn't work, may be there is another option available which is to

a) Create a kernel module (NOTE: It runs with same privilages as the kernel) which does

a.1) Disable interrupts so that control doesn't get out of our code

a.2) Over write the reset vector with x-loader or what ever custom bootloader one wants to get control of.

a.3) Change the memory map to have a 1-to-1 map for the region where the code is currently running (or rather for the code which will be run in the next step) or overwrite a region which already has 1-to-1 map between Physical and Virtual addresses, with the code for the next steps. Go to next step.

a.4) Disable page tables (I haven't tried this before, ie after it has already been enabled, but I don't see any reason why ARM doesn't allow this - except for things like what we are trying).

a.5) Change to the reset ARM privilage level (If a soft reset doesn't do it already, haven't looked at ARM at this level for ages, so don't remember)

a.6) Trigger a soft reset

This should give control to the bootloader which we have loaded into the reset vector address. (Rather we should trap all possible exceptions i.e all the 8 or 16 or what ever is the number of exception addresses in the exception vector).

NOTE: If we are not able to change back to the reset time privilage level for the ARM processor, then we should be still able to have a modified Linux kernel, which doesn't try to switch ARM privilages if not required - this I have tried, ages ago, If I am not wrong as part of some other activity I had done.
[Barnes & Noble Nook Tablet] AdamOutler:
Hey guys... Lets flood the Barnes and Noble forums with our free thinking.

http://bookclubs.barnesandnoble.com/t5/NOOK-Tablet/ct-p/NOOKtablet

If anyone would like to help, please start a new topic requesting an open-ended X-Loader for development purposes. This would allow us to have free reign over the device.

Please ask your community manager for an unlocked X-Loader or U-Boot here: http://bookclubs.barnesandnoble.com/t5/Ask-Your-Community-Manager/bd-p/NTAYCM

Please Make a suggestion that the bootloaders be unlocked here: http://bookclubs.barnesandnoble.com/t5/NOOK-Tablet-Ideas-Suggestions/idb-p/NTIdeas

Please request support on loading a custom U-Boot/kernel here: http://bookclubs.barnesandnoble.com/t5/NOOK-Tablet-Support/bd-p/NTReader

Please Discuss how crappy it is that we can do a better job of designing firmware and they are not utilizing our tallents here: http://bookclubs.barnesandnoble.com/t5/NOOK-Tablet-General-Discussion/bd-p/NTGenDiscuss
[Barnes & Noble Nook Tablet] Entropy512:
That's basically how the original Xbox (not the 360) was cracked. They found a buffer overflow exploit that only allowed them to patch a few bytes in memory, and not anything more. But this was enough for them to corrupt the device's key into one that was divisible by 3 (easily factorable = easily crackable).

The issue is - do we yet have any docs on where the key resides, and also I would not be surprised if there are additional protections, such as a final "protect efuse" eFuse - e.g. blow that fuse and it won't let you blow any others.
[Barnes & Noble Nook Tablet] AdamOutler:
Uboot tools may come in handy. http://code.google.com/p/omap-u-boot-utils/
[Barnes & Noble Nook Tablet] AdamOutler:
hrm... I'm looking at the update.zip file.

post-build=acclaim/blaze/blaze:2.3.4/GINGERBREAD/1.4.0:user/test-keys
post-timestamp=1321043891
pre-device=blaze

hrm.. shouldn't that be

post-build=acclaim/blaze/blaze:2.3.4/GINGERBREAD/1.4.0:user/release-keys
post-timestamp=1321043891
pre-device=blaze

??

Is the stock recovery file signed with test keys?

Yes, it looks like we can resign using test keys and make our own ROMs.
[Barnes & Noble Nook Tablet] AdamOutler:
My tablet is out being worked on to get an initial JTAG flash. Would someone please try modifying the acclaim_update.zip, then run the test sign.jar on it, put it on the sdcard and see what happens? See here for tutorial. http://www.robmcghee.com/android/creating-an-android-update-zip-package/

It seems like a very blatent security hole.
[Barnes & Noble Nook Tablet] Montisaquadeis:
*chuckles* Wouldnt it be fun of them to leave certain holes open for the developers like you to find and use?
[Barnes & Noble Nook Tablet] strictlyrude27:
I'll do it tonight if it's not done by then. I have plenty of experience with signing zips from my own work on the Samsung Vibrant. I'll try replacing the stock boot animation with the CM7 one.
[Barnes & Noble Nook Tablet] strictlyrude27:
Adam -

when I first started "devving"for the Vibrant (a software GPS fix) I took the pains to run testsign.jar on every zip I created. Later on I realized I could just copy over the META-INF folder to new zips and it worked the same as signing.

Would this method of signing also work, or do I need to run the .jar?
[Barnes & Noble Nook Tablet] AdamOutler:
I'm not sure. I'd probly run the testsign on it to be sure... It's 3e recovery, not cwm or 2e.

Try adding su binary to /system/xbin and superuser.apk to /system/app then run testsign on it.

If this works, we may be able to root from SDCard.
[Barnes & Noble Nook Tablet] Indirect:
I don't know why but I have a hunch that the zip internally isn't actually signed. I know it seems weird but hear me out: We were never supposed to even get this far, why would they provide a security measure for something we weren't supposed to actually find out about and have gone through ALL the trouble on that zip? Lock the bootloader and kill root, you have a secure enough environment to quietly kill off development temporarily, why go any further than that? I know I'm probably wrong and this could end pretty bad for the device but meh, it's just a though.
[Barnes & Noble Nook Tablet] strictlyrude27:
On it. I was about to work (from home), but this is way more fun :) I'm downloading acclaim_update.zip now. Will report back within the next 15 minutes.. I'll be in IRC.
[Barnes & Noble Nook Tablet] liquidzoo:
Please report back here as well, for those of us who are at work and have no IRC access (or those that can't get on IRC for whatever reason).

If this works, that's a huge hole...stand by for 1.4.2 ;)
[Barnes & Noble Nook Tablet] strictlyrude27:
Does not work. I can see the NT attempt to flash, but immediately error with the message

I removed all CERT files from the zip, added Superuser.apk and su to the right spots, and signed. MD5 verified between my computer and my NT.

Maybe I'm doing something wrong, but I doubt it.

Other ideas?
[Barnes & Noble Nook Tablet] 150pilot:
ROM Bootloader AIS Explained

AIS magic word, 0×41504954

The AIS boot image for UART is an ASCII string with no spaces or carriage returns between elements (see Figure 13).

415049545853590358535901108000000000004001802028028024280200222801884069020 0032A020C027702884068028C1FDB020840686C6E10CD10442641003C2C6E45B06C6E2 C6E00B48C6E008AEFC08000585359020E85A97BFFFFFFA858535901108000400000000 C0000000A0000000B0000000C585359028434A250FFFFFFDC58535906108000000000000 20000004C

Using the DMSoC Bootloader

Software Development Tools

---------- Post added at 11:21 PM ---------- Previous post was at 10:42 PM ----------

TI-OMAP4 Vulnerabilities

Christian Ohm discovered that the perf command looks for configuration

files in the current directory. If a privileged user were tricked into

running perf in a directory containing a malicious configuration file, an

attacker could run arbitrary commands and possibly gain privileges.
[Barnes & Noble Nook Tablet] hkvc:
Stupid thought wrt testkeys / otacert

Hi All,

Haven't looked at otacerts and or the key security mechanism concept in Android yet or for that matter even openssl, but just a stupid thought based on going thro the AOSP tree, As we have root access to the device have we looked at the otacert file in existing recovery image and or the android root system.

i.e in its /system/etc/security/otacerts.zip

OPTION 1 ==> In turn does it match the testkeys maintained in the AOSP source. In which case signing with the default AOSP testkeys should do the job.

If not, does this update replace the original otacerts.zip with a new version which adds or provides testkeys???

OPTION 2 ==> I ideally would assume that this contains the public key. If it is the case as we have root access (or if we have a exploit to get root access in recovery mode), cann't we replace the otacerts.zip file with what we want and thus inturn use what ever private key (which we have access to) we want to sign and update the packages.

OPTION 3 ==> BUT At the same time in the build/target/product/security/README file it shows about using the pem file (which is what is also in the otacerts.zip) for signing. That is confusing me a bit, does that mean that I can use the pem file in otacerts.zip and use it to sign my update.zip package ??????

Eitherway as I mentioned, currently I haven't really looked into the way otacerts.zip works and or is used in Android, this is just stupid guess work :-)
[Barnes & Noble Nook Tablet] hkvc:
1.41 otacert testkeys does NOT match AOSP testkeys (Note: SECURE BOOT beyond this)

Hi,

NOTE1: Any exploit in recovery image or its mechanism is less likely to break the SECURE BOOT CHAIN, unless we get a signed bootloader (i.e either x-loader/MLO or uboot) which doesn't check signature beyond itself. Unless I am missing something about how these work.

NOTE2: The ONLY WAY any recovery.img exploit can help is, if the hash and signature if any for the bootloaders or kernels being updated is CALCULATED AT RUNTIME and then BURNT into some SECURE location in recovery mode, THEN YES a loop hole or root access to recovery mode can help.

I did find some time to look at the bn 1.41 update file, in turn it does have a /system/etc/security/otacerts.zip file which is being updated or re installed that seems strange or why????

However the testkeys public key in this 1.41's zip file is different from the AOSP testkeys file.

Which means the only option we have for using the recovery image to update a custom rom (which doesn't modify kernel :-( is to find a root exploit in the recovery image to allow us to replace the otacerts.zip file (i.e assuming recovery image is being checked for modifications before loading, if only the kernel in it is being checked and not anything else then we can always recreate a recovery image with root access builtin, but I assume pokey already has cross verified that any change in recovery image invalidates it???).

However also do note that If we do get root access (which we already have) then either way we can replace or put what ever files we want in the system with out requiring any recovery mode circus. BUT BUT BUT as far as I can think STILL this is NOT going to replace the SECURE BOOT CHAIN unless we get a signed bootloader which doesn't check signature for the next guy in the boot chain/sequence.

NOTE: I haven't checked what is the otacerts.zip file in the new 1.41 recovery.img file contain, nor in the default i.e 1.40 recovery.img or in the 1.40 runtime filesystem. But this wont help break secure boot.
[Barnes & Noble Nook Tablet] succulent:
*Bump

I have a log on my NT about a recovery that I've done several days ago. I hope it can be some help.
[Barnes & Noble Nook Tablet] :
good news. I was just talking to AndroidNemith on Twitter and he said that he bypassed the bootloader with hijacking (like on the Moto Defy). He got it working, now he´s searching for a easier method to get CWM on the nook tablet. Seems like he also gets distracted by Nook Color bits.
[Barnes & Noble Nook Tablet] HMG10:
Has he posted any information on how he has accomplished this? If he had others helping him, the process would be sped up.
[Barnes & Noble Nook Tablet] :
well I think if you ask him on twitter, he´ll probably do that :)
[Barnes & Noble Nook Tablet] HMG10:
Believe it or not, I don't use twitter.
[Barnes & Noble Nook Tablet] :
haha okey ;) I see what I can do. And he also said that if you wanna know how he got the CWM on the Nook Tablet, you just have to look at the Moto Defy development (2-init, hijacking).
[Barnes & Noble Nook Tablet] AdamOutler:
Hey guys.. Please partake in this Social Engineering project I've started.

http://xdaforums.com/showthread.php?t=1378886&page=14

The idea is to gain the attention of the customers. To raise awareness of open-source and the benefeits Barnes and Nobel can gain. To make Barnes and Nobel realize that by cutting us off, they are cutting themselves off from the geeks who are trusted by peers to recommend or disaprove high-tech purchases by friends and colleagues.

Post on Barnes and Nobel's website and "laruel" important posts for the good of the XDA Community. This will make a good portion of their customer base aware and push for the things we want. If you have nothing to say, laurel the posts so they get into the "top laureled posts" list and are un-ignorable.
[Barnes & Noble Nook Tablet] hkvc:
applypatch and install-recovery.sh and recovery-from-boot.p

Hi All,

Looking at /system/etc/install-recovery.sh and applypatch command one question which comes up is

$ cat /system/etc/install-recovery.sh

#!/system/bin/sh

if ! applypatch -c IMG:/dev/block/platform/mmci-omap-hs.1/by-name/recovery:2048:70ef89e0497435e988819690aaabb35da6b7677f; then

log -t recovery "Installing new recovery image"

applypatch IMG:/dev/block/platform/mmci-omap-hs.1/by-name/boot:2850816:114706e7bbfa4c806323215a83d6ad4e9cd392f7 IMG:/dev/block/platform/mmci-omap-hs.1/by-name/recovery 532ad547febe82850924a52625132376514e3a8b 3203072 114706e7bbfa4c806323215a83d6ad4e9cd392f7:/system/recovery-from-boot.p

else

log -t recovery "Recovery image already installed"

fi

$ /system/bin/applypatch

usage: /system/bin/applypatch <src-file> <tgt-file> <tgt-sha1> <tgt-size> [<src-sha1>:<patch> ...]

or /system/bin/applypatch -c <file> [<sha1> ...]

or /system/bin/applypatch -s <bytes>

or /system/bin/applypatch -l

Filenames may be of the form

MTD:<partition>:<len_1>:<sha1_1>:<len_2>:<sha1_2>:...

to specify reading from or writing to an MTD partition.

a) Why is the logic only checking for the 1st 2K bytes to decide whether a valid recovery image is there or not ??? Is it a simple speed optimisation (should be but just hoping against hope :-) or is it ?

b) It is overwriting initial part of recovery partition (unless there is a header in there with in each of these files) from 1st ~2.8MB of the boot partition. BUT potentially is also applying a patch file which is "/system/recovery-from-boot.p" to potentially convert what ever it is in boot partition to be appropriate for recovery partition is it???

NOTE: this patch file does seem to have multiple images or patches with in it or something like that, i.e apply it over different locations or so? or is it

NOTE: No idea why a gap before 677f and 2f7 when posting to forum
[Barnes & Noble Nook Tablet] AdamOutler:
OOOooooHhhhh Ho Ho!!!!!

Here's our security hole! The first 4095 bites of Recovery partition are mostly comprised of expendable 0's. Also, Recovery partition is larger than boot partition by a few hundred K. We should be able to fit in kernel in there... just design a kernel and hex-edit, copy-pasta.

Where did you find this information? We can make an interceptor xLoader bootloader if this applies to more than just the recovery partition.
[Barnes & Noble Nook Tablet] hkvc:
Possible 2K check for Recovery mainly in install-recovery.sh

Hi AdamOutler/All,

I was just going thro the different files in the system, and noticied the logic in install-recovery.sh inturn calling a program called applypatch with strange numbers, so had a look at what applypatch says in the commandline. Based on that what I infer is that install-recovery.sh potentially uses the 1st 2K bytes to decide whether it should overwrite the recovery partition or not based on this check. That is we could POTENTIALLY OVERWRITE beyond 2k of the recovery partition and it WONT AUTOMATICALLY overwrite the original recovery image back.

NOTE: This is currently based on just deduction from the applypatch commandline help and how it is used in install-recovery.sh. I haven't reversed the applypatch to asm and cross checked nor checked to see if source is available somewhere.

HOWEVER I DO NOT think the SECURE BOOTLOAD CHAIN also just looks at only 2K, LESS Likely (Some one could definetely try with microsd, currently I havent had time to look at this angle). Rather seeing how applypatch handles stuff and what this recovery-from-boot.p contains and how this is used along with install-recovery.sh over 1 or 2 update cycles by BN may give some idea.

Also later (when one has time) I or someone else has to cross check as to what is BN changing between the Boot and Recovery image using this recovery-from-boot.p patch file.

Sorry if I gave any wrong impression wrt Secure bootloader chain, currently I haven't cross checked that path. This is more of how install-recovery.sh decides whether to overwrite or not, or so it seems. But will secure bootloader accept such a modified recovery partition, not cross checked currently.
[Barnes & Noble Nook Tablet] CelticWebSolutions:
Lets hope that he gets back to developing this. We are now all itching to get a decent kernel and / or rom on these things! It's desperately in need of a decent os boost :)
[Barnes & Noble Nook Tablet] hkvc:
Does 2-init allow a new kernel to be used?? What ever I could gather it is more of user space replacement by hijacking the init process potentially, unless I am missing something? If it does allow kernel to be replaced by loading a kernel module and soft reseting/jumping into a new bootloader or kernel, I will be interested in having a look at it, if there are any links.
[Barnes & Noble Nook Tablet] AdamOutler:
Yes. The idea is similar to what I'll be working on once I get a total restore option ready.

Using the Linux /dev/mem device, on a rooted tablet, we can inject an insecure kernel and/or bootloader directly into memory, then point the system pointer at that memory location. This will basically hot-boot/hijack the entire system and bypass security checks.

Someone needs to work on this... My device wont' be here until at least Thursday and I will be taking at least a week to brick and unbrick my Nook Tablet for the greater good of having a restoration option once we screw things up.
[Barnes & Noble Nook Tablet] apavoratiago:
Thank god!!! Theres people working and thinking how to "fix" this problem.

Writing with my NT (not rooted anymore) from Ecuador South America, just wanna say thanks for your time and work for the community.
[Barnes & Noble Nook Tablet] CelticWebSolutions:
The vast majority of us will be waiting patiently and if you need anything any of us can help with I'm sure you only have to ask and we'll all help where we can in return for your help to us. Luckily for us it's people like yourselves and a few others that make this forum what it is :)

Good luck!
[Barnes & Noble Nook Tablet] AdamOutler:
If anyone wants to help, rather than going in the back door, lets try to get the keys to the front door.

I need help here: http://xdaforums.com/showthread.php?t=1407890