Hi
I've been following this tutorial in order to dump my original telus ROM for another user here that have asked me.
http://forum.xda-developers.com/showthread.php?t=327073
However, when I get this step:
check for real size
D:\_ROM>pdocread -w -d TrueFFS -p Part02 -t
real nr of sectors: 132752 - 64.82Mbyte (0x40d2000)
I get the following error:
ERROR: ITTFFSGetInfo - The device is not ready for use.
WARNING: using default 512 bytes for sectorsize
CopyTFFSToFile(0x0, 0x43e0000, Part02.raw)
ERROR: ITReadDisk: outbuf==NULL
- The device is not ready for use.
Any clues?
Thanks
Ok I got the device name point but now when I try to read the partition size, with all the names OK, it gives me the default 512bytes...
Took me a few minutes to figure this out, so I thought to share
This is taken from some scripts I use in CF-Root, you might need to change it slightly for other CWM3 kernels (like prefixing busybox to various commands, etc).
updater-script
Assumptions:
- rootfs is mounted as rw, so we can write temporary files anywhere (ram disk)
- you put a "myscript.sh" in the system folder inside the update
All this script does is extract whatever you have in update.zip/system folder to /tmp/update, and run the myscript.sh file.
Code:
ui_print("Extracting files ...");
package_extract_dir("system", "/tmp/update");
set_perm(0, 0, 0755, "/tmp/update/myscript.sh");
run_program("/tmp/update/myscript.sh");
myscript.sh
Assumptions:
- all busybox commands are symlinked in /sbin, this is usually the case for CWM3 kernels
Code:
#!/sbin/busybox sh
# get file descriptor for output
OUTFD=$(ps | grep -v "grep" | grep -o -E "update_binary(.*)" | cut -d " " -f 3);
# same as progress command in updater-script, for example:
#
# progress 0.25 10
#
# will update the next 25% of the progress bar over a period of 10 seconds
progress() {
if [ $OUTFD != "" ]; then
echo "progress ${1} ${2} " 1>&$OUTFD;
fi;
}
# same as set_progress command in updater-script, for example:
#
# set_progress 0.25
#
# sets progress bar to 25%
set_progress() {
if [ $OUTFD != "" ]; then
echo "set_progress ${1} " 1>&$OUTFD;
fi;
}
# same as ui_print command in updater_script, for example:
#
# ui_print "hello world!"
#
# will output "hello world!" to recovery, while
#
# ui_print
#
# outputs an empty line
ui_print() {
if [ $OUTFD != "" ]; then
echo "ui_print ${1} " 1>&$OUTFD;
echo "ui_print " 1>&$OUTFD;
else
echo "${1}";
fi;
}
# --- example usage ---
# empty line after "Extracting ..." from updater-script
ui_print;
# give the user some status
ui_print "doing something (1 of 4)";
# assume this won't take more than 30 seconds
progress 0.25 30;
# you'd do something useful here
sleep 15s;
# update status
ui_print "- done with something (1 of 4)";
# we're done, make sure the progress bar is at 25%
set_progress 0.25;
# empty line
ui_print;
# repeat this a few times ;)
ui_print "doing something (2 of 4)";
progress 0.25 30;
sleep 15s;
ui_print "- done with something (2 of 4)";
set_progress 0.50;
ui_print;
ui_print "doing something (3 of 4)";
progress 0.25 30;
sleep 15s;
ui_print "- done with something (3 of 4)";
set_progress 0.75;
ui_print;
ui_print "doing something (4 of 4)";
progress 0.25 30;
sleep 15s;
ui_print "- done with something (4 of 4)";
set_progress 1.00;
ui_print;
# done !
ui_print "done! rebooting!";
How, what, why ?
While updater-script is fine for a lot of things, like installing a new ROM and whatnot, anything sufficiently complicated still has to be done through shell scripts, because a great many things just cannot be easily done in edify. It's nice to be able to give the user some status when doing these operations. There are modded versions of CWM that make the same thing possible in other ways, like simply writing to STDOUT or STDERR. This requires either a custom update_binary or recovery binary, though.
This works because communication between recovery and update_binary is through a file descriptor (pipe). Recovery runs update_binary with the FD as command line parameter. Because the shell script is run as a child process of update_binary, it can write the same commands to that FD (commands recovery listens for), because child processes inherited FD numbers and access rights.
So, all the script has to do is figure out which FD to write to, and pass it the right commands. Finding the FD isn't difficult, as it is passed on the command line and so is listed in the output of ps. Some grep and cut magic retrieve it. See the OUTFD=$(...) line. The right commands are defined in the functions at the top.
Note: this is all taken from my rfs<=>ext4 conversion script for CF-Root/ext4. Slightly adjusted, hopefully it still works as expected
Enjoy!
Thank you chainfire
Sent from my GT-I9000 using Tapatalk
Thanks for this chainfire.
Precisely what I was looking for! You're my hero today, man!
Hi Chainfire
Thanks for your tricks, I'm using it for an almost bulletproof MTD flash script.
BTW, i'd like to call some set_perm commands. But set_perm isn't a recognized command for update-binary.
IDK if I'm clear.
Do you have some advise on that?
RolluS said:
BTW, i'd like to call some set_perm commands. But set_perm isn't a recognized command for update-binary.
Click to expand...
Click to collapse
I've sort this writing equivalent functions:
Code:
set_perm() { # same as set_perm command in updater-script, for example:
#
# set_perm 0 3003 02750 "/system/bin/netcfg"
#
# sets user:group to 0:3003 and perm to 02750 for the file /system/bin/netcfg
$CHOWN $1:$2 $4
$CHMOD $3 $4
}
set_perm_recursive() { # same as set_perm command in updater-script, for example:
#
# set_perm_recursive 0 2000 0755 0755 "/system/bin"
#
# sets uid:gid to 0:2000 and perm to 0755 for folders and 0755 for files recursively in /system/bin
$CHOWN -R $1:$2 $5
$CHMOD $3 $5
#chmod recursive of folder
$FIND $5/* -type d |while read folder; do
$CHMOD $3 $folder
done
#chmod recursive of files
$FIND $5/* -type f |while read file; do
$CHMOD $4 $file
done
}
There is no error handling (yet), so be carrefull when calling these functions
no FD, no output
Chainfire said:
This works because communication between recovery and update_binary is through a file descriptor (pipe). Recovery runs update_binary with the FD as command line parameter. Because the shell script is run as a child process of update_binary, it can write the same commands to that FD (commands recovery listens for), because child processes inherited FD numbers and access rights.
So, all the script has to do is figure out which FD to write to, and pass it the right commands. Finding the FD isn't difficult, as it is passed on the command line and so is listed in the output of ps. Some grep and cut magic retrieve it. See the OUTFD=$(...) line.
Click to expand...
Click to collapse
finding the FD is difficult on an SGY phone under MT 2.0 kernel, because is is not passed as command line param and therefore not in the ps output.
can anyone give an example of a working FD ?
the expression returns "" on my SGY, and no output is readable from script.
above zip as one file with the (.*) business removed from FD expression in myscript.sh
I don't see that ps gives me a "FD" in its output. whatever that really is. /tmp/recovery.log says that /sbin/recovery has no command line params either on SGY
from recov.log:
I:Set boot command "boot-recovery"
Command: "/sbin/recovery"
there is no FD in the command line ! where is it then ?
I'll test this in a bit. Nice hack b/w.
any news?
Thanks for this trick. What I wanted to do is to redirect stdout (and stderr) of my script to the UI. I know that you can see this in "show logs", but I wanted it to display right during the installation. Here is what I came up with:
Code:
#!/sbin/busybox ash
OUTFD=$(ps | grep -v "grep" | grep -o -E "update_binary(.*)" | cut -d " " -f 3);
/sbin/busybox ash $* 2>&1 |
while read -r line
do
echo "ui_print $line" >&$OUTFD;
echo "ui_print " >&$OUTFD;
done
If you save this as "scripts/stdoutwrapper.sh", you can do something like this:
Code:
package_extract_dir("scripts", "/tmp/update");
set_perm(0, 0, 0755, "/tmp/update/stdoutwrapper.sh");
run_program("/tmp/update/stdoutwrapper.sh", "/tmp/update/myscript.sh", "param1", "param2");
In myscript.sh, use any shell commands. The output will be redirected to the UI. Therefore, you should be able to write scripts that work both on the command line and in recovery without changes.
Please note: As all output will be printed, the tricks with set_progress etc. don't work. It would probably be possible to use a prefix to identify commands that should be executed, not printed, so you could do e.g. "echo '<#>set_progress 0.25'".
what value does OUTFD have? find out like below:
adb shell
ps
then /sbin/recovery might have PID 2166 on SGY phone
su
ls -l --color=never /proc/2166/fd
may give you e.g.
3 -> /dev/tty0
so 3 is your OUTFD !
now grep it accordingly for the script. use MT kernel 2.0 on SGY for above capability
time saver
edify Scripts may be tested by executing update-binary directly:
update-binary version output package
An example would be:
update-binary 2 stdout /sdcard/update.zip
Just noticed Chainfire's ui_print shell script in the latest SuperSU zip, and that lead me here.
Here are some updated versions (for CWM6?); ui_print and set_perm from SuperSU and the other 2 from my tinkering today:
Code:
OUTFD=$2;
ZIP=$3
ui_print() {
echo -ne "ui_print $1\n" > /proc/self/fd/$OUTFD;
echo -ne "ui_print\n" > /proc/self/fd/$OUTFD;
}
set_perm() {
chown $1.$2 $4
chown $1:$2 $4
chmod $3 $4
}
show_progress() { echo "progress $1 $2" > /proc/self/fd/$OUTFD; }
set_progress() { echo "set_progress $1" > /proc/self/fd/$OUTFD; }
ex:
show_progress 1.34 0;
ui_print "Hello world!";
set_progress 0.5;
ui_print " "; #blank line
set_progress 1.34;
ui_print "Done!";
Also worth noting he just uses busybox unzip to extract files from the flashable zip directly and goes from there.
ex:
ui_print "Extracting files!"
cd /tmp
unzip -o "$ZIP"
mai77 said:
what value does OUTFD have?
Click to expand...
Click to collapse
I put ui_print "Test: $OUTFD" in a script and the value of OUTFD appears to increase with every zip flashed.
Not much use knowing it in that case.
Nice work, I used this in my little zip. However, it doesn't work with TWRP. Is there any way to accomplish that?
sorry to put this here but could anyone direct me towards the cwm or TWRP version for "jxjpb" (asia) baseband pls?
klenamenis said:
Nice work, I used this in my little zip. However, it doesn't work with TWRP. Is there any way to accomplish that?
Click to expand...
Click to collapse
TWRP names the extracted update-binary "updater", so you can add something like this (or modify the regex in the existing line):
Code:
[ $OUTFD != "" ] || OUTFD=$(ps | grep -v "grep" | grep -o -E "updater(.*)" | cut -d " " -f 3)
_that said:
TWRP names the extracted update-binary "updater", so you can add something like this (or modify the regex in the existing line):
Code:
[ $OUTFD != "" ] || OUTFD=$(ps | grep -v "grep" | grep -o -E "updater(.*)" | cut -d " " -f 3)
Click to expand...
Click to collapse
Shouldn't be necessary with any reasonably current recovery. That was just a hack Chainfire wrote to get the FD back in the CWM3 days.
All that should be required (and has always worked for me) is to make the update-binary your shell script, then:
Code:
OUTFD=$2;
See my other updated commands above. And some zips I've made which should provide good references for people: Nexus Louder, Xposed Framework Installer, and Nexus BootUnlocker. All available in my Odds and Ends thread, linked in my sig.
osm0sis said:
Shouldn't be necessary with any reasonably current recovery. That was just a hack Chainfire wrote to get the FD back in the CWM3 days.
All that should be required (and has always worked for me) is to make the update-binary your shell script, then:
Code:
OUTFD=$2;
Click to expand...
Click to collapse
Yes, that works if you replace the whole update-binary with a shell script, but this method is for scripts that are called from the updater-script when using a binary updater.
I've recently switched to a shell script as updater too, but I had to write my own zip signing program because busybox unzip was unable to extract files from a zip signed by SignApk.
osm0sis said:
See my other updated commands above. And some zips I've made which should provide good references for people: Nexus Louder, Xposed Framework Installer, and Nexus BootUnlocker. All available in my Odds and Ends thread, linked in my sig.
Click to expand...
Click to collapse
Wow, nice collection! I remember some other posts from you that were very helpful, thanks!
_that said:
Yes, that works if you replace the whole update-binary with a shell script, but this method is for scripts that are called from the updater-script when using a binary updater.
I've recently switched to a shell script as updater too, but I had to write my own zip signing program because busybox unzip was unable to extract files from a zip signed by SignApk.
Wow, nice collection! I remember some other posts from you that were very helpful, thanks!
Click to expand...
Click to collapse
Nice! My misunderstanding then.
And ah yes, the old "1 and 8" issue with unzip. Might be resolved in the latest busybox 1.22.1 but I'm not 100% about that, and it'll be awhile before that makes it into recoveries.
I'd love to get hold of your zip signer if that'd be okay. I have Chainfire's solution, but I was still running into some verification problems (I think) from the MinSignApk whole file resigning.
osm0sis said:
And ah yes, the old "1 and 8" issue with unzip. Might be resolved in the latest busybox 1.22.1 but I'm not 100% about that, and it'll be awhile before it makes it into recoveries.
Click to expand...
Click to collapse
Exactly! I learned a lot about the zip format while researching this.
osm0sis said:
I'd love to get hold of your zip signer if that'd be okay. I have Chainfire's solution, but I was still running into some verification problems (I think) from the MinSignApk whole file resigning.
Click to expand...
Click to collapse
Argh! I saw your original question in that thread but I never found the solution because there were so many pages in between...
I ended up with a hack that appears to resemble Chainfire's minsignapk, but I didn't need to write my own zipadjust. Basically I simply sign the zip normally with signapk, then I unpack and repack the whole archive using 7zip (bonus: slightly better compression), and then I run the whole-zip-signer on the archive.
Here is my SignWholeFile.jar - the source code is just too ugly to publish. View attachment SignWholeFile.jar If you find that it works better than Chainfire's version, I'll clean the source and release it.
This is the script I use for signing:
Code:
#!/bin/sh
KEYDIR=~/android/aosp/build/target/product/security
SIGNAPK=~/android/aosp/prebuilts/sdk/tools/lib/signapk.jar
SIGNWHOLEFILE=~/android/src/signapk/SignWholeFile.jar
java -jar $SIGNAPK -w $KEYDIR/testkey.x509.pem $KEYDIR/testkey.pk8 "$1" "$1.signed.zip"
mv "$1" "$1.unsigned"
signedzip=$(readlink -f "$1.signed.zip")
[ -d /tmp/signapk2 ] && rm -rf /tmp/signapk2
mkdir /tmp/signapk2
pushd /tmp/signapk2
unzip $signedzip
rm $signedzip
7z a -r -mx=9 $signedzip *
#7z a -r $signedzip *
popd
mv "$1.signed.zip" "$1"
java -jar $SIGNWHOLEFILE $KEYDIR/testkey.x509.pem $KEYDIR/testkey.pk8 "$1" "$1"
I ran all the required commands and noticed that the chmod did not do anything. So I decided to run the temp root command abd I get permission denied.
Sent from my T-Mobile G2 using XDA App
Please anyone? I run this command "adb shell chmod 755 /data/local/tmp/*" but it does not do anything, is there something I have to change on that line?
Been trying to root for 2 days now but unsuccessful.
you're not supposed to see any return on the command prompt. Just continue with the procedure.
Thanks for giving me a reply, waited many hours. THANK you though.
When I run the temp root command, I get this.
"C:\android-sdk-windows\platform-tools>adb shell /data/local/tmp/psneuter
mmap() failed. Operation not permitted
C:\android-sdk-windows\platform-tools>adb shell
"
C:\android-sdk-windows\platform-tools>adb shell
#
#
# cd /data/local/tmp
cd /data/local/tmp
# ./busybox md5sum /dev/block/mmcblk0p18
./busybox md5sum /dev/block/mmcblk0p18
b532ca54a073f0c4043bd7be69ebce8d /dev/block/mmcblk0p18
# cd /data/local/tmp
cd /data/local/tmp
# ./gfree -f -b hboot-eng.img
./gfree -f -b hboot-eng.img
--secu_flag off set
--cid set. CID will be changed to: 11111111
--sim_unlock. SIMLOCK will be removed
--hboot set. hboot image hboot-eng.img will be installed in partition 18
Section header entry size: 40
Number of section headers: 44
Total section header table size: 1760
Section header file offset: 0x00015384 (86916)
Section index for section name string table: 41
String table offset: 0x000151cb (86475)
Searching for .modinfo section...
- Section[16]: .modinfo
-- offset: 0x000011cc (4556)
-- size: 0x000000cc (204)
Kernel release: 2.6.32.17-g9ab3677
New .modinfo section size: 204
Attempting to power cycle eMMC... OK.
Write protect was successfully disabled.
Searching for mmc_blk_issue_rq symbol...
- Address: c029c72c, type: t, name: mmc_blk_issue_rq, module: N/A
Kernel map base: 0xc029c000
Kernel memory mapped to 0x40002000
Searching for brq filter...
- Address: 0xc029c72c + 0x34c
- 0x2a000012 -> 0xea000012
Backing up current partition 18 and installing specified hboot image...
Backing up current partition 7 and patching it...
patching secu_flag: 0
Done.
# ./flash_image recovery recovery.img
./flash_image recovery recovery.img
# cd /data/local/tmp
cd /data/local/tmp
# ./flash_image recovery recovery.img
./flash_image recovery recovery.img
# ./root_psn
./root_psn
# sync
sync
#
Did these commands run right?
# cd /data/local/tmp
# ./gfree -f -b hboot-eng.img
# ./flash_image recovery recovery.img
# ./root_psn
# sync
All looks good to me.... When yoh restart the phone do you have s off?
Sent from my HTC Vision using XDA App
Hi all folks,
I have some question about the stock android system in this specific box and the format of the dumped partition.
Try to explain, I'm using rkflashtool to interact with the memory of the RK3188
This is the output of the command
rkflashtool r 0 1 | head -n 11
-------------------------------------------------------------------------------------------------
CMDLINE:console=ttyFIQ0 androidboot.console=ttyFIQ0
init=/init initrd=0x62000000,0x00800000 mtdparts=rk29xxnand:
[email protected](misc),
[email protected](kernel),
[email protected](boot),
[email protected](recovery),
[email protected](backup),
[email protected](cache),
[email protected](userdata),
[email protected](kpanic),
[email protected](system),
[email protected](user)
-------------------------------------------------------------------------------------------------
I guess the boot partition is something linke that:
+-------+ <--- 0x00019fe0
| boot |
+-------+ <----0x00012000
With this command i'm able to dump the entrie boot partition on my linux box in a file named b00t.img :
rkflashtool r 0x12000 0x8000 > b00t.img
Now, i have find out that with the tool rkunpack (or simply with dd) i'm able to unpack this b00t.img. The output are two file:
b00t.img-raw
b00t.img-symbol
The first file is no more than a gzip compressed data file, I'm able to extract the data in a directory with this command:
gunzip < ../b00t.img-raw | sudo cpio -i --make-directories
Now in this dir I have all the files of the / partition. I can modify for example the /init.rc.
I want to repack the entrie b00t.img in order to flash it again on the device.
NB:
In this thread this guys work at something like my problem...
http://www.freaktab.com/showthread....-Tricks-by-Finless&p=4055&viewfull=1#post4055
The difference is that they work on a different partition layout, and the rkunpack of dumped boot.img return they only boot.img-raw.
Obviously I've already tried to repack the modified directory in this two ways:
mkcramfs myboot myboot-temp.img
kcrc myboot-temp.img customboot.img
or
find . ! -name "."| sort | cpio -oa -H newc | gzip -n > ../newboot.gz
kcrc newboot.gz customboot.img
Neither of these leads to obtain a file large enough to fit the boot partition on the deivice, that I want fill with:
rkflashtool w 0x12000 0x8000 < modifiedb00t.img
Has anyone ever worked with rk3188? Any idea?
Thanks in advance.
Anyone?
Has anyone installed self signed ROMs using the method described in this blog http://mjg59.dreamwidth.org/31765.html? The goal is to install a self signed image that allows you to only install images signed by a key you generate yourself to avoid the giant security hole caused by custom recoveries that don't check signatures.
Here's the overview :
First: Unlock your bootloader. /data will be wiped.
Second: Get a copy of the stock recovery.img for your device.
Third: Grab mkbootimg from here and build it. Run unpackbootimg against recovery.img.
Fourth: Generate some keys. Get this script and run it.
Fifth: zcat recovery.img-ramdisk.gz | cpio -id to extract your recovery image ramdisk. Do this in an otherwise empty directory.
Sixth: Get DumpPublicKey.java from here and run it against the .x509.pem file generated in step 4. Replace /res/keys from the recover image ramdisk with the output. Include the "v2" bit at the beginning.
Seventh: Repack the ramdisk image (find . | cpio -o -H newc | gzip > ../recovery.img-ramdisk.gz) and rebuild recovery.img with mkbootimg.
Eighth: Write the new recovery image to your device
Ninth: Get signapk from here and build it. Run it against the ROM you want to sign, using the keys you generated earlier. Make sure you use the -w option to sign the whole zip rather than signing individual files.
Tenth: Relock your bootloader
Eleventh: Boot into recovery mode and sideload your newly signed image.
Click to expand...
Click to collapse
I have the 8" Tab (SM-T310) and want to try it. Anyone know if there's an official source of stock recovery images? I have the 4.4.2 update.zip from an OTA update I never installed (my tablet's still on stock 4.2.2), can the recovery somehow be extracted from that? Since I'm still on 4.2.2, I don't need to unlock the bootloader, right? Can I use Heimdall to put the new recovery on the tab?
Here's my step by step if anyone else is crazy enough to try this.
First: Unlock your bootloader. /data will be wiped.
Click to expand...
Click to collapse
Skipped so far, running 4.2.2 which from what I've been reading I think isn't locked.
Second: Get a copy of the stock recovery.img for your device.
Click to expand...
Click to collapse
Grabbed the update from Kies (on Windows VM):
Agreed to Kies update when I plugged in the tablet.
Watched my temp folder (from windows search bar enter %temp%) until tmp*.tmp.zipfolder showed up (wait for tmp*.tmp file to download and get converted to a zip, then it unzips into zipfolder automatically), unplugged the tablet immediately as it booted into download mode, copied tmp*.tmp.zipfolder somewhere else (desktop) before Kies cancelled the update process and deleted the temp files.
Third: Grab mkbootimg from here and build it. Run unpackbootimg against recovery.img.
Click to expand...
Click to collapse
Source is on github: osm0sis/mkbootimg From here on I'm using linux.
cd into mkbootimg folder and run "make"
run
Code:
./unpackbootimg -i recovery.img -o rec
(rec is the folder I unpacked to, make the folder first or it'll segfault)
Fourth: Generate some keys. Get this script and run it.
Click to expand...
Click to collapse
Saved script (posted below, can't post links yet...) to "make_key.sh", then
Code:
chmod +x make_key.sh
to make it executable.
Ran script, usage: /make_key.sh <name> <subject> [<keytype>]
subject must be in the format "/C=GB/ST=London/L=London/O=Global Security/OU=IT Department/CN=example.com" (look up "Create CSR using OpenSSL Without Prompt (Non-Interactive)" for what all that means)
Fifth: zcat recovery.img-ramdisk.gz | cpio -id to extract your recovery image ramdisk. Do this in an otherwise empty directory.
Click to expand...
Click to collapse
Make a directory, cd into it, run
Code:
zcat recovery.img-ramdisk.gz | cpio -id
with recovery.img-ramdisk.gz pointing to where your file is (mine was ../recovery.img-ramdisk.gz).
Sixth: Get DumpPublicKey.java from here and run it against the .x509.pem file generated in step 4. Replace /res/keys from the recover image ramdisk with the output. Include the "v2" bit at the beginning.
Click to expand...
Click to collapse
Not sure why he's using a different DumpPublicKey.java than the one that's in the mkbootimg git... but it's in the "libmincrypt/tools/DumpPublicKey.java" that was in the mkbootimg git, I didn't see any differences using diff.
Running
Code:
javac DumpPublicKey.java
tells me I need BouncyCastleProvider. And now I'm stuck.
Downloaded the Bouncy Castle jar and put it in the same folder as DumpPublicKey.java and ran
Code:
javac -cp bcprov-jdk15on-152.jar DumpPublicKey.java
echo "Main-Class: DumpPublicKey" > manifest.txt
jar cvfm DumpPublicKey.jar manifest.txt DumpPublicKey.java
Then running
Code:
java com.android.dumpkey.DumpPublicKey
gave me various class not found errors and I ended up with a file structure like this trying to make it find the bouncy castle. Annnnnd I'm stuck.
.
├── bcprov-jdk15on-152.jar
├── com
│** └── android
│**** └── dumpkey
│****** ├── bcprov-jdk15on-152.jar
│****** ├── DumpPublicKey.class
│****** ├── DumpPublicKey.jar
│****** ├── DumpPublicKey.java
│****** └── manifest.txt
├── DumpPublicKey.class
├── DumpPublicKey.java
└── manifest.txt
I obviously don't know how to java at all.... any suggestions?
I just needed to put the "-cp" in the java command as well as the javac command.
Code:
java -cp .:./bcprov-jdk15on-152.jar com.android.dumpkey.DumpPublicKey
The full command is
Code:
java -cp .:./bcprov-jdk15on-152.jar com.android.dumpkey.DumpPublicKey /path/to/key.x509.pem > keys
After deleting stuff and testing, I found I only needed files in these locations:
.
├── bcprov-jdk15on-152.jar
├── com
│** └── android
│** └── dumpkey
│** ├── DumpPublicKey.class
│** └── DumpPublicKey.jar
├── DumpPublicKey.java
└── manifest.txt
Then I replaced the "/res/keys" file with the "keys" file I just made.
Seventh: Repack the ramdisk image (find . | cpio -o -H newc | gzip > ../recovery.img-ramdisk.gz) and rebuild recovery.img with mkbootimg.
Click to expand...
Click to collapse
From the folder that the ramdisk image was extracted into, run
Code:
find . | cpio -o -H newc | gzip > ../recovery.img-ramdisk.gz
mkbootimg needs offsets that were printed when I ran unpackbootimg:
BOARD_KERNEL_CMDLINE
BOARD_KERNEL_BASE 10000000
BOARD_NAME
BOARD_PAGE_SIZE 2048
BOARD_KERNEL_OFFSET 00008000
BOARD_RAMDISK_OFFSET 01000000
BOARD_TAGS_OFFSET 00000100
Still in the folder where I unpacked the recovery image (mkbootimg is one directory up)
Code:
../mkbootimg --kernel recovery.img-zImage --ramdisk recovery.img-ramdisk.gz --base 10000000 --pagesize 2048 --kernel_offset 00008000 --ramdisk_offset 01000000 --tags_offset 00000100 -o newrecovery.img
Eighth: Write the new recovery image to your device
Click to expand...
Click to collapse
This thread says Heimdall 1.4.0 works for T31x: http://forum.xda-developers.com/showthread.php?t=2522091
Oh how nice, Heimdall 1.4.1 is in my package manager.
Connect device and restart in download mode (held the "HOME" button, "Volume Down" and "Power" all at the same time (for about 5 seconds). Hit the "Volume Up" to enter download mode when prompted.)
Code:
sudo heimdall flash --verbose --no-reboot --RECOVERY recovery.img
Ninth: Get signapk from here and build it. Run it against the ROM you want to sign, using the keys you generated earlier. Make sure you use the -w option to sign the whole zip rather than signing individual files.
Click to expand...
Click to collapse
signapk is on github in android/platform_build/tools. And it gives more bouncy castle errors. Put bcpkix-jdk15on-152.jar and bcprov-jdk15on-152.jar in the signapk folder and run
Code:
javac -cp .:./bcprov-jdk15on-152.jar:./bcpkix-jdk15on-152.jar SignApk.java
echo "Main-Class: SignApk" > manifest.txt
jar cvfm SignApk.jar manifest.txt SignApk.java
make directory com/android/signapk/ and move in all the *.class files and the SignApk.jar
Code:
java -cp .:./bcprov-jdk15on-152.jar:./bcpkix-jdk15on-152.jar com.android.signapk.SignApk /path/to/key.x509.pem /path/to/key.pk8 ../original.zip ../signed.zip
I just replaced the recovery in the OTA with the recovery with my keys from earlier, then rezipped it before signing. And after starting sideloading I noticed I left the "-w" option off the signing command, so I made another file with "-w".
Sideloaded with:
Code:
adb reboot recovery
(then volume down to select apply update from ADB)
adb sideload signed.zip
Then saw:
loading: 'update.zip'
sending: 'update.zip' <completion percent>
(might have to do some adb stopping/starting or adb usb beforehand to make it work, I was getting "error: closed" at first. If it just sits on "loading" something's wrong, as I found out last night when I waited hours for "loading" to turn into something else.)
After the file finished uploading, In terminal I got the response "* failed to write data 'protocol fault (couldn't read status): Success' *"
And on the device I got (for a few seconds before it showed only the sad robot on its back). Then after a couple minutes it rebooted back into recovery.
E: Footer is wrong
E: Footer is wrong
E: Signature verification failed
Installation aborted
So I tried again, but this time selected the option to wipe the cache before adb sideload. Then I tried again, using the update.zip that I forgot to add the "-w" option when signing. So far all fails.
I have no idea if the issue is how the recovery was flashed or what, so I'm doing it manual...
Code:
adb shell
su
#first backup current recovery
dd if=/dev/block/mmcblk0p10 of=/sdcard/recoverybk.img
adb pull /sdcard/recoverybk.img
# now push and dd my signed recovery
adb push /sdcard/recovery.img
dd if=/sdcard/recovery.img of=/dev/block/mmcblk0p10
And still having the same signature verification issue.
Edit: I went back and unpacked the recovery I pulled off the device (unpackbootimg), and it looks like somehow I managed to run mkbootimg with the old ramdisk image.
New problem with the new recovery: "E:failed to load keys". Maybe it had something to do with using ec keys just for funsies. So I remade the keys with the default, redumped into the ramdisk image, rebuild/reflashed recovery, resigned the update.zip. Now it's back to the "footer is wrong, signature verification failed" error.
But this is still trying to use the OTA 4.4.something update, not a full ROM. What's it do with Cyanogen?
First attempt: Download Cyanogen and sideload it (unmodified)
E:failed to verify whole-file signature
E:signature verification failed
Ok, expected behavior, it's not signed with my keys.
Attempt 2: sign Cyanogen with my keys and sideload it
Install from ADB complete!! Success!!
@user0002,
great thread! have you considered assembling a toolkit/suite for this process?
Thanks.
m
moonbutt74 said:
@user0002,
great thread! have you considered assembling a toolkit/suite for this process?
Thanks.
m
Click to expand...
Click to collapse
Hmmm... that's a good idea.