[ROM] [STOCK] + insecure boot image (adb root) + deodexed system

[ROM] [STOCK] + insecure boot image (adb root) + deodexed system - Nexus 10 Android Development

I would like to share a collection of factory images. It contains the full packages, also the extracted .img files. I also included insecure boot image (adb shell gives root access) and deodexed system image for each of them.
full image packages are "tgz" files.
image files extension is .img
isecure boot images are *.unsec.img
deodexed system images are *.deodex.img
These are all to be flashed with fastboot. These all derived from STOCK (https://developers.google.com/android/nexus/images) with no changes except the insecure adb boot image and the deodexed system image.
Deodexed fs is exactly the same size as the original when mounted.
The collection contains:
mantaray_4.2-jop40c
mantaray_4.2-jop40c-factory-0d641789.tgz size: 326396069
mantaray-jop40c
image-mantaray-jop40c.zip size: 328044861
boot.img size: 4716544
boot.img.unsec.img size: 4716544
bootloader-manta-mantalj12.img size: 1310720
cache.img size: 10617136
recovery.img size: 5228544
system.img size: 541540212
system.img.deodex.img size: 499677904
mantaray_4.2.2-jdq39
mantaray-jdq39-factory-d79f489e.tgz size: 328019721
mantaray-jdq39
image-mantaray-jdq39.zip size: 329787974
boot.img size: 4718592
boot.img.unsec.img size: 4718592
bootloader-manta-mantalj12.img size: 1310720
cache.img size: 10621244
recovery.img size: 5230592
system.img size: 535248732
system.img.deodex.img size: 496339676
userdata.img size: 140778452
The files can be downloaded from: http://web.djodjo.org/?a=download:android:ROM_images:factory_images_gn_mantaray
if it helps you buy me a beer

Related

[Q] Can't boot with custom Ramdisk (resolved)

I dumped my boot device which i believe is /dev/mtd/mtd2 according to /proc/mtd
#cat /dev/mtd/mtd2 > boot.img
I took that image and ran the split_bootimg perl script on it to separate the kernel and ramdisk images.
#split_bootimg boot.img
Then I just tried to recombine them with mkbootimg without making any modifications.
#mkbootimg --cmdline 'no_console_suspend=1 console=null' --kernel boot.img-kernel --ramdisk ramdisk-new.gz -o boot-new.img
* I also tried an image with identical boot options as I found the stock kernel has
I then copied and erased/flashed the new image
#cat /dev/zero > /dev/mtd/mtd2
#flash_image boot boot-new.img
The phone just sits at the HTC screen forever when I try and boot it.
If I reboot into recovery and flash the original "boot.img" backup using the same method it boots OK.
What is it I'm missing? thanks!

I tried dumping the new base.img I made
Original from ROM for comparison:
Page size: 2048 (0x00000800)
Kernel size: 2271684 (0x0022a9c4)
Ramdisk size: 167343 (0x00028daf)
Second size: 0 (0x00000000)
Board name:
Command line: no_console_suspend=1
Repacked:
Page size: 2048 (0x00000800)
Kernel size: 2271684 (0x0022a9c4)
Ramdisk size: 167343 (0x00028daf)
Second size: 0 (0x00000000)
Board name:
Command line: no_console_suspend=1
I also downloaded the kernel source for the incredible and tried to find the base address and used 0x10000000 on the mkbootimg command no to avail.
I did notice new image is smaller than the old by ~1MB! Even though when I unpack it still shows them as the same size.
3145728 boot.img
2443264 newboot.img
Any help here is very appreciated.

I found the solution. I was using the wrong base address on mkbootimg command
I found the proper base address by downloading the kernel source for the droid incredible.
(DROID Incredible by HTC (Verizon) – GB MR - 2.6.35 kernel source code)
Then I looked up the processor used in the incredible hardware in the file referenced below and got the proper offset. It's boot up now
arch\arm\mach-msm\include\mach\memory.h

[DEV][HOWTO] Extracting stock firmware files from .tot files

Hello everyone!
First off:
DISCLAIMER: I AM NOT RESPONSIBLE FOR ANYTHING YOU DO TO YOUR PHONE WHILE USING ANY OF THE INFORMATION LOCATED BELOW. IF YOU DO NOT UNDERSTAND WHAT IS BEING DONE, PLEASE DO NOT TRY ANYTHING DONE HERE!
This is still in a VERY basic phase. I am not sure how helpful it will be, but currently, I have been able to extract some of the smaller partitions from the AT&T firmware file.
Starting off, when LGNPST is used to image a phone, it creates a log file in C:\LG Electronics\LGNPST\Models\LOG\ For example, mine was called LS970Log_COM5.log. We are really only interested in one part of this file, located close to the bottom when the phone is actually being imaged. It should look something like this:
0Download mode locking
0Download : PrimaryGPT 0x 0 Size: 0x 512Kb, File Offset: 0x 100000
0 3.182994E-313mmc Init
0Partition Count : 35======================================================
0======================================================
0Download : modem 0x 800000 Size: 0x 54272Kb, File Offset: 0x 180000
0Download : sbl1 0x4800000 Size: 0x 512Kb, File Offset: 0x3680000
0Download : sbl2 0x4880000 Size: 0x 512Kb, File Offset: 0x3700000
0Download : sbl3 0x4900000 Size: 0x 1024Kb, File Offset: 0x3780000
0Download : aboot 0x4b00000 Size: 0x 512Kb, File Offset: 0x3880000
0Download : rpm 0x4b80000 Size: 0x 512Kb, File Offset: 0x3900000
0Download : boot 0x5000000 Size: 0x 7168Kb, File Offset: 0x3980000
0Download : tz 0x6800000 Size: 0x 512Kb, File Offset: 0x4080000
0(null)kip misc Partition
0Download : system 0xb000000 Size: 0x 131072Kb, File Offset: 0x4900000
0Download : system 0x13000000 Size: 0x 512Kb, File Offset: 0xc900000
0Download : system 0x1325e000 Size: 0x 129024Kb, File Offset: 0xc980000
0Download : system 0x1b1fd000 Size: 0x 129536Kb, File Offset: 0x14780000
0Download : system 0x2325e000 Size: 0x 129024Kb, File Offset: 0x1c600000
0Download : system 0x2b1fd000 Size: 0x 129536Kb, File Offset: 0x24400000
0Download : system 0x3325e000 Size: 0x 129024Kb, File Offset: 0x2c280000
0Download : system 0x3b1fd000 Size: 0x 129536Kb, File Offset: 0x34080000
0Download : system 0x4325e000 Size: 0x 129024Kb, File Offset: 0x3bf00000
0Download : system 0x4b1fd000 Size: 0x 76800Kb, File Offset: 0x43d00000
0Download : system 0x53000000 Size: 0x 512Kb, File Offset: 0x48800000
0Download : system 0x5b000000 Size: 0x 512Kb, File Offset: 0x48880000
0Download : system 0x63000000 Size: 0x 512Kb, File Offset: 0x48900000
0Download : persist 0x7a800000 Size: 0x 4608Kb, File Offset: 0x48980000
0Download : recovery 0x8b000000 Size: 0x 8192Kb, File Offset: 0x48e00000
0Download : BackupGPT 0xab380000 Size: 0x 512Kb, File Offset: 0x49600000
0
*********************************************************************************************
Click to expand...
Click to collapse
What do we see that is important here? Image sizes and offsets for data in the file! For example, lets take the boot partition.
0Download : boot 0x5000000 Size: 0x 7168Kb, File Offset: 0x3980000
Click to expand...
Click to collapse
We have a offset of 0x3980000 and a size of 7168Kb. That converts to an equivalent of an offset of 60293120 bytes and a size of 7340032 bytes (I really hope I got that right. As I'm sitting here writing this, I'm thinking of how many different ways I could have messed up that calculation...)
Here, I am using dd on linux in order to separate the partitions from the binary file, but it can be done using equivalent tools on windows.
$ dd bs=1 skip=60293120 count=7340032 if=LGE970AT-00-V10o-ATT-US-SEP-29-2012+0.tot of=boot.img
Click to expand...
Click to collapse
Basically, what I am doing here is copying 7340032 bytes, starting at byte 60293120, from the .tot file to boot.img.
Now, lets check out the backups made with FreeGee when you unlock, to see if it matches with what was actually written to the phone. In order to see if they are equal, we need to trim the backup, because the backup that is taken is actually of the entire partition, not just the actual data.
$ dd bs=1 count=7340032 if=boot-att-backup.img of=boot-att-backup-trimmed.img
Click to expand...
Click to collapse
This is doing basically the same, starting at the first byte, copying 7340032 bytes to boot-att-backup-trimmed.img. This is just making sure you only get the same amount of data that was written.
Now, If of course we want to see if the data is actually the same, so we will also use the diff command, also found on linux, and I'm sure is also available on windows.
$ diff -s boot.img boot-att-backup-trimmed.img
Click to expand...
Click to collapse
If both files are identical, which means everything was done correctly, this should result in the output "Files boot.img and boot-att-backup-trimmed.img are identical", which it does! (The -s flag makes diff report identical files.)
So, now that we know that we can successfully extract the boot partition, I also tried this with the aboot partition, and it worked as well! I have not had success extracting the system partition yet, as it is split up into several partitions. I was hoping that someone with more knowledge could piece together a system image. Enjoy

SnowLeopardJB said:
Hello everyone!
First off:
DISCLAIMER: I AM NOT RESPONSIBLE FOR ANYTHING YOU DO TO YOUR PHONE WHILE USING ANY OF THE INFORMATION LOCATED BELOW. IF YOU DO NOT UNDERSTAND WHAT IS BEING DONE, PLEASE DO NOT TRY ANYTHING DONE HERE!
This is still in a VERY basic phase. I am not sure how helpful it will be, but currently, I have been able to extract some of the smaller partitions from the AT&T firmware file.
Starting off, when LGNPST is used to image a phone, it creates a log file in C:\LG Electronics\LGNPST\Models\LOG\ For example, mine was called LS970Log_COM5.log. We are really only interested in one part of this file, located close to the bottom when the phone is actually being imaged. It should look something like this:
What do we see that is important here? Image sizes and offsets for data in the file! For example, lets take the boot partition.
We have a offset of 0x3980000 and a size of 7168Kb. That converts to an equivalent of an offset of 60293120 bytes and a size of 7340032 bytes (I really hope I got that right. As I'm sitting here writing this, I'm thinking of how many different ways I could have messed up that calculation...)
Here, I am using dd on linux in order to separate the partitions from the binary file, but it can be done using equivalent tools on windows.
Basically, what I am doing here is copying 7340032 bytes, starting at byte 60293120, from the .tot file to boot.img.
Now, lets check out the backups made with FreeGee when you unlock, to see if it matches with what was actually written to the phone. In order to see if they are equal, we need to trim the backup, because the backup that is taken is actually of the entire partition, not just the actual data.
This is doing basically the same, starting at the first byte, copying 7340032 bytes to boot-att-backup-trimmed.img. This is just making sure you only get the same amount of data that was written.
Now, If of course we want to see if the data is actually the same, so we will also use the diff command, also found on linux, and I'm sure is also available on windows.
If both files are identical, which means everything was done correctly, this should result in the output "Files boot.img and boot-att-backup-trimmed.img are identical", which it does! (The -s flag makes diff report identical files.)
So, now that we know that we can successfully extract the boot partition, I also tried this with the aboot partition, and it worked as well! I have not had success extracting the system partition yet, as it is split up into several partitions. I was hoping that someone with more knowledge could piece together a system image. Enjoy
Click to expand...
Click to collapse
would it be possible to guide me through this from the very beginning? i want to start cooking for this device, but i need a legit flashable Rom. Please and Thank you.

You are most likely better off just pulling a system image off your device. So, if you are rooted, you can pull your system with something like this:
# busybox tar cf /sdcard/system.tar /system/*
Click to expand...
Click to collapse
That should give you all of the system files all together in a tar archive on your internal sdcard.

I messaged you, but is there any way to use this on the Sprint version to create a flashable .zip?

sorry about the resurrection,
but has there been any progress made on this? More of a curiosity, then anything.
Thanks