@All,
My question is very simple I believe.
The latest RUU release for Sapphire/Magic contains after extraction 2 zip files as follows:
rom.zip
This contains the following files:
android-info.txt
boot.img
recovery.img
spalsh_HTC_Magig.nb0
system.img
userdata.img
rom1.zip
This contains the following files:
boot_special.img
hboot_7200A.nb0
radio.img
Is it possible somehow to combine the above 2 ROM files so that the device can be flashed with one single sappimg.zip file?
I tried combine all above files into one single zip archive, but flashing does not start. maybe I have overlooked something somewhere, or special attention have to be given to some config file or something have to be added maybe?
I do not want to flash via RUU package, only via card method. Any suggestions as to how the above can be done?
Regards
Every copy of noogie.img.gz I get I am unable to extract as all the instructions I have read require. I have tried Winrar and 7zip, but each say the file is broken. I have downloaded the file from three different locations and it's the same story every time. Noogie.img.gz is a 3MB file that I can only view in 7zip. It shows 11 files (boot.scr, boot.script, cfg.bin etc etc). Is this noogie.img.gz the img or do I need to extract the .gz first to acquire an img?
Edit: I finally found a copy that appears to work. Nook-Root-Kit addictivetips . com . The file is 2.2MB and yields a 77MB (noogie.img) file that is associated with WinImage. When viewed in 7zip it shows the same 11 files. I became impatient, I used it, and it worked. The only issue was the "Root Forever" screen was halfway cut off, and it took several attempts to restart the Nook, but all was well.
Help me unpack .tar.md5. I have Windows 7,8.1 and 10. what program to use to uncompress the file system.img, and system.img.ext4 and the file itself ***.tar.md5
I watched a lot of instructions and downloaded many, many programs ...everywhere says that the file is corrupted...I realized that is not true unpack tar.md5. I'm doing this using total commander.I just wash the end of the tar.md5. and write zip
My phone G900F. I have port galaxy s6 G920F ror my G900F
I recently unpacked a system.img using this post http://forum.xda-developers.com/pocket-neo/general/guide-extract-factory-samsungs-img-file-t3184278. If your trying to get into a tar.md5 rename it to just "tar" and use something like winrar to open it up and pull the IMG file you want.
I've downloaded the latest firmware from Sammobile for my phone (G950FXXU1CRB7_G950FOXM1CRB9_BTU.zip - no carrier, UK) and I'm now trying to flash it. I tried to use Flashfire, but it doesn't run properly (it starts up, runs through some checks and then just returns to home screen), so I figured that, being a Linux user, I'd use Heimdall. I do have TWRP on the phone, but, as far as I can tell, the files aren't compatible for flashing with TWRP.
I unzipped the zip file resulting in a bunch of tar.md5 files, which (based on a guide I found online) I renamed to .tar files:
AP_G950FXXU1CRB7_CL12993647_QB17006525_REV00_user_low_ship_meta.tar
BL_G950FXXU1CRB7_CL12993647_QB17006525_REV00_user_low_ship.tar
CP_G950FXXU1CRAP_CP8821295_CL12993647_QB16754748_REV00_user_low_ship.tar
CSC_OXM_G950FOXM1CRB9_CL12993647_QB17217244_REV00_user_low_ship.tar
HOME_CSC_OXM_G950FOXM1CRB9_CL12993647_QB17217244_REV00_user_low_ship.tar
I then untarred these and got some .lz4 files ( a completely new extension to me):
boot.img.lz4
cache.img.lz4
cm.bin.lz4
modem.bin.lz4
modem_debug.bin.lz4
omr.img.lz4
param.bin.lz4
recovery.img.lz4
sboot.bin.lz4
system.img.lz4
up_param.bin.lz4
userdata.img.lz4
I assume I'm supposed to extract these using lz4?
Which files should I then flash? I'm assuming recovery.img will overwrite TWRP?
phunni said:
I've downloaded the latest firmware from Sammobile for my phone (G950FXXU1CRB7_G950FOXM1CRB9_BTU.zip - no carrier, UK) and I'm now trying to flash it. I tried to use Flashfire, but it doesn't run properly (it starts up, runs through some checks and then just returns to home screen), so I figured that, being a Linux user, I'd use Heimdall. I do have TWRP on the phone, but, as far as I can tell, the files aren't compatible for flashing with TWRP.
I unzipped the zip file resulting in a bunch of tar.md5 files, which (based on a guide I found online) I renamed to .tar files:
AP_G950FXXU1CRB7_CL12993647_QB17006525_REV00_user_low_ship_meta.tar
BL_G950FXXU1CRB7_CL12993647_QB17006525_REV00_user_low_ship.tar
CP_G950FXXU1CRAP_CP8821295_CL12993647_QB16754748_REV00_user_low_ship.tar
CSC_OXM_G950FOXM1CRB9_CL12993647_QB17217244_REV00_user_low_ship.tar
HOME_CSC_OXM_G950FOXM1CRB9_CL12993647_QB17217244_REV00_user_low_ship.tar
I then untarred these and got some .lz4 files ( a completely new extension to me):
boot.img.lz4
cache.img.lz4
cm.bin.lz4
modem.bin.lz4
modem_debug.bin.lz4
omr.img.lz4
param.bin.lz4
recovery.img.lz4
sboot.bin.lz4
system.img.lz4
up_param.bin.lz4
userdata.img.lz4
I assume I'm supposed to extract these using lz4?
Which files should I then flash? I'm assuming recovery.img will overwrite TWRP?
Click to expand...
Click to collapse
Yes you can use "unlz4" to decompress those. recovery.img will overwrite TWRP.
Excellent - thank you. Do I need to flash all the others? What about the modem_debug file?
phunni said:
Excellent - thank you. Do I need to flash all the others? What about the modem_debug file?
Click to expand...
Click to collapse
Hi
How did you get on?
Im new to all this flashing and appeared to have bricked my Samsung S8 with the same AP_G950FXXU1CRB7_CL12993647_QB17006525_REV00_user_low_ship_meta.tar.md5 as you and im also on a Mac
Ive found that Heimdall is about the only software that will connect to the phone but just where does everything go?
https://imgur.com/a/qe1cqh0
Any help would be appreciated
phunni said:
Excellent - thank you. Do I need to flash all the others? What about the modem_debug file?
Click to expand...
Click to collapse
I'm trying to do the same thing but whenever I use unlz4 or lz4 - d boot.img.lz4 I get an error "Error 64: Does not support stream size". I'm using Debian 8.11.
Can you tell me how you you uncompressed the files or what might be causing my error?
Cheers,
While trying to modify my KW88 Pro watch to run AsteroidOS I took the advice of the program and clicked "Format All + Download" without fully understanding what it does. It deletes all partitions. The install then failed with some random errors but I had a brick. I managed to recover it with KW88 Pro firmware (KW88Pro_V1.5_NHH_B_20190114) I found on discourse.fullandroidwatch.com (don't know how legit it is but at least it works now).
While this guide is how to fix the "PMT changed for the ROM, it must be downloaded" error, the above is relevant. You must find firmware for your watch that has the default partition layout if you did not take a backup before formatting or if you don't know the partition layout. In a nutshell you get the PMT error when the partition layout of the scatter file does not match the partition layout of the device, and the stock firmware + scatter file is needed as a reference point. My error:
https://imgur.com/aFZKfOo
Let's compare the start addresses of those 3 partitions to the stock firmware:
https://imgur.com/rV3XBt2
Boot and Logo partitions are the same, but User Data starts at a different address.
If we compare the contents of both the scatter files we see the same thing:
https://imgur.com/OYw10d3
https://imgur.com/DNQ1Ztw
In a nutshell what you need to do is clone the partition layout (start address variables + offset variable) into the new scatter file, but maintain all other variables of the scatter file. It should also be mentioned that there are other partitions in the scatter file that I had from AsteroidOS that did not match the physical layout of the firmware I used, and even though I was not flashing them I still had to edit the scatter file.
Afterwards using these settings I flashed successfully:
https://imgur.com/TdVRDEV
I also want to note that the End Addresses will not match even with the correct partition layout because different firmware has different sizes on disk, despite the space allocated for the partitions. In theory if you want you could reclaim unused space by tweaking the original scatter file and then the custom scatter file, but it may also impact your future updates if the partition is too small.
Hope I made someone's day easier, best of luck
Can you explain the getting the partition start and offset address part?
Because I think im going to brick my phone really soon if I can't make this auto-generated scatter I got from internet work to flash my phone back to stock rom.
The scatter itself already has some bugs with userdata partition (Too large)
kutiz21 said:
Can you explain the getting the partition start and offset address part?
Because I think im going to brick my phone really soon if I can't make this auto-generated scatter I got from internet work to flash my phone back to stock rom.
The scatter itself already has some bugs with userdata partition (Too large)
Click to expand...
Click to collapse
Sure thing. The scatter file which is for stock firmware vs. the file for new firmware will not allocate the space on disk based on what partitions are actually, physically on it. The new scatter file for custom firmware will be for what the devs had on their device, but not what you actually have on yours (different hardware versions, android releases, w.e.). What you need to do is take the existing partitions of your device, the start addresses for them, add the size of that partition to get the end address and using that information supply that data to the new scatter file. You COULD in theory also change the partition sizes but that is more prone to error so I did not recommend that. So what I did would visually look like this, the | are partition start / end markers
Original scatter file:
|xxxxxxxxxxx||xxxxxxxxxxx||xxxxxxxxxxxxxxxxxxxxxxxxxxx||xxxxxxxxxxxxxxxxxxxxxx||xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx||xxxxxxxxxxxxx|
vs new scatter file:
|xxxxxxxxxxx||xxxxxxxxxxx||xxxxxxxxxxxxxxxxxxxxxxxxxxx||xxxxxxxxxxxxxxx||xxxxxxxxxxxxxxxxxxxxxxx||xxxxxxxxxx|
vs the patched scatter file:
|xxxxxxxxxxx||xxxxxxxxxxx||xxxxxxxxxxxxxxxxxxxxxxxxxxx||xxxxxxxxxxxxxxx....................||xxxxxxxxxxxxxxxxxxxxxxx....................................................||xxxxxxxxxx........|
Tl;Dr An offset is basically a way of saying address + data/space (until next segment at next address).
Intersting
printf() said:
Sure thing. The scatter file which is for stock firmware vs. the file for new firmware will not allocate the space on disk based on what partitions are actually, physically on it. The new scatter file for custom firmware will be for what the devs had on their device, but not what you actually have on yours (different hardware versions, android releases, w.e.). What you need to do is take the existing partitions of your device, the start addresses for them, add the size of that partition to get the end address and using that information supply that data to the new scatter file. You COULD in theory also change the partition sizes but that is more prone to error so I did not recommend that. So what I did would visually look like this, the | are partition start / end markers
Original scatter file:
|xxxxxxxxxxx||xxxxxxxxxxx||xxxxxxxxxxxxxxxxxxxxxxxxxxx||xxxxxxxxxxxxxxxxxxxxxx||xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx||xxxxxxxxxxxxx|
vs new scatter file:
|xxxxxxxxxxx||xxxxxxxxxxx||xxxxxxxxxxxxxxxxxxxxxxxxxxx||xxxxxxxxxxxxxxx||xxxxxxxxxxxxxxxxxxxxxxx||xxxxxxxxxx|
vs the patched scatter file:
|xxxxxxxxxxx||xxxxxxxxxxx||xxxxxxxxxxxxxxxxxxxxxxxxxxx||xxxxxxxxxxxxxxx....................||xxxxxxxxxxxxxxxxxxxxxxx....................................................||xxxxxxxxxx........|
Tl;Dr An offset is basically a way of saying address + data/space (until next segment at next address).
Click to expand...
Click to collapse
I used Smartphone flash tool version 3 and 5 and I have managed to use my own image to flash numerous phones, encrypted with a key or with no keys (Auth file).
Usually, I would use Google's method of flashing back rom that is using a zip file contains bunch of flashable system images and let fastboot app itself flash it.
I dumped my images using dd tool and img2simg (Full blown raw ext4 file, not sparsed.)
Because fastboot likes sparse images rather than raw ones and flashable sparse images can be easily flashed with SP tool normally (It can make phones bootable but will more likely making phone unbootable most of the time)
I do aware that I need to adjust the address thing. But normally, using the start address based on the scatter. SP app can automatically calculates how large the image and it can prevents you from flashing because it is too large.
But this particular phone won't flash even if it is the stock rom. Which dumped and got its scatter file generated by some sketchy "miracle box".
My best guess is that the scatter file was tied to specific emmc chip and it is not for my phone's emmc so there might be some difference there.
Because when I use the REAL flash scatter file from actual OEM (In this case, Nokia 1, European Variant). It can make my APAC counterpart can be flashed normally, even with my custom sparsed or raw image (These 2 variants were kinda different, technically.)
I would like to point out that newer SP flash tool app tends to hate to co-operate with scatter scripts so that could be a reason (I used older build of version 5 and it only gets the userdata bug, but it does lags the app when the bug "PMT changed for the ROM, it must be downloaded" show up. Because it was a bug and it hadn't fixed in that build, which is fixed in the latest build of SP app when I attempt to flash)
And flashing extracted "stock" rom from flash tool and flash it back over fastboot tool tends to break system OTA and make my phone on bootloop (I highly doubted it was the raw image thing, because of the free space it can allocated. I flashed it raw back then I think because i don't know what happened yet, keep in mind that stock rom images shipped for SP flash tool were most likely in raw state, not compressed like sparse images)
And SP flash tool also hates raw dd images too (too big?????)
So like. What do I need to fix the script? What program that can calculate the exact offset for it? I still be able to flash the stock rom with fastboot fine. But for "unforeseen consequences" that makes it unbootable, I still need it.
Say the scatter is not reliable or doesn't exist. How do I use the readback function and then use some aged apps like MTK droid tool to generate actual offsets and possibly generates scatter for me (Most likely will not work because my phone's Android is too new for it). I used to work with Android 4.2.2 so it's really easy back then.
kutiz21 said:
So like. What do I need to fix the script? What program that can calculate the exact offset for it? I still be able to flash the stock rom with fastboot fine. But for "unforeseen consequences" that makes it unbootable, I still need it.
Say the scatter is not reliable or doesn't exist. How do I use the readback function and then use some aged apps like MTK droid tool to generate actual offsets and possibly generates scatter for me (Most likely will not work because my phone's Android is too new for it). I used to work with Android 4.2.2 so it's really easy back then.
Click to expand...
Click to collapse
I'm not sure how to get the data when no original scatter file exists, I was fortunate enough to find a reference for my stock OS. The other scatter file was for AsteroidOS. I think the easiest way to explain what I did would be to share the scatter files. Effectively start address + partition size should not be larger than the start address of the next partition.
Stock scatter file:
https://pastebin.com/tfFDCPfT
Original AsteroidOS scatter file:
https://pastebin.com/0z7DtL9u
Patched AsteroidOS scatter file:
https://pastebin.com/iiYZTzBt
Take note that in my original post screenshots, AstreroidOS was only flashing 3 partitions (corresponding to the is_download: true/false field of the scatter file). That told me that those were the partitions / boundaries that need to match, the other partitions were irrelevant (for the purpose of flashing anyway). AsteroidOS itself is contained inside the userdata partition, effectively leaving other ~20 partitions as "lower layers" or unused.
printf() said:
I'm not sure how to get the data when no original scatter file exists, I was fortunate enough to find a reference for my stock OS. The other scatter file was for AsteroidOS. I think the easiest way to explain what I did would be to share the scatter files. Effectively start address + partition size should not be larger than the start address of the next partition.
Stock scatter file:
https://pastebin.com/tfFDCPfT
Original AsteroidOS scatter file:
https://pastebin.com/0z7DtL9u
Patched AsteroidOS scatter file:
https://pastebin.com/iiYZTzBt
Take note that in my original post screenshots, AstreroidOS was only flashing 3 partitions (corresponding to the is_download: true/false field of the scatter file). That told me that those were the partitions / boundaries that need to match, the other partitions were irrelevant (for the purpose of flashing anyway). AsteroidOS itself is contained inside the userdata partition, effectively leaving other ~20 partitions as "lower layers" or unused.
Click to expand...
Click to collapse
So my insights were true. It does automatically calculates the free space of a partition to whether allow you to flash or not. But I tried fiddling with it and it doesn't work. I might try to individually comment out those partitions as unflashable and try it out.
One more thing is that I used to had this error. But it will be gone when I explicitly referencing SP flash tool the preloader partition image (flashing it or not doesn't matter) alongside with all of my custom images but they must be fully loaded in the app.
You will not be able to flash if it can't fully loaded all partitions that has the property "is_download: true". Maybe that should allow me to do the flash.
Any more thoughts on " boundary_check and is_reserved"? Because I used to poke with these and managed to flash my other phone successfully.
I don't have the phone to test right now but more food for thought I guess.
Cheers!
kutiz21 said:
Any more thoughts on " boundary_check and is_reserved"? Because I used to poke with these and managed to flash my other phone successfully.
I don't have the phone to test right now but more food for thought I guess.
Cheers!
Click to expand...
Click to collapse
Not sure what is_reserved does, but boundary_check probably validates the scatter file vs. the layout on the disk. If you don't do the check though you are risking overwriting a partition which might be needed for the lower layer functionality - keystore, firmware, etc.