On Thu, 09 Aug 2018 17:47:59 +0000 Fil Lupin <fillu...@protonmail.com> wrote:
> Hello, Hi, > 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 partitions: 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: https://www.xda-developers.com/root/ 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: https://media.ccc.de/v/34c3-8784-emmc_hacking_or_how_i_fixed_long-dead_galaxy_s3_phones https://github.com/oranav/emmc-talk-2017.git And the code is here: https://github.com/oranav/i9300_emmc_toolbox - Three is also some details on an exploit for the galaxy S6 here: https://wikileaks.org/ciav7p1/cms/files/cadmium.pdf 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 that: $ 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. Denis.
pgpz_nK8NSLK6.pgp
Description: OpenPGP digital signature
_______________________________________________ Replicant mailing list Replicant@osuosl.org https://lists.osuosl.org/mailman/listinfo/replicant
