2

Sadly my device (sm-g3185) isn't supported by any of the CWM or NANDbackup so I am trying to do a backup manually. I found this thread which tells me to open one terminal (I'm on Arch Linux) and run:

adb forward tcp:5555 tcp:5555
adb shell
su
/system/xbin/busybox nc -l -p 5555 -e /system/xbin/busybox dd if=/dev/block/mmcblk0

And then another terminal and run:

adb forward tcp:5555 tcp:5555
cd /path/to/store/the/backup
nc 127.0.0.1 5555 | pv -i 0.5 > mmcblk0.raw

I did all this and it seems to be working. However, there was a delay of a few seconds between launching the dd command in terminal1 and the nc command in terminal2.

Can I trust the backup I created in this way? Doesn't this mean that I've lost some of the output of dd? Shouldn't these be run concurrently or, at least, shouldn't the nc command be started before the dd one?

1

Can I trust the backup I created in this way?

Yes, you can. This is the most complete backup that you can make of your device.

The integrity of the backup can be tested easily, you can simply run md5sum on /dev/block/mmcblk0 and check the output against the md5sum of the mmcblk0.raw file.

If you want to list the partitions inside the backup, you can run parted /path/to/store/the/backup/mmcblk0.raw print on the host computer. On it you will find your system and userdata partitions and lots of hidden partitions with the phone bootloader, the IMEI, the recovery...

There was a delay of a few seconds between launching the dd command on the device and the nc on the host computer. Doesn't this mean that I've lost some of the output of dd?

No, you don't need to worry. When you run nc -l, it will listen for an inbound connection. I the meantime, it will block the pipe and keep dd from sending data. This means that the first byte will be sent by dd once you stablish the connection from the other side.

Shouldn't these be run concurrently or, at least, shouldn't the nc command be started before the dd one?

No. As I explained on the last paragraph, you don't need to care about that. dd will start to send the data once the nc instance running on the device receives the inbound connection form the nc instance running on the host and reads data from the pipe.


Additional notes.

  • You can find a build of TWRP for your device here (mirror). This will allow you to make backups directly from the device. Warning: I don't assure you that this recovery will work on your device.

  • You don't need to run adb forward tcp:5555 tcp:5555 twice. Running it the first time is enough. You're doing exactly the same thing again.

2

I let it run and after it finished, dd reported:

7818182656 bytes (7.3GB) copied, 1245.237601 seconds, 6.0MB/s

And ls -l mmcblk0.raw on my computer shows:

-rw-r--r-- 1 terdon terdon 7818182656 Nov 10 14:45 mmcblk0.raw

Since the file is the right size, presumably the backup was successful.

  • I am still interested in an answer that explain why that worked so I won't accept this for a while. Is there some sort of buffering going on here? How does it work exactly? – terdon Nov 10 '15 at 12:54
  • is the .raw the same as a .img? – Alexis Nov 20 '15 at 2:52
  • @Alexis yes, the extension is irrelevant, I just chose .raw. – terdon Nov 20 '15 at 3:01
  • did it end up working for you? Could you check out my question android.stackexchange.com/questions/129330/…? – Alexis Nov 20 '15 at 3:05
  • @Alexis yes, it worked fine for me. At least, it created a file of the right size which is a good indication. Presumably, the dd output was buffered which is why nothing was lost. As for your question, please edit it and explain what you are trying to do. – terdon Nov 20 '15 at 13:39
1

Here's the output of busybox nc -h from the Kindle Fire HDX I'm working on:

BusyBox v1.20.2 (2013-01-21 11:34:41 CET) multi-call binary.

Usage: nc [-iN] [-wN] [-l] [-p PORT] [-f FILE|IPADDR PORT] [-e PROG]

Open a pipe to IP:PORT or FILE

        -e PROG Run PROG after connect
        -l      Listen mode, for inbound connects
                (use -l twice with -e for persistent server)
        -p PORT Local port
        -w SEC  Timeout for connect
        -i SEC  Delay interval for lines sent
        -f FILE Use file (ala /dev/ttyS0) instead of network

So, the entire image is received because netcat waits for the connection to be established before running busybox dd if=/dev/block/mmcblk0, that connection being established by nc 127.0.0.1 5555 in the second terminal window.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.