Hi,
when I still hadn't the device, I wanted to know exactly what's included in stock ROMs to have a better idea of what to expect. I hence downloaded a stock firmare and the stock system.img (see below for the steps).
Ok, so what? Well, when KK was released I decided to do the same (I was still waiting for the device), but I couldn't. Unlike before, I didn't find a single system.img, but multiple files (3 to be exact, maybe it's too big to be flashed at once with fastboot, I don't know, I'm new to this) and couldn't understand how the original image was splitted to generate those files.
Did anyone see something similar already and sucesfully merged splitted filesystems?
I know I could simply ask for a system dump (or wait for KK), but now I'm curious to know on how to do this. I tried few things but I couldn't find any way to do it. Maybe I could see how fastboot treat these files, but I wonder if anyone already knows the answer.
Anyway, here the steps to mount the system.img of our stock JB firmwares. Maybe there's an easier way, I honestly don't know. As far as I know, converting the sparge image should be enough, but I had to do more:
Code:
#Convert sparse image with simg2img
simg2img system.img system.img.raw.tmp
#UTF8 may slow down grep, switch to C
export LANG=C
#Look for the ext4 magic and calculate its position
magic=`grep -aobP -m1 '\x53\xEF' system.img.raw.tmp | head -1 | cut -d":" -f1`
offset=$(($magic-1080))
#Remove extra header with dd
dd if=system.img.raw.tmp of=system.img.raw ibs=$offset skip=1
#Remove temp file
rm system.img.raw.tmp
Now you can mount system.img.raw as a normal ext4 filesystem.
Just concatenate the three chunks together like so:
Code:
cat system.img_sparsechunk1 system.img_sparsechunk2 system.img_sparsechunk3 > system.img
Then apply the steps from the OP and voilà!
Edit: Scratch that: the image is accessible, some files are visible but others are missing. To be continued...
Darkshado said:
Just concatenate the three chunks together like so:
Code:
cat system.img_sparsechunk1 system.img_sparsechunk2 system.img_sparsechunk3 > system.img
Then apply the steps from the OP and voilà!
Edit: Scratch that: the image is accessible, some files are visible but others are missing. To be continued...
Click to expand...
Click to collapse
As you have found that doesn't work, remember that each file will have metadata headers so that may be one reason you can't just cat them together.
To OP - can't you just mount each img as a filesystem and copy all the files from each mounted filesystem to another entirely separate directory. At least that way you have all the files in one place, eg copy
/sparsechunk1/system/file1 to /newdir/system/file1
And so on.
scott_doyland said:
As you have found that doesn't work, remember that each file will have metadata headers so that may be one reason you can't just cat them together.
To OP - can't you just mount each img as a filesystem and copy all the files from each mounted filesystem to another entirely separate directory. At least that way you have all the files in one place, eg copy
/sparsechunk1/system/file1 to /newdir/system/file1
And so on.
Click to expand...
Click to collapse
Only the first chunk can be mounted, the other two are not recognized as filesystem and there's no way to mount them.
It's not as if /system was divided in three parts and then an image for each one was created, so that you can treat them as separate files (what you said would work in this case).
One image is created and then it's splitted in three in some unknown way. The first image is the one that holds the informations to access the files, the other two just pieces of files that can't be accessed without the informations in the first chunk.
mfastboot knows how to correctly copy the data from the separate images with the right offsets inside the phone so that in the end all the files can be accessed. Concatenating the files using dd using the correct offsets could maybe work, but after a few attempts I gave up.
There is method to extract files under Windows
Al936 said:
There is method to extract files under Windows
Click to expand...
Click to collapse
Any change you happen to be willing to share the contents of or principles behind `sparse2img.exe`?
HolySid said:
Any change you happen to be willing to share the contents of or principles behind `sparse2img.exe`?
Click to expand...
Click to collapse
What kind of principles you expect from me? I just posted the link to one of the method to extract all files and folders from stock firmware's system partition. The tools were not developed by me - I just informed XDA community about it. As you can see from the tread several persons already confirmed that it works.
Al936 said:
What kind of principles you expect from me? I just posted the link to one of the method to extract all files and folders from stock firmware's system partition. The tools were not developed by me - I just informed XDA community about it. As you can see from the tread several persons already confirmed that it works.
Click to expand...
Click to collapse
Oh, I'm sorry, I thought it was your work. I just want to know how to merge the system files. I know the exe is working, but I'm running Linux, so my question it is both out of curiosity and simply because I cannot run the code.
Try running it with wine or in virtual machine.
sent via tapatalk
Thanks, I managed it by using another laptop. But still, I'd rather know what happened
Sent from my XT1032 using xda app-developers app
Darkshado said:
Just concatenate the three chunks together like so:
Code:
cat system.img_sparsechunk1 system.img_sparsechunk2 system.img_sparsechunk3 > system.img
Then apply the steps from the OP and voilà!
Edit: Scratch that: the image is accessible, some files are visible but others are missing. To be continued...
Click to expand...
Click to collapse
I just replaced the first line in the OP's instructions with this to join the system.img_sparsechunk files:
Code:
simg2img system.img_sparsechunk.* system.img.raw.tmp
And then the rest worked fine. Here were the exact steps I took (I shortened it a tiny bit, but it's the same concept):
Code:
simg2img system.img_sparsechunk.* system.img.raw.tmp
offset=`LANG=C grep -aobP -m1 '\x53\xEF' system.img.raw.tmp | head -1 | awk '{print $1 - 1080}'`
dd if=system.img.raw.tmp of=system.img.raw ibs=$offset skip=1
sudo mkdir /mnt/system
sudo mount system.img.raw /mnt/system
SenorChang said:
I just replaced the first line in the OP's instructions with this to join the system.img_sparsechunk files:
Code:
simg2img system.img_sparsechunk.* system.img.raw.tmp
And then the rest worked fine. Here were the exact steps I took (I shortened it a tiny bit, but it's the same concept):
Code:
simg2img system.img_sparsechunk.* system.img.raw.tmp
offset=`LANG=C grep -aobP -m1 '\x53\xEF' system.img.raw.tmp | head -1 | awk '{print $1 - 1080}'`
dd if=system.img.raw.tmp of=system.img.raw ibs=$offset skip=1
sudo mkdir /mnt/system
sudo mount system.img.raw /mnt/system
Click to expand...
Click to collapse
It worked. Thank you!
Related
Several people have already figured out the details on their own, but I have gotten requests to do a more comprehensive tutorial on how the boot and recovery images are structured, and how you can edit them.
Background
Your phone has several devices which hold different parts of the filesystem:
Code:
#cat /proc/mtd
dev: size erasesize name
mtd0: 00040000 00020000 "misc"
mtd1: 00500000 00020000 "recovery"
mtd2: 00280000 00020000 "boot"
mtd3: 04380000 00020000 "system"
mtd4: 04380000 00020000 "cache"
mtd5: 04ac0000 00020000 "userdata"
In this tutorial, we will deal with "recovery" and "boot". The "boot" device holds the files that are automatically loaded onto the root of your filesystem every time you boot (details below).
"system" holds everything that gets mounted in your system/ directory, and userdata/ is everything that shows up in data/ (this is all the apps you've installed, your preferences, etc).
The recovery and boot partitions are at /dev/mtd/mtd1 and /dev/mtd/mtd2, and before you do anything else you should back these up (note: this may not be the best way of doing this because it may not deal properly with bad blocks etc, but it's all we've got until somebody comes up with a better method, and besides you will probably be restoring from update.zip anyway):
Code:
# cat /dev/mtd/mtd1 > /sdcard/mtd1.img
# cat /dev/mtd/mtd2 > /sdcard/mtd2.img
The other thing you should do is put your favorite update.zip file into the root directory of your sd card so that if you screw up your boot partition you can boot into recovery mode and re-apply the update. You probably want one of the pre-rooted recovery images found elsewhere on the forums.
There is also another important file you should know about. In /system/recovery.img there is a full copy of everything that is loaded on mtd1. This file is automatically flashed onto mtd1 every time you shut down. That means two things: 1. Any changes you make directly to /dev/mtd/mtd1 get blown away on reboot and 2. If you want to change /dev/mtd/mtd1 you're probably better off just sticking the image in /system/recovery.img and rebooting. When creating your own custom update.zip files (especially when adapting the stock images), you can get tripped up if you forget to replace /system/recovery.img and it ends up overwriting /dev/mtd/mtd1 unbeknownst to you. Watch out.
Structure of boot and recovery images
The boot and recovery images are not proper filesystems. Instead, they are a custom android format consisting of a 2k header, followed by a gzipped kernel, followed by a ramdisk, followed by a second stage loader (optional, we have not seen these in the wild yet). This structure is outlined in mkbootimg.h:
Code:
+-----------------+
| boot header | 1 page
+-----------------+
| kernel | n pages
+-----------------+
| ramdisk | m pages
+-----------------+
| second stage | o pages
+-----------------+
n = (kernel_size + page_size - 1) / page_size
m = (ramdisk_size + page_size - 1) / page_size
o = (second_size + page_size - 1) / page_size
0. all entities are page_size aligned in flash
1. kernel and ramdisk are required (size != 0)
2. second is optional (second_size == 0 -> no second)
A ramdisk is basically a small filesystem containing the core files needed to initialize the system. It includes the critical init process, as well as init.rc, which is where you can set many system-wide properties. If you really want to know more about it, here is the documentation. Here's a list of files on a typical ramdisk:
Code:
./init.trout.rc
./default.prop
./proc
./dev
./init.rc
./init
./sys
./init.goldfish.rc
./sbin
./sbin/adbd
./system
./data
The recovery image typically has a few extra files, which constitute the recovery binary and supporting files (the application that gets run if you hold down home+power when rebooting). These files are:
Code:
./res
./res/images
./res/images/progress_bar_empty_left_round.bmp
./res/images/icon_firmware_install.bmp
./res/images/indeterminate3.bmp
./res/images/progress_bar_fill.bmp
./res/images/progress_bar_left_round.bmp
./res/images/icon_error.bmp
./res/images/indeterminate1.bmp
./res/images/progress_bar_empty_right_round.bmp
./res/images/icon_firmware_error.bmp
./res/images/progress_bar_right_round.bmp
./res/images/indeterminate4.bmp
./res/images/indeterminate5.bmp
./res/images/indeterminate6.bmp
./res/images/progress_bar_empty.bmp
./res/images/indeterminate2.bmp
./res/images/icon_unpacking.bmp
./res/images/icon_installing.bmp
./sbin/recovery
Unpacking, Editing, and Re-Packing the images
Note: below I give you the details for unpacking and repacking manually, but I have attached two perl scripts that do most of this for you
If you are good with a hex editor, you can open up any of these images and strip off the first 2k of data. Then, look for a bunch of zeroes followed by the hex 1F 8B (which is the magic number of a gzip file). Copy everything from the first line of the file, through the zeroes, and stopping at the 1F 8B. That is the kernel. Everything from the 1F 8B through the end is the ramdisk. You could save each of these files separately. In order to see the contents of the ramdisk, you need to un-gzip it and then un-cpio it. You could use a command like this (ideally after creating a new directory and cd'ing into it):
Code:
gunzip -c ../your-ramdisk-file | cpio -i
That will place all of the files from the ramdisk in your working directory. You can now edit them.
In order to re-create the ramdisk, you need to re-cpio them and re-gzip those files, with a command like the following (remember, cpio will include everything in the current working directory, so you probably want to remove any other cruft you might have in there):
Code:
find . | cpio -o -H newc | gzip > ../newramdisk.cpio.gz
The final step is to combine the kernel and your new ramdisk into the full image, using the mkbootimg program (which you should download and compile from the git repository):
Code:
mkbootimg --cmdline 'no_console_suspend=1 console=null' --kernel your-kernel-file --ramdisk newramdisk.cpio.gz -o mynewimage.img
Now, there's a lot of hassle in pulling apart files in hex editors and remembering all of these commands, so I wrote unpack and repack perl scripts for you (attached). Hooray.
Flashing your new image back onto the phone
You will probably only ever be flashing boot images directly to the phone, given the fact that /system/recovery.img automatically flashes the recovery device for you (as noted above). If you have created a new recovery image, just stick it in /system/recovery.img and reboot. If you are flashing a boot image, stick it on your phone via adb (a tool included in the Android SDK):
Code:
adb push ./mynewimage.img /sdcard
Then, open a shell to your phone via 'adb shell', get root, and do the following two commands to flash your new boot image:
Code:
# cat /dev/zero >> /dev/mtd/mtd2
write: No space left on device [this is ok, you can ignore]
# flash_image boot /sdcard/mynewimage.img
Reboot.
If your phone starts all the way up, congratulations. If not, you did something wrong and you'll need to boot into recovery mode and apply your update.zip file (reboot while holding down home+power, when you get the recovery screen press alt+L and then alt+S).
Something fun to do with your new found power
If you place a file titled initlogo.rle in the root directory of your boot image, the phone will display this image upon boot (after the "G1" image and before the Android animation). In order to create this file, you need to create a 320x480 image in Photoshop or Gimp and save it as a "raw image" file. You then need to compress that image with the program to565. More details on that here.
This is not the same thing as applying an update.zip
You will see other places on the forums that describe how to create customized update.zip files, as well as update.zip files that people are sharing. For example, there is a recent update.zip which is a modified version of rc30 (with the anti-root aspects disabled). The update.zip files include new boot images, recovery images, and typically replacements for the entire system/ directory as well as other updates. If you are creating a custom boot or recovery image, it is typically a good idea to start with the image distributed with the most recent update you have applied (flashing an image from an older release could have unintended consequences).
Questions?
hooray! you're awesome
Where does boot.img flash? What is the corresponding part of the system?
Dimath said:
Where does boot.img flash? What is the corresponding part of the system?
Click to expand...
Click to collapse
I'm not sure what exactly you mean, but when you do flash_image boot imagefile.img it will write imagefile.img to /dev/mtd/mtd2, which is where your phone looks for the boot files. Did that answer your question?
For your command...
Code:
cat /dev/zero >> /dev/mtd/mtd2
Do you mean
Code:
cat /dev/zero > /dev/mtd/mtd2
?
The idea being that you erase flash in the version with one '>', whereas you... append to the end of a device in the version with two '>'s? I can see the utility of erasing flash with one '>' but appending seems... odd. Am I missing something?
Is this any different than using the Dalvik Debug Monitor (DDMS) file manager found the the Android SDK? I'm able to push, pull, and delete files on my G1 with no problem.
Would this be the only way to rebuild a system app (i.e. Settings.apk) with more debug (Log. to extract via adb logcat over usb), then rebuild the entire system.img, then flash into the G1?
eckzow said:
For your command...
Code:
cat /dev/zero >> /dev/mtd/mtd2
Do you mean
Code:
cat /dev/zero > /dev/mtd/mtd2
?
The idea being that you erase flash in the version with one '>', whereas you... append to the end of a device in the version with two '>'s? I can see the utility of erasing flash with one '>' but appending seems... odd. Am I missing something?
Click to expand...
Click to collapse
I think you're right. I copied that from somebody else's instructions and it certainly seems to make more sense with one '>'. Anybody know for sure?
In any event, this is unnecessary in most cases because flash_image should overwrite the whole thing. The only exception is when you have an identical header on your image to the one that is already on the device. This shouldn't happen in my instructions (mkbootimg creates a header that includes the build timestamp) but I kept the instruction there just for good measure.
andonnguyen said:
Is this any different than using the Dalvik Debug Monitor (DDMS) file manager found the the Android SDK? I'm able to push, pull, and delete files on my G1 with no problem.
Click to expand...
Click to collapse
The adb push command I gave is no different, but you would still have to unpack/repack and flash_image according to my instructions.
I've tried these instructions on RC30 1.3. Basically I extracted, unpacked, and repacked, just to see if it would work. The resultant file is too large; it fails when you run flash_image.
I'm trying to modify my boot image of my ADP1 using the perl scripts, but I receive the following warning while decompressing the ramdisk:
Code:
$ unpack-bootimg.pl mtd2.img
kernel written to mtd2.img-kernel.gz
ramdisk written to mtd2.img-ramdisk.cpio.gz
removed old directory mtd2.img-ramdisk
[B]gzip: ../mtd2.img-ramdisk.cpio.gz: decompression OK, trailing garbage ignored
462 blocks[/B]
extracted ramdisk contents to directory mtd2.img-ramdisk/
Is this warning expected? Is safe to continue?
Also, I've found that the size of the modified packed image is far smaller than the original one
Code:
$ ll mtd2.img mtd2-modified.img
-rwx------ 1 ris ris 2621440 2009-01-07 19:19 mtd2.img
-rw-r--r-- 1 ris ris 1533952 2009-01-07 20:49 mtd2-modified.img
Update: I've tried anyway.
For the record, I've obtained the boot.img using cat, uncompressed with the perl script, modified default.prop, repacked with the perl script.
As you see from the code above, the img file is much smaller (Opening with a hex editor you can see that the end of the original image is full of 0xFF, so I believe it's ok, both the gzip warning and the different file sizes).
Reflashed it from recovery mode, using
fastboot flash boot mt2-modified.img
fastboot reboot
... and worked flawlessly
I'm leaving the coment for future references.
Thanks for the tutorial
[RiS] said:
gzip: ../mtd2.img-ramdisk.cpio.gz: decompression OK, trailing garbage ignored
462 blocks
Is this warning expected? Is safe to continue?
Click to expand...
Click to collapse
Yes, you would expect trailing zeroes, which would give you that error. The trailing zeroes exist in order to pad the image size to the nearest page boundary. They are added by mkbootimg.
[RiS] said:
Also, I've found that the size of the modified packed image is far smaller than the original one
As you see from the code above, the img file is much smaller (Opening with a hex editor you can see that the end of the original image is full of 0xFF, so I believe it's ok, both the gzip warning and the different file sizes).
Click to expand...
Click to collapse
Yep, that's exactly why. Nothing to worry about.
Thanks for the informative clarification.
alansj said:
There is also another important file you should know about. In /system/recovery.img there is a full copy of everything that is loaded on mtd1. This file is automatically flashed onto mtd1 every time you shut down. That means two things: 1. Any changes you make directly to /dev/mtd/mtd1 get blown away on reboot and 2. If you want to change /dev/mtd/mtd1 you're probably better off just sticking the image in /system/recovery.img and rebooting.
Click to expand...
Click to collapse
I'm using an stock ADP1, and the file /system/recovery.img does not exist. Is this expected?
Also, I've found out in JFv.1.31 that the recovery image is in /data/recovery.img (although there is no /data/recovery.img in my ADP1 neither..)
[RiS] said:
I'm using an stock ADP1, and the file /system/recovery.img does not exist. Is this expected?
Also, I've found out in JFv.1.31 that the recovery image is in /data/recovery.img (although there is no /data/recovery.img in my ADP1 neither..)
Click to expand...
Click to collapse
It deletes it after it flashes on the first bootup after you apply the update.
JesusFreke said:
It deletes it after it flashes on the first bootup after you apply the update.
Click to expand...
Click to collapse
Are you refering to /data/recovery.img or /system/recovery.img? or both?
[RiS] said:
Are you refering to /data/recovery.img or /system/recovery.img? or both?
Click to expand...
Click to collapse
I'm referring to /data/recovery.img in JFv1.2 and up (although there was a bug in the RC8 version of JFv1.2 that prevented it from being deleted)
So is there any reason why there is no /system/recovery.img on my ADP1?
When I use the unpack script on JF1.31 boot.img, it prints out like this:
"Could not find any embedded ramdisk images. Are you sure this is a full boot image?"
Any help?
[RiS] said:
So is there any reason why there is no /system/recovery.img on my ADP1?
Click to expand...
Click to collapse
Stock or JFv1.3?
JesusFreke said:
Stock or JFv1.3?
Click to expand...
Click to collapse
"Stock". I've just modified boot img to change default.prop
hey everyone, this all started when i began to try and get my sd partitioned for apps. i have the stock rogers fw with haykuro's root based off cyangens recovery? anyway, i got the partition to work and all and even copied files over. my only problem is that the ext2 does not mount unless i do it manually from the terminal on device. i have come up with an init.rc file that i believe should work. currently it is in /etc
Code:
on boot
export PATH /data/busybox
mount -rw -t ext2 /dev/block/mntblk0p2 /system/sd
on device-added-/dev/block/mntblk0p2
mount -rw -t ext2 /dev/block/mntblk0p2 /system/sd
any ideas?
Tried lucids script to do everything?
http://forum.xda-developers.com/showthread.php?t=480582 I mean I know that rom you have has a adds2sd thing in it, but I can only speak with what I use and know. =)
i'll check it out, but my rom is stock. there is no apps2sd in it. i just partitioned and was going to set up some links when i realized the partition wasn't mounting on it's own. thanks for the link though
The init.rc isn't a shell script, and doesn't run normal commands - its built-in mount command has a different syntax from normal mount. Check out the source or other init.rc files for the syntax.
gwydionwaters said:
i'll check it out, but my rom is stock. there is no apps2sd in it. i just partitioned and was going to set up some links when i realized the partition wasn't mounting on it's own. thanks for the link though
Click to expand...
Click to collapse
Check your PM
i figured it out a little, i have noticed that the init i create is being overwritten when i reboot. i would assume perhaps i need to add the modified file into the system.img and then flash that version on? does that sound right to anyone?
The init is flashed during boot. Its in the boot.img. you can check the stickys to see how to crack one open and put it back together. Ill fix it for you this weekend as promised. Ill even show you what I did but I gotta get time at my computer. Patience my internet friend, patience.
Edit
Also check the "all you need to know" post by haykuro. Its the most recent thread started by him in this forum I believe
If you are using a stock rom did you get the modified mount.conf that supports partition mounts?
lol no i didn't know there was one. i did modify my mount.conf on my own and added the entry for the ext.
i'm having some serious trouble unpacking my boot image, and yes i have read all there is to read and then some. i originally tried unyaffs on the image i got from my nandroid back up i made before root, but it was claiming a broken image. so i made a current back up and tried that boot, the same problem. i figured maybe the nandroid backup utility was creating bad images so i went another route. i started on device and created an image of my boot mount
Code:
cat /dev/mtd/mtd2 > /sdcard/boot.img
i stripped off the header and kernel, saved the remainder as a raw file. then
Code:
gunzip -c boot | cpio -i
and it sort of works, maybe with errors and then asks for the name of archive 2 ..
cpio: Cannot identify format. Searching...
cpio: Cpio file name length 46200 is out of range
cpio: Invalid header, starting valid header search.
cpio: Cpio file name length 6960 is out of range
cpio: Cpio file name length 40367 is out of range
cpio: Cpio file name length 21330 is out of range
gunzip: /device/here/boot: decompression OK, trailing garbage ignored
cpio: End of archive volume 1 reached
ATTENTION! cpio archive volume change required.
Ready for archive volume: 2
Input archive name or "." to quit cpio.
Archive name >
Click to expand...
Click to collapse
and if i enter anything it can't find/read the file (the one i named of course) and if i quit there is nothing gained, no files or anything
I'm sure several people will be wanting this information, so I figured I would post it here for everyone. This will allow you to backup your system and create custom Odin images for restore purposes. For anyone unfamiliar with the Samsung system, they use Odin to flash things to the device, much like HTC has RUU and Moto has SBF. Odin files are either .tar files, or .tar.md5 files.
The .tar.md5 files are .tar files with the md5 checksum added to the end of the file. If you attempt to flash a .tar.md5 file, Odin will automatically check that the contents are what they should be before flashing and proceed with the flash if the md5 is valid, otherwise it will stop.
In Odin, you should use the PDA button for all flashing. The PIT button may be used as well, if we can get a valid .pit file for the device, but for now, PIT won't be used either. Other than PDA, Start/Reset are the only other buttons you need to worry about.
Now, on to creating the backup files. First, you will need your device to be rooted (perm or temp root will work), and you also need to have access to terminal on the phone, either via an emulator or adb shell access. To create the backup files, you won't need a Linux/UNIX system, but you will if you want to create a flashable Odin package. The following will output the files on the root of the SDCard, adjust the "of=" path if you want them somewhere else. It will also create the files for the proper filename for Odin as well. So to create the files, here are the commands you will use from root shell (#):
System:
Code:
dd if=/dev/block/stl10 of=/sdcard/factoryfs.rfs bs=4096
Kernel:
Code:
dd if=/dev/block/bml8 of=/sdcard/zImage bs=4096
Recovery:
Code:
dd if=/dev/block/bml9 of=/sdcard/recovery.bin bs=4096
DO NOT INCLUDE THE FOLLOWING IN ANYTHING BUT A PERSONAL BACKUP
Cache:
Code:
dd if=/dev/block/mmcblk0p3 of=/sdcard/cache.rfs bs=4096
DBData:
Code:
dd if=/dev/block/stl11 of=/sdcard/dbdata.rfs bs=4096
Data:
Code:
dd if=/dev/block/mmcblk0p1 of=/sdcard/movinand.bin bs=4096
The last three files (cache, dbdata, data) may contain personal information, so do not include these 3 files in anything but a personal backup/recovery package.
To create a flashable Odin package, you need to pull all of the files off of the phone/sdcard and onto your computer. From there, you use the following to create the package:
Code:
tar -H ustar -c factoryfs.rfs recovery.bin zImage > package_name.tar
md5sum -t package_name.tar >> package_name.tar
mv package_name.tar package_name.tar.md5
If you want to include cache/dbdata/data in the above for personal use, just add them after the "-c" and before the ">".
There are other files that may be in Odin packages, but they are protected by Samsung and cannot be dumped properly. The files are the bootloader, secondary bootloader, modems, and .lfs partitions. The files would be boot.bin, Sbl.bin, modem.bin (not sure what it would be for the CDMA/LTE dual modem here), and param.lfs. It however isn't that big of an issue that these can't be dumped as the can't really be altered by normal flashing of the device, and are usually only altered via OTA updates.
Thanks for this info imnuts! I unfortunately updated to the new update and would like to go back to rooted but cant until I downgrade.
Thanks!
Thanks for posting this. I'm going to attempt to make a personal backup and then I can factory reset the phone and make a stock version for people to use. I'm haven't installed the update yet either, so I'm hoping this will let people get back to ED1. I've also been playing around with theming using the fascinate community rom theme and ninjamorph to swap files. It'll take a while, but it's currently the only way I feel safe messing with framework-res.
wynalazca said:
Thanks for posting this. I'm going to attempt to make a personal backup and then I can factory reset the phone and make a stock version for people to use. I'm haven't installed the update yet either, so I'm hoping this will let people get back to ED1. I've also been playing around with theming using the fascinate community rom theme and ninjamorph to swap files. It'll take a while, but it's currently the only way I feel safe messing with framework-res.
Click to expand...
Click to collapse
I'm definitely looking forward to having a downgrade ROM image to get back to ED1!
So how do you add the last personal 3 i just got the droid charge and i am not very familiar with samsung files i had a droid x and a thunderbolt very shortly and am familiar with ruu and sbf but how do you add cache dbdata and the other one. I meab like the actual command not the instruction to put it after c
rami98 said:
So how do you add the last personal 3 i just got the droid charge and i am not very familiar with samsung files i had a droid x and a thunderbolt very shortly and am familiar with ruu and sbf but how do you add cache dbdata and the other one. I meab like the actual command not the instruction to put it after c
Click to expand...
Click to collapse
The only thing that would change would be the tar command. If you want to include the other files, it would be:
Code:
tar -H ustar -c cache.rfs dbdata.rfs factoryfs.rfs movinand.bin recovery.bin zImage > package_name.tar
md5sum -t package_name.tar >> package_name.tar
mv package_name.tar package_name.tar.md5
You just need to pull the files from your phone and have them in the same directory that you're in in terminal, and have them named appropriately. It also doesn't matter what order they are in (that I know of), I just have them in alphabetical order for ease of reading.
So im going to try and do the voodoo lagfix for the first time ever but I wanted to make a backup. Im on ED2 and NOT rooted so how would I go about making these backups?
imnuts said:
The only thing that would change would be the tar command. If you want to include the other files, it would be:
Code:
tar -H ustar -c cache.rfs dbdata.rfs factoryfs.rfs movinand.bin recovery.bin zImage > package_name.tar
md5sum -t package_name.tar >> package_name.tar
mv package_name.tar package_name.tar.md5
You just need to pull the files from your phone and have them in the same directory that you're in in terminal, and have them named appropriately. It also doesn't matter what order they are in (that I know of), I just have them in alphabetical order for ease of reading.
Click to expand...
Click to collapse
I tried the above and I keep getting this error message in the command prompt:
'tar' is not recognized as an internal or external command, operable program or batch file.
(I'm trying this on windows 7 professional)
Any help would be appreciated, thanks!
mypantsaretorn said:
I tried the above and I keep getting this error message in the command prompt:
'tar' is not recognized as an internal or external command, operable program or batch file.
(I'm trying this on windows 7 professional)
Any help would be appreciated, thanks!
Click to expand...
Click to collapse
You wouldn't by any chance be trying the "tar" command at a windows command prompt, would you?
imnuts said:
To create the backup files, you won't need a Linux/UNIX system, but you will if you want to create a flashable Odin package.
To create a flashable Odin package, you need to pull all of the files off of the phone/sdcard and onto your computer. From there, you use the following to create the package:
Code:
tar -H ustar -c factoryfs.rfs recovery.bin zImage > package_name.tar
md5sum -t package_name.tar >> package_name.tar
mv package_name.tar package_name.tar.md5
If you want to include cache/dbdata/data in the above for personal use, just add them after the "-c" and before the ">".
Click to expand...
Click to collapse
Course you might be running Linux in a vmware or Hyper-V environment....hint?
HTH
Damn! I didn't pay attention to the second part of that sentence! Lol
Thanks for the "hint"..
Sent from my SCH-I510 using XDA App
The other option would be using Cygwin, but I've never tried it, so it may or may not work.
imnuts said:
The other option would be using Cygwin, but I've never tried it, so it may or may not work.
Click to expand...
Click to collapse
cygwin works!
Edit: Here is how:
1. Search google for cygwin - download
2. Run - you will be prompted to get packages - I assumed "archive" was a good place to start - not sure if you need this or not...
3. When complete you will see a new icon on your desktop - double-click
4. Be patient as it loads
5. Copy the files output'ed from first post to same folder on PC
6. Back in cygwin:
a. cd x: (where x: is the drive letter of the drive that has the folder with the files)
b. tar -H ustar -c cache.rfs dbdata.rfs movinand.bin factoryfs.rfs recovery.bin zImage > package_name.tar
c: md5sum -t package_name.tar >> package_name.tar
d: mv package_name.tar package_name.tar.md5
Complete output of commands:
These files are for the users to personalise their cygwin experience.
They will never be overwritten nor automatically updated.
`./.bashrc' -> `/home/UWINKET//.bashrc'
`./.bash_profile' -> `/home/UWINKET//.bash_profile'
`./.inputrc' -> `/home/UWINKET//.inputrc'
`./.profile' -> `/home/UWINKET//.profile'
Your group is currently "mkgroup". This indicates that neither
your gid nor your pgsid (primary group associated with your SID)
is in /etc/group.
The /etc/group (and possibly /etc/passwd) files should be rebuilt.
See the man pages for mkpasswd and mkgroup then, for example, run
mkpasswd -l [-d] > /etc/passwd
mkgroup -l [-d] > /etc/group
Note that the -d switch is necessary for domain users.
[email protected] ~
$ cd h:
System Volume Information
[email protected] /cygdrive/h
$ cd downloads
[email protected] /cygdrive/h/downloads
$ cd charge
[email protected] /cygdrive/h/downloads/charge
$ cd tarbackup/
[email protected] /cygdrive/h/downloads/charge/tarbackup
$ tar -H ustar -c cache.rfs dbdata.rfs movinand.bin factoryfs.rfs recovery.bin
zImage > package_name.tar
[email protected] /cygdrive/h/downloads/charge/tarbackup
$ md5sum -t package_name.tar >> package_name.tar
[email protected] /cygdrive/h/downloads/charge/tarbackup
$ mv package_name.tar package_name.tar.md5
[email protected] /cygdrive/h/downloads/charge/tarbackup
$
Hmm flash did not work with my personal data in it - got an error. Created a new .tar file with just factoryfs.rfs recovery.bin and zImage and was able to flash that. TG for TiBu!
jism31 said:
Thanks for this info imnuts! I unfortunately updated to the new update and would like to go back to rooted but cant until I downgrade.
Click to expand...
Click to collapse
How do you start doing this. How do I get to root shell (#)... Thanks
AD
I plan to get rooted on ED1 so I can get a stock image backed up, and have a clean base to work from. Still getting my head around the odin stuff first.
RaptorMD said:
I plan to get rooted on ED1 so I can get a stock image backed up, and have a clean base to work from. Still getting my head around the odin stuff first.
Click to expand...
Click to collapse
you dont have to do that its already done
http://forum.xda-developers.com/showthread.php?t=1085190
Well, I successfully followed all the instructions and have created my first ODIN flashable file, I have not tried to flash it yet. I'm just curious, I pull all the different .rfs, .bin, and zImage on this file and noticed it's about 1.8gb file. Is this normal?
Also, before I try to flash this. Should I have dissable voodoo lagfix and converted back to rfs before I dumped the files?
Thanks for all the help!
JKChad said:
Well, I successfully followed all the instructions and have created my first ODIN flashable file, I have not tried to flash it yet. I'm just curious, I pull all the different .rfs, .bin, and zImage on this file and noticed it's about 1.8gb file. Is this normal?
Also, before I try to flash this. Should I have dissable voodoo lagfix and converted back to rfs before I dumped the files?
Thanks for all the help!
Click to expand...
Click to collapse
Yes, that's normal for it to be so large as dd will dump the partition, including empty space. If you were to compress it with zip or lzma, it'd drop down considerably.
Not sure about the voodoo part as I've never dumped files from an ext4 partition. I don't see any reason why it wouldn't work, but I'd flash with caution and have another working image ready just in case.
imnuts said:
Not sure about the voodoo part as I've never dumped files from an ext4 partition. I don't see any reason why it wouldn't work, but I'd flash with caution and have another working image ready just in case.
Click to expand...
Click to collapse
Shouldn't be an issue as long as he keeps the voodoo kernel.
Sent from my SCH-I510 using Tapatalk
Anybody try this with voodoo yet ?
Since most of the high-end devices are using now EXT4 partitions i decided to make a guide.
I am doing this because this is the easiest way to create an EXT4 image.
This is not my guide I am just adapting and make it clear to everybody; someone showed me how to do this (I will mention him at the end of the guide).
Let's assume that you dumped the system.img from your own device and you want to add something to it.
We will create a new system.img and we will name it system_new.img, the size will be 240 Mb.
Step 1
Linux Machine (I used Ubuntu)
We prepare the directories and copy the system.img in the folder in which we will work.
mkdir system (here we will mount the old system.img
mkdir system_new (here we will mount the system_new.img)
Step 2 – Creation of the actual EXT4.img
dd if=/dev/zero of=system_new.img bs=4k count=60000
Translation of the terms,
bs =blocksize, 4k= the size of the block`s which in this case is 4kb
count=60000, the number of block`s, in our case will result an image of 240 Mb.
The blocksize can be 1k/2k/4k/16k
To get the exact size of the image that you create use simple maths.
60000 * 4 = 240000
Step 3 Formating the system_new.img with EXT4
mkfs.ext4 system_new.img
It will be a question where you will select yes (Y)
We override the file system check (If you don`t do this, the image will not work)
tune2fs -c0 -i0 system_new.img
Step 4 We mount the directories that we previous created.
mount -o loop system_new.img system_new/
mount -o loop system_new.img system/
Step 5 We copy the content from the old system.img in the system_new.img
cp -v -r -p system/* system_new/
We sync the files
sync
Step 6 Unmounting the partitons.
umount system_new/
umount system/
Step 7 Enjoy your new ext4 system.img
Tips:
If you are using Ubuntu just type
sudo su
And you will be root and no more sudo at each command.
You can add new files in the new created system.img but you need to set the permissions and ownership properly, otherwise it will not work.
Credits: arctablet.com administrator.
work perfect!
I managed to create a new system img for huawei phone.
Errors in Step 3 and 4: Unable to proceed
Hi There,
I am getting errors in step 3 and 4.
Step 3 Formating the system_new.img with EXT4
mkfs.ext4 system_new.img
It will be a question where you will select yes (Y) -- after this below error comes
Device size reported to be zero. Invalid partition specified, or partition table wasn't reread after running fdisk, due to a modified partition being busy and in use. You may need to reboot to re-read your partition table.
We override the file system check (If you don`t do this, the image will not work)
tune2fs -c0 -i0 system_new.img -- after this below error comes
Attempt to read block from filesystm resulted in short read while trying to open system.img
Step 4 We mount the directories that we previous created.
mount -o loop system_new.img system_new/ -- after this below error comes
unknown filesystem type 'ext4'
Could you please help.
i whant to create and system.img.ext4 for my android ! ! But i saw that image which is created is just system.img ! I`m using ubuntu and i whant to know what is need it to create that system.img.ext4 ! I don`t see that img to be ext4 file ! Thanks
jabarel said:
i whant to create and system.img.ext4 for my android ! ! But i saw that image which is created is just system.img ! I`m using ubuntu and i whant to know what is need it to create that system.img.ext4 ! I don`t see that img to be ext4 file ! Thanks
Click to expand...
Click to collapse
I'm not sure but it's probably just a matter of file extenstion.
By the way, great tuto. May be someting to add :
Android ext4 don't seem to be the exact standart of linux ext4 file systems.
To make it fully compatible and usable with fastboot, the use of "ext2simg" can be useful.
So it will be something like this :
ext2simg fs2convert.img fsconverted.img
ext2simg can be found in android-tools in debian repository.
I am porting a rom ,i extracted "system.new.dat" into "sytem" folder , applied changes according to this guide to port a ROM -->> http://forum.xda-developers.com/showthread.php?p=65933478#post65933478
can you tell me how to reconstruct the "system.new.dat" from "sytem" folder ?
is mkfs.ext4 applet available to arm devices..??
you can do it faster...
Great if you create a new image, but to edit no need to create all these steps ...
Just copy the system.img to system_new.img and mount that one and edit..
There's no clear instruction!
Hours of researching many places and no good instruction about how to create or edit an EXT4 with or without Linux!
I know this is an old post but I just wanted to try, might get a reply!
Frank2406 said:
Hours of researching many places and no good instruction about how to create or edit an EXT4 with or without Linux!
I know this is an old post but I just wanted to try, might get a reply!
Click to expand...
Click to collapse
what is not clear?
this has been tested by me and it works.
there are more refined ways in doing it, it just depends on what you need to to with the ext4 image.
globula_neagra said:
what is not clear?
this has been tested by me and it works.
there are more refined ways in doing it, it just depends on what you need to to with the ext4 image.
Click to expand...
Click to collapse
Step 1: "We prepare the directories" you said. What directories?
"mkdir system"
"mkdir system_new" which, what or where are they?
Step 2: The whole step 2 for a newbie in Linux like me is bla bla bla except the title "Creation of the actual EXT4.img"!
And the rest of your guide is as the same as step 2 which I mentioned.
And if this guide is for Ubuntu experts then maybe in the beginning you could mention so people don't get their hopes up dear globula_neagra!!
Long story short, I just wanted to try a custom Rom on my Zenwatch 1, but I've forgot to make backup, so the official Rom was gone. Asus itself didn't help to get a copy of the official one, so I tried Anthias custom Rom instead, but that made the watch even worse.
Then I started to research how to fix it, so I found this article.
It s not a step by step guide on how to use ubuntu.
I assume that wheen you want to learn something you do use google too. For this instance i would google in this way "what does mkdir command in ubuntu"
After i understood the purpose of the command and how to use it i would try to apply it using the guide and after that you will see that things will start to make sense.
My guide was written with the idea that if you use android you have an idea of linux too and in this case ubuntu.
The command line in linux is somewhat similar to the one in windows commander there are some extra things that you need to learn but those can t be put in a guide like this.
In regards to your watch. My advice is to find another one and take a system dump from that one and flash it to yours if you have an unlocked bootloader.
Here you cand find some good reads on how to dump the files from the watch. And a bit more details on what is the business with the ext4 creation. Topic is5 years old but still relevant.
http://www.arctablet.com/blog/forum/arnova-7c-g3/arnova-7c-g3-dev-topic/
First the disclaimer:
I am not responsible for what you do to your phone. Following these directions could cause you to brick, locust plague, or end of times. You assume ALL responsibility for what you do with this information.
Now, on to the fun stuff. I take *NO* credit for this information at all. I am a student of people far more knowledgeable about these things. However, I've managed to take what I've learned and apply it in really fun ways. For example, I have a script that takes an OTA and builds a new full ODIN image from it...with all partitions fully signed except system. Many people have asked me to "repackage it" with various requests. This tutorial is going to show how to do that.
Requirements:
o) You will need to install Cygwin. A default installation should suffice for this exercise.
o) You will need one of the ODIN TAR Full Rooted Restore images. They are gzipped to make them smaller.
Process:
o) You need to unpack the files stored inside the gzip. 7 Zip is a handy program for doing that. We need the individual partition files extracted to a work directory that can be accessed from a Cygwin command prompt. I create a C:\Android\S4_GPE directory for my own image creation tasks.
o) Once the individual files are unpacked, we need to repack them. Open a Cygwin command prompt and navigate to the directory you extracted the files to. In my case, that would be cd c:/Android/S4_GPE
Follow the directions below to repack the files as needed. I give a few examples here to show you the basics of how it's done. Basically you run each command in your Cygwin command prompt. Or you can add them to an SH script and run it that way. Whatever you feel most comfortable with.
The output of these commands is an ODIN flashable file that will install what you choose.
BOOT
filename=boot
tar -H ustar -c boot.img > $filename.tar
md5sum -t $filename.tar >> $filename.tar
mv $filename.tar $filename.tar.md5
RECOVERY
filename=recovery
tar -H ustar -c recovery.img > $filename.tar
md5sum -t $filename.tar >> $filename.tar
mv $filename.tar $filename.tar.md5
MODEM
filename=modem
tar -H ustar -c NON-HLOS.bin modem.bin > $filename.tar
md5sum -t $filename.tar >> $filename.tar
mv $filename.tar $filename.tar.md5
FULL ODIN IMAGE
filename=I9505GUEUB_FULL_ROOTED
tar -H ustar -c boot.img recovery.img NON-HLOS.bin modem.bin system.img.ext4 > $filename.tar
md5sum -t $filename.tar >> $filename.tar
mv $filename.tar $filename.tar.md5
gzip $filename.tar.md5
Those are some of the common ones. What if I wanted a "semi-full rooted image"? For instance, without the modems? You just modify this line:
tar -H ustar -c boot.img recovery.img NON-HLOS.bin modem.bin system.img.ext4 > $filename.tar
so that it becomes:
tar -H ustar -c boot.img recovery.img system.img.ext4 > $filename.tar
Of if you don't want recovery, either, and just want boot and system:
tar -H ustar -c boot.img system.img.ext4 > $filename.tar
And the rest stays the same. I really hope this helps people. I will update this post to clarify anything that's confusing and will try to help people in this thread to create whatever they need. Again, you take responsibility for anything you create using these instructions and flash to your phone.
whats the command to create a system dump to an odin compatible system.img file? been a while. i forget
This is how I do it in my script:
adb shell "su -c 'cd /sdcard; dd if=/dev/block/platform/msm_sdcc.1/by-name/system of=/sdcard/system.img.ext4'"
adb pull /sdcard/system.img.ext4
adb shell rm /sdcard/system.img.ext4
SamuriHL said:
This is how I do it in my script:
adb shell "su -c 'cd /sdcard; dd if=/dev/block/platform/msm_sdcc.1/by-name/system of=/sdcard/system.img.ext4'"
adb pull /sdcard/system.img.ext4
adb shell rm /sdcard/system.img.ext4
Click to expand...
Click to collapse
I'm a relative noob and just learning as much as I can and this is alot of great info. I am able to pull system dump and pull recovery.img from my but when I create an odin flashable recovery image (for back-up purposes) it fails auth. Is there a way to pull a signed recovery image from system? Thanks.
No. When you dd extract a partition it adds padding to it which messes with the signature. I create a signed recovery img file by patching the boot img with the recovery-from-boot.p in the OTA update. That's a lot more involved than what's in this tutorial, however.
SamuriHL said:
No. When you dd extract a partition it adds padding to it which messes with the signature. I create a signed recovery img file by patching the boot img with the recovery-from-boot.p in the OTA update. That's a lot more involved than what's in this tutorial, however.
Click to expand...
Click to collapse
Got it, thank you. I found the thread on hexediting the partition file. I will see if that works.
muniz_ri said:
Got it, thank you. I found the thread on hexediting the partition file. I will see if that works.
Click to expand...
Click to collapse
My initial results weren't very conclusive on that. I tried it with the NON-HLOS.bin file just to see if I could make it consistent with the one I create by patching, and the results were not good. There's no way to know exactly how long to make the cut. It seems like all you do is remove the trailing 00's when hexediting, but, I can tell you that's not enough to make it match. I've got more research to do on this as it would be extremely useful to be able to edit the dd extracted files to make them match the signed files. So far, that doesn't seem possible.
SamuriHL said:
My initial results weren't very conclusive on that. I tried it with the NON-HLOS.bin file just to see if I could make it consistent with the one I create by patching, and the results were not good. There's no way to know exactly how long to make the cut. It seems like all you do is remove the trailing 00's when hexediting, but, I can tell you that's not enough to make it match. I've got more research to do on this as it would be extremely useful to be able to edit the dd extracted files to make them match the signed files. So far, that doesn't seem possible.
Click to expand...
Click to collapse
That's too bad, I was also hoping removing the trailing zeros would work. Can you point me to a tutorial, etc where i can learn how to patch using the OTA files? thanks again.
muniz_ri said:
That's too bad, I was also hoping removing the trailing zeros would work. Can you point me to a tutorial, etc where i can learn how to patch using the OTA files? thanks again.
Click to expand...
Click to collapse
It's not quite as simple as that. There isn't a tutorial on it. I learned what I know from Matt Groff. It started with a thread here:
http://forum.xda-developers.com/showthread.php?t=1702233
But that thread isn't going to teach nearly enough to learn how to do this. It involves parsing the update scripts from the OTA to find the command they use to patch the actual partition and then converting that to a command to patch the file. So if you look at this command from install-recovery.sh:
applypatch EMMC:/dev/block/platform/msm_sdcc.1/by-name/boot:8036608:1ad324cf48a6e19fd402603477cd0ed8472ed863 EMMC:/dev/block/platform/msm_sdcc.1/by-name/recovery f4579fa7099942ec2f214cff81014b8e8b1a550f 8632576 1ad324cf48a6e19fd402603477cd0ed8472ed863:/system/recovery-from-boot.p
What that's doing is taking 8036608 bytes from the boot partition, ensuring it has a sha1 hash of 1ad324cf48a6e19fd402603477cd0ed8472ed863, patching it with the contents of the recovery-from-boot.p file, and then writing it to the recovery partition.
Each time an OTA comes out for our phones, I create signed recovery, modem, and non-hlos files using this process. Then I use the process outlined in this tutorial to create the ODIN tar md5 files that I post.
SamuriHL said:
It's not quite as simple as that. There isn't a tutorial on it. I learned what I know from Matt Groff. It started with a thread here:
http://forum.xda-developers.com/showthread.php?t=1702233
But that thread isn't going to teach nearly enough to learn how to do this. It involves parsing the update scripts from the OTA to find the command they use to patch the actual partition and then converting that to a command to patch the file. So if you look at this command from install-recovery.sh:
applypatch EMMC:/dev/block/platform/msm_sdcc.1/by-name/boot:8036608:1ad324cf48a6e19fd402603477cd0ed8472ed863 EMMC:/dev/block/platform/msm_sdcc.1/by-name/recovery f4579fa7099942ec2f214cff81014b8e8b1a550f 8632576 1ad324cf48a6e19fd402603477cd0ed8472ed863:/system/recovery-from-boot.p
What that's doing is taking 8036608 bytes from the boot partition, ensuring it has a sha1 hash of 1ad324cf48a6e19fd402603477cd0ed8472ed863, patching it with the contents of the recovery-from-boot.p file, and then writing it to the recovery partition.
Each time an OTA comes out for our phones, I create signed recovery, modem, and non-hlos files using this process. Then I use the process outlined in this tutorial to create the ODIN tar md5 files that I post.
Click to expand...
Click to collapse
Success! Thanks so much, just created my first signed odin image!
Theres two more ways the get signed images. One is using dd if=of with the right bs and count. For example, I extracted the stock signed PIT file for the S4 using
Code:
su
dd if=/dev/block/mmcblk0 of=/sdcard/sch1545.pit bs=8 count=580 skip=2176
you can see the thread and md5 comparisonhere The other method is hexediting but it was easier on 4.2.2 but still very doable on 4.3. You have to know what signatures look like though. Hexediting can also be useful for manually extracting the zimage and ramdisk from a boot.img
Sent from my SCH-I545 using XDA Premium 4 mobile app
Surge1223 said:
Theres two more ways the get signed images. One is using dd if=of with the right bs and count. For example, I extracted the stock signed PIT file for the S4 using
Code:
su
dd if=/dev/block/mmcblk0 of=/sdcard/sch1545.pit bs=8 count=580 skip=2176
you can see the thread and md5 comparisonhere The other method is hexediting but it was easier on 4.2.2 but still very doable on 4.3. You have to know what signatures look like though. Hexediting can also be useful for manually extracting the zimage and ramdisk from a boot.img
Sent from my SCH-I545 using XDA Premium 4 mobile app
Click to expand...
Click to collapse
I'm also going to play around more with hexediting, if it will work it seems much more straightforward. Thanks again for all of the good info!
SamuriHL said:
My initial results weren't very conclusive on that. I tried it with the NON-HLOS.bin file just to see if I could make it consistent with the one I create by patching, and the results were not good. There's no way to know exactly how long to make the cut. It seems like all you do is remove the trailing 00's when hexediting, but, I can tell you that's not enough to make it match. I've got more research to do on this as it would be extremely useful to be able to edit the dd extracted files to make them match the signed files. So far, that doesn't seem possible.
Click to expand...
Click to collapse
Sam, id be glad to try hexediting the NON-HLOS.bin file and then send you the md5.
Sent from my SCH-I545 using XDA Premium 4 mobile app
Surge1223 said:
Sam, id be glad to try hexediting the NON-HLOS.bin file and then send you the md5.
Sent from my SCH-I545 using XDA Premium 4 mobile app
Click to expand...
Click to collapse
I'll pm one to you tomorrow. I definitely am curious if you're able to md5 hash it correctly.
Pm sent. Good luck.
Sent from my SM-P600 using Tapatalk 4
SamuriHL said:
Pm sent. Good luck.
Sent from my SM-P600 using Tapatalk 4
Click to expand...
Click to collapse
How do you limit the number of bytes extracted for the mdm.bin to match the updater script's parameters? Thank you.
muniz_ri said:
How do you limit the number of bytes extracted for the mdm.bin to match the updater script's parameters? Thank you.
Click to expand...
Click to collapse
I didn't. The first signed modem bin I made was done by looking at the size in the updater script and using cygwin to copy that many bytes to a new file. From then on I just patched the previous version's modem bin and NON-HLOS bin files.
Sent from my SM-P600 using Tapatalk 4
SamuriHL said:
I didn't. The first signed modem bin I made was done by looking at the size in the updater script and using cygwin to copy that many bytes to a new file. From then on I just patched the previous version's modem bin and NON-HLOS bin files.
Sent from my SM-P600 using Tapatalk 4
Click to expand...
Click to collapse
First time quickly hexediting it I got
md5: 9616e85b765e0365e8ccd57550a715b8
Surge1223 said:
First time quickly hexediting it I got
md5: 9616e85b765e0365e8ccd57550a715b8
Click to expand...
Click to collapse
Which doesn't match the digital signature. This is what I was afraid of and what I was running into.
Sent from my SM-P600 using Tapatalk 4
SamuriHL said:
Which doesn't match the digital signature. This is what I was afraid of and what I was running into.
Sent from my SM-P600 using Tapatalk 4
Click to expand...
Click to collapse
what are you comparing the sig to?
Sent from my SCH-I545 using XDA Premium 4 mobile app