Related
In the Excalibur forum we are struggling to flash a file to a particular offset in NAND (samsung onedisk flash). The file is 4Mbyte and was dumped with bkondisk (by itsme). Deploying pof's ideas, I have patched Excalibur SPL which bypasses vendor/model and signature checking and raises security level to 0. Using this SPL the flash commands can be used w/o restrictions
A similar patched bootloader exists for Vox S710. That SPL includes same commands as the Excalibur SPL.
The SPL offers 2 commands to interactively flash files from MTTY: ls ("load signed"??) and lnbs ("load new binary signed"??)
Afaik the commands are invoked as:
Code:
lnbs [pathname [StartAddr [Length [SkipOffset ["cp"]]]]]
ls [pathname [StartAddr [Length [SkipOffset ["cp"]]]]]
The question is what format the files must have and how to figure out start address. I found some info in the Hermes Wiki. I also suggested Excalibur various tests:
1. The file test3.nbs in this case has a 0x20 byte header ("R000FF") which includes data blocksize and signature size and flag. But somehow it doesn't like the start address of which I also don't know how to figure it out for the various ROM parts. How was that done for Hermes? (reversing SPL or sniffing USB)
Code:
Cmd>lnbs test3.nbs 500a0000
clean up the image temp buffer at 0x8C080000 Length 0x03900000
MTTYDownloadImage "test3.nbs"
:F=test3.nbs
start download
S
HAddress A0000000h Length 0040034Dh
Start Address out of boundary
checking image header
2. The file test.nb w/o any header, just the 4MB binary file with no modifications
Code:
Cmd>ls test.nb 500a0000
clean up the image temp buffer at 0x8C080000 Length 0x03900000
MTTYDownloadImage "test.nb"
:F=test.nb
start download
S
HAddress A0000000h Length 00400000h
Start Address out of boundary
checking image header
3. The file test2.nbh with a full .nbh header and given type 0x300 (GSM Radio code, although the 4MB file also includes config and simlock data etc.). This was actually the most succesful since it passed mosts tests in the SPL. So it seems a valid file, but it couldn't be confirmed that anything was flashed at all.
Code:
Cmd>lnbs test2.nbh 500a0000
clean up the image temp buffer at 0x8C080000 Length 0x03900000
MTTYDownloadImage "test2.nbh"
:F=test2.nbh
start download
S
HAddress 00000000h Length 0040054Dh
Start Address out of boundary
checking image headerFirst MTTY record empty
Image Download Finish... please check your image
Please reset the device to restart the program!!
DownloadImage success.
Can anyone with more knowledge about this subject please drop some feedback? Thx!
Cheers
JockyW
Edit: I totally forgot about the wdata command which is used by the official RUU. It can not be used interactive from MTTY, but it is possible to use it from self written programs. I think the idea is that only signed .nbh files (which include ROM type information in the header) can use be flashed using this command:
Code:
wdata length checksum
Once all data and the last signature (flag == 2) has been sent to SDRAM and all CRC and sig checks are passed the flashing process starts. The funny thing is that the help text of wdata suggests that also unsigned data can be flashed or be dropped at any memory location. Is this intentional deceiving by HTC ??
Code:
Cmd>wdata
Usage:
wdata [StartAddr Len]
Write data to memory(if write to ROM, need erase first).
StartAddr : Start address of memory.
Len : How many bytes will be written.
Length must not more than 0x10000 bytes(buffer limitation).
Write to RAM: 4 bytes(CRC checksum limitation).
1 byte(in user mode).
Write to ROM: 4 bytes(CRC checksum limitation).
2(16-bit)/4(32-bit) bytes(in user mode).
Write to ROM(16-bit data bus): 32 bytes(writebuffer mode).
Write to ROM(32-bit data bus): 64 bytes(writebuffer mode).
Length must be 4 bytes boundary(CRC checksum) if not in user mode.
After command execute, then send out the data to terminal.
Data format: HTCS(4 bytes)+DATA+checksum(4 bytes, if not in user mode)+HTCE(4 bytes).
while flashing test2.nbh, wlan data doesn't be modified.
jockyw2001's question is very important to find our wi-fi back. plz help us!Thanks!
details about our problem and what we have done can be seen at http://forum.xda-developers.com/showthread.php?t=328690
jockyw2001
You may use method imei-check - they for flash of the area CID have changed address of the flash splash screen - hereinafter they form file nbh (consists only of splash screen) with necessary area CID.
arc said:
jockyw2001
You may use method imei-check - they for flash of the area CID have changed address of the flash splash screen - hereinafter they form file nbh (consists only of splash screen) with necessary area CID.
Click to expand...
Click to collapse
Ah great! You've got a link as well? Thx!
Hi jocky,
interesting thing..
why don;t u try its utils for the above and check..
issue pdcocread -l command and get the header and rom address.
then try with lnbs or ls command to flash back.From whatever I know, lnb and lnbs/ls command can b used when yr device is Super CID.
While flahing ROM, RUU issues set le 1 command and write the ROM using wdata command.You can check these things, with USB monitor
hdubli
The commands lnb and lnbs different -
lnb - load the unsigned code.
lnbs- load signed code -have other structure and headline
hdubli said:
issue pdcocread -l command and get the header and rom address.
then try with lnbs or ls command to flash back.From whatever I know, lnb and lnbs/ls command can b used when yr device is Super CID.
Click to expand...
Click to collapse
hi,
pdocread -l returns:
Code:
>pdocread.exe -l
58.82M (0x3ad1000) DSK1:
| 2.09M (0x217400) Part00
| 3.20M (0x333000) Part01
| 53.53M (0x3586800) Part02
59.31M (0x3b4f000) DSK2:
| 59.06M (0x3b0e800) Part00
...
You mean the values in parantheses?
On excalibur only signed data is accepted by ls or lnbs (dunno the difference between the two. Anyone?).
I disassembled spl and found the startaddress boundary check routine. In it I see the hardcoded nand address boundaries which have no resemblance whatsoever with pdocread.
I'm now checking arc's hint to patch splash screen flashroutine in same way as imei-check does it. I just hope I can use ls and lnbs (with USPL of course), since that would be far more comfortable
This tool can be used to either decompile or compile ROMs for various Asus devices that used the ABI firmware format (Can also be used in O2 XDA Zest ). The current version can support P835 unencrypted ABI, and even encrypted ABI from updater EXE! Current finding is this tool also supports unreleased Garmin-Asus ROMs!
Thanks (Especially )Harshal and Leon in AsusPda for testing.
Usage:
- Decompiling ROM
1. p835abisplit2 <abi/exe file>
2. os.nb0 and extrom.img released (Only for Pre-P835 devices), os.nb0 cab be processed by imgfsfromnb or osnbtool, extrom.img can be processed by WinImage.
- Compiling ROM
1. First rename the new os.nb0 to os-new.nb0, and rename extrom.img to extrom-new.img (If the new files do not exist, then the compiler will use the parts from original ROM)
2. p835abisplit2 /b <abi/exe file>
3. out.abi releases, which can be used to flash directly (Only for Pre-P835 devices or Post-P835 devices with unencrypted ROM).
4. If you input the updater EXE to p835abisplit2, it will also produce out.exe with region locked patched which can be used to flash your new ROM directly on devices with any region!
- Note when building ROM
1. If you need to modify XIP, make sure the modded XIP is the same size as the original one before merging back to nb0, otherwise booting will fail
2. For Pre-P835 devices, current version can create big-storage ROMs with variable size of imgfs. If the new OS is smaller than the original one, the freed space will be allocated to user space (The left part as shown in Memory setting) after flashing. However the user space display will only reflect the change on second flash.
3. For Post-P835 devices, all partitions must be exactly same size with the original one (i.e. you need to pad the partition before putting it back), otherwise the device won't boot.
4. For Pre-P835 devices, you can modify ExtROM as you like, but not remove or rebuild the image file, otherwise you may get a brick! (Not able to enter bootloader)
Final Warning: Customizing a ROM always has risks, I won't be responsible for any damages lead to your custom ROM!
Release Notes:
v2.40:
- Added support for M930
v2.32:
- Support extraction of encrypted ABI file resource from P835 updater exe
- Support reconstruction of P835 updater exe
- When rebuild to exe, the produced out.exe is patched to install in devices of any region.
V2.20:
- Support extration and rebuilding of P835 ABI file (Note that not for ABI inside EXE)
- When rebuild with exe, OUT.EXE will be produced for direct flashing
starkwong said:
This tool can be used to either decompile or compile ROMs for various Asus devices that used the ABI firmware format (Can also be used in O2 XDA Zest ).
Thanks Harshal and Leon in AsusPda for testing.
Usage:
- Decompiling ROM
1. p565abisplit2 <abi/exe file>
2. os.nb0 and extrom.img released, os.nb0 cab be processed by imgfsfromnb or osnbtool, extrom.img can be processed by WinImage.
- Compiling ROM
1. First rename the new os.nb0 to os-new.nb0, and rename extrom.img to extrom-new.img (If the new files do not exist, then the compiler will use the parts from original ROM)
2. p565abisplit2 /b <abi/exe file>
3. out.abi releases, which can be used to flash directly.
- Note when building ROM
1. If you need to modify XIP, make sure the modded XIP is the same size as the original one before merging back to nb0, otherwise booting will fail
2. OS part doesn't need to be the same size as the original. If the new OS is smaller than the original one, the freed space will be allocated to user space (The left part as shown in Memory setting) after flashing. However the user space display will only reflect the change on second flash.
3. You can modify ExtROM as you like, but not remove or rebuild the image file, otherwise you may get a brick! (Not able to enter bootloader)
Final Warning: Customizing a ROM always has risks, I won't be responsible for any damages lead to your custom ROM!. Moreover, don't use it in P835 abi, it won't work
Click to expand...
Click to collapse
Nice we all waiting for it
Many Congrats for successfully ripping through the ROM !!
Partition offsets and checksums reported by the tool are :
Part #0002 sz:0003e000=>0003e000 cs:625f94b2=>625f94b2 of:000003a0=>000003a0
Part #0004 sz:00100000=>00100000 cs:ffe5f731=>ffe5f731 of:0003e3a0=>0003e3a0
Part #0103 sz:00452a8c=>00452a8c cs:99f65978=>99f65978 of:0013e3a0=>0013e3a0
Part #0104 sz:000fffc0=>000fffc0 cs:5e03943f=>5e03943f of:00590e2c=>00590e2c
Part #0005 sz:07e00000=>07e00000 cs:674f4072=>674f4072 of:00690dec=>00690dec
Part #0013 sz:00a00000=>00a00000 cs:56994bf9=>56994bf9 of:08490dec=>08490dec
I am a little scared to use this tool for following reasons :
1. Actually, the IMGFS & ExtROM offsets are '00690dfc' & '08490dfc' respectively.
2. Checksums( 674f4072, 56994bf9....) can not be located in the Header.
3. The Adler32 checksum for the ExtROM is '5ff94bfa', while your tool reports '56994bf9'.
Any clues ?
rishi2504 said:
Many Congrats for successfully ripping through the ROM !!
Partition offsets and checksums reported by the tool are :
Part #0002 sz:0003e000=>0003e000 cs:625f94b2=>625f94b2 of:000003a0=>000003a0
Part #0004 sz:00100000=>00100000 cs:ffe5f731=>ffe5f731 of:0003e3a0=>0003e3a0
Part #0103 sz:00452a8c=>00452a8c cs:99f65978=>99f65978 of:0013e3a0=>0013e3a0
Part #0104 sz:000fffc0=>000fffc0 cs:5e03943f=>5e03943f of:00590e2c=>00590e2c
Part #0005 sz:07e00000=>07e00000 cs:674f4072=>674f4072 of:00690dec=>00690dec
Part #0013 sz:00a00000=>00a00000 cs:56994bf9=>56994bf9 of:08490dec=>08490dec
I am a little scared to use this tool for following reasons :
1. Actually, the IMGFS & ExtROM offsets are '00690dfc' & '08490dfc' respectively.
2. Checksums( 674f4072, 56994bf9....) can not be located in the Header.
3. The Adler32 checksum for the ExtROM is '5ff94bfa', while your tool reports '56994bf9'.
Any clues ?
Click to expand...
Click to collapse
Tool works properrly.No harm is trying
starkwong, is there any tool to decompile P835's ROM in the same way?
New version posted.
rishi2504:
The image checksum is not calculated by plain Adler32, actually is uses the same formula as older Asus ROMs, however it is not a one-time calculation.
Checksums are inside header, given you decoded it correctly.
starkwong, here's what I get when trying to decompile a ROM:
Code:
v2.40 (Jun 16 2009 19:56:06)
ExtractABI(): Trying to load G5_ALL_V4.11.0_V3.6.12.P2_Ship_WWE_app_MYS00_V2.3.6.exe...
Module loaded, searching for BIN resource...
Found matching resource at BIN #211!
GetPartitions(): Getting Partition Information...
*** Encrypted ABI detected
ABI Version 0x00030012
Project Name: G5
Partition Type: 000f [email protected]
Partition Type: 000e [email protected]
Partition Type: 000e [email protected]
Partition Type: 0004 [email protected]
Partition Type: 0004 [email protected]
Partition Type: 000f [email protected]
Partition Type: 000f [email protected]
Partition Type: 0102 damage [email protected]
Partition Type: 0005 UnKnown [email protected]
Partition Type: 0002 [email protected]
Partition Type: 0003 [email protected]
ProcessABI(): Writing OS data...
* BIN(P835) Image Detected
Warning: OS.nb0/flash.bin is not a NB image, not modifying MSFLSH50 headers
ProcessABI(): No ExtROM partition found.
OK!
So it seems that partitions are not detected correctly, there's no os.nb0 at the output, and the flash.bin apperars to be of no use. Even when I found imgfs partition inside of it, there's still something wrong with it, e.g. bad start block offset, and everything else is also broken.
Can you help me with this?
In fact it is correct, as Asus uses B000FF image on P835, not a plain NB0 image.
You need to use osnbtool to get a nb0 with extra bytes, then use nbsplit -data 2048 -extra 8 to get a nb0 with sector size 0x800.
ginkage said:
starkwong, here's what I get when trying to decompile a ROM:
Code:
v2.40 (Jun 16 2009 19:56:06)
ExtractABI(): Trying to load G5_ALL_V4.11.0_V3.6.12.P2_Ship_WWE_app_MYS00_V2.3.6.exe...
Module loaded, searching for BIN resource...
Found matching resource at BIN #211!
GetPartitions(): Getting Partition Information...
*** Encrypted ABI detected
ABI Version 0x00030012
Project Name: G5
Partition Type: 000f [email protected]
Partition Type: 000e [email protected]
Partition Type: 000e [email protected]
Partition Type: 0004 [email protected]
Partition Type: 0004 [email protected]
Partition Type: 000f [email protected]
Partition Type: 000f [email protected]
Partition Type: 0102 damage [email protected]
Partition Type: 0005 UnKnown [email protected]
Partition Type: 0002 [email protected]
Partition Type: 0003 [email protected]
ProcessABI(): Writing OS data...
* BIN(P835) Image Detected
Warning: OS.nb0/flash.bin is not a NB image, not modifying MSFLSH50 headers
ProcessABI(): No ExtROM partition found.
OK!
So it seems that partitions are not detected correctly, there's no os.nb0 at the output, and the flash.bin apperars to be of no use. Even when I found imgfs partition inside of it, there's still something wrong with it, e.g. bad start block offset, and everything else is also broken.
Can you help me with this?
Click to expand...
Click to collapse
B000FF image cannot be modified without osnbtool or viewbin or cvrtbin tool..For Ext ROM there is no partition in the abi file which can b read as .nb0 Ext ROM is inside the OS and is not as a partition.So what the output u get from the tool is correct.Whatever ROMs u saw mine are from using the same tool
I hope this clarifies.
starkwong, Thank you so much, it worked perfectly!
Can't use this tool on my Asus M530w. Getting this message:
Copyright(C) 2009 Studio KUMA(starkwong). All rights reserved
v2.40 (Jun 16 2009 19:56:06)
ExtractABI(): Trying to load nk.abi...
Failed loading as module (193). Perhaps ABI?
Trying as ABI directly...
Creating file mapping...
GetPartitions(): Getting Partition Information...
Error: AES Key not suitable for this ROM
unencrypted vers encrypted
There is little bit mess in description.
If you will use unecrypted rom + p835abisplit2 you will get os.nb0.
With encrypted rom + p835abisplit2 you will get flash.bin.
starkwong said:
4. For Pre-P835 devices, you can modify ExtROM as you like, but not remove or rebuild the image file, otherwise you may get a brick! (Not able to enter bootloader)
Click to expand...
Click to collapse
Hi,
Can i add my own cab/xml files to this Ext_ROM, after removing the files not needed ?
rishi2504 said:
Hi,
Can i add my own cab/xml files to this Ext_ROM, after removing the files not needed ?
Click to expand...
Click to collapse
Don't bother dude , figured it out ...
Is there anyway I can extract the flash.bin file from a .abi file using this tool?
My P835 is unable to upgrade from the SD card with the .abi file on it.. so I wanted to extract the flash.bin and see if I can use the QPST tool to update the image with flash.bin file..
Sorry if I'm being stupid here (not unusual!). I'm trying to use this tool to get a .abi file out of O2's "Xda_Zest Firmware Update_V7.7.0S.WWE20.00_M4.6.5.P7_V2.1.4 GBR20.exe" so I can stick it on the SD card and flash the ROM, but of course I'm only ending up with the two files you mention, os.nb0 and extrom.img, no .ABI file. I can look in the extrom.img file with winrar, but the file only contains FINDMA~1.000 (300 bytes), 000dummy.001 (0 bytes) and _setup.xml (1205 bytes).
Plainly I'm thick - where am I going wrong, and how do I get the .ABI file?
Basically u need adb/android SDK before proceed.
[WITH ROOT ACCESS]
[+] Dump/copy boot.img
Code:
Command prompt :
> adb shell
> su
> dd if=/dev/block/mmcblk0p4 of=/sdcard/boot.img
More partition/img availabe to dump. Will update later.
[WITHOUT ROOT ACCESS]
Currently only /system is usable
1) Android SDK (just need adb)
2) Download busybox
3) Command prompt :
> adb push busybox /data/local/busybox
> adb shell
> cd /sdcard/
> chmod 755 /data/local/busybox
> /data/local/busybox tar cvf sysdump.tar /system
4) Ignore tar: error exit delayed from previous errors'. Is done correctly.
----------------------------------------------------------------------
Just finished dumped my semi-virgin One X system partition from SEA WWE stock ROM .
The file would be OneX_SEA_WWE_1.26.707.2_SYSTEM_DUMP.zip 558.3 MB
Hi,
can you tell me how to dump mine? My phone arrives tomorrow.
Thanks in advance...
@anko
Thread updated with guide.
so, is it true that i can simply download the system dump from the link your provide, and flash it via recovery if i want to go back to stock SEA rom?
by the way, i am using a SEA htc one X too.
ck_looi said:
so, is it true that i can simply download the system dump from the link your provide, and flash it via recovery if i want to go back to stock SEA rom?
by the way, i am using a SEA htc one X too.
Click to expand...
Click to collapse
not sure & never try
it was dumped before i unlock my device.
see here if u want unlock & backup ur stock rom including boot image. do nandroid backup after flashing Interim CWM. Then only restorable. (boot .img still hv to flash thru fastboot to restore or use new method by blubbers)
my current stock is 1.26.707.4
will i be able to flash this and then get update to 707.4 OTA? Just want to make sure i got the right stock rom for my one x.
Picked mine up today going to do system dump of mine its on t-mobile software is 126.110.5
Sent from my HTC One X using XDA
monx® said:
Basically u need adb/android SDK before proceed.
[WITH ROOT ACCESS]
[+] Dump/copy boot.img
Code:
Command prompt :
> adb shell
> su
> dd if=/dev/block/mmcblk0p4 of=/sdcard/boot.img
More partition/img availabe to dump. Will update later.
Click to expand...
Click to collapse
i just dump boot (mmcblk0p4) and system (mmcblk0p12). is that good enough? (maybe recovery partition) I assume i would use fastboot flash to flash this image if I want to revert to stock?
zenkinz said:
i just dump boot (mmcblk0p4) and system (mmcblk0p12). is that good enough? (maybe recovery partition) I assume i would use fastboot flash to flash this image if I want to revert to stock?
Click to expand...
Click to collapse
Yes but RUU 1.26.707.4 is available (at least for our region). better extract *.img directly.
monx® said:
Yes but RUU 1.26.707.4 is available (at least for our region). better extract *.img directly.
Click to expand...
Click to collapse
ok thanks.
I've done Paul's procedure to Unlock + Interim CWM + SU, so now I'm rooted with S-On. After which I've done full backup thru interim CWM recovery prior to uninstalling bloatwares and I'm still now on stock ROM.
How different is this backup then? Back to stock?
Sent from my HTC One X using xda premium
Gday, now this looks like it spits out a tar file, I assume this is flashable through fastboot? I'm just trying to put together a fastboot flashable img of my providers stock rom for another user...
Edit, I might be being stupid, but shouldn't adb pick up the stock rom when connected and booted into rom? Put usb connection into usb host mode...
M.
2nd method works great...
monx® said:
Basically u need adb/android SDK before proceed.
[WITH ROOT ACCESS]
[+] Dump/copy boot.img
Code:
Command prompt :
> adb shell
> su
> dd if=/dev/block/mmcblk0p4 of=/sdcard/boot.img
More partition/img availabe to dump. Will update later.
[WITHOUT ROOT ACCESS]
Currently only /system is usable
1) Android SDK (just need adb)
2) Download busybox
3) Command prompt :
> adb push busybox /data/local/busybox
> adb shell
> cd /sdcard/
> chmod 755 /data/local/busybox
> /data/local/busybox tar cvf sysdump.tar /system
4) Ignore tar: error exit delayed from previous errors'. Is done correctly.
----------------------------------------------------------------------
Just finished dumped my semi-virgin One X system partition from SEA WWE stock ROM .
The file would be OneX_SEA_WWE_1.26.707.2_SYSTEM_DUMP.zip 558.3 MB
Click to expand...
Click to collapse
Does this work on other models?
helloansuman said:
2nd method works great...
Click to expand...
Click to collapse
Hi, I was curious if this worked on other models specifically the xperia arc so-01c. I wish to dump a japanese docomo rom that I guess is pretty rare for English websites. Thanks in advance. AJ
I already have my boot.img and what not just need to dump my boot.img-kernel... How to?
2nd method works great on other phone thankx man!
just tell us one more thing that how to dump boot/kernel in the same is it possible or not ??
Hi
My device is rooted an i accidentally deleted NVRAM Partition And now imei is null and not signal
NVRAM Partition is not in FTF file so, I kindly ask if someone with a rooted Xperia M5 running stock firmare (the firmware version/device variant doesn't matter, it can be from doul SIM devices too) could run the following commands from ADB and then upload the file that will be pulled from the phone here:
adb shell su -c "dd if=/dev/block/platform/mtk-msdc.0/by-name/nvram of=/data/local/tmp/nvram.img"
adb shell su -c "chmod 777 /data/local/tmp/nvram.img"
adb pull /data/local/tmp/nvram.img"
DO NOT EVER flash the NVRAM or TA partition of another device, even if it's from exactly the same model. You'll hard brick your device by doing that, those partitions are unique to each unit, that's why they're not available in FTF...
mbc07 said:
DO NOT EVER flash the NVRAM or TA partition of another device, even if it's from exactly the same model. You'll hard brick your device by doing that, those partitions are unique to each unit, that's why they're not available in FTF...
Click to expand...
Click to collapse
I have a backup of TA partitions can this help me to solve this problem?
what i do to restore it?
What do you think I should do?
(sorry for my poor English)
How to backup partition images with dd on the command line (root required)
We don't currently have a working custom recovery for the Xperia 10 III, but if you have root there's a simple method to dump partition images.
This is a very good idea and you should do it at least once, especially if you like to mess around the device a lot.
You won't be able to do this before you root, so by the time you do some partitions will not be stock anymore. Use XperiFirm instead to get the clean stock images.
Special partitions:
The userdata partition holds all your personal files and system settings. It's huge (about 105 GB) and obviously you can't dump it into itself. You can dump it on an SD card if it's 128+ GB.
The super partition is a physical partition that contains several logical partitions (including system and vendor) That's why you won't find those in the partition list. This is done on Android 10+ devices to allow those logical partitions to be resized or rearranged as needed. You don't need to split out the internal logical partitions, you can flash back the entire super partition. The stock firmware also comes with a super image, not individual logical partitions.
Using a helper script:There's a Magisk module called Backup (by Draco) which gives you a command line shell script you can use if you prefer. It mostly does the same things I described above. The script is here if anybody wants to just grab it directly.
On the plus side, the script knows to dump only the active A/B image (which is the one that interests you most). On the flip side, it doesn't have a feature to skip userdata.
So here is a shell command that will use the backup script to dump all partitions, but only those matching your device's active A/B slot, and skips userdata:
Code:
backup $(ls /dev/block/bootdevice/by-name/ | grep -v userdata | sed 's/_[ab]$//')
And here's one that also skips super:
Code:
backup $(ls /dev/block/bootdevice/by-name/ | grep -v userdata | grep -v super | sed 's/_[ab]$//')
How to dump partitions manually:If you can't/won't use the helper script you can do it by hand. All the following commands need root:
Find the names of all the partitions:
Code:
ls /dev/block/bootdevice/by-name/
Dump one specific partition identified by NAME:
Code:
dd if=/dev/block/bootdevice/by-name/NAME of=NAME.img
Dump all partitions except userdata:
Code:
ls /dev/block/bootdevice/by-name/ | grep -v userdata | while read NAME; do echo dd if=/dev/block/bootdevice/by-name/${NAME} of=${NAME}.img; done
Find the active slot:
Code:
getprop ro.boot.slot_suffix
Get checksums for all the images after the dump:
Code:
md5sum *.img
Confused about _a and _b partitions?You should read about A/B Seamless Updates.
Long story short, some partitions have two copies eg. boot_a and boot_b. When you boot up the device you use the partitions in one slot (eg. the _a partitions). When an OTA update is being downloaded, it writes into the partitions for the other slot (eg. the _b partitions). Your phone can stay in use while this happens. If the OTA fails nothing is broken, you just keep using the good slot partitions. After the OTA is successful you switch to the other slot and also have the previous version in the other slot in case you need to switch back.
This means that some of the _a and _b images for the same partition can be different for you! So it's strongly recommended to do the checksums, and also to find out which is your active slot, so you know which partitions you're using right now.
I used a 128 GB card to take a backup of userdata. The backup script had some trouble with the backup location being on the storage card for some reason and I didn't have time to figure it out, but the dd command I gave above worked fine.
Code:
# time dd if=/dev/block/bootdevice/by-name/userdata of=userdata.img
112111374336 bytes (104 G) copied, 2342.274225 s, 46 M/s
39m02.31s real 1m11.78s user 14m44.72s system
Code:
# adb pull /storage/1234-ABCD/backup/userdata.img ./
/storage/1234-ABCD/backup/userdata.img: 1 file pulled, 0 skipped.
87.2 MB/s (112111374336 bytes in 1225.663s)
So that's 104 GB that took 39 minutes to be written to a new Samsung Evo U3/V30 microSDXC (46 MB/sec real write speed) and 20 minutes to be read to the PC (Samsung Evo M.2) with adb pull over USB (87 MB/sec read speed). Just so you know what you're in for.
I was looking into whether I could speed up the process of taking userdata snapshots by dumping the partition directly to the PC, but you need to be root to access the device block. The stock ROM doesn't allow the command adb root, but I found this blog post which made me realize you can run a su -c command that asks dd to write to stdout and just pipe the output to a file. The post author has also made this helpful Python script which lets you do pulls and pushes with root-only files.
If you want to run the command directly (I've only tested on Linux, no idea if it works on PowerShell but it might):
Code:
# adb shell "su -c" "dd if=/dev/block/bootdevice/by-name/userdata" > userdata.img
If you want to use the Python script:
Code:
# adb-root.py pull /dev/block/bootdevice/by-name/userdata userdata.img
Using the same fast SSD on the PC side as above, I now get:
Code:
218967528+0 records in
218967528+0 records out
112111374336 bytes (104 G) copied, 1077.681097 s, 99 M/s
real 17m57.910s
So that's roughly 15 minutes compared to 1 hour total with the previous method and you don't need to have a 128 GB SD card anymore.
Are you able to switch to a different backup location? Say a USB OTG if possible.
mikeshutte said:
Are you able to switch to a different backup location? Say a USB OTG if possible.
Click to expand...
Click to collapse
With dd yes, simply move to the directory you want before you call dd.
The backup script is bugged and seems to ignore the -d parameter for the backup location so it always uses /sdcard/backup. (I think it might be expecting a different version of getopts...) Normally I would say to try creating a symlink from /sdcard/backup to the OTG storage but the ln utility is also behaving strangely and I can't make any symlinks (even with root).
wirespot said:
With dd yes, simply move to the directory you want before you call dd.
The backup script is bugged and seems to ignore the -d parameter for the backup location so it always uses /sdcard/backup. (I think it might be expecting a different version of getopts...) Normally I would say to try creating a symlink from /sdcard/backup to the OTG storage but the ln utility is also behaving strangely and I can't make any symlinks (even with root).
Click to expand...
Click to collapse
Ok I'll give it a try and see what happens. Thanks for your help.
Hi, I'm used to TWRP backups, so I don't really understand this tool. I've backedup everything except the massive userdata partition. If needed, how would I restore this? Is the userdata partition required when I have all the others?
Thanks!
jakito said:
Hi, I'm used to TWRP backups, so I don't really understand this tool. I've backedup everything except the massive userdata partition. If needed, how would I restore this? Is the userdata partition required when I have all the others?
Thanks!
Click to expand...
Click to collapse
This is basically the same thing that TWRP does, dd is a command line Linux tool that makes a "raw" copy of a partition.
Restoration is a bit more tricky. In theory you can simply dump the raw backup copy over the partition. The problem is that it's not ok to do it while the system is running. Typically it's done by booting into recovery (TWRP) and overwriting the partition from there.
Another method for restore is to use fastboot, which is an alternative tool you can boot into that only does one thing, write partitions. But fastboot is typically locked by the vendor to only write signed images, so it can only be used to write official release ROMs.
There are some limited uses for fastboot, such as overwriting the boot partition, which is not checked for signature anymore once you've unlocked the bootloader. So if you want to experiment with unofficial kernels and mess something up you can always restore a good boot partition with fastboot.
TLDR: for the time being until we get a working TWRP recovery the most you can do is take backups, but not restore them.
wirespot said:
This is basically the same thing that TWRP does, dd is a command line Linux tool that makes a "raw" copy of a partition.
Restoration is a bit more tricky. In theory you can simply dump the raw backup copy over the partition. The problem is that it's not ok to do it while the system is running. Typically it's done by booting into recovery (TWRP) and overwriting the partition from there.
Another method for restore is to use fastboot, which is an alternative tool you can boot into that only does one thing, write partitions. But fastboot is typically locked by the vendor to only write signed images, so it can only be used to write official release ROMs.
There are some limited uses for fastboot, such as overwriting the boot partition, which is not checked for signature anymore once you've unlocked the bootloader. So if you want to experiment with unofficial kernels and mess something up you can always restore a good boot partition with fastboot.
TLDR: for the time being until we get a working TWRP recovery the most you can do is take backups, but not restore them.
Click to expand...
Click to collapse
I see. Thank you nonetheless!
wirespot said:
This is basically the same thing that TWRP does, dd is a command line Linux tool that makes a "raw" copy of a partition.
Restoration is a bit more tricky. In theory you can simply dump the raw backup copy over the partition. The problem is that it's not ok to do it while the system is running. Typically it's done by booting into recovery (TWRP) and overwriting the partition from there.
Another method for restore is to use fastboot, which is an alternative tool you can boot into that only does one thing, write partitions. But fastboot is typically locked by the vendor to only write signed images, so it can only be used to write official release ROMs.
There are some limited uses for fastboot, such as overwriting the boot partition, which is not checked for signature anymore once you've unlocked the bootloader. So if you want to experiment with unofficial kernels and mess something up you can always restore a good boot partition with fastboot.
TLDR: for the time being until we get a working TWRP recovery the most you can do is take backups, but not restore them.
Click to expand...
Click to collapse
I don't know how I ended up but making a backup you can't restore is completely pointless.
Techguy777 said:
I don't know how I ended up but making a backup you can't restore is completely pointless.
Click to expand...
Click to collapse
No, it's not. All your data is in there. You can mount your backup on a linux computer and pull out apks as well as app data. You can then restore these folder by folder with adb and a root shell on your phone.
That beeing said, does anyone know a proper backup software like Titanium Backup for Android 11 and above? Sometimes I read recommendations, but looking at the ratings it seems that no software manages to achieve the same level of comfort and control. Also they all seem to suffer from the same limitations.
Let's be honest: Google wants to make your life hard, so they can lock you in.
@xperinaut
I'm using Titanium on Android 11. Is it not working for you?