Related
Hey guys, I've been reading for a while now, finally decided to sign up.
I'm making some modifications to the Galaxy Tab, just playing around and seeing what all is possible. Before I go start deleting potentially important system files, I wanted to get myself a little 'brick insurance'. I'm looking to get a copy of the stock firmware for the US Verizon Wireless version of the Tab (SCH-I800). It is currently running DJ11.
I don't think it is available from either Samsung or Verizon currently, although Samsung HAS provided all of the source code. If I wanted to make a backup of the firmware, something that I could load from the SDCard (ideally, just give it one of those update.zip files) how would I go about doing that?
This is my current plan, tell me if I'm not on track here. I have downloaded the Android Froyo source code available on the Android site. I downloaded the SCH-I800_OpenSource files from Samsung's open source center. If I combine these files as described in the readme from Samsung, and then build the whole project, I should get some sort of "stock" software, in basically the exact same state that it was when I got it from Verizon. Does this sound right?
I want to be able to quickly revert back to like-new set up, so I would prefer to not have to use one of the modified European/International versions if possible. Is there any other trick to getting an unmodified firmware to revert to? Any suggestions?
Thank You
I don't think it'll matter until someone creates a new recovery image. If you could get a clockwork recovery image, you'd be a hero
DavidThompson256 said:
This is my current plan, tell me if I'm not on track here. I have downloaded the Android Froyo source code available on the Android site. I downloaded the SCH-I800_OpenSource files from Samsung's open source center. If I combine these files as described in the readme from Samsung, and then build the whole project, I should get some sort of "stock" software, in basically the exact same state that it was when I got it from Verizon. Does this sound right?
Click to expand...
Click to collapse
Not even close i'm afraid!
Samsung are only required to release the Linux kernel source. The actual OS is not licensed under a "copy left" license, so Samsung are under no obligation to release their customized Android code.
So, you could create your own AOSP build, but this would be absolute stock Froyo - no Samsung launcher, or any of their custom apps.
Regards,
Dave
Yaotl said:
I don't think it'll matter until someone creates a new recovery image. If you could get a clockwork recovery image, you'd be a hero
Click to expand...
Click to collapse
You can use odin or redbend_ua to flash firmwares, you don't necessarily need clockwork - although it would be nice!
Hey infamousjax,
Do you happen to have an update.zip for the verizon tab you can upload? I managed to ninjamorph my framework so nothing opens anymore. I must have used a file that was the wrong png format or something. Anyway I do have the backup framework-res.apk, but I am unsure on the "update-script" as I can't get programs on my tab at the moment.
ninja4hire said:
Hey infamousjax,
Do you happen to have an update.zip for the verizon tab you can upload? I managed to ninjamorph my framework so nothing opens anymore. I must have used a file that was the wrong png format or something. Anyway I do have the backup framework-res.apk, but I am unsure on the "update-script" as I can't get programs on my tab at the moment.
Click to expand...
Click to collapse
I have the Sprint version... and the stock recovery can't flash update.zips unless they are signed.
infamousjax said:
I have the Sprint version... and the stock recovery can't flash update.zips unless they are signed.
Click to expand...
Click to collapse
Yeah I just tried to make an update.zip and sign it with a test signer. Now when go into recovery and run the update.zip it freezes on an Android icon with an exclamation point.
ninja4hire said:
Yeah I just tried to make an update.zip and sign it with a test signer. Now when go into recovery and run the update.zip it freezes on an Android icon with an exclamation point.
Click to expand...
Click to collapse
Can you boot up regularly?
yeah, it's just that I can't open programs or the settings menu.
edit: I have been trying to do an update.zip, but I keep getting "E: signature verification failed". I have tried to different signers already...
This one
http://www.robmcghee.com/android/creating-an-android-update-zip-package/
and this one
http://www.londatiga.net/it/how-to-create-android-update-zip-package/
Your not going to able to sign it without Samsung's signatures... and good luck finding those
yeah I pretty much gave up. I called last night and got the verizon insurance. So now I'm just gonna wait a few days then tell them I dropped it and pay $80 for a new one.
just tell them it started bootlooping for no reason... they should replace it for free if its within 30 days
So it sounds as though I'm not really on the right track here, perhaps I don't need to recompile this thing myself. From some of the replies, I've gathered that there IS at least some way to create a backup of the firmware, in case I screw it up.
Can anyone point me to specific steps on how to do a backup for the Tab? I've seen several guides for other phones before, but I believe that each device is slightly different, and may take different steps. Any suggestions?
Thanks again.
For your stock recovery
Code:
cat /dev/block/bml8 > /sdcard/recovery.bin
For your kernel
Code:
cat /dev/block/bml7 > /sdcard/zImage
Thanks a lot, that info was really helpful!
So, unrelated now, but just kind of curious... is there a reference sheet somewhere or something that explains what each of the files in /dev/block is for? I know they are different sections of the filesystem.
I have about 60 different files in that directory, and was just curious to know what each of them was for.
Thanks again for all the info.
DavidThompson256 said:
is there a reference sheet somewhere or something that explains what each of the files in /dev/block is for? I know they are different sections of the filesystem.
Click to expand...
Click to collapse
What they represent is different devices, not different sections of filesystems. At best (without RAID or LVM) each device holds one filesystem. In unix, filesystems can be mounted at various points into the root filesystem to appear as a single namespace, but they will still be separate filesystems.
Under the block dir you will see anything that is a block device, anything that can be written to randomly, as opposed to a serial type of device. So, all the random access hardware on your device (SDCARD, NAND...) will be represented there except for your RAM. Each physical device will likely have partitions on them so, if a device is named xxx, xxx01 will likely mean partition one on device xxx. Sometimes the same device will appear with several names, one may be buffered access, the other may be raw.
Your internal NAND is likely on the same device, just different partitions of that device. Some of these partitions may not hold filesystems, they may hold other blobs such as a boot loader, or the kernel. To see which ones hold filesystems, you can type df in a terminal and you will likely see which devices are mounted where in the filesystem namespace.
As for the rest of the devices and partitions, they are very hardware device specific. And I don't own a Galaxy tab, so I can't help with that, sorry. But, I hope I didn't give you info you already knew and I hope it might have been at least somewhat helpful...
I have a rooted Galaxy Nexus GSM (Maguro) running ClockworkMod and the stable version of CM9. I've been trying to find out how exactly the IMEI is stored --- whether it's baked into the radio component or whether it's controllable from firmware --- and how /factory/nv_data.bin relates to it.
I was able to "break" my IMEI, i.e., set it to the infamous 004999010640000, via the following procedure (derived from http://forum.xda-developers.com/showthread.php?t=1264021 ):
0. Get an adb root shell
1. Back up the contents of `/factory`, e.g., with `adb pull`
2. Remount the `/factory` filesystem read-only with `mount -oremount,rw /dev/block/mtdblock0 /factory`
3. Delete `/factory/nv_data.bin` and `/factory/nv_data.bin.md5`
4. Delete `/data/radio/nv_data.bin` and `/data/radio/nv_data.bin.md5`
5. Reboot
After this, the IMEI was reported as 004999010640000. Then I was able to restore my IMEI to its original value as follows:
0. Restore `/factory/nv_data.bin` (owned by root)
1. Restore `/data/radio/nv_data.bin` (owned by radio)
So it seems clear that the IMEI reported by the device depends on the contents of the firmware. But it's possible that the radio unit is hard-wired to only be in two possible states, 004999 and the true IMEI.
`/data/radio/nv.log` has log lines from code attempting to read `nv_data.bin`, in particular:
Fri Aug 24 01:10:53 2012: MD5 is turned on.
I searched all the repositories in the Google Android codebase for the string "MD5 is turned on" and couldn't find the code that generates this log line. Is it possible that it's generated by a proprietary binary blob?
So, the open questions:
1. Where is the code that knows how to interpret nv_data.bin?
2. Does nv_data.bin actually contain the IMEI?
Thanks for your time!
Have a look at this thread.
efrant said:
Have a look at this thread.
Click to expand...
Click to collapse
That's more or less what I did; I was able to break and unbreak my IMEI using the procedures outlined there. What I'm trying to find out is whether the IMEI is actually stored in that file (the first "theorem" in that post, although it is not proven), what code is able to read the IMEI, and whether the IMEI can be modified.
There's some more information here: http://forum.xda-developers.com/showthread.php?t=1626593&page=2
which points to the Samsung rild as the code which knows how to interpret nv_data.bin, and suggests that the md5 verification is performed with a secret seed. But I can't find the source code for the Samsung-specific rild to confirm this. Perhaps it is a binary blob somewhere on my phone's filesystem?
The two strings I have to recognize the code are the log message `MD5 is turned on.` and the function `__refresh_md5_file`.
Update: running `pmap` on `/system/bin/rild` showed that it links against `/system/vendor/lib/libsec-ril.so`. I think this is the relevant blob --- it looks like both of those strings are in there.
slingamn said:
Update: running `pmap` on `/system/bin/rild` showed that it links against `/system/vendor/lib/libsec-ril.so`. I think this is the relevant blob --- it looks like both of those strings are in there.
Click to expand...
Click to collapse
/system/vendor/lib/libsec-ril.so is just the "radio interface layer". It has nothing to do with the IMEI.
efrant said:
/system/vendor/lib/libsec-ril.so is just the "radio interface layer". It has nothing to do with the IMEI.
Click to expand...
Click to collapse
I think it does have to do with the IMEI, based on the strings that are in it. Here's the output of `nm -D` on it: gist.github.com/70f5222ce6d578a9655e
In particular, here are some suggestive strings: requestGetIMEI, requesetOemImei, requestOemEventStartIMEI, TxIMEI_EventStartImei, RxIMEI_UpdateItem.
I think it's likely that some of the functions here can be used to push a new IMEI value into the radio unit. But given that it also contains the log messages found in `nv_data.log`, it seems like it definitely has the role of reading and verifying `nv_data.bin`.
Does anyone have any guesses about the naming scheme of these functions, in particular the "Tx" and "Rx" strings?
slingamn said:
I think it does have to do with the IMEI, based on the strings that are in it. Here's the output of `nm -D` on it: gist.github.com/70f5222ce6d578a9655e
In particular, here are some suggestive strings: requestGetIMEI, requesetOemImei, requestOemEventStartIMEI, TxIMEI_EventStartImei, RxIMEI_UpdateItem.
I think it's likely that some of the functions here can be used to push a new IMEI value into the radio unit. But given that it also contains the log messages found in `nv_data.log`, it seems like it definitely has the role of reading and verifying `nv_data.bin`.
Does anyone have any guesses about the naming scheme of these functions, in particular the "Tx" and "Rx" strings?
Click to expand...
Click to collapse
so? no updates on this?
i'm stuck with the 0000049xxxxx generic IMEI and no back up... i'm trying everything i found on the internet with my poor knowledge and i'm stuck... no idea what to do
blasael said:
so? no updates on this?
i'm stuck with the 0000049xxxxx generic IMEI and no back up... i'm trying everything i found on the internet with my poor knowledge and i'm stuck... no idea what to do
Click to expand...
Click to collapse
I gave up on this project. If you're interested in working on it further, I would suggest contacting the Replicant developers (#replicant on freenode) for advice --- they're the people I would expect to know the most about hardware issues of this stripe.
slingamn said:
I gave up on this project. If you're interested in working on it further, I would suggest contacting the Replicant developers (#replicant on freenode) for advice --- they're the people I would expect to know the most about hardware issues of this stripe.
Click to expand...
Click to collapse
i am also haviong the same problem.I installed 4.3 factory image,build JWR66Y on my Galaxy Nexus .But after flashing my IMEI become generic (004999010640000).So I cant registered on network. Can give some suggestions to restore my genuine IMEI...
On Samsung phones I guess you can turn root on/off by changing the variable in default.prop, but I have my phone rooted and it says ro.secure=1. How would I modify the bootloader? What would I look for to find out what I'm talking about?
I would like to try compiling my own kernel too. XDA University has information about compiling the kernel, but it is kind of unclear about how to put the actual package together though, or at least confusing. It says just zip the image and .ko files together and then it is good to flash, but then gives a file structure tree with unknown files? I downloaded a kernel to test from this site and the file structure was different, and it also reset the whole phone to get the job done.
I have tried to look up what it takes to unpack a T800_whatever.tar.md5, mod it, and then put it back together, and frankly I think none of the guides I have seen work. They're too outdated, and Samsung changed something. The whatever.tar.md5 file is no longer a tar archive with md5 sum attached to it, but it is now a tar archive, with some metadata, and md5 checksum attached.
The next issue is how to convert a sparse system.img back into non-sparse one after it was modified. One tool simg2img, which many recommend, doesn't seem to work, and another tool called make_ext4fs seems to be impossible to build from source because nobody has provided the damn instructions on how to build it. The typical open source Linux/Unix software in 99% of cases comes with makefiles and configurations scripts and (don't laugh) README files which make building software easy. But google's sources seems to have none of that. Some web sites suggest a specific gcc command to build it, but of course it won't work on _my_ specific Linux laptop (CentOS). I can't believe this stuff has to be so hard. This is just sloppy packaging and software distribution on google's part.
Akopps said:
I have tried to look up what it takes to unpack a T800_whatever.tar.md5, mod it, and then put it back together, and frankly I think none of the guides I have seen work. They're too outdated, and Samsung changed something. The whatever.tar.md5 file is no longer a tar archive with md5 sum attached to it, but it is now a tar archive, with some metadata, and md5 checksum attached.
The next issue is how to convert a sparse system.img back into non-sparse one after it was modified. One tool simg2img, which many recommend, doesn't seem to work, and another tool called make_ext4fs seems to be impossible to build from source because nobody has provided the damn instructions on how to build it. The typical open source Linux/Unix software in 99% of cases comes with makefiles and configurations scripts and (don't laugh) README files which make building software easy. But google's sources seems to have none of that. Some web sites suggest a specific gcc command to build it, but of course it won't work on _my_ specific Linux laptop (CentOS). I can't believe this stuff has to be so hard. This is just sloppy packaging and software distribution on google's part.
Click to expand...
Click to collapse
Simg2img works fine for me as does make_ext4fs.
I use these 2 binaries all the time and can unpack and repack system images no problem.
Either you're using the wrong versions or your syntax is wrong.
There's also a toolkit available somewhere that you can compile on Linux which will build all the necessary binaries.
However at the moment the name escapes me.
EDIT : here we go.
https://forum.xda-developers.com/showthread.php?t=2600364
linux meanwhile have a package for simg2img
Code:
sudo apt-get install android-tools-fsutils
sudo yum install android-tools
Here a complete guide. Tested on product.img.lz4 inside CSC tar.
samsung android 10 pack repack img.lz4
Procedure to modify a product.img.lz4 used by Samsung Android phones with Android 10
Procedure to modify a product.img.lz4 used by Samsung Android phones with Android 10 - samsung-android-pack-repack.sh
gist.github.com
make_ext4fs does not work on newer android versions. You must use latest img2simg to convert a raw img to sparse image (it works on android 10)
Akopps said:
I have tried to look up what it takes to unpack a T800_whatever.tar.md5, mod it, and then put it back together, and frankly I think none of the guides I have seen work. They're too outdated, and Samsung changed something. The whatever.tar.md5 file is no longer a tar archive with md5 sum attached to it, but it is now a tar archive, with some metadata, and md5 checksum attached.
The next issue is how to convert a sparse system.img back into non-sparse one after it was modified. One tool simg2img, which many recommend, doesn't seem to work, and another tool called make_ext4fs seems to be impossible to build from source because nobody has provided the damn instructions on how to build it. The typical open source Linux/Unix software in 99% of cases comes with makefiles and configurations scripts and (don't laugh) README files which make building software easy. But google's sources seems to have none of that. Some web sites suggest a specific gcc command to build it, but of course it won't work on _my_ specific Linux laptop (CentOS). I can't believe this stuff has to be so hard. This is just sloppy packaging and software distribution on google's part.
Click to expand...
Click to collapse
renzofilini said:
Here a complete guide. Tested on product.img.lz4 inside CSC tar.
samsung android 10 pack repack img.lz4
Procedure to modify a product.img.lz4 used by Samsung Android phones with Android 10
Procedure to modify a product.img.lz4 used by Samsung Android phones with Android 10 - samsung-android-pack-repack.sh
gist.github.com
Click to expand...
Click to collapse
Hi. Do I get it right that this won't affect the bootloader, thus the Knox bit?
I keep getting this error after installing several Gcams. Then I have to close it. Any idea what it may be?
You must have camera2api enabeld in build.prop!!
look at this website for your solution;
miui-magisk-camera2-api-enabler
If you want you can check if the api is enabled by searching in the build.prop file and look for "camera.HAL3.enabled=" string. In my case it wasn't there, so i knew the strings had to be filled in the build.prop. It is possible to just add the lines of code yourself, just copy the lines from the dosbox example from the website. You can also just flash the zip file from that site using Magisk. That's what i did and it works like a charm...
as always: KNOW WHAT YOU ARE DOING WHEN TINKERING WITH SYSTEM FILES!!! MAKE A BACKUP JUST IN CASE THINGS GO WRONG AND YOU WANT TO REVERT TO AN OPERATING STATE!!! Don't say i din't warn y'all