[Replicant] backup stock ROM without root

Denis 'GNUtoo' Carikli GNUtoo at no-log.org
Fri Aug 10 14:48:08 UTC 2018

On Thu, 09 Aug 2018 17:47:59 +0000
Fil Lupin <fillupin at protonmail.com> wrote:

> Hello,

> up to this day, I always rooted my phone and installed replicant as a
> first step, but I encountered a strange behaviour after installation
> on a GT-I9100 which persuades me to do a full backup before modifying
> anything.
> Since I failed to use "adb shell" on my device which is non-rooted,
> do you know any way to make some backup of a stock ROM? Regards,
The issue is that, as I understand, the Samsung bootloaders doesn't let
you dump the partitions: to load your code, you need to flash either the
recovery partition or the boot partition.

So you can flash a recovery that gives you access to the full
internal storage (eMMC) either on the boot or recovery partition, but
then the partition is erased in the process.

So if you don't need the stock recovery, having a full backup can be
done with something like:
$ adb shell "cat /dev/block/mmcblk0" > backup-mmcblk0.img
You'll have to check that the internal Storage(eMMC) is mmcblk0 and not
mmcblk1 otherwise change the command accordingly.

The Replicant 6.0 recovery may not work for that because as I
understand, they will refuse to let you have a shell under ADB unless
you already have the authorization to do so under Replicant.

So you could try to enable adb on the stock OS first, or try to make
use a Replicant 4.2 recovery. If none of that work you could try
another recovery or to make your own.
The most famous standalone recovery is called twrp and they seem to
have signatures and corresponding source code:
- https://twrp.me/faq/pgpkeys.html
- https://github.com/TeamWin
However I didn't check if everything was fully free software or not.

I think it would be easier if Replicant also had 'debug' recoveries for
such uses cases.

I've seen a stock OS refusing to upgrade if the device is 'rooted'.
The device was rooted with an apk, which also changed the recovery.
This persisted after the 'reset to factory', so it might be because it
detected a different recovery, or for other reasons.

There are several ways to workaround the inability to dump one of the
1) Use an application that roots your device without touching the
   filesystem or replacing anything. Then you could easily dump the
   recovery (cat /dev/block/platform/*/by-name/RECOVERY
   There is a list of such applications here:
   Some seem to have corresponding source code on github, however I've
   not looked yet in depth which ones are trustworthy, and what they
   do beside giving the user root access.
   A solution for that would be to package some of such applications in
   f-droid and describe exactly what they do.
2) Use a bootloader exploit. So far here are the one I know of:
   - There is code that uses a bootloader exploit to gain code
     execution in the bootloader, in order to repair dead internal
     storage (eMMC):
     The detail are here:
     And the code is here:
   - Three is also some details on an exploit for the galaxy S6 here:
  Here you might be able to load your own boot.img/recovery.img with
  such code and dump the internal storage (eMMC).

On devices with fastboot it's way more easy as you can usually just do
$ fastboot boot recovery.img
It will then load recovery.img in RAM and boot from it without altering
the internal storage (eMMC). You could then dump the internal storage
with the adb command mentioned above.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.osuosl.org/pipermail/replicant/attachments/20180810/b23fec53/attachment.asc>

More information about the Replicant mailing list