Related
This thread is dedicated to booting Qualcomm Snapdragon-based Samsung Galaxy S3 models from an SD card.
As I understand it, this only works because the Snapdragon boot ROM (NOT the bootloader, which resides on the eMMC - this is part of the CPU) has a fallback mode which reads the bootloader from an SD card if the eMMC fails. To date, the only devices I am aware of that have this fallback mode are the Snapdragon Galaxy S3 models designed for use in the US. As such, this will not work on international/Exynos based phones.
The process of preparing an SD card for this is fairly simple. All that is needed is a working, rooted phone and an empty SD card.
The dumps at the end of this post were obtained by various people using a variant of the following command:
Code:
busybox dd if=/dev/block/mmcblk0 of=/sdcard/backup.bin bs=1M count=70
Depending on the device, you may need more than 70MB, but on the Sprint Galaxy S3, the first 70MB of the eMMC contains everything needed for download mode without including identifying information in the dump, like the EFS partition for example.
If you are absolutely certain your SD card is empty, you can change the dd command to "of=/dev/block/mmblk1" to write the eMMC backup image directly to the SD card instead of to a file. Be very careful working with dd! mmcblk0 is the eMMC and mmcblk1 is the external SD card.
This should be obvious, but cross-device dumps will not work! This is the main reason so many people are finding themselves in need of this guide!
Use common sense - do your research and don't cross-flash, especially between US and international ROMs!
If your model is not listed there, search the forums or ask someone to make a dump for you.
Please note: if your phone model is not listed here, that doesn't mean this method won't work - however, I would appreciate it if everyone would do their research instead of bombarding me with private messages.
I hope this helps! Flash wisely!
For posterity, this is the content of the OP that led me to discover the SD boot mode by accident:
I am trying to fix a 16GB Sprint Samsung Galaxy S3 that went through a rooting process and failed, leaving download mode and most other recovery options inaccessible.
I don't have a USB download mode jig or JTAG equipment, but I noticed it's recognized as "05c6:9008 Qualcomm, Inc. Gobi Wireless Modem (QDL mode)" when connected to a Linux computer.
From what I've read, not many people have gotten it out of this mode, however, I've found guides that imply the NAND/eMMC is writable in this mode with qdload.pl. None of the files I've seen want to be flashed with this tool - the generic, unsigned 8960_msimage.mbn/MPRG8960.hex files to get it into EMMC USB storage mode don't execute/stay intact after flashing, so I'm guessing they failed the signature check.
Is anyone willing to dump the partition table/bootloader from their working 16GB Sprint SGS3 for me?
Code:
dd if=/dev/block/mmcblk0 of=/sdcard/backup.bin bs=1048576 count=70
I unfortunately don't know what stages of the bootloader were corrupted, and I'm not sure what address to flash aboot to, if that's even possible with qdload.
Downloads:
Sprint SPH-L710: http://www.mediafire.com/download/231uhy6l80jx74n/debrick_sph_l710.img.xz (Thanks @CNexus!)
AT&T SGH-i747: http://d-h.st/iEy (Thanks @Android_Geeek!)
T-Mobile SGH-T999: http://www.mediafire.com/download/grgyera66w0rt25/debrick_SGH-T999.img (Thanks @Techlyfe!)
Sure, gimme a sec.
EDIT: You know you can find these in the firmware zips freezes has in his thread, right?
CNexus said:
Sure, gimme a sec.
EDIT: You know you can find these in the firmware zips freezes has in his thread, right?
Click to expand...
Click to collapse
I've been looking around for stock firmware packages and couldn't find them. I'll look a little harder...
EDIT: This? sbl1.mbn? Downloading it, but I'll be pretty disappointed if it doesn't work after using ~700MB...
Top of this thread you will find all the latest MD4 stuff
http://forum.xda-developers.com/showthread.php?p=32176586
Sent from the future via Tapatalk 4
No, the firmware zips, not the ROMs
And yes. The bootloaders are there, they're smaller, like 20~ MB
Grab the one that says "MD4 firmware/modem/baseband"
EDIT: This thread may be useful, it's a different device but the board is the same (MSM8960).
CNexus said:
No, the firmware zips, not the ROMs
And yes. The bootloaders are there, they're smaller, like 20~ MB
Grab the one that says "MD4 firmware/modem/baseband"
Click to expand...
Click to collapse
Found it, thanks. Unfortunately, flashing the SBL didn't fix it.
What address does aboot get flashed to? Can someone post the partition table so I can figure out the offset?
Here are two more links that give more technical information on the MSM8960 bootloaders.
Here
http://forum.xda-developers.com/showthread.php?t=1856327
And here
http://forum.xda-developers.com/showthread.php?t=1769411
You should be able to find most everything you need there.
CNexus said:
Here are two more links that give more technical information on the MSM8960 bootloaders.
Here
http://forum.xda-developers.com/showthread.php?t=1856327
And here
http://forum.xda-developers.com/showthread.php?t=1769411
You should be able to find most everything you need there.
Click to expand...
Click to collapse
I've been over those threads multiple times and I still don't know what address to plug into qdload to flash aboot (mmcblk0p5).
parted /dev/block/mmcblk0 might help.
Ok, I was just trying to help.
Code:
Disk /dev/block/mmcblk0: 15.8GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 4194kB 67.1MB 62.9MB modem
2 67.1MB 67.2MB 131kB sbl1
3 67.2MB 67.5MB 262kB sbl2
4 67.5MB 68.0MB 524kB sbl3
5 68.0MB 70.1MB 2097kB aboot
6 70.1MB 70.6MB 524kB rpm
CNexus said:
Ok, I was just trying to help.
Code:
Disk /dev/block/mmcblk0: 15.8GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 4194kB 67.1MB 62.9MB modem
2 67.1MB 67.2MB 131kB sbl1
3 67.2MB 67.5MB 262kB sbl2
4 67.5MB 68.0MB 524kB sbl3
5 68.0MB 70.1MB 2097kB aboot
6 70.1MB 70.6MB 524kB rpm
Click to expand...
Click to collapse
Thanks! Sorry I'm being so demanding - you have no obligation to help me, after all.
Could I trouble you for the size in bytes? Again, thanks for the help!
Edit: This is probably asking too much, but it would be immensely helpful:
"dd if=/dev/block/mmcblk0 of=/sdcard/backup.bin bs=1M count=70"
gTan64 said:
"dd if=/dev/block/mmcblk0 of=/sdcard/backup.bin bs=1M count=70"
Click to expand...
Click to collapse
Anyone with a rooted SGS3 willing to do this? I don't know what got messed up or how - the guy who gave this phone to me just said it wouldn't reboot after one of the steps in the rooting process - but flashing that backup with qdload could be a good method of fixing bricked phones without JTAG!
In the spirit of sharing, if I manage to fix it, I'll be doing an Ubuntu "port" (building a bootloader/kernel for desktop Linux distros, not Ubuntu Touch), hopefully with Freedreno drivers too.
Sorry, couldn't get the size in bytes or else I would have posted that instead of the MB
Here's the output of dd
http://db.tt/nvwsj4e5
CNexus said:
Sorry, couldn't get the size in bytes or else I would have posted that instead of the MB
Here's the output of dd
http://db.tt/nvwsj4e5
Click to expand...
Click to collapse
It's supposed to be the first 70MB of the eMMC chip, containing the partition table, the 64MB firmware partition, the three bootloader stages, and aboot. Unless I gave the wrong command or you changed it, 70 bytes isn't going to be much help
gTan64 said:
It's supposed to be the first 70MB of the eMMC chip, containing the partition table, the 64MB firmware partition, the three bootloader stages, and aboot. Unless I gave the wrong command or you changed it, 70 bytes isn't going to be much help
Click to expand...
Click to collapse
I know, but that is the output, I was surprised as well
CNexus said:
I know, but that is the output, I was surprised as well
Click to expand...
Click to collapse
I'm guessing the version of dd on your phone is a stripped down version that doesn't recognize suffixes.
dd if=/dev/block/mmcblk0 of=/sdcard/backup.bin bs=1024 count=71680
gTan64 said:
It's supposed to be the first 70MB of the eMMC chip, containing the partition table, the 64MB firmware partition, the three bootloader stages, and aboot. Unless I gave the wrong command or you changed it, 70 bytes isn't going to be much help
Click to expand...
Click to collapse
I know, but that is the output, I was surprised as well
EDIT: dd would not accept "MB" for some reason, so I just wrote out the number of bytes. Here's the file
http://d-h.st/G3l
Md5sum: 12ca987274d905865a337d687f9e2a73
CNexus said:
I know, but that is the output, I was surprised as well
EDIT: dd would not accept "MB" for some reason, so I just wrote out the number of bytes. Here's the file
http://d-h.st/G3l
Md5sum: 12ca987274d905865a337d687f9e2a73
Click to expand...
Click to collapse
I miscalculated - it should have been 70.6MB - but I was able to find the aboot offset, so it's okay!
Huge thanks! Flashing now!
gTan64 said:
I miscalculated - it should have been 70.6MB - but I was able to find the aboot offset, so it's okay!
Huge thanks! Flashing now!
Click to expand...
Click to collapse
After the process failed for the umpteenth time, I concluded qdload only loads code into RAM and executes it - of course, in this case, it wasn't executing the backup. It seems I need an alternative method of accessing the eMMC.
The aboot/appsbl address I used was incorrect, so I still need to figure out where it's supposed to be loaded in RAM.
This doesn't appear to be common knowledge, unfortunately. Looks like I may have to JTAG it after all...
gTan64 said:
Looks like I may have to JTAG it after all...
Click to expand...
Click to collapse
I am happy to eat those words! I was able to get CNexus's backup onto an SD card (fixing the rpm, tz, and boot.img partitions that weren't part of the backup) and it booted that with no trouble! I'm currently in download mode flashing a stock ROM! Yay!!!
Thanks CNexus for the eMMC dump! I'll be posting a fixed dd image for an SD card soon for anyone who wants it. No more JTAG!
gTan64 said:
I am happy to eat those words! I was able to get CNexus's backup onto an SD card (fixing the rpm, tz, and boot.img partitions that weren't part of the backup) and it booted that with no trouble! I'm currently in download mode flashing a stock ROM! Yay!!!
Thanks CNexus for the eMMC dump! I'll be posting a fixed dd image for an SD card soon for anyone who wants it. No more JTAG!
Click to expand...
Click to collapse
HOLY GEEZ. AWESOME SAUCE. Please post a thread in development outlining your process so we can get it stickied !!
Also, PM me a Dropbox link to it or something and I'll mirror everywhere lol :thumbup::beer::beer:
This is actually great. Do you happen to know how the phone was initially bricked?
The Thanks button is just to avoid "THANKS" posts in threads. Nothing more. Don't defeat the purpose of why it was introduced.
Hi, bit of a noob - not sure if i have the terminology right but i have a Note II N7100 and need to do some forensics for a pal whos wife is possibly having an affair and hides it thru kik online chat not txts. I am planning to take an image to a 32gb microsd, move to PC,run winhex and finally testdisc over the resulting drive to hopefully recover some deleted sqlite db's!
I am going off this guide - forensicfocus.com/2012/09/12/android-forensics/ - I have rooted the phone all fine. But i am having a job with the "dd" command for example
dd if=/dev/block/mmcblk0p16 of=/extSdCard/image.img
This returns "/extSdCard/image.img - cannot open for write. No such file or directory"
Or dd if=/dev/block/mmcblk0p16 of=/dev/block/vold/179:33/image.img
returns "/dev/block/vold/179:33/image.img - cannot open for write. Not a directory"
Ive used "diskdigger" to look for images and devices are:
/system 2gb (/dev/block/mmcblk0p16)
/efs 20mb (/dev/block/mmcblk0p3)
/cache 1.34gb (/dev/block/mmcblk0p12)
/data 10.6gb (/dev/block/mmcblk0p16)
/storage/extSdCard, 29gb (dev/block/vold/179:33)
Any help or links on the syntax appreciated greatly
Off the top of my head the first thing I would try is sending the dd image to the internal sdcard first, then moving it to the external later. Might be that it's having trouble going the extra step away from the device.
You could always just plug it into a computer and use adb to pull the dd image(s) directly to the computer and skip putting them on the phone at all. It's what I would do to minimize my residual impact on the device at hand.
Also, try naming them as the mmcblk.img corresponding to what partition you are pulling, makes it easier to go through later.
Try this:
Code:
dd if=/dev/block/mmcblk0p13 of=/storage/extSdCard/system.img bs=4096
This should give you a dd of /system (which is /dev/block/mmcblk0p13, not /dev/block/mmcblk0p16).
dwitherell said:
Try this:
Code:
dd if=/dev/block/mmcblk0p13 of=/storage/extSdCard/system.img bs=4096
This should give you a dd of /system (which is /dev/block/mmcblk0p13, not /dev/block/mmcblk0p16).
Click to expand...
Click to collapse
ah you are a hero! :good::good::good:
G2 Mini
dwitherell said:
Try this:
Code:
dd if=/dev/block/mmcblk0p13 of=/storage/extSdCard/system.img bs=4096
This should give you a dd of /system (which is /dev/block/mmcblk0p13, not /dev/block/mmcblk0p16).
Click to expand...
Click to collapse
Thanks dude! you saved my ass with the D620!
Can someone with a developer edition m9 get me a copy of their misc partition? I'm trying to track down some odd behavior with mine (corrupted my partition, I could jsut wipe it but i want to byte by byte revert until I find the cause).
adb shell
su
dd if=/dev/block/mmcblk0p32 of=/sdcard/MISC.img
It does not contain any identifying or sensitive information. Would much appreciate it!
Got it via PM thanks!
[How to] determine dd parameters for all LG G4 models
IMPORTANT:
Only for advanced users!
You are an advanced user if you know exactly what you are doing.
You are an advanced user if you know what to do if something went wrong.
You are NOT an advanced user if you know how to do copy+paste.
You can bring your smartphone into a state, so it no longer works.
I am not responsible for anything. The following instructions are only suggestions.
Hello,
everyone knows how to root the LG G4 with the "low effort root" method.
They copied the system partition to an ".img" file, rooted it and copied it back to the "system" partition.
Many users wonder how to get the right parameters for the "dd" commands.
Please read the complete guide and be sure that you understand it until you execute a command!
Information:
Code:
dd if=/inputfile bs=8192 count=12345 of=/outputfile
if = Input File
of = Output File
bs = Blocksize in bytes (default is 512 - to increase copy speed use multiple of 512 e.g. 8192)
count = how many blocks
skip = skip blocks before start reading
seek = skip blocks before start writing
more info: http://man7.org/linux/man-pages/man1/dd.1.html
There are different models of the LG G4 on the market.
We know that the system partition is different depending on the model of the G4.
As an example I will show you how to calculate the parameters for the LG G4 H815 (International Model).
What you need:
Windows with Send_Command.exe
Instructions:
At first we need to know where the "system" partition starts (first sector) and how big it is (partition size).
I used the first method to find these values. But I recommend the second method because it's easier.
First method (difficult method, extracting the GPT and using "gdisk" in linux to read the partition info)
What you need:
Linux with "gdisk" installed
Instructions:
Put your smartphone to "Download Mode" and connect it to the Send_Command.exe command prompt.
We need to copy the partition table to the internal storage.
The partition table of GPT (GUID Partition Table) has a size of 16384 bytes and starts at LBA2.
Each LBA has a size of 512 bytes. Because we start at LBA0 we need to add 1024 bytes.
In summary 16384 + 1024 = 17408 (bytes).
Execute the following command:
Code:
dd if=/dev/block/mmcblk0 bs=1 count=17408 of=/data/media/0/gpt_backup.img
Enter "LEAVE" to restart your phone.
You will find the (very small) file "gpt_backup.img" on your internal storage.
Switch to Linux:
Copy the file to your Linux and open the terminal. Then type this:
Code:
gdisk /yourpath/gpt_backup.img
Some warnings will occur. Ignore them.
You will see:
Code:
Command (? for help):
Enter "p" and hit "enter".
You will get a list of the partitions.
Scroll up a bit and check that you see:
"Logical sector size: 512 bytes"
Scroll down and look for the "system" partition.
You will find a line similar to this:
Code:
47 884736 9363455 4.0GiB FFFF system
Now you know the number of the "system" partition is "47".
You will see:
Code:
Command (? for help):
Type "i" and hit "enter".
You will be asked the partition number.
Enter it and hit "enter".
You will see something conatining lines similar to this:
Code:
First sector: 884736
Last sector: 9363455
Partition size: 8478720
Partition name: 'system'
We need the values from "First sector" and "Partition size".
Second method (easier method, just using "adb shell" to read the partition info)
What you need:
adb shell
usb debugging enabled
To get the "logical sector size" use:
cat /sys/block/mmcblk0/queue/logical_block_size
It should be 512
smason said:
To find in any smartphone the offset and the size of /system:
$ adb shell
[email protected]:/ $ ls -la /dev/block/bootdevice/by-name/system
ls -la /dev/block/bootdevice/by-name/system
lrwxrwxrwx root root 2015-01-02 10:50 system -> /dev/block/mmcblk0p47
[email protected]:/ $ cd /sys/block/mmcblk0/mmcblk0p47
cd /sys/block/mmcblk0/mmcblk0p47
[email protected]:/sys/block/mmcblk0/mmcblk0p47 $ cat start
cat start
884736
[email protected]:/sys/block/mmcblk0/mmcblk0p47 $ cat size
cat size
8478720
[email protected]:/sys/block/mmcblk0/mmcblk0p47 $
so:
offset = 512 * 884736 = 452984832
partition size = 512 * 8478720 = 4341104640
Cheers!
Click to expand...
Click to collapse
So "first sector" is the value from "cat start" (884736).
The "partiton size" is the value from "cat size" (8478720).
Now the mathematics (using the values from above):
Logical sector size = 512 (I never saw something different on LG G4 smartphones)
Assuming bs=8192
skip and seek: "First sector" * "Logical sector size" / bs
884736 * 512 / 8192 = 55296
count: "Partition size" * "Logical sector size" / bs
8478720 * 512 / 8192 = 529920
That was an example for the H815 (International Model).
Use your own values to calulate the "dd" parameters!
Back to Windows:
Put your smartphone to "Download Mode" and connect it to the Send_Command.exe command prompt.
Now you can copy your "system" partition to "system.img" with the following command:
Code:
dd if=/dev/block/mmcblk0 bs=8192 skip=55296 count=529920 of=/data/media/0/system.img
Replace the values with the ones you calculated for your model!
Now you could copy the "system.img" to your Linux and root it or do everything else you want.
Important: Do NOT delete the original "system.img" from your internal storage as long as you are not 100% sure your G4 is stable.
If your modifications don't work, you can copy back the original "system" partition (with "dd").
To copy the modified "system_changed.img" back to the "system" partition use the following command:
Code:
dd if=/data/media/0/system_changed.img bs=8192 seek=55296 count=529920 of=/dev/block/mmcblk0
Replace the values with the ones you calculated for your model!
Important: Be sure to use "skip" when reading and "seek" when writing.
The "dd" command should take about a minute.
Did the instructions help you?
Please give a "Thanks!"
Thank you
Hi,
thanks for this great post.
I just have one question. With your formulas and using 8K block size, I get a floating point number as result. So I used a block size of 4K instead, and I get an even number. This seems better to me so I went with it, as I believe smaller block sizes are always ok?
I'm just wondering one thing which seems not right to me. My system partition is reported to be 2.5GB:
Partition number (1-42): 39
Partition GUID code: EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 (Microsoft basic data)
Partition unique GUID: A8725BAA-9E45-B2F8-8FA3-8C972F60F0CF
First sector: 836608 (at 408.5 MiB)
Last sector: 6074573 (at 2.9 GiB)
Partition size: 5237966 sectors (2.5 GiB)
Attribute flags: 1000000000000000
Partition name: 'system'
So with the formulas:
FACTOR 512 / 4096 = 0.125
skip and seek: "First sector" * "Logical sector size" / bs
836608 *FACTOR = 104576
count: "Partition size" * "Logical sector size" / bs
8478720 * FACTOR = 1059840
If I now run the dd command:
dd if=/dev/block/mmcblk0 bs=4096 skip=104576 count=1059840 of=/storage/external_SD/system.img
I get a file system.img which is 4096 MB. Should it not be 2.5GB as my original system partition?
If I use bs=512 (the default) and type
dd if=/dev/block/mmcblk0 bs=512 skip=836608 count=8478720 of=/storage/external_SD/system.img
I get a system.img of the right size (bit over 2.5GB).
I think the block size to use for "skip" is to be specified with the option ibs=XXX, not bs=XXX which only applies to "count" (according to man dd). I tried the ibs option, but the command then just doesn't work on Send_Command.exe. It doesn't even print an error but simply returns immediately.
Cheers
Jen
Hi,
which phone do you have?
Your calculation seems wrong. It's ok to use BS with 4k. I could be a bit slower then 8k, but that doesn't matter.
BUT: Look at your "count" value. Your partition size is 5237966. You used 8478720 (the value from my G4(H815EU) example). Thats wrong!!!
How to calculate with 1k and your values:
bs=1024
skip=836608*512/1024=418304
count=5237966*512/1024=2618983
Please check my calulation!!!
It's interesting, that the Send_Command shell has access to your external sd card...
I think the block size to use for "skip" is to be specified with the option ibs=XXX, not bs=XXX which only applies to "count" (according to man dd).
Click to expand...
Click to collapse
No. "bs" is the right parameter.
If you use "bs" it sets "ibs" and "obs" to the value of "bs".
Just do "dd --help" on a linux system for more details.
Hi Dominik,
oh my, how embarrassing I actually did take the wrong value from the example you posted. I used my value (the 5237966) for calculating the parameters with bs=8K, and got a floating value, so tried 4K instead... and the wrong value must have snug in. Oups.
I also get floating value on 4K now that you've pointed my mistake out:
5237966 * 512/4096= 654745.75
If I rounded this up, would this not mean that I copy a tiny bit of the next partition on the image? And if I then use the image to restore, would I not run the risk to damage something in the following partition?
Anyway, it's not a huge drama as I can just use bs=512 and it works.
Yes I have access to the SD card, the image also has copied there successfully. I was also surprised because I read in the forums that it's not possible.
I found it out with the "df" command, as the SD was listed there. I needed to use it because there's no room on my internal storage (it's a ridiculous 8GB on the LG H735) to store the image there.
My system partition is only 2.5GB so I don't think I have to reformat, but you are right it would be better to use ext4.
Ok
I removed my information about formatting the sd card.
You dont't have to format it. FAT32 is ok.
So you can use your sd card on systems which don't support ext4 too.
I have the LG G4S (H735). It's unusable without rooting as it only has 8GB internal memory. That's why I'm trying to root it now.
jen.magnolis said:
I have the LG G4S (H735). It's unusable without rooting as it only has 8GB internal memory. That's why I'm trying to root it now.
Click to expand...
Click to collapse
Ok, good luck.
Please open a new thread if you have questions about rooting your phone.
Or is there already one? Maybe these?
http://forum.xda-developers.com/g4/help/rooting-lg-h735-g4-beat-t3192491
http://forum.xda-developers.com/g4/general/lg-g4s-world-root-lg-devices-t3231759/page7
Oh. Just saw that you are already there
dominik-p said:
Ok, good luck.
Please open a new thread if you have questions about rooting your phone.
Or is there already one? Maybe these?
http://forum.xda-developers.com/g4/help/rooting-lg-h735-g4-beat-t3192491
http://forum.xda-developers.com/g4/general/lg-g4s-world-root-lg-devices-t3231759/page7
Oh. Just saw that you are already there
Click to expand...
Click to collapse
I just created a new thread too to focus on the particular problem I have:
http://forum.xda-developers.com/g4/general/rooting-lg-g4s-h735-t3243549
this guide helped in dumping boot and recovery partitions.
thank you very much sir! i successfully dumped my boot and recovery partition using dd in my mediatek device by following your guide.
sparksthedev said:
thank you very much sir! i successfully dumped my boot and recovery partition using dd in my mediatek device by following your guide.
Click to expand...
Click to collapse
Congratulations
Did you use the first (more komplex) oder the second method for your device?
I saw that you had problems in this thread:
http://forum.xda-developers.com/showthread.php?p=65907557#post65907557
And you wrote a guide for MTK devices here:
http://forum.xda-developers.com/general/general/guide-dumping-boot-img-recovery-img-t3339530
This doesn't work with the LG G4, but I think it will help many others.
Thank you
My sister asked me to root her phone. It seems more complicated than anything I did in the past (HTC Wildfire, Galaxy Core Plus, Xperia M4A).
I tried this tutorial and it kinda worked, but I can't mount image I got, so it's useless (image, not tutorial!).
Phone is LG-H736 (Beat). I got this result in gdisk:
Code:
Partition number (1-42): 39
Partition GUID code: EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 (Microsoft basic data)
Partition unique GUID: A9520AE6-ABC6-F107-E8FE-B37C4C30CB77
First sector: 836608 (at 408.5 MiB)
Last sector: 6074573 (at 2.9 GiB)
Partition size: 5237966 sectors (2.5 GiB)
Attribute flags: 1000000000000000
Partition name: 'system'
The 8K bs gave me floating point result, so I used 0,5K.
So the dd command were:
Code:
dd if=/dev/block/mmcblk0 bs=512 skip=836608 count=5237966 of=/storage/external_SD/system.img
BTW, I had access to SDCard and I didn't need to open ports...
EDIT: I got the system.img. The problem was I haven't got enough space on SD card.
But now I bricked it...
https://forum.xda-developers.com/g4/help/softbricked-g4-beat-lg-h735-t3959237
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?