Related
Extracting the N2 root filesystem and adding rc.local
These instructions assume using a linux console.
The root filesystem lives in a u-boot/PPCboot ramdisk. These instructions tell you how to extract it.
Boot your nt with the "rooted forever" sdcard while connected with usb.
Make a copy of the boot partition. After this you may reboot your nt normally.
$ tar -cf boot.tar boot/
$ tar xvf boot.tar
$ cd boot
Extract the uRamdisk file. first 64 bytes is the u-boot header, we need to skip it.
$ dd if=URamdisk bs=64 skip=1 of=ramdisk.gz
ramdisk.gz now contains the root file system.
Copy ramdisk.gz to a work directory, then extract it:
gunzip -v ramdisk.gz
cpio -iv < ramdisk
The root file system will populate your work dir. Delete the ramdisk file. You can now make changes to the root file system.
The change I'm going to make is a simple one: adding the ability to run an rc.local file at boot.
edit the init.rc file in your work directory, adding at the bottom:
Code:
service rclocal /etc/rc.local
enabled
user root
oneshot
rebuilding the uRamdisk file is simple, once you know how (thanks to JesusFreke for pointing me in the right direction). cd into your working directory, issue these commands:
Code:
find . -regex "./.*"| cpio -ov -H newc | gzip > ../ramdisk.gz
mkimage -A ARM -T RAMDisk -n Image -d ../ramdisk.gz ../uRamdisk
A script with the the commands above is attached. Also attached is a rooted uRamdisk with the rc.local ability already build in. To replace the uRamdisk file, boot with your "Rooted Forever" sdcard, and copy the uRamdisk file to the nook's boot directory.
What's this good for? That's up to you. I'm using it to automatically start dropbear so I can ssh in my Nooks and also use rsync to keep them synced with my ebook library. This is also one of the steps in building a kernel for the Nook ST.
jocala said:
Extracting the N2 root filesystem and adding rc.local
These instructions assume using a linux console.
The root filesystem lives in a u-boot/PPCboot ramdisk. These instructions tell you how to extract it.
Boot your nt with the "rooted forever" sdcard while connected with usb.
Make a copy of the boot partition. After this you may reboot your nt normally.
$ tar -cf boot.tar boot/
$ tar xvf boot.tar
$ cd boot
Extract the uRamdisk file. first 64 bytes is the u-boot header, we need to skip it.
$ dd if=URamdisk bs=64 skip=1 of=ramdisk.gz
ramdisk.gz now contains the root file system.
Copy ramdisk.gz to a work directory, then extract it:
gunzip -v ramdisk.gz
cpio -iv < ramdisk
The root file system will populate your work dir. Delete the ramdisk file. You can now make changes to the root file system.
The change I'm going to make is a simple one: adding the ability to run an rc.local file at boot.
edit the init.rc file in your work directory, adding at the bottom:
Code:
service rclocal /etc/rc.local
enabled
user root
oneshot
rebuilding the uRamdisk file is simple, once you know how (thanks to JesusFreke for pointing me in the right direction). cd into your working directory, issue these commands:
Code:
find . -regex "./.*"| cpio -ov -H newc | gzip > ../ramdisk.gz
mkimage -A ARM -T RAMDisk -n Image -d ../ramdisk.gz ../uRamdisk
A script with the the commands above is attached. Also attached is a rooted uRamdisk with the rc.local ability already build in. To replace the uRamdisk file, boot with your "Rooted Forever" sdcard, and copy the uRamdisk file to the nook's boot directory.
What's this good for? That's up to you. I'm using it to automatically start dropbear so I can ssh in my Nooks and also use rsync to keep them synced with my ebook library. This is also one of the steps in building a kernel for the Nook ST.
Click to expand...
Click to collapse
dd if=URamdisk bs=64 skip=1 of=ramdisk.gz
Click to expand...
Click to collapse
"uRamdisk" instead of "URamdisk"
Thanks again.
Things you will need:
Cygwin- http://www.cygwin.com/setup.exe
ADB- http://developer.android.com/sdk/index.html
Loki Patch source- https://github.com/djrbliss/loki
These are the steps i took to compile and use loki_patch.
I will assume you have the android sdk setup and ready, I will assume your SDK is under c:/AndroidSDK(this is how mine is setup)
Pulling aboot.img using adb:
You can copy cmd.exe into the folder where adb is located and run it from there so you do not have to navigate to the folder manually, or just run cmd.exe and navigate to the adb folder, for me it is c:\AndroidSDK\sdk\platform-tools.
Once you are in your adb file path and your phone is connected and in debug mode follow these instructions to pull aboot.img from your phone.
Original instructions from djrbliss here https://github.com/djrbliss/loki
[email protected]:~$ adb shell
[email protected]:/ $ su
[email protected]:/ # dd if=/dev/block/platform/msm_sdcc.1/by-name/aboot of=/data/local/tmp/aboot.img
[email protected]:/ # chmod 644 /data/local/tmp/aboot.img
[email protected]:/ # exit
[email protected]:/ $ exit
[email protected]:~$ adb pull /data/local/tmp/aboot.img
3293 KB/s (2097152 bytes in 0.621s)
Now you should have the file aboot.img in the platform-tools folder(where the adb.exe file is located)
Copy this file to your desktop so you know where it is.
Installing gcc with Cygwin:
Original Instructions came from here http://www.eecg.utoronto.ca/~aamodt/ece242/cygwin.html
Step 0: Download and run the cygwin installer.
Step 1: Select “Install from Internet”
Step 2: Install to default location
Step 3: Use default local package directory (click next)
Step 4: Use whatever internet connection settings (click next)
Step 5: Select a mirror (use the one already selected, click next)
Step 6 (a): In the “Select Packages” expand “Devel”:
Step 6 (b): Select gcc, gdb, and make
Step 7: click next and follow the rest of the installation instructions.
Ok, now that gcc is installed we can compile the loki_patch source to make the executable.
Go here https://github.com/djrbliss/loki
You should see a file called loki_patch.c, click this link and it will open and you can see all the code.
Select the code from top to bottom and right click, copy.
Now right click on your desktop and select new> text file.
Open this text file and paste the code into it, go to file and save as loki_patch.c (make sure you have your file extensions turned on so you can save this as a c source and not a txt file).
We should now have a file called loki_patch.c on the desktop, keep it there for now.
Open up windows explorer and navigate to the following:
c:\cygwin\home\<username>\
(You will see a few files and a kitchen folder)
Create a new folder in here called compile.
Now, let's go back to the desktop and copy loki_patch.c and aboot.img and paste those into the compile folder you just created.
Go ahead and run cygwin.
Now we need to change directories, so let's type the following:
cd compile
We should now be in the compile folder.
Lets compile this code so we can use it, type the following command:
gcc loki_patch.c -o loki_patch
We should now have a file in the compile folder called loki_patch.exe( windows added this .exe, the file extension can be left alone or deleted)
Now you need a boot.img file to patch, grab one from a rom or kernal and copy this into the compile folder.
Once all the files are in the compile folder run the following command to patch the boot.img file:
./loki_patch boot aboot.img boot.img boot.lok
We should now have a boot.lok file in the compile folder, hope this helps and i hope i didnt leave anything out, i will try and update this with screen shots later.
Nice work..thanks
C13v3r0n3 first link is Broken: Cygwin, my friend!!
TheAxman said:
Nice work..thanks
Click to expand...
Click to collapse
And that's why you guys rock because that's all greek to me.
"If you ain't first yer last"
Sent from my rockin ATT S4
I was wondering if I could mount an empty.img file so that I could add executable into it and chmod 777 them or what ever the number is maybe 666.
Then I would add the location to my $PATH variable in the "/system/etc/mkshrc" file so I could execute those programs from any directory.
What say you?
Has this been done before?
It works!
Well, I wen ahead and tried it out, I figured "What the hell, its not like I have to format my sd card." It worked!
So what I did
1) I changed directories to Downloads. ("cd ~/Downloads")
2) I created a directory for my image in Downloads, and moved into it. (mkdir image && cd ./image)
3) I created an empty 4 gig image called apps.img using dd ("dd if=/dev/zero of=apps.img bs=1MB count=0 seek=4096")
4) I formated it to ext2 ("mke2fs -F apps.img")
5) I used adb to push it to my phone ("adb push ~/Downloads/image/apps.img /storage/sdcard0/Download/")
6) Then on my phone as su I mounted the image ("mount -o loop '/storage/sdcard0/Download/apps.img' '/data/local/mnt' ") {with single quotes around the directories, the double quotes wrap the whole actual command, you don't need them} [EDIT: I used bash on the phone to do this, ie I "su" [enter] ; "bash" [enter] ; "THE ABOVE COMMAND" [enter]
7) To test I used the python interpreter as my executable so I created a folder in /data/local/mnt called apps,(note* I should have made that folder on my pc before I pushed it to my phone to ensure that the foder was actually in the apps.img file.) I created two more folders "bin" and "lib" using "File Manager" on my phone. I then moved what I needed to run python into those folders (though you'll see I forgot something)
8) I added PYTHONHOME PYTHONPATH and added the bin folder I created to $PATH in the /system/etc/bash/bashrc file (Ask and I'll explain). If you don't have bash the mkshrc file is located "/system/etc/mkshrc" on your phone (if its Sprint SGSIII) adding environment variable there will accomplish the same thing, sorta.
9) I connected my phone to pc w/usb, opened up a teminal on pc, started an adb shell
10)........
Code:
[email protected]:~$ adb devices
List of devices attached
xxxxxxxx device
[email protected]:~$ adb shell
[email protected]:/ $ su
[email protected]:/ # bash
void endpwent()(3) is not implemented on Android
localhost / # which python
/data/local/mnt/apps/bin/python
localhost / # python
'import site' failed; use -v for traceback
Python 2.6.2 (r262:71600, Mar 20 2011, 16:54:21)
[GCC 4.4.3] on linux-armv7l
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> import sys
>>> import math
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: No module named math
>>> import io
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/home/manuel/AptanaStudio3Workspace/python-for-android/python-build/output/usr/lib/python2.6/io.py", line 63, in <module>
ImportError: No module named _fileio
>>>
localhost / # exit
[email protected]:/ # ^D
[email protected]:/ $ ^D
[email protected]:~$
I'm thinking that if I can get my mkbootimg tools to work, I would mod an init script to mount the apps.img and then create links for each file in say '/mnt/apps/bin' create a link*in '/system/bin'. this should allow for phones with small or near full system partition install stuff like busybox or your own pprograms. More usefull for a developer.
I wanna try this with pythonforandroid, if I can make python and its modules. accessible during early init or just before the boot process finishes in general, and use it to run python, maybe python can handle boot in a different way, or maybe just one specific. function you might needs.
one big question I have. Does the pythonforandroid interpreter run ontop of the D VM?
Edge-Case said:
I'm thinking that if I can get my mkbootimg tools to work, I would mod an init script to mount the apps.img and then create links for each file in say '/mnt/apps/bin' create a link*in '/system/bin'. this should allow for phones with small or near full system partition install stuff like busybox or your own pprograms. More usefull for a developer.
I wanna try this with pythonforandroid, if I can make python and its modules. accessible during early init or just before the boot process finishes in general, and use it to run python, maybe python can handle boot in a different way, or maybe just one specific. function you might needs.
one big question I have. Does the pythonforandroid interpreter run ontop of the D VM?
Click to expand...
Click to collapse
I don't think so. All command-line programs I know of interface directly with the kernel.
Sent from my S3 on Sense 5 (you jelly?)
CNexus said:
I don't think so. All command-line programs I know of interface directly with the kernel.
Sent from my S3 on Sense 5 (you jelly?)
Click to expand...
Click to collapse
So getting an extended set of Linux (kernel) cli programs working with Android (kernel) is a matter of having the nessissary libraries, kernel prereq., and being compiled for the target processor?
From what I have read, the Android kernel has been cut back so far from the original Linux kernel that its difficult to port "Linux apps" to Android. Something about a slimmed down version of the GNU C/C++ libraries and the Android kernel being designed to run mostly Dalvik.
I haven't tried directly running any "Linux app" (already compiled for arm) on Android yet, but my game plan for that test was to load up an .img file with the nessissary execs, libs, config, etc files (as ext3 this time) and running some scripts that get the paths variables set up and then execute the script, I wrote a short Bash script that sets up python variables and adds others to PATH etc, and it worked, I had python on the img and the img mounted to /mnt/myside and python ran but with some errors, I need to get the variables right, its driving me mad, if its not this its that, last time it was the basic "help()" command not being declaired or something.
Well thats my plan, either these "Linux apps" run on Android without problem or I am going to A) write my own kernel to be compatible with Android/ cli Linux or I am going to get as much source code as I can and practice the art of compiling against Android and/or patching the code when/where nessissary.
We'll see what happens, I've done enough today/night.
Hi,
I made a tutorial explaining how to compile the ouya's kernel from scratch.
I made this tutorial because I needed to enable the nfs protocol versions 3 and 4 to use file shares from my Synology NAS. The ouya's kernel enabled by default only comes with version 2 and i had problems to mount my NFS shares.
Let's start. my english is not very good then ignore the grammatical errors.
Let's first download the required files. I'm on the premise that you have an ubuntu linux installed on your machine.
*** DOWNLOAD OUYA FIRMWARE ***
1. Open your browser and type:
https://devs.ouya.tv/api/firmware_builds
2. Search for a string like this:
http://cds.t2z5c2q6.hwcdn.net/ota/RC-OUYA-1.2.1084-r1_ota.zip (this is the latest version of ouya firmware)
3. Download it:
$ wget http://cds.t2z5c2q6.hwcdn.net/ota/RC-OUYA-1.2.1084-r1_ota.zip
2. Create a directory an put the file there:
$ mkdir ouyafiles
4. unzip it:
$ unzip RC-OUYA-1.2.1084-r1_ota.zip
5. Now you have a lot of files and directories. We need only one. The name of file is: boot.img. We need to unzip this file to retrieve the ramdisk file that will be needed along with the compiled kernel. For this we need to download the following perl script:
$ wget http://www.enck.org/tools/split_bootimg_pl.txt
5. Rename the script and change the permissions to execute:
$ mv split_bootimg_pl.txt split_bootimg.pl
$ chmod 755 split_bootimg.pl
6. Run this command to unpack the file:
$ ./split_bootimg.pl boot.img
7. Now you have 2 files: boot.img-kernel and boot.img-ramdisk.gz. We only need the boot.img-ramdisk.gz. Lets unzip this again and rename the unzipped file:
$ gzip -dc ../boot.img-ramdisk.gz | cpio -i
$ mv boot.img-ramdisk ramdisk
8. OK. Now you have this file. We will use it later in the tutorial.
*** DOWNLOAD ANDROID NDK ***
1. Open the Browser and paste this URL: http://developer.android.com/tools/sdk/ndk/index.html
2. Download the Linux 64-bit (x86) package file:
$ wget http://dl.google.com/android/ndk/android-ndk-r9d-linux-x86_64.tar.bz2
3. Unzip it:
$ tar -jxvf android-ndk-r9d-linux-x86_64.tar.bz2
4. Rename the unzipped directory to "ndk":
$ mv android-ndk-r9d ndk
5. Load the environment variables:
$ export CROSS_COMPILE=/your_home_directory/ndk/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86_64/bin/arm-linux-androideabi-
$ export ARCH=arm
Obs.: (remember the /your_home_directory/ is the default home directory that you user in linux uses to work).
*** DOWNLOAD THE OUYA KERNEL SOURCE ***
1. Open your browser and go to this URL:
https://github.com/ouya/ouya_1_1-kernel
2. In the right side of the page you will have a download button called "Download ZIP". Click and Download it.
3. Unpack it and rename the unzipped directory to "kernel"
4. Maybe the /kernel/drivers/pci/Kconfig file will corrupt before unzip the file. Kconfig is a symbolic link. Remove it and Download again using the command inside the kernel/drivers/pci/ directory:
$ wget https://raw.githubusercontent.com/ouya/ouya_1_1-kernel/master/drivers/pci/Kconfig
6. Now you have the default ouya kernel for compile!
*** RECOVER .CONFIG FILE FROM OUYA ***
1. You need to retrieve a file that is in ouya. To retrieve the file you need install the package android-tools-adb. use the following command:
$ sudo apt-get install android-tools-adb
2. Now you have to connect your ouya via usb. By default your ouya don't enable adb. You need to go to DEVELOPMENT screen on your ouya and enable “ADB: ON”.
3. Fine. Now test if the adb is connecting. Try this commands:
$ adb start-server
$ adb devices (this will show something like this “1234567890ABCDEF device”)
PS.: if no devices appears... you need to search in the internet about “how to use adb to connect android devices”
4. Now you will pull the config file:
$ adb pull /proc/config.gz config.gz (this will pull config.gz to your computer)
5. Unzip it and copy to kernel directory:
$ gunzip config.gz
$ cp config /your_home_directory/kernel/.config
6. Now your kernel is ready to compile. We're ensuring that the standards are consistent settings. From now on it is your responsibility to enable and disable kernel configurations.
*** REBUILDING KERNEL ***
1. Go to Kernel Directory:
$ cd /your_home_directory/kernel/
2. Make sure to run the environment variables CROSS_COMPILE and ARCH described above in the tutorial.
$ export CROSS_COMPILE=/your_home_directory/ndk/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86_64/bin/arm-linux-androideabi-
$ export ARCH=arm
3. Use this command to change some settings:
$ make menuconfig
4. Use this command to build the kernel after you change your new settings:
$ make
5. Some warnings will display in your console... its normal.
6. if the process run ok you 'll have a bzImage file under the directory kernel/arch/arm/boot
7. copy this file to the same directory where you store the ramdisk file.
*** UPLOAD THE NEW KERNEL AND THE RAMDISK TO OUYA ***
1. You will need to install the fastboot on linux using this command:
$ apt-get install android-tools-fastboot
2. Now you have to reboot your device in bootloader mode:
$ adb reboot-bootloader
3. You can check if you devices enters in this mode using this command:
$ fastboot devices
4. If it works. You can upload your new kernel and the default ramdisk:
$ fastboot flash:raw boot ./zImage ./ramdisk
The system should now boot with your custom kernel installed!
*** DOWNLOAD OUYA FIRMWARE ***
$ mv boot.img-ramdisk ramdisk
Click to expand...
Click to collapse
Why do we need this? Can't we simply copy it from an existing OUYA machine?
ndk/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86_64/bin/arm-linux-androideabi-
Click to expand...
Click to collapse
The current android-ndk-r10e only has androideabi-4.8 and androideabi-4.9. Can I use them, too?
Edit: I got an error ("unknown CPU architecture") with android-ndk-r10e and arm-linux-androideabi-4.8 so I used android-ndk-r9d with arm-linux-androideabi-4.6, and that worked.
6. if the process run ok you 'll have a bzImage file
Click to expand...
Click to collapse
It's actually a zImage file (without the b).
Thank you so much for the tutorial!
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.