Download of RC19 from Google Found!!! - G1 Android Development

Download of RC19 from Google Found!!! - G1 Android Development

https://android.clients.google.com/updates/signed-kila-ota-114235-prereq.TC4-RC19.zip
Not sure when this is from. I was tooling around trying to find a way to flash myself off of the RC29 test build that I stupidly put on. Stumbled across this. Tried to flash it over my RC29-Test, and it failed with the following error:
Code:
E:Failure at line 1:
assert file_contains(SYSTEM:build.prop", "test-keys"0 == "true" || file_contains
("SYSTEM:build.prop", "ro.build.fingerprint=tmobile/kila/dream/trout:1.0/
TC4-RC19/109652:user/ota-rel-keys,release-keys") == "true"
Installation aborted.
My build contains the following line:
Code:
ota-rel-keys,for-testing,release-keys
Let me know what y'all think.

I think its something good to add to my collection Thx

Darkrift said:
I think its something good to add to my collection Thx
Click to expand...
Click to collapse
I think it will be good for doing file diffs when we get to that point.

Thanks, It is good to have this...

Has anyone thought of trying to apply these updates to the RC1 from the emulator?

yeah, some guy named neoobs thought of it, not sure if he tried it yet though

Darkrift said:
yeah, some guy named neoobs thought of it, not sure if he tried it yet though
Click to expand...
Click to collapse
If I knew how to apply them I would have tried... but how do you hold the home button and the power button on the emulator? LOL

can you mis-match specific files?
I wonder if you can mis-match specific files in the updates.
I.e I wonder if you copied an RC19 file and built a custom version - but also copied the signatures into the appropriate files - since the file is still signed and it would still verify, I think it would still work to grab old versions and mix in with new versions.
The usefullness of making a frankenbuild is probably "not much" - but perhaps if there is a vulnerable file in one version it could be injected into a later version.

RyeBrye said:
I wonder if you can mis-match specific files in the updates.
I.e I wonder if you copied an RC19 file and built a custom version - but also copied the signatures into the appropriate files - since the file is still signed and it would still verify, I think it would still work to grab old versions and mix in with new versions.
The usefullness of making a frankenbuild is probably "not much" - but perhaps if there is a vulnerable file in one version it could be injected into a later version.
Click to expand...
Click to collapse
That won't work because there are 2 files with signatures... one of which is signed in the other. So if you change the signature file it will not validate. Pretty smart if you ask me.

neoobs said:
That won't work because there are 2 files with signatures... one of which is signed in the other. So if you change the signature file it will not validate. Pretty smart if you ask me.
Click to expand...
Click to collapse
I don't see where the one signs the other - the only META-INF file that is signed is the update-script that I can see in either file.
I do see in the code where it EXPLICITLY does NOT verify the .SF files however:
Code:
for (i = 0; i < mzZipEntryCount(pArchive); ++i) {
const ZipEntry *entry = mzGetZipEntryAt(pArchive, i);
UnterminatedString fn = mzGetZipEntryFileName(entry);
int len = mzGetZipEntryUncompLen(entry);
// Don't validate: directories, the manifest, *.RSA, and *.SF.
if (entry == mfEntry) {
LOGV("Skipping manifest %.*s\n", fn.len, fn.str);
} else if (fn.len > 0 && fn.str[fn.len-1] == '/' && len == 0) {
LOGV("Skipping directory %.*s\n", fn.len, fn.str);
} else if (!strncasecmp(fn.str, "META-INF/", 9) && (
!strncasecmp(fn.str + fn.len - 4, ".RSA", 4) ||
!strncasecmp(fn.str + fn.len - 3, ".SF", 3))) {
LOGV("Skipping signature %.*s\n", fn.len, fn.str);
} else {
unverified[i] = true;
totalBytes += len;
}
}
So I think it is entirely possible to swap in other files that are signed with the same key from an older version. If they change keys, I don't think it will work.

Another thought...
It doesn't make sense to me that the public key would be distributed along with the update - it looks like the phone is using the public key to verify the signed hashes - which is fine - they can see that the hashes were signed by the private-key pair of that RSA file...
But the .RSA is explicitly not verified, and I don't see in the verify.c file where it checks against any kind of keystore on the device...
I wonder if it is just checking that the files are signed, but not necessarily who they are signed by? Meaning - it's making sure the update hasn't been corrupted or tampered with - but not who made the update in the first place?

RyeBrye said:
I don't see where the one signs the other - the only META-INF file that is signed is the update-script that I can see in either file.
I do see in the code where it EXPLICITLY does NOT verify the .SF files however:
Code:
for (i = 0; i < mzZipEntryCount(pArchive); ++i) {
const ZipEntry *entry = mzGetZipEntryAt(pArchive, i);
UnterminatedString fn = mzGetZipEntryFileName(entry);
int len = mzGetZipEntryUncompLen(entry);
// Don't validate: directories, the manifest, *.RSA, and *.SF.
if (entry == mfEntry) {
LOGV("Skipping manifest %.*s\n", fn.len, fn.str);
} else if (fn.len > 0 && fn.str[fn.len-1] == '/' && len == 0) {
LOGV("Skipping directory %.*s\n", fn.len, fn.str);
} else if (!strncasecmp(fn.str, "META-INF/", 9) && (
!strncasecmp(fn.str + fn.len - 4, ".RSA", 4) ||
!strncasecmp(fn.str + fn.len - 3, ".SF", 3))) {
LOGV("Skipping signature %.*s\n", fn.len, fn.str);
} else {
unverified[i] = true;
totalBytes += len;
}
}
So I think it is entirely possible to swap in other files that are signed with the same key from an older version. If they change keys, I don't think it will work.
Click to expand...
Click to collapse
in one of the SF's (Signature Files HAHA never caught that till now) It has the SHA1-digest of the other. I believe it is Cert.sf, at the top it signs manifest.sf
This is why you can not alter the SF's at all because they both have all the files signed with one of them signing the other. Making it impossible to get around. And with SHA1 it just makes it hard to even think about it. Might as well do as others have said and find exploits.

RyeBrye said:
It doesn't make sense to me that the public key would be distributed along with the update - it looks like the phone is using the public key to verify the signed hashes - which is fine - they can see that the hashes were signed by the private-key pair of that RSA file...
But the .RSA is explicitly not verified, and I don't see in the verify.c file where it checks against any kind of keystore on the device...
I wonder if it is just checking that the files are signed, but not necessarily who they are signed by? Meaning - it's making sure the update hasn't been corrupted or tampered with - but not who made the update in the first place?
Click to expand...
Click to collapse
I like that idea... anyone know how to sign the files with your own rsa?

RyeBrye said:
It doesn't make sense to me that the public key would be distributed along with the update - it looks like the phone is using the public key to verify the signed hashes - which is fine - they can see that the hashes were signed by the private-key pair of that RSA file...
But the .RSA is explicitly not verified, and I don't see in the verify.c file where it checks against any kind of keystore on the device...
I wonder if it is just checking that the files are signed, but not necessarily who they are signed by? Meaning - it's making sure the update hasn't been corrupted or tampered with - but not who made the update in the first place?
Click to expand...
Click to collapse
Aperantly not many people know about private-public key cryptography.
Please, if you have the time, wiki private-public key cryptography or download the podcast from TWiT (This Week in Tech) Security now on that subject (episode ~15 or so, it was early on).
A simple explination:
Two keys are generated at random (or user input through an algorithm). A private key and a public key. The private key is used to encrypt files an ONLY the public key can decrypt it. IT IS NOT REVERSABLE.
The public key can be "publicly known", hence the name. It actually has to either be with the files or on the device that needs to unencrypt said files.
Now here's the awsome part a brute force attack on SHA1 would take millions of years to crack ON ONE KEY. (Much more detail to that)
Another added mesure of security is hash checking. Run a file through an algorythm and you get an unique ID for that file. You change as much as ONE BIT on that file and the output of the algorythm is COMPLETLY different.
Not imposible to crack, imposible to stay alive long enough to see it done.

Thats the Thing with PKey and Private Key and it Impossible to crack unless the Boot loader is not checking for Signing Authority.
Please Understand Signing a File and Encrypting the File is Different thing we have G1 Update.zip as Normal Zip file but The moment we change any byte in Zip Store the Checking gets failed. if G1 Boot loader is really not checking Singer and only rely on Signed Object whosmever may have signed then we got the Solution but i dont either HTC or Google is that foolish to do that.
We must have to look at G1 Source code for Details.
I think what cmonex and Olipro does is better. Get Source code of Boot loader Recompile it with disabled Signing Funda. Load the Boot Loader into Memory and that Jump to that Location. here Root access to Device is Necesory once we are Succefull to run Patched Bootloader from Memory Flashing Customised Image may not be a Problem

snoslicer8 said:
https://android.clients.google.com/updates/signed-kila-ota-114235-prereq.TC4-RC19.zip
Not sure when this is from. I was tooling around trying to find a way to flash myself off of the RC29 test build that I stupidly put on. Stumbled across this. Tried to flash it over my RC29-Test, and it failed with the following error:
Code:
E:Failure at line 1:
assert file_contains(SYSTEM:build.prop", "test-keys"0 == "true" || file_contains
("SYSTEM:build.prop", "ro.build.fingerprint=tmobile/kila/dream/trout:1.0/
TC4-RC19/109652:user/ota-rel-keys,release-keys") == "true"
Installation aborted.
My build contains the following line:
Code:
ota-rel-keys,for-testing,release-keys
Let me know what y'all think.
Click to expand...
Click to collapse
can anyone post this file somewhere i can get it? it's not there anymore. My PC no longer see's my device, i'm wondering if flashing back to RC19 will work.

canOpoop said:
can anyone post this file somewhere i can get it? it's not there anymore. My PC no longer see's my device, i'm wondering if flashing back to RC19 will work.
Click to expand...
Click to collapse
First, you can't flash the RC19 if you have RC29.
Second, what do you mean your PC doesn't see your device? If your talking about the SD card through the phone, at the top of your phone when you have connected, you will have a notification at the top of your phone.
Either drag the notification bar or press menu on your home screen and click on Notifications. Select the USB selectionan it will prompt you, select "Mount"

quedijo said:
First, you can't flash the RC19 if you have RC29.
Second, what do you mean your PC doesn't see your device? If your talking about the SD card through the phone, at the top of your phone when you have connected, you will have a notification at the top of your phone.
Either drag the notification bar or press menu on your home screen and click on Notifications. Select the USB selectionan it will prompt you, select "Mount"
Click to expand...
Click to collapse
First: check this out. http://www.blogsdna.com/1256/how-to-quickly-update-t1-mobile-g1-phone-firmware-manually-rc29.htm
i'm thinking if i get the file (RC19) i can flashback.
Second: It had worked before (before the OTA update). I have tried 3 different PC's 2 different USB cables, REFlash of RC29, and a hard reset (to Factory). i do not ever get a notification to mount in Notification bar. Windows throws out the error "One of the USB Devices attached to this computer has malfuctioned, and windows does not recognize it." And yes i have tried different USB ports.
i'm open to any more ideas...

canOpoop said:
First: check this out. http://www.blogsdna.com/1256/how-to-quickly-update-t1-mobile-g1-phone-firmware-manually-rc29.htm
i'm thinking if i get the file (RC19) i can flashback.
Second: It had worked before (before the OTA update). I have tried 3 different PC's 2 different USB cables, REFlash of RC29, and a hard reset (to Factory). i do not ever get a notification to mount in Notification bar. Windows throws out the error "One of the USB Devices attached to this computer has malfuctioned, and windows does not recognize it." And yes i have tried different USB ports.
i'm open to any more ideas...
Click to expand...
Click to collapse
Use anycut and create a shortcut to the activity "SD Card" and see what it says when you open it.

neoobs said:
Use anycut and create a shortcut to the activity "SD Card" and see what it says when you open it.
Click to expand...
Click to collapse
Tmobile is replacing device. I should get a new on Tuesday the 11th. they are out of stock.

Related

All the technical details you'd like

Here's the thread for tech details. No questions in this thread, please.
My input:
Rooting the Rogers Dream
Download the tools required
Extract to anywhere on your computer.
Place update.zip on the root of your sd card.
Reboot the device into SPL (power off, hold camera button, boot, press "back" or "send" [check prompt on device] to enter "FASTBOOT" instead of "HBOOT")
Code:
fastboot boot recovery.img
Apply update, wait until phone idles, press HOME+BACK, it will reboot, finish writing hboot, then reboot again into recovery by itself. Do not interrupt it at all until it's done.
HOME+BACK to reboot into regular device.
Power off, hold camera, boot, go back into FASTBOOT
Code:
fastboot flash recovery recovery.img
Code:
fastboot flash boot boot.img
Code:
fastboot reboot
that's it!
Rooting the HTC Magic / Sapphire: http://android-dls.com/wiki/index.php?title=Magic_Rooting
Developer notes (for devs and rom builders):
Dev's (cyanogen, i'm looking at you [you requested this info ]) you can download my hacked up mkbootimg and some other tools here: http://www.mediafire.com/?njl4x5ozldm
these are all baked up by me in a flurry of rush and etc, so excuse the sloppiness
You will have 2 tools to use now, compileboot and compilebootmagic.
compileboot creates a regular g1 boot img (and the vodafone magic as well supports these old boot locations)
compilebootmagic has 2 options.
compilebootmagic -1 will create an image supported by the HTC Dream (rogers), all new magic devices, and most likely the hero and etc (these new locations are based on ram size pretty much)
compilebootmagic -2 will create an image with user supplied arguments (it says dream but disregard it, i made it before finding out the new codes matched -1)
Discovering new boot locations!
This is a fun (and easy) bit.
Just grab a boot.img from the device you'd like to learn about, and follow the chart below:
Code:
0xf-0xc (backwards): kernel addr
0x17-0x14 (backwards): ramdisk addr
0x1f-0x1c (backwards): second addr
0x23-0x20 (backwards): tags addr
you can also use this script (linux users):
Code:
#!/usr/bin/php
<?php
function bootloc($file) {
$handle = fopen($file, 'rb');
$data = stream_get_contents($handle);
fclose($handle);
$text = "";
for($a = 0; $a < 8; $a++) {
$text .= $data[$a];
}
if($text == "ANDROID!") {
$out = sprintf("Kernel addr : 0x%02x%02x%02x%02x", ord($data[hexdec('f')]), ord($data[hexdec('e')]), ord($data[hexdec('d')]), ord($data[hexdec('c')]))."\n";
$out .= sprintf("Ramdisk addr: 0x%02x%02x%02x%02x", ord($data[hexdec('17')]), ord($data[hexdec('16')]), ord($data[hexdec('15')]), ord($data[hexdec('14')]))."\n";
$out .= sprintf("Second addr : 0x%02x%02x%02x%02x", ord($data[hexdec('1f')]), ord($data[hexdec('1e')]), ord($data[hexdec('1d')]), ord($data[hexdec('1c')]))."\n";
$out .= sprintf("tags addr : 0x%02x%02x%02x%02x", ord($data[hexdec('23')]), ord($data[hexdec('22')]), ord($data[hexdec('21')]), ord($data[hexdec('20')]))."\n";
return $out;
} else {
return false;
}
}
if($argc < 2) {
echo "Usage:\n";
echo $argv[0]." <img file/s>\n";
echo "example:\n";
echo $argv[0]." boot.img boot-new.img recovery.img recovery-new.img\n";
} else {
for($a = 1; $a < $argc; $a++) {
$out = bootloc($argv[$a]);
if($out) {
echo $argv[$a],":\n";
echo $out;
} else {
echo $argv[$a]," is not a boot/recovery img!\n";
}
}
}
usage: bootlocations.php <boot.img, more than one can be supplied>
example: bootlocations.php boot.img boot-new.img
NOTE: i will try to keep adding to this until it's full. any information that isn't in here, feel free to request via pm.

Reserved for future postings

Once again, great work Haykuro

Okay, I see the trickery now.
Thanks for this info, I'll build a version of CM for Rogers later

Another thing.. Does this device use the same libhtc_ril.so as the G1 ROM and/or does it need different RIL properties in build.prop? I am thinking it does because of the different radio, but I've only seen G1 "ports" of the ROM.

cyanogen said:
Another thing.. Does this device use the same libhtc_ril.so as the G1 ROM and/or does it need different RIL properties in build.prop? I am thinking it does because of the different radio, but I've only seen G1 "ports" of the ROM.
Click to expand...
Click to collapse
lol the g1 ports of the rom never changed the lib much (if not at all [do an md5sum ;P])
the phone is practically identical to ours, aside some physical things (crystals, etc)

thx for the tools
cheers

Thanks again Haykuro! This is great information.

thank you for this! Hopefully intructions on how to root the mytouch will come soon!

Tried to make a version of CM-3.6 for the Rogers Dream and it isn't booting according to the testers.. Doesn't even get adbd started.
I set the boot.img up properly.
Code:
Kernel addr : 0x19208000
Ramdisk addr: 0x1a200000
Second addr : 0x1a100000
tags addr : 0x19200100
Something else has to be different, or that device hates my kernel.
EDIT:
Haykuro sent me the kernel config from a running Dream device, and there are some options enabled in it that aren't part of any Linux kernel.
CONFIG_MSM_AMSS_SUPPORT_256MB_EBI1=y
CONFIG_CPU_FREQ_GOV_MSM7K=y
So we are going to need whatever they patched in to be able to build custom kernels. Interestingly, the device is also using cpufreq settings of 384MHz/528MHz by default.

Great job haykuro, but ive been hearing reports that you cannot flash any rom (only rogers based roms) Any news on this? Thanks again!

I commend your turn around, Steve, and am quite impressed.

cyanogen said:
EDIT:
Haykuro sent me the kernel config from a running Dream device, and there are some options enabled in it that aren't part of any Linux kernel.
CONFIG_MSM_AMSS_SUPPORT_256MB_EBI1=y
CONFIG_CPU_FREQ_GOV_MSM7K=y
So we are going to need whatever they patched in to be able to build custom kernels. Interestingly, the device is also using cpufreq settings of 384MHz/528MHz by default.
Click to expand...
Click to collapse
That is my stumbling block too. It's not just those two options, config diff is quite significant. I've sent a couple of emails to htc kernel devs a few weeks ago, but got no response. HTC must release the patched source, though, to comply with GPL2. I'm not sure what's be the best way to persuade them to.

Can't ender code in SPL
Once I boot into SPL how do I enter the code. nothing happens when I press the keys on my keyboard.

stongest said:
Once I boot into SPL how do I enter the code. nothing happens when I press the keys on my keyboard.
Click to expand...
Click to collapse
Wow this was pretty dead and you just revived it from its slumber among the dead.
Theres no code to enter
You have to install once you get a custom rec.

Ace42 said:
Wow this was pretty dead and you just revived it from its slumber among the dead.
Theres no code to enter
You have to install once you get a custom rec.
Click to expand...
Click to collapse
At least he searched for it

stongest said:
Once I boot into SPL how do I enter the code. nothing happens when I press the keys on my keyboard.
Click to expand...
Click to collapse
through adb

ok.. I am getting closer to understanding this!
But, still no luck.
I downloaded this file
http://sapphire-port-dream.googlecode.com/files/spl-signed.zip
then saved it to my SD card and renamed it to update.zip
Then I do this
Reboot the device into SPL (power off, hold camera button, boot, press "back" or "send" [check prompt on device] to enter "FASTBOOT" instead of "HBOOT")
and nothing happens.. any ideas?

You install .zip things like that, like the SPL and new roms in the recovery mode, not bootloader. You'll start up with home + power to get to that.
However, given that you don't know this yet, I'd spend a *lot* more time getting comfortable with the whole flashing roms/messing with your phone stuff before installing that SPL, that's a pretty good way to brick your phone if you don't know a bit more about what you're doing.

Sorry for necro posting, i'm new to the whole rooting thing. My phone info is:
Firmware: 1.5
Baseband Version: 62.59S.20.23U_3.22.26.17
Kernel Version: 2.6.27-d5acf552
Build Number: 1.89.631.1 146733 CL#94714
I have a rogers HTC dream for Canada.
What files do i exactly need, and once acquiring them I just follow the instructions in the first post?

[App] [2.3+] OTA Verifier

Whenever there's an over-the-air (OTA) update sent-out or made available (either leaked or official), there's always a large number of users that end-up reporting that their installations have failed with the infamous and dreaded "E:Error in /sdcard/xxx.zip (Status 7) installation aborted." error message. So, I decided to try to write an app that would help folks figure-out what the issues might be so that they can get their OTA update installed.
The OTA Verifier app can be used to evaluate an over-the-air (OTA) update.zip or other flashable .zip file before you attempt the install or afterwards to help you figure-out why the installation may have failed. OTA Verifier will point-out what files and conditions are being tested so that you can more easily attempt to correct these issues.
Play Market Link (free!): OTA Verifier (beta)
Do I have to be rooted to use this?
No, but rooted devices will have more conditions that the app will be able to test/evalute because it will have access to protected files that non-rooted devices don't.
Will the app actually do the installation or change anything on my device?
No. The app will only evaluate the expressions and conditions contained inside the updater-script file inside the .zip file that's trying to be installed. None of the functions or commands that try to modify your device (i.e., delete/patch/format/extract, etc.) will be evaluated or executed. The app basically operates in "read-only" mode with respect to the .zip file being evaluated.
Will this app work on older devices or flashable .zip files that use the amend update-script files?
No, this app evaluates and interprets the newer edify updater-script files (notice the "r" in "updater").
How do I use this app?
Install and launch the app
Click the "Select File" button and navigate to desired .zip file
Long-press (press and hold) the file entry for the desired .zip file
Click the "Verify OTA .zip" file pop-up
Wait for the app to process the file (should take under a minute, depending on your device)
View the displayed results (text will also be copied to the clipboard)
Miscellaneous info:
1. Savvy root users probably already know that after a failed .zip file installation, you should be able to view the /cache/recovery/log file to view the information about what might have failed. OTA Verifier will try to uncover all of the issues and not just the first one that causes the installation to fail.
2. While I wrote this app principally to evaluate OTA update.zip files, the edify updater-script files are used and written by ROM devs and others who created flashable .zip files. This app can be used to evaluate those file's updater-script files, too.
How does this all work?
Here's the basic outline/structure of what the app does:
1. the .zip file is selected by the user via the file selector
2. list of frozen system apps are identified for later reporting
3. the updater-script file is extracted from the META-INF/com/google/android folder in the .zip file
4. this updater-script file is parsed and converted into reverse polish notation (RPN) for execution
5. edify functions that might modify your device are NOT evaluated; these include apply_patch, delete, delete_recursive, format, mount, package_extract_dir/file, run_program, set_perm[_recursive], symlink, unmount, write_raw_image, etc.
6. note: the update-binary executable is not used by or involved in this app; the edify script interpreter that the app uses was written by me, in Java, specifically for this app
7. the remaining edify script functions that test conditions (such as apply_patch_check, apply_patch_space, assert, concat, file_exists, file_getprop, getprop, greater_than_int, if-then-else-endif, ifelse, is_substring, less_than_int, read_file, ui_print, and various operators (!, !=, &&, (, ), ;, ||, +, ==)) are evaluated using an operand/operator stack from the RPN expression parsed from the updater-script statements
8. expressions that fail (return a null-string) or are bypassed (usually because a resource (file/partition) is protected/secured against read-access) are reported for the user
9. after the entire script has been processed, the results are displayed in a pop-up window on the device and the text of those results are copied to the clipboard
Planned / future features:
- preferences / settings
- logging of the output to a file on the /sdcard
- test if .zip file is signed or not
- display more stats
- "explanation mode" to interpret, in English, what the edify commands are testing
Successfully tested on:
Samsung Galaxy Nexus (CDMA) 4.1.1
Samsung Galaxy Nexus (GSM) 4.1.2
Asus Nexus 7 tablet 4.1.2
Motorola Droid X 2.3.4
The following edify commands/functions/operators are supported:
Code:
[COLOR="blue"]apply_patch_check[/COLOR] // apply_patch_check ( <filepath>, <sha1-checksum> [ , <sha1-checksum> ... ] )
// apply_patch_check ( <compoundvalue> )
<compoundvalue> := [ EMMC : <filepath> : <sha1-size> : <sha1-checksum> [ <sha1-size> : <sha1-checksum> ... ]
[ MTD : <dev-block> : <sha1-size> : <sha1-checksum> [ <sha1-size> : <sha1-checksum> ... ]
[ vfat : <dev-block> : <sha1-size> : <sha1-checksum> [ <sha1-size> : <sha1-checksum> ... ]
<dev-block> := filename in /dev/block
[COLOR="Blue"]apply_patch_space[/COLOR] // apply_patch_space ( <bytes> )
[COLOR="blue"]assert[/COLOR] // assert ( <expression> )
[COLOR="blue"]concat[/COLOR] // conact ( <string> , <string> )
[COLOR="blue"]file_exists[/COLOR] // file_exists ( <filepath> )
[COLOR="blue"]file_getprop[/COLOR] // file_getprop ( <filepath>, <propertyname> )
[COLOR="blue"]getprop[/COLOR] // getprop ( <propertyname> )
[COLOR="blue"]greater_than_int[/COLOR] // greater_than_int ( <integer>, <integer> )
[COLOR="blue"]if then else endif[/COLOR] // if <condition> then <expression> [ else <expression> ] endif
[COLOR="blue"]ifelse[/COLOR] // ifelse ( <condition>, <then-expression> [ <else-expression> ] )
[COLOR="blue"]is_substring[/COLOR] // is_substring ( <string> , <string> )
[COLOR="blue"]less_than_int[/COLOR] // less_than_int ( <integer>, <integer> )
[COLOR="blue"]read_file[/COLOR] // read_file ( <filepath> )
[COLOR="blue"]ui_print[/COLOR] // ui_print ( <string> ) parsed & executed, but output not displayed
[COLOR="blue"]![/COLOR] // logical NOT operator
[COLOR="blue"]!=[/COLOR] // not equals operator
[COLOR="blue"]&&[/COLOR] // logical AND operator
[COLOR="blue"]([/COLOR] // open paren: precedence / grouping
[COLOR="blue"])[/COLOR] // close paren: precedence / grouping
[COLOR="blue"];[/COLOR] // sequence/imperative (terminates & separates statements)
[COLOR="blue"]||[/COLOR] // logical OR operator
[COLOR="blue"]+[/COLOR] // string concatenation operator
[COLOR="blue"]==[/COLOR] // equals operator
[COLOR="blue"]#[/COLOR] // comment line
The following edify functions are NOT supported (the majority of them because they are intended to modify your device):
Code:
[COLOR="blue"]apply_patch[/COLOR]
[COLOR="blue"]delete[/COLOR]
[COLOR="blue"]delete_recursive[/COLOR]
[COLOR="blue"]format[/COLOR]
[COLOR="blue"]mount[/COLOR]
[COLOR="blue"]package_extract_dir[/COLOR]
[COLOR="blue"]package_extract_file[/COLOR]
[COLOR="blue"]run_program[/COLOR]
[COLOR="blue"]set_perm[/COLOR]
[COLOR="blue"]set_perm_recursive[/COLOR]
[COLOR="blue"]symlink[/COLOR]
[COLOR="blue"]unmount[/COLOR]
[COLOR="blue"]write_raw_image[/COLOR]
[COLOR="blue"]is_mounted[/COLOR] // innocuous, but still not supported
[COLOR="blue"]stdout[/COLOR] // innocuous, but still not supported
[COLOR="blue"]show_progress[/COLOR] // innocuous, but still not supported
[COLOR="blue"]set_progress[/COLOR] // innocuous, but still not supported
Keywords:
OTA, over-the-air, updater-script, edify, amend
Screenshots:
updated 9-May-2014

updated to version 1.3
Updated app with root-enabled file browser for navigating to protected/secured directories like /cache to select OTA's update zip file.
Full change log to date:
[v1.3 - 04-Nov-2012]:
- for rooted devices, change file browser to allow navigating and selecting .zip files in protected directories (like /cache)
[v1.2 - 29-Oct-2012]:
- minor fix to handle two reports of null pointer exceptions
[v1.1 - 28-Oct-2012]:
- remove unused SD card write permission
[v1.0 - 28-Oct-2012]:
- initial Play Market release

This is pretty cool.
Any chance you could direct me to an explanation for sha1-size (for apply_patch_check) is though? I'm working on some edify scripting stuff and trying to incorporate some asserts for a specific bootloader (important to what I'm doing), and this is honestly the best reference I've found for it yet.

osm0sis said:
This is pretty cool.
Any chance you could direct me to an explanation for sha1-size (for apply_patch_check) is though? I'm working on some edify scripting stuff and trying to incorporate some asserts for a specific bootloader (important to what I'm doing), and this is honestly the best reference I've found for it yet.
Click to expand...
Click to collapse
You bet!
I'm heading home from work here soon and I'll dig-up the details for you .
(yeah, I scoured the internet for detailed information on Edify scripting as well as reviewed the actual Google/Android code--there's not a complete compendium, unfortunately).
I'll ping you back after a bit...
Cheers!

osm0sis said:
Any chance you could direct me to an explanation for sha1-size (for apply_patch_check) is though?
Click to expand...
Click to collapse
Okay, here's what I know about the apply_patch_check command:
There are basically two formats:
Code:
apply_patch_check // apply_patch_check ( <filepath>, <sha1-checksum> [ , <sha1-checksum> ... ] )
// apply_patch_check ( <compoundvalue> )
<compoundvalue> := [ EMMC : <filepath> : <sha1-size> : <sha1-checksum> [ <sha1-size> : <sha1-checksum> ... ]
[ MTD : <dev-block> : <sha1-size> : <sha1-checksum> [ <sha1-size> : <sha1-checksum> ... ]
[ vfat : <dev-block> : <sha1-size> : <sha1-checksum> [ <sha1-size> : <sha1-checksum> ... ]
The first of which is what I think you typically see in updater-script files where you have a filename, followed by one or more SHA1 digests. Here's an example:
assert(apply_patch_check("/system/app/ApplicationsProvider.apk", "41bb5aaaa2791e68b55622fcca13f0e4efa757b2", "fc845332ae7f706824de73f64ae47f93866ad245"));
The second format is what I call a compound value format, where the file or partition to be checked and the SHA1 digests to be compared, are all concatenated together in a single, colon-separated value. For example:
assert(apply_patch_check("EMMC:/dev/block/platform/omap/omap_hsmmc.0/by-name/boot:4247552:3f4d4f9549d307d152f8503983ee4ff5f46b0a43:4470784:fbd13c778b34fdb7917c1ccee6389aa9b13a92bd")); 
In the above, I've colored the sizes in red of file/partition on which to compute the SHA1 checksum (colored in black). I figured this out and verified this by using dd to copy the portions of the partition in question and calculating the SHA1 checksums on it.
My app only supports parsing and evaluating two sets of lengths/SHA1s for the compound format at this time (that's all I've encountered so far in the scripts that I've viewed).
Does that help and/or answer your questions?
Cheers!

Thanks! Yeah that helps a lot, but unfortunately it doesn't seem to solve the problem I've been seeing..
Using dd to grab the partition img I can sha1sum that and that SHA1 doesn't allow it to pass the assert, or even a direct sha1_check of the partition.
Code:
run_program("/sbin/busybox", "dd", "if=/dev/block/platform/sdhci-tegra.3/by-name/USP"), "of=/tmp/bootloader.img")
ui_print(sha1_check(read_file("/tmp/bootloader.img"))); = 8c206a1a87599f532ce68675536f0b1546900d7a (also, bootloader.img is 2097152 in size)
ui_print(sha1_check(read_file("/dev/block/platform/sdhci-tegra.3/by-name/USP"))); = da39a3ee5e6b4b0d3255bfef95601890afd80709
assert(apply_patch_check("EMMC:/dev/block/platform/sdhci-tegra.3/by-name/USP:2097152:8c206a1a87599f532ce68675536f0b1546900d7a")); = Fail
They just don't match and I'm completely baffled by it. I can work around it by using dd to pull the img first and using that for my asserts but it's not as clean as I'd like it.

osm0sis said:
Yeah that helps but I guess unfortunately it doesn't entirely solve the problem I've been seeing.
Using dd to grab the partition img I can sha1sum that and that SHA1 doesn't allow it to pass the assert, or even a direct sha1_check of the partition.
They just don't match and I'm completely baffled by it. I can work around it by using dd to pull the img and using that for my asserts but it's not as clean as I'd like it.
Click to expand...
Click to collapse
Is it for the Gnex or the N7 (I have those same devices)?
I'd be happy to test something for you...just PM me or send me an email ([email protected]).
I don't know if you're using my app to test with, but you can also manually run the update-binary directly on/from your phone (i.e., you don't have to run it in recovery, but you obviously need to be careful what your updater-script does ).
I'm still looking for the exact syntax in my notes, but I'll edit this post when I find it...brb.
~ ~ ~
edit: http://wiki.opticaldelusion.org/wiki/Update-binary shows this:
update-binary <api> <pipefd> <zip>
Click to expand...
Click to collapse
I know I did this during my early testing, but I can't remember the exact syntax...I'll try it and re-re-edit .

Man thanks so much, PM sent.
Sorry for cluttering up your thread with this semi-OT stuff.

osm0sis said:
Man thanks so much, PM sent.
Sorry for cluttering up your thread with this semi-OT stuff.
Click to expand...
Click to collapse
LOL, not a problem...it's all Edify-related and updater-script related...I'm betting that's what'll lead most folks here.
Happy to help .

==================
Detailed Analysis
==================
- you have no frozen system apps (good!)
- there were 2 failed expressions; see below for the details about these tests that will cause your OTA install to fail
- there were no bypassed expressions (good!)
-------------------------------
statistics:
frozen system apps: 0
success count: 526
fail count: 2
ignore count: 1587
partition count: 2
protected count: 2
bypassed count: 0
-------------------------------
updater-script analysis details:
FAILED: line #268:
assert(apply_patch_check("/system/app/XT9IME.apk", "8aba56a4406128e78f5729753252c3d93bc21cb4", "965b437bce65018eeb31ff9a381c3687542099e0"));
----------------------
FAILED: line #1038:
assert(apply_patch_check("EMMC:/dev/block/platform/sdhci-tegra.3/by-name/LNX:5013504:c48f8e86c73fb2c2ba1794f5ec98e27c9e206ed5:5060608:319331fae14fec8a88063751475fce26bae328e0"));
So a question, could this failure above be causing my 32 GB nexus 7 to have system update issues? (Not necessarily XT9IME.apk (which I shouldn't have deleted), more the other one) Is there a fix?
Sent from my Nexus 7 using Tapatalk HD
---------- Post added at 10:44 AM ---------- Previous post was at 10:39 AM ----------
==================
Detailed Analysis
==================
- you have no frozen system apps (good!)
- there were 2 failed expressions; see below for the details about these tests that will cause your OTA install to fail
- there were no bypassed expressions (good!)
-------------------------------
statistics:
frozen system apps: 0
success count: 526
fail count: 2
ignore count: 1587
partition count: 2
protected count: 2
bypassed count: 0
-------------------------------
updater-script analysis details:
FAILED: line #268:
assert(apply_patch_check("/system/app/XT9IME.apk", "8aba56a4406128e78f5729753252c3d93bc21cb4", "965b437bce65018eeb31ff9a381c3687542099e0"));
----------------------
FAILED: line #1038:
assert(apply_patch_check("EMMC:/dev/block/platform/sdhci-tegra.3/by-name/LNX:5013504:c48f8e86c73fb2c2ba1794f5ec98e27c9e206ed5:5060608:319331fae14fec8a88063751475fce26bae328e0"));
Sent from my Nexus 7 using Tapatalk HD
Click to expand...
Click to collapse
So a question, could this failure above be causing my 32 GB nexus 7 to have system update issues? (Not necessarily XT9IME.apk (which I shouldn't have deleted), more the other one) Is there a fix?

modwilly said:
So a question, could this failure above be causing my 32 GB nexus 7 to have system update issues? (Not necessarily XT9IME.apk (which I shouldn't have deleted), more the other one) Is there a fix?
Click to expand...
Click to collapse
Looks like you've updated the boot (LNX) partition in addition to deleting (or renaming/moving) the XT9IMG.apk?
So yes, the OTA will not install until you've put both items back to their expected state.
The fix, of course, depends on exactly what you did to change them in the first place.

version 2.1 uploaded to Play Store
Major re-write of app done for version 2.0 and above.
Recent change log:
[version 2.1 - 6-May-2014]:
- fix issue w/identification of non-existent files
[version 2.0 - 5-May-2014]:
- major app update: edify parsing, RPN processing and execution engine completely re-written
- original core app behavior and functionality remain the same, but code cleanup and re-write should mean better and more robust handling of future OTA updater-script expressions
Click to expand...
Click to collapse
Thanks and let me know if you have any questions.

@scary alien could you please tell me how to get apply_patch_space bytes? i am making ota script and i got almost all, still need to generate:
apply_patch_space(bytes) || abort("Not enough free space on /cache to apply patches.");
Click to expand...
Click to collapse
i just dunno how

ZduneX25 said:
@scary alien could you please tell me how to get apply_patch_space bytes? i am making ota script and i got almost all, still need to generate:
i just dunno how
Click to expand...
Click to collapse
It's just the available space (in bytes) in the /cache partition that you want to make sure is available (i.e., free space) for any operations your updater-script file will do concerning /cache.
For example:
apply_patch_space(1000000) || abort("Not enough free space on /cache to apply patches.");
Click to expand...
Click to collapse
Would verify that there is at least 1MB (1,000,000) free bytes available in /cache.
Does that answer what you're asking?
Lemme know--happy to help if I can.
Cheers!

@scary alien not really, i mean i know how it works, just dunno how to generate proper size in updater, for example:
i create regular ota: multiple .p files and some images, zipped, signed OTA.zip size is 20mb, /patch size is 7 mb, images 10 mb and /system (new files) 3mb, how do i know how many bytes i should set to make this ota install in recovery?
should i summarize .p files size or target (patched apk, jar) files size (would be around 90mb) or what else?

I think the size would depend on when your patch files are cleaned-up...i.e., after each patching operation or at the end. If its at the end, you'll of course need to account to all of the space you might use in /cache.
I don't know of a good way to tell you what the high water mark would be other than testing and recording the output of a "df /cache" command at various points in your updater-script file.

I could do that however I don't see it universal or handy, each ota has different size so it would need more/less free space every time.
There is how Google gets this value : https://github.com/MiCode/patchrom_tools/blob/kitkat/releasetools/edify_generator.py#L131 maybe you will understand better.

ZduneX25 said:
I could do that however I don't see it universal or handy, each ota has different size so it would need more/less free space every time.
There is how Google gets this value : https://github.com/MiCode/patchrom_tools/blob/kitkat/releasetools/edify_generator.py#L131 maybe you will understand better.
Click to expand...
Click to collapse
I think I understood what you meant...there's no easy way to make this universal for each OTA except to evaluate each file that might need to use space resources from the /cache partition.
Even the edify-generator git that you referenced does this dynamically:
releasetools/ota_from_target_files:
Code:
for diff in diffs:
tf, sf, d = diff.GetPatch()
if d is None or len(d) > tf.size * OPTIONS.patch_threshold:
# patch is almost as big as the file; don't bother patching
tf.AddToZip(output_zip)
verbatim_targets.append((tf.name, tf.size))
else:
common.ZipWriteStr(output_zip, "patch/" + tf.name + ".p", d)
patch_list.append((tf.name, tf, sf, tf.size, common.sha1(d).hexdigest()))
[COLOR="Red"]largest_source_size[/COLOR] = max([COLOR="red"]largest_source_size[/COLOR], sf.size)
:
:
:
if patch_list or updating_recovery or updating_boot:
script.[COLOR="Blue"][B]CacheFreeSpaceCheck[/B][/COLOR]([COLOR="red"]largest_source_size[/COLOR])

I have seen it, but here comes largest_source_size:
Code:
largest_source_size = 0
https://github.com/MiCode/patchrom_tools/blob/kitkat/releasetools/ota_from_target_files#L532

ZduneX25 said:
I have seen it, but here comes largest_source_size:
Code:
largest_source_size = 0
https://github.com/MiCode/patchrom_tools/blob/kitkat/releasetools/ota_from_target_files#L532
Click to expand...
Click to collapse
Yeah, that's just the initialization of that variable...it gets updated in the for-loop that I included above.
(you know that's not my tool, software, right?)

Detection of key-pressing at boot-time.

Hi good people of N7 land,
I wanted to ask if it's possible to make keys get detected at boot-time so that a certain function is carried out. If so how?
For example:
The N7 is booting up. I press the Vol + key, and due to a script executed by the init.delta.rc, /system is mounted to a IMG file in the sdcard. A dual-boot mod.
I also ask if this is the best way to do this, and please for the love of God, don't point me to MultiROM. I want to work on my own mod.
I expect helpful answers. And if you can't answer my question, don't even bother posting here.
Although this is a question, this is more dev-related than anything I've encountered in the Q/A section. So I thought of posting it here.
Please move this if this is not the right place, and accept my apologies.
sgt. meow

I don't think this is possible using just some script - init has no way to get input events from keys, so you would have to either edit the init binary or use exec init command.
You could use it to run another binary, which would check if volwhatever is pressed and either did nothing or did the dual-boot stuff.
It depends on when you want to check for the keypress, because if it is after the /system partition is mounted, you could use busybox and run bash script, otherwise it would have to be real binary, because when init is started, you have pretty much "just" kernel running and no userspace.
Or you could pack busybox to boot.img, but if you can code, the binary is pretty easy to make.

@up
Exactly the kind of answer I was hoping to find. Sucks to realize that I still don't know a lot of coding. But I'm willing to learn if you could point me to the right direction.

sgt. meow said:
Hi good people of N7 land,
I wanted to ask if it's possible to make keys get detected at boot-time so that a certain function is carried out. If so how?
For example:
The N7 is booting up. I press the Vol + key, and due to a script executed by the init.delta.rc, /system is mounted to a IMG file in the sdcard. A dual-boot mod.
I also ask if this is the best way to do this, and please for the love of God, don't point me to MultiROM. I want to work on my own mod.
I expect helpful answers. And if you can't answer my question, don't even bother posting here.
Although this is a question, this is more dev-related than anything I've encountered in the Q/A section. So I thought of posting it here.
Please move this if this is not the right place, and accept my apologies.
sgt. meow
Click to expand...
Click to collapse
The first idea that comes to my mind would be to code a simple no-UI app which would use a Service executed by a BroadCastReceiver set to BOOT_COMPLETED.
Then, when triggered (=at boot-time), the service would wait for the user to press a defined key (i.e : volume up). When the service receives the key press, it would mount /system or whatever you wanna do, then stop running (so that other volume up presses don't trigger this event again).
The code could be something like :
Your AndroidManifest.xml :
Code:
< ?xml version="1.0" encoding="utf-8"?>
< manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.sgtmeow.boot.service"
android:versionCode="1"
android:versionName="1.0">
< uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED" />
< application android:icon="@drawable/icon" android:label="@string/app_name">
< service android:name=".BootService">
< intent-filter>
< action
android:name = "com.sgtmeow.boot.service.BootService">
< /action>
< /intent-filter>
< /service>
< receiver android:name=".BootReceiver">
< intent-filter>
< action
android:name ="android.intent.action.BOOT_COMPLETED">
< /action>
< /intent-filter>
< /receiver>
< /application>
< uses-sdk android:minSdkVersion="8"
android:targetSdkVersion="17"android:targetSdkVersion="17" />
< /manifest>
BootReceiver.java :
Code:
package com.sgtmeow.boot.service;
import android.content.BroadcastReceiver;
import android.content.Context;
import android.content.Intent;
public class BootDemoReceiver extends BroadcastReceiver {
@Override
public void onReceive(final Context context, final Intent bootintent) {
Intent mServiceIntent = new Intent();
mServiceIntent.setAction("com.sgtmeow.boot.service.BootService");
context.startService(mServiceIntent);
}
}
BootService.java
Code:
package com.sgtmeow.boot.service;
import java.io.DataOutputStream;
import android.app.Service;
import android.content.Intent;
import android.os.IBinder;
import android.util.Log;
import android.view.KeyEvent;
import com.sgtmeow.boot.service.BootReceiver;
public class BootService extends Service {
Runtime mRuntime;
Process mProcess = null;
DataOutputStream mOutput = null;
@Override
public IBinder onBind(final Intent intent) {
return null;
}
@Override
public void onCreate() {
super.onCreate();
}
public boolean onKeyDown(int keyCode, KeyEvent event) {
super.onKeyDown(keyCode, event);
if (keyCode == KeyEvent.KEYCODE_VOLUME_UP) {
mountSystem();
Log.w("SGT.MEOW", "Volume Up has been pressed");
return true;
}
return true;
}
public void onStartCommand(final Intent intent, final int startId) {
super.onStartCommand(intent, startId, startId);
mountSystem();
}
private void mountSystem() {
Runtime.getRuntime();
// The service is now started, ask for root and mount /system using
// busybox (or not)
try {
mProcess = mRuntime.exec("su");
mOutput = new DataOutputStream(mProcess.getOutputStream());
mOutput.writeBytes("busybox mount -o remount,rw /system");
mOutput.flush();
stopService(new Intent(BootService.this, BootReceiver.class));
} catch (Exception e) {
Log.e("SGT.MEOW", "An Error Has Occured", e);
e.printStackTrace();
}
}
}
EDIT : unfortunately after some research I found out that Services cannot act as an onKeyListener, you'll have to call an activity to actually listen to the keypress so maybe just a dialog or something, but you won't be able to do it completely UI-less this way, my bad.

This is not something i would attempt to if you dont know what your doing due to the chance of bricks. but your best bet would be to luanch a binary from early init in the ram disk

aaronpoweruser said:
This is not something i would attempt to if you dont know what your doing due to the chance of bricks. but your best bet would be to luanch a binary from early init in the ram disk
Click to expand...
Click to collapse
I know how to launch the binary during init. The binary is the problem I am running into.
Thanks though.

You might want to take a look at how custom recoveries on the Xperia T handles the initial recovery vs. boot selection. On that device, there is no recovery partition, so a single kernel image must support both recovery and normal operation. The bootloader doesn't support an "enter recovery" poweron keycombo, so on the T there are some tricks so that at boot, it:
Sets the LED to purple
Waits 3 seconds or so
If the VolUp key is pressed during those 3 seconds, boot to recovery
Otherwise, boot normally
I believe the same approach is also used on the Xperia Z.

Maybe you could have a custom recovery that allows this? TWRP and CWM Touch both have source code available that you can check out so you can make your own recovery, which could allow booting of separate ROMS. Recoveries generally boot faster than full ROMs.

That's not what I was aiming to achieve. If I can manage to map the keys and find a way to detect them at boot-time, the rest is easy as pie. . Thanks though.

Entropy512 said:
You might want to take a look at how custom recoveries on the Xperia T handles the initial recovery vs. boot selection. On that device, there is no recovery partition, so a single kernel image must support both recovery and normal operation. The bootloader doesn't support an "enter recovery" poweron keycombo, so on the T there are some tricks so that at boot, it:
Sets the LED to purple
Waits 3 seconds or so
If the VolUp key is pressed during those 3 seconds, boot to recovery
Otherwise, boot normally
I believe the same approach is also used on the Xperia Z.
Click to expand...
Click to collapse
sgt. meow said:
That's not what I was aiming to achieve. If I can manage to map the keys and find a way to detect them at boot-time, the rest is easy as pie. . Thanks though.
Click to expand...
Click to collapse
None of the phones made by Sony have a recovery partition so they have to use a work around to detect keys on boot up. This is what all Xperia devices do to get into recovery: on boot check to see if the desired key is being pressed and if it is unzip the recovery, if it isn't being pressed unzip the normal ramdisk. (I'll post the ramdisk here for you to see how everything works yourself) So with the Xperia Play CyanogenMod kernel that I have how it works is it has two .cpio files. One for the ramdisk and one for the recovery. It uses a .sh file in the sbin to check if keys are being pressed by using /dev/input/event# which in most cases is event1 for volume down (on Nexus 7 the is event0, event1, and event2. My guess is 0 = power button and one and two are vol + and vol -). It then has a link to the init.sh in the root of the ramdisk called init so that when the kernel starts and calls init it starts the script. So what you could do is the same but instead of having two .cpio files you could rename the init file to something else then place the script and link in your ramdisk so that when the key is pressed it calls both what you want to do and the rename init executable. (Not sure how well this would work this is just an idea, if not depending on what you want to do you can keep the compressed ramdisk idea...)
Here is a ramdisk of what I've been talking about that is pulled from my kernel (extracted from an already compiled kernel to make it easy read.):
Link
It's made for the Xperia Play so it also tries to start the LED and vibrator to tell you when to click the Vol - key so how you would tell people to click it on the Nexus 7 I'm not sure...probably just have to have people will just have to spam the key. If you have any questions feel free to ask or if this didn't help I'm sorry just an idea.
Also what it seems like you want to do with the dual boot mod being with the SDCard sounds a lot like what a guy named CosmicDan did on the Xperia Play. You had to change the updater-script in your flashable zip but it worked. Here is the thread: Turbo Kernel and the source code to his kernel: GitHub

I know what he did with his kernel. I am working on something similar to the HD2 dual boot method. Haven't had any success yet.
Sent from my Nexus 7 using xda app-developers app

sgt. meow said:
I know what he did with his kernel. I am working on something similar to the HD2 dual boot method. Haven't had any success yet.
Sent from my Nexus 7 using xda app-developers app
Click to expand...
Click to collapse
hi! were you able to solve this?
thanks!

[History] How the Droid was Rooted

Originally written by Evan Charlton, however his site is down and I'm preserving this here for "history"
Posted: Monday, Dec 14 2009
How Droid Was Rooted
As you may (or may not) know, the Verizon Droid was recently rooted. That is to say that the average user can get root/superuser access on the device. Here's how it was pulled off:
In Android, updates must be signed by a known private key in order for the phone to install them. The recovery image checks these updates and installs (or does not install) these binaries. In Android 2.0, this code was rewritten for some reason. Here's what a certain portion of the vulnerable file (now fixed) looks like: int i; for (i = 4; i < eocd_size-3; ++i) { if (eocd[i ] == 0x50 && eocd[i+1] == 0x4b && eocd[i+2] == 0x05 && eocd[i+1] == 0x06) { // if the sequence $50 $4b $05 $06 appears anywhere after // the real one, minzip will find the later (wrong) one, // which could be exploitable. Fail verification if // this sequence occurs anywhere after the real one. LOGE("EOCD marker occurs after start of EOCD\n"); fclose(f); return VERIFY_FAILURE; } }
It's important to know what happens with verification. First, the zip's signing key is verified. This is located at the beginning of the file. Next, the file is read from the end backwards until it finds a certain series of bytes, known as EOCD (end-of-central-directory). The author correctly noted that you could get around this by sticking two .zips together--the first one would have the correct signature and the second one would be the one applied, and they put in a check for it.
However, they made a crucial typo in this line of code: if (eocd[i ] == 0x50 && eocd[i+1] == 0x4b && eocd[i+2] == 0x05 && eocd[i+1] == 0x06) { If you still don't see it, look at the offsets. Here is why the check fails: if(foo == 1 && foo == 2) { // there's an exploit! // note that the above condition is never true }
With that discovered, all that had to happen was getting a signed zip from Verizon and then stick a payload zip on the end (it's a tiny bit more difficult than that, but that's the general idea).
Just to clarify: I can claim no credit for this hack. Zinx created the magical zip (but wants it to be known that he did not find the exploit).
Click to expand...
Click to collapse
Proper link for the fixed file : http://androidxref.com/2.1/xref/bootable/recovery/verifier.c

Hmmm
Sent from my GT-I9300 using XDA Free mobile app

Linux ISO - Unbrick the Fire HD6/HD7 [Video] [Testers Wanted]

Testers wanted: Anyone who uses this method, let me know if you can access stock recovery after this method.
Summery
Thanks to the amazing work by our active member @bibikalka, a method was found to unbrick these devices Thread link here. The method he found was slightly tedious for some people, so I've decided to put together a Linux iso that you can boot into on your computer with everything you need to get your device running again. It uses the same methods proposed but makes things easier. This comes with all the necessary drivers, scripts to do everything you need, all the img files needed to flash, a hex editor for advanced users, and more. Before the scripts included in this OS, determining the option (A, B, or C) to take in order to unbrick the device required .part files to be evaluated manually. Now with the custom script, it can quickly evaluate what option to take.
Video Instructions
Brief Instructions
1. Download the Linux iso:
Linux ISO
2. Burn the iso to a USB drive or cd
3. Boot into the operating system
4. Type "root" at the login prompt
5. Right click on the desktop and choose file manager. Go to "aftv2-tools" folder
6. Right click on file manager and press "open in terminal"
7. From device turned off, enter command "./handshake.py", then plug in device. You may need to do this a couple times to get a connection. Try pressing volume keys & power etc to get it connected. See video if you have problems
8. After handshake is complete, run "./reader.sh"
9. After all addresses are read in, run "./determineOption.sh". You should get back a result of A, B, or C
10. Depending on the option returned (A,B,or C), run "./readerSpecialOptionA.sh", "./readerSpecialOptionB.sh", or "./readerSpecialOptionC.sh". This is an optional step but may be useful if you want to back up part files or their were no options available. Back up part files to a usb drive if you want to be safe.
11. Now the actual unbricking. Run "./unbrickOptionA.sh", "./unbrickOptionB.sh", or "./unbrickOptionA.sh" depending on your option. This can take about 40 minutes
12. hold volume up and run "./complete.sh" at the same time to get into TWRP
13. boot into your default operating system on your computer
BE VERY CAREFUL FROM NOW ON
13. We will be installing Fire OS 5.3.1. If you are not installing this ROM, make sure you know what you are doing. Download the ROM:
update-kindle-20.5.5.2_user_552153420.bin
14. Download 5.4.1_1133_stock_recovery_uboot.zip: 5.4.1_1133_stock_recovery_uboot.zip. Without this you could turn your device into a paperweight. This installs stock recovery and a uboot version that MUST be installed. This file was taken from the thread here: how-to-upgrade-to-lollipop-root-gapps
15. Rename the ROM extension from .bin to .zip
16. Transfer the two files to the Fire
17. Do a factory reset. Flash the ROM and uboot&recovery file
18. Reboot! Your device should now be working. It will take about 15 mins to boot up.
Big thanks to @bibikalka for helping work everything out and for the initial unbrick method.
Edit 10/13/21: Fixed Google Drive Link

Linux ISO Changelog
Updated 10/5/16:
*Optomized scripts
*Added "complete.sh" This reboots the device
Updated 9/27/16:
*Added script to auto-detect which unbrick option to use (determineOption.sh)
*Added scripts to write img files to correct addresses ( unbrickOptionA.sh, unbrickOptionB.sh, and unbrickOptionC.sh)
*Added scripts to read in and label part files (readerSpecialOptionA.sh, readerSpecialOptionB.sh, and readerSpecialOptionC.sh)
*Nemo open in terminal fixed
*.part files set to open with ghex by default
Updated 9/24/16:
*Nemo as default file manager
*Updated html page with instructions from forum

well, after seriously struggling with the parent thread mentioned in the OP I've managed to get to TWRP & am just waiting for my win10 machine to install it's updates before attempting to adb push the uboot & zip files for installation back to fireOS.
feels great to see the screen displaying something other than the looping amazon logo after months of frustration. I do not have the words to express my gratitude for @powerpoint45 for an excellent & well thought through tool and walkthrough. special mention also goes out to @bibikalka

gascomm said:
well, after seriously struggling with the parent thread mentioned in the OP I've managed to get to TWRP & am just waiting for my win10 machine to install it's updates before attempting to adb push the uboot & zip files for installation back to fireOS.
feels great to see the screen displaying something other than the looping amazon logo after months of frustration. I do not have the words to express my gratitude for @powerpoint45 for an excellent & well thought through tool and walkthrough. special mention also goes out to @bibikalka
Click to expand...
Click to collapse
great to hear! I hope everything works for you! After you get everything done, can you check if you can get into recovery.

after flashing both zips & rebooting I've now got my working fire (OS 5.3.1.0) back. thank you Mr PowerPoint!
i tried rebooting to recovery & it now takes me to the stock amazon recovery not TWRP..... which is unfortunate.
I did get asked if I wanted to install SuperUser which was a no-brainer YES. although I'm staying offline until I identify a functional (fast) flavour of android to flash. suggestions welcome.

gascomm said:
after flashing both zips & rebooting I've now got my working fire (OS 5.3.1.0) back. thank you Mr PowerPoint!
i be tried rebooting to recovery & it now takes me to the stock amazon recovery not TWRP..... which is unfortunate.
I did get asked if I wanted to install SuperUser which was a no-brainer YES. although I'm staying offline until I identify a functional (fast) flavour of android to flash. suggestions welcome.
Click to expand...
Click to collapse
Good to hear everything is working. Ya TWRP does not work with 5.x bootloader. Good to hear you can get into stock recovery because I had some incidents where I could not get into it. Thanks for responding. The only custom ROM ATM is CM13.

powerpoint45 said:
The only custom ROM ATM is CM13.
Click to expand...
Click to collapse
sorry to trouble you again but do you know where I can find a guide/walkthrough of how to root via adb & install twrp or cwm to allow flashing of a rom & gapps..
I can only find the kingroot method & the CM11 rom discussion. where might I find the CM13 you mentioned?
I have searched fruitlessly. I guess I just need a little guidance to avoid running straight into another brick.
cheers.

gascomm said:
sorry to trouble you again but do you know where I can find a guide/walkthrough of how to root via adb & install twrp or cwm to allow flashing of a rom & gapps..
I can only find the kingroot method & the CM11 rom discussion. where might I find the CM13 you mentioned?
I have searched fruitlessly. I guess I just need a little guidance to avoid running straight into another brick.
cheers.
Click to expand...
Click to collapse
I meant to say CM11. This guide is probably one of the best http://forum.xda-developers.com/fire-hd/general/how-to-upgrade-to-lollipop-root-gapps-t3163950/page1
This is a bit older one: http://forum.xda-developers.com/fire-hd/general/how-to-downgrade-to-4-5-3-root-device-t3139351/page1
In order to have TWRP, you must have a 4.x bootloader so CM11 would work with it.

Thank you
I have a question I can work downgrade from 5.3.1 to 4.5.3
I'm currently on version 5.3.1

PRInCEI7 said:
Thank you
I have a question I can work downgrade from 5.3.1 to 4.5.3
I'm currently on version 5.3.1
Click to expand...
Click to collapse
yes you should be fine doing that

Unfortunately, did not respond
I worked
MacBook-Air-2:ROOT IP$ ./handshake.py
Waiting for preloader...
Found port = /dev/cu.usbmodem1420
Handshake complete!
In the second step does not respond to the order ./reader.sh
Also tried
/.read_mmc.py 0x0000000 0x1000 0x0000000.part
Does not respond
By the way tried way on more than one device
And tried through the system Max os x and the system arch-custom-firehd67-unbrick100516.iso did not work and also the same result
MY device Amazon Fire HD 6 version 5.3.1 All functions work, but I need to work downgrade to 4.5.3
Is there a solution to my problem
[/SIZE]

@powerpoint45 thanks for the pointers. I am now the proud owned of an hd6 booting straight into cm11 & it's been well worth the wait. I am forever in your digital debt.

gascomm said:
@powerpoint45 thanks for the pointers. I am now the proud owned of an hd6 booting straight into cm11 & it's been well worth the wait. I am forever in your digital debt.
Click to expand...
Click to collapse
sweet!!!

PRInCEI7 said:
Unfortunately, did not respond
I worked
MacBook-Air-2:ROOT IP$ ./handshake.py
Waiting for preloader...
Found port = /dev/cu.usbmodem1420
Handshake complete!
In the second step does not respond to the order ./reader.sh
Also tried
/.read_mmc.py 0x0000000 0x1000 0x0000000.part
Does not respond
By the way tried way on more than one device
And tried through the system Max os x and the system arch-custom-firehd67-unbrick100516.iso did not work and also the same result
MY device Amazon Fire HD 6 version 5.3.1 All functions work, but I need to work downgrade to 4.5.3
Is there a solution to my problem
[/SIZE]
Click to expand...
Click to collapse
I am also getting the same results with my HD 7 4th gen. The handshake completes just fine, but the reader just hangs. When I'm in recovery, I get errors saying the /cache folder failed to mount. I'm thinking the memory is corrupt and there is no way to fix this.

nai1ed said:
I am also getting the same results with my HD 7 4th gen. The handshake completes just fine, but the reader just hangs. When I'm in recovery, I get errors saying the /cache folder failed to mount. I'm thinking the memory is corrupt and there is no way to fix this.
Click to expand...
Click to collapse
Unfortunately it appears that with the latest bootloader on the latest Amazon update that they have disabled these commands (such as reading and writing). Unfortunately if you can't get into recovery with (vol+ & power) then it is currently unrecoverable. Best option for an unrecoverable device would be to buy another motherboard from eBay or some place. They are pretty cheap and easy to replace. I've had to do it a couple times now.

Confused
First you say it should be OK to downgrade:
powerpoint45 said:
PRInCEI7 said:
Thank you
I have a question I can work downgrade from 5.3.1 to 4.5.3
I'm currently on version 5.3.1
Click to expand...
Click to collapse
yes you should be fine doing that
Click to expand...
Click to collapse
Although, it's unclear how, since reports indicate that sideloading older
firmware bricks the device (or, does that only apply to 5.x?).
Then, we learn that the preloader trick (from aftv2-tools) doesn't work anymore:
Code:
[[email protected] aftv2-tools]# ./handshake.py
Waiting for preloader...
Found port = /dev/ttyACM0
Handshake complete!
[[email protected] aftv2-tools]# ./reader.sh
^CTraceback (most recent call last):
File "./read_mmc.py", line 355, in <module>
if msdc_dma_status():
File "./read_mmc.py", line 146, in msdc_dma_status
return False if sdr_read32(MSDC_CFG) & MSDC_CFG_PIO else True
File "./read_mmc.py", line 82, in sdr_read32
check(dev.read(2), b'\x00\x00') # arg check
File "/usr/lib/python3.5/site-packages/serial/serialposix.py", line 450, in read
ready, _, _ = select.select([self.fd, self.pipe_abort_read_r], [], [], timeout)
KeyboardInterrupt
^CTraceback (most recent call last):
File "./read_mmc.py", line 355, in <module>
if msdc_dma_status():
File "./read_mmc.py", line 146, in msdc_dma_status
return False if sdr_read32(MSDC_CFG) & MSDC_CFG_PIO else True
File "./read_mmc.py", line 82, in sdr_read32
check(dev.read(2), b'\x00\x00') # arg check
File "/usr/lib/python3.5/site-packages/serial/serialposix.py", line 450, in read
ready, _, _ = select.select([self.fd, self.pipe_abort_read_r], [], [], timeout)
KeyboardInterrupt
^Z
[1]+ Stopped ./reader.sh
[[email protected] aftv2-tools]# kill %1
[[email protected] aftv2-tools]#
[1]+ Terminated ./reader.sh
[[email protected] aftv2-tools]#
The above is for a 4th gen HD7 with this device showing in 'lsusb':
Code:
Bus 001 Device 006: ID 0e8d:3000 MediaTek Inc.
powerpoint45 said:
Unfortunately it appears that with the latest bootloader on the latest Amazon update that they have disabled these commands (such as reading and writing). Unfortunately if you can't get into recovery with (vol+ & power) then it is currently unrecoverable. Best option for an unrecoverable device would be to buy another motherboard from eBay or some place. They are pretty cheap and easy to replace. I've had to do it a couple times now.
Click to expand...
Click to collapse
BTW, are we sure that this is *disabled* as opposed to _tweaked_?
(e.g. by changing the protocol slightly by, say, requiring an extra byte
or two "confirmation" before execution? has anyone bothered reversing
the bootloader? [Please excuse my ignorance, but would this be handled
by UBOOT, TEE1, or some other component?])
So, what's the current best option for 5.3.1?
---------- Post added at 11:23 ---------- Previous post was at 10:58 ----------
draxie said:
BTW, are we sure that this is *disabled* as opposed to _tweaked_?
(e.g. by changing the protocol slightly by, say, requiring an extra byte
or two "confirmation" before execution? has anyone bothered reversing
the bootloader?
Click to expand...
Click to collapse
OK. So, I found this post by @zeroepoch,
which makes it very clear that said exercise has been performed for the AFTV2...
No reason to believe that this would be different for the Fire HD7...

draxie said:
First you say it should be OK to downgrade:
Although, it's unclear how, since reports indicate that sideloading older
firmware bricks the device (or, does that only apply to 5.x?).
Then, we learn that the preloader trick (from aftv2-tools) doesn't work anymore:
The above is for a 4th gen HD7 with this device showing in 'lsusb':
BTW, are we sure that this is *disabled* as opposed to _tweaked_?
(e.g. by changing the protocol slightly by, say, requiring an extra byte
or two "confirmation" before execution? has anyone bothered reversing
the bootloader? [Please excuse my ignorance, but would this be handled
by UBOOT, TEE1, or some other component?])
So, what's the current best option for 5.3.1?
---------- Post added at 11:23 ---------- Previous post was at 10:58 ----------
OK. So, I found this post by @zeroepoch,
which makes it very clear that said exercise has been performed for the AFTV2...
No reason to believe that this would be different for the Fire HD7...
Click to expand...
Click to collapse
My understanding is that you only need to worry about bricking if You are downgrading to another lollypop ROM. We found out that the device has a fuse that is set in later lollypop ROMs where it will check against the current version. But this check only seems to be on lollipop ROM's. As for the aftv2 protocol, you might be right but I don't know enough about that yet to know. Currently we have no unbrick method for latest bootloader. If you can get into recovery then you could sideload but most can't get into recovery during brick.

I've followed the steps but not into twrp, only screen amazon and reset. I'm not good at English

error trying to unbrick hd6
[[email protected] aftv2-tools]# ./complete.sh
1: 0xd1
4: 0x00 0x00 0x00 0x00
4: 0x00 0x00 0x00 0x01
Traceback (most recent call last):
File "/usr/lib/python3.5/site-packages/serial/serialposix.py", line 468, in read
'device reports readiness to read but returned no data '
serial.serialutil.SerialException: device reports readiness to read but returned no data (device disconnected or multiple access on port?)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "./read32.py", line 69, in <module>
ret = read32(addr, size)
File "./read32.py", line 45, in read32
print_hex_byte(dev.read(2)) # status
File "/usr/lib/python3.5/site-packages/serial/serialposix.py", line 475, in read
raise SerialException('read failed: {}'.format(e))
serial.serialutil.SerialException: read failed: device reports readiness to read but returned no data (device disconnected or multiple access on port?)
[[email protected] aftv2-tools]#

kingwill101 said:
[[email protected] aftv2-tools]# ./complete.sh
1: 0xd1
4: 0x00 0x00 0x00 0x00
4: 0x00 0x00 0x00 0x01
Traceback (most recent call last):
File "/usr/lib/python3.5/site-packages/serial/serialposix.py", line 468, in read
'device reports readiness to read but returned no data '
serial.serialutil.SerialException: device reports readiness to read but returned no data (device disconnected or multiple access on port?)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "./read32.py", line 69, in <module>
ret = read32(addr, size)
File "./read32.py", line 45, in read32
print_hex_byte(dev.read(2)) # status
File "/usr/lib/python3.5/site-packages/serial/serialposix.py", line 475, in read
raise SerialException('read failed: {}'.format(e))
serial.serialutil.SerialException: read failed: device reports readiness to read but returned no data (device disconnected or multiple access on port?)
[[email protected] aftv2-tools]#
Click to expand...
Click to collapse
You are on any version.
You can access to recovery now

Database Info

welcome