[Q] [kitchen][help me!!]cant build a new boot.img - Samsung Galaxy Nexus

Found BOOT-EXTRACTED folder, checking contents ...
Found boot.img-ramdisk
Found zImage
Working folder found
od: boot.img: No such file or directory
Compiling mkbootfs ...
Error: mkbootfs not successfully compiled!
Press Enter to continue
how to solve it ??

push

Related

Android Kitchen not working properly on Fedora 16 x64 [Solved]

Has anyone been able to get the android kitchen to actually work on Fedora 16 and if so, how?
The reason I ask is because it does start and it does find the system.img and boot.img but its complaining during the working folder set up. See below:
Code:
Creating working folder WORKING_112911_011054 ...
Copying boot.img ...
Copying system.img ...
Adding an update-script ...
Chunk size is 2048 bytes in system.img
Spare size calculated to be 64 bytes
Compiling unyaffs ...
In file included from /usr/include/features.h:387:0,
from /usr/include/sys/types.h:26,
from unyaffs.c:10:
/usr/include/gnu/stubs.h:9:27: fatal error: gnu/stubs-64.h: No such file or directory
compilation terminated.
Error: unyaffs not successfully compiled!
Never mind. I fixed it already.
So I'll share. If you run into that error just open up a new terminal and type:
Code:
su -
yum install glibc-devel.x86_64 --disablerepo=adobe\*
Simple enough, lol
sir
wildstang83 said:
Never mind. I fixed it already.
So I'll share. If you run into that error just open up a new terminal and type:
Code:
su -
yum install glibc-devel.x86_64 --disablerepo=adobe\*
Simple enough, lol
Click to expand...
Click to collapse
do you know how to add device in android kitchen?

[dev]How to Un/Re/Pack a Boot.blob and unyaff a boot.img

Technically i have to give credit to scott crossler
www.scottsroms.com
for showing me the method
and then i came upon turges
faq
Thanks Turge and Scott and whomever created these blobpacktools
but since i keep getting pms
and im sure you do to
scott
Here are the steps for repacking the boot.img. Some involve running the commands via cygwin, others involve running them via the Windows Command Prompt.
The instructions for installing cygwin, extracting and repacking the boot.img were found here: http://www.freeyourandroid.com/guide...ot-img-windows
Once you have setup cygwin, extract the attached files in a folder under your "home" folder in cygwin.
Also unzip blob tools into the same folder as your boot.blob
1.
Code:
copy boot.blob to the same folder and run the following via
the Windows Command Prompt to extract the boot.img from the boot.blob:
BlobUnpack.exe boot.blob
ren boot.blob.LNX boot.img
which will create boot.img
2.
Code:
From the cygwin bash terminal window,
switch to the same folder and run the following
to extract the ramdisk from the boot.img:
./extractboot boot.img
You now have an out/ramdisk folder
that contains the files you want to edit.
3.
Code:
Once done, repack the ramdisk and kernel into boot_new.img
with the following command (via cygwin once again):
./packboot
4.
Code:
then from the Command Prompt repack boot_new.img
into boot2.blob using the following:
blobpack -s boot2.blob LNX boot_new.img
5.
Code:
You can now flash the boot.blob to the staging
partition via a command in updater-script:
Code:
package_extract_file("/boot.blob", "/dev/block/mmcblk0p4");
or by using adb while in recovery/android:
Code:
dd if=/sdcard/boot2.blob of=/dev/block/mmcblk0p4
Lastly the rundown is like this
if you want to take a ota blob
and extract the contents for a raw base
and a raw kernel
1
take the ota and extract the blob file and place
in your folder with blobtools
2. then run
Code:
blobunpack.exe blob
Which now creates
Blob.APP =System.img (can be renamed system.img and unyaffed in the kitchen)or straight cygwin
Blob.sos=Recovery Img
Blob.Ebt=Bootloader information
Blob.Lnx=kernel (can also just be renamed boot.img and unyaffed in kitchen)
Blob.pt=Partition info
so to repack lets say your custom remade image
and your custom kernel
and a recovery of your choice
run
Code:
blobpack.exe -s blob lnx boot.img sos twrp.blob app system.img
then simply take the blob replace in the ota file
and flash in recovery
and it should flash a rom packed as a blob
Hi!
...also you can flash the new boot.blob via fastboot mode
>fastboot-i 0x0B05 flash boot boot.blob
:good:
Call me stupid, but what does repacking the boot.img do? I never pm'ed you, but what would we gain from this. a lil lost
unpacking a boot.img allows you to take a stock already built kernel
and make specific changes to the ramdisk
more specifically
default.prop
can make kernel insecure
debuggable
bootanimation enabled
blah blah blah
and init.rc
but also
cardhu
and goldfish.rc
and init.trace
and init.usb
then repacked and good to flash
seanzscreams said:
Lastly the rundown is like this
if you want to take a ota blob
and extract the contents for a raw base
and a raw kernel
1
take the ota and extract the blob file and place
in your folder with blobtools
2. then run
Code:
blobunpack.exe blob
Which now creates
Blob.APP =System.img (can be renamed system.img and unyaffed in the kitchen)or straight cygwin
Blob.sos=Recovery Img
Blob.Ebt=Bootloader information
Blob.Lnx=kernel (can also just be renamed boot.img and unyaffed in kitchen)
Blob.pt=Partition info
so to repack lets say your custom remade image
and your custom kernel
and a recovery of your choice
run
Code:
blobpack.exe -s blob lnx boot.img sos twrp.blob app system.img
then simply take the blob replace in the ota file
and flash in recovery
and it should flash a rom packed as a blob
Click to expand...
Click to collapse
Hi!
For a linux (Ubuntu) machine you can easily unpack blob.APP
> sudo mkdir mnt
> sudo mount -o loop blob.APP mnt
- now in your mnt directory , you will have /system ! :good:
Hi,
My TF300tl can't unlock bootloader. so can I use this way to pack custom ROM ( cm11, liplop...) as official ROM to flash for my tablet ?
konnichiwa said:
Hi,
My TF300tl can't unlock bootloader. so can I use this way to pack custom ROM ( cm11, liplop...) as official ROM to flash for my tablet ?
Click to expand...
Click to collapse
I wouldn't think so, as the ROM would have to be signed to be official

[Q][KERNEL] Not able to unpack some boot.img

The tool I use is KITCHEN for unpacking boot.img
Yesterday i encountered a problem while unpacking boot.img file
Code:
Press Enter to continue
Kernel found at offset 131072 in boot.img
Setting offset=131072 in mkbootimg.c, line 76
Setting offset=131072 in mkbootimg.c, line 109
Setting offset=131072 in extract-kernel.pl, line 23
Setting offset=131072 in extract-ramdisk.pl, line 23
Extracting kernel ...
Extracting ramdisk ...
Error: No ramdisk folder found!
Contents of bootimg_050313_133308:
total 3340
-rw-r--r-- 1 user None 3419532 May 3 13:33 zImage
Press Enter to continue
Got an error. Showing No ramdisk folder found. Is there any other way to unpack such boot.img??
Tried a lot searching on Google about this but didnt find any solution.
Someone who play with kernels everyday help me out please
Anyone??
Does anyone know about lzma compression? I guess such boot.img are compressed using lzma algorithm. How to unpack and re-pack such boot.img?
Plz someone help
Sent from my LT18i using xda app-developers app
Have you tried another method?
XperienceD said:
Have you tried another method?
Click to expand...
Click to collapse
Yep i did. Now able to unpack and re-pack lzma compressed boot.img files
For extracting boot.img-ramdisk.gz (LZMA compressed only) should type
Code:
lzma -dc ../boot.img-ramdisk.gz | cpio -i
All the Credit goes the original Dev.:good:
Reference used : http://forum.xda-developers.com/showthread.php?t=1659584&highlight=lzma
rohan170890 said:
Yep i did. Now able to unpack and re-pack lzma compressed boot.img files
For extracting boot.img-ramdisk.gz (LZMA compressed only) should type
Code:
lzma -dc ../boot.img-ramdisk.gz | cpio -i
All the Credit goes the original Dev.:good:
Reference used : http://forum.xda-developers.com/showthread.php?t=1659584&highlight=lzma
Click to expand...
Click to collapse
helo bro .. i am facing the same prblm like ramdisk folder not found while unpacking boot.img ... will u plzz help me to unpack it
here is the boot.img file http://www.mediafire.com/download/781fb7713efj719/boot.img

[Q] Issues with Signing Android Factory Images, ROMs and OTA Files.

I am doing R&D on FOTA(Firmware Update Over the Air) using Nexus 7-Wifi(grouper). For which I followed the following steps.
1. Downloaded the android source from source.android.com for v 4.2.2_r1 and v 4.3_r1
2. Downloaded the binaries for grouper, extract it to my source folder.
3. Then I compiled the source code using following commands.
i. source build/envsetup.sh
ii. lunch full_grouper-userdebug
iii. make -j8 dist
4. After few tries, I had success in compiling the source for Nexus 7(grouper).
5. I got following files in $out/source_4.2.2/dist folder
-----------------------------------------------
adb*
android-common-carousel.jar
android-common.jar
android-info.txt
android-support-v13.jar
android-support-v4.jar
android-support-v7-gridlayout.jar
build.prop
com.android.nfc_extras.jar
fastboot*
full_grouper-apps-eng.root.zip
full_grouper-emulator-eng.root.zip
full_grouper-img-eng.root.zip
full_grouper-ota-eng.root.zip
full_grouper-symbols-eng.root.zip
full_grouper-target_files-eng.root.zip
gpl_source.tgz
guava.jar
installed-files.txt
jsr305.jar
mkbootfs*
mkbootimg*
mkyaffs2image*
mp4parser.jar
package-stats.txt
ramdisk.img
signapk.jar
vendor_owner_info.txt
-----------------------------------------------
6. Then I generated my own keys using /development/tools/make_key tool for media, testkey, releasekey, shared, platform.
Assume my keys are locate at /keys folder.
7. Then I created a signed target zip file using following command.
/source/build/tools/releasetools/sign_target_files_apks -v -p ../host/linux-x86 -d /keys full_grouper-target_files-eng.root.zip signed_target_files.zip
8. From signed target zip file I create
/source/build/tools/releasetools/img_from_target_files -v -p ../host/linux-x86 signed_target_files.zip signed_img_from_target_files.zip
9. Then I flashed the signed_img_from_target_files.zip using fastboot command using the following script:
----------------------------------------------------------------------
fastboot oem unlock
fastboot erase boot
fastboot erase cache
fastboot erase recovery
fastboot erase system
fastboot erase userdata
fastboot reboot-bootloader
sleep 10
fastboot -w update signed_img_from_target_files.zip
----------------------------------------------------------------------
10. The device gets flashed well and is working, but I am getting an log while flashing in which it is unable to find boot.sig, system.sig and recovery.sig
11. Now the otacerts.zip file contains a testkey which is not the one that I signed it with.
file located at "/system/etc/security/otacerts.zip" on device.
12. Now since the otacerts.zip is signed with the default key it gives a mismatch error which I tried to flash an OTA update which is signed by the my custom key.
Now my doubt is:
How can I add boot.sig, recovery.sig and system.sig to signed_img_from_target_files.zip?
Is there anything I am doing wrong?
Does the recovery checks the current ROM keys from "/system/etc/security/otacerts.zip"?
What is the correct procedure to sign the OTA update?
i am posting this reply just for people who are looking for help too,
you need to explicitly define "BUILD_SECURE := true" in your device make file so that android/build/core/Makefile will use device/*/$(TARGET_DEVICE)/releasekey.x509.pem for OTA_PUBLIC_KEYS

Setting up a self-signed (restrictive) recovery for self-signed ROMs

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.

Categories

Resources