FORUMS
Remove All Ads from XDA

[TOOL] Lanchon REPIT: The Data-Sparing Repartitioning Tool For Android

2,674 posts
Thanks Meter: 4,451
 
By Lanchon, Senior Member on 13th April 2016, 06:50 PM
Post Reply Email Thread
Lanchon REPIT: The In-Device Data-Sparing Repartitioning Tool For Android


REPIT is a simple, safe, device-only, data-sparing, and easily portable repartitioning tool for Android devices:
  • device-only: just flash a zip file in recovery to repartition the device.
  • simple: rename the zip file before flashing to configure your choice of partition sizes, file systems, wipes, etc.
  • safe:
    • a correctly ported REPIT can never hard-brick your device.
    • before starting, REPIT checks for the existence of all the tools that will be needed for the task at hand, verifies that the current partition layout passes several sanity checks, checks and fixes all the involved file systems, and verifies that the new partition layout will meet its sanity checks too. REPIT performs a dry-run of the complete repartitioning process to detect possible problems early on.
    • if REPIT fails, it will nonetheless try to restore your device to a working in-between state.
    • my estimate is that around 1000 users have already repartitioned with REPIT with no incidents of data loss, boot loops or soft bricks (2016-04).
  • easily portable: a simple configuration file is all that is needed to port REPIT to a new device.

Documentation (HELL YEAH, read this!) -> HERE

Downloads -> HERE


this is a user discussion thread. post here for general discussion and user support.
for official support create a Github issue, but only of you have read the docs.

new versions will not be announced here.
please 'watch' the Github project to receive notifications.


special thanks to the.gangster.



XDA:DevDB Information
Lanchon REPIT, Tool/Utility for all devices (see above for details)

Contributors
Lanchon
Source Code: https://github.com/Lanchon/REPIT


Version Information
Status: Stable

Created 2016-04-13
Last Updated 2019-06-07
The Following 66 Users Say Thank You to Lanchon For This Useful Post: [ View ] Gift Lanchon Ad-Free
13th April 2016, 06:50 PM |#3  
Lanchon's Avatar
OP Senior Member
Thanks Meter: 4,451
 
Donate to Me
More
Reserved
The Following 3 Users Say Thank You to Lanchon For This Useful Post: [ View ] Gift Lanchon Ad-Free
13th April 2016, 07:22 PM |#4  
the.gangster's Avatar
Senior Member
Thanks Meter: 1,371
 
More
Good to have a place again to discuss issues or simple questions.
Great tool, that meanwhile left its corner where it grew up (the Galaxy S2 - i9100), meanwhile supporting a growing number of devices.

RELEASES AND CHANGELOG
The Following 3 Users Say Thank You to the.gangster For This Useful Post: [ View ] Gift the.gangster Ad-Free
13th April 2016, 07:33 PM |#5  
Lanchon's Avatar
OP Senior Member
Thanks Meter: 4,451
 
Donate to Me
More
Quote:
Originally Posted by the.gangster

Good to have a place again to discuss issues or simple questions.
Great tool, that meanwhile left its corner where it grew up (the Galaxy S2 - i9100), meanwhile supporting a growing number of devices.
@Lanchon
you accidently linked the downloads to your flashize github instead of the Repit one.

lol thanks, mucho copy/pasta, fixed!
The Following 2 Users Say Thank You to Lanchon For This Useful Post: [ View ] Gift Lanchon Ad-Free
13th April 2016, 11:38 PM |#6  
Member
Thanks Meter: 21
 
More
Thanks so much!
Perfect tool, used this evening on a old but still used I9100!
The Following 2 Users Say Thank You to PacoRabanne2k For This Useful Post: [ View ] Gift PacoRabanne2k Ad-Free
16th April 2016, 02:48 AM |#7  
Senior Member
Thanks Meter: 123
 
More
Tried this on a n7000 recently, tried to resize cache, which didn't work, saw partition structure with modem after cache, and understand your concerns in the comments. I imagine the we could so some experiments like you are doing for the Honor 4, however I'm not at the stage where I want to volunteer my device as potential sacrifice.

A question on "wipe", how sure are we that "wipe" actually wipes, ie is all the previous data non-recoverable down to a block level?

Does the wipe trigger some type of NAND erase cycle? This would be problematic on n7000 given the hard brick issues with NAND firmware there, and on the n7000 IIRC the ioctl() is filtered and purposely ignored, maybe this is also an issue with i9100? I don't recall.

If I have a used ext4 parition, and then format & wipe it then I think a fstrim happens. If I then change it to vfat, and dd the partition, am I able to recover blocks from the original ext4 partition, or does the trim cause the nand to regard the blocks as empty and return 0x0000000 or 0x11111111 or something deterministic?

I'm looking for a wipe that actually wipes, ext4 and vfat, rather then my current solution which is to dd if=/dev/zero of=/path, which is slow and is difficult to get a progress report, as kill -USR1 is a PITA.
16th April 2016, 11:54 AM |#8  
Lanchon's Avatar
OP Senior Member
Thanks Meter: 4,451
 
Donate to Me
More
Quote:
Originally Posted by samarium

Tried this on a n7000 recently, tried to resize cache, which didn't work, saw partition structure with modem after cache, and understand your concerns in the comments. I imagine the we could so some experiments like you are doing for the Honor 4, however I'm not at the stage where I want to volunteer my device as potential sacrifice.

A question on "wipe", how sure are we that "wipe" actually wipes, ie is all the previous data non-recoverable down to a block level?

Does the wipe trigger some type of NAND erase cycle? This would be problematic on n7000 given the hard brick issues with NAND firmware there, and on the n7000 IIRC the ioctl() is filtered and purposely ignored, maybe this is also an issue with i9100? I don't recall.

If I have a used ext4 parition, and then format & wipe it then I think a fstrim happens. If I then change it to vfat, and dd the partition, am I able to recover blocks from the original ext4 partition, or does the trim cause the nand to regard the blocks as empty and return 0x0000000 or 0x11111111 or something deterministic?

I'm looking for a wipe that actually wipes, ext4 and vfat, rather then my current solution which is to dd if=/dev/zero of=/path, which is slow and is difficult to get a progress report, as kill -USR1 is a PITA.

hi,

well, it's not that it didn't work lol! cache was intentionally left out of the resizable set. you've seen the comments and the 4X discussion so you know exactly why.

i wouldn't do the experiments anyway. in the Honor there is something useful to be gained: 1 extra GB to a 4GB /data, which is a lot. in the S2 cache is 100MB. cache is unused nowadays, so the only logical thing to do is shrink it. plus you want something left, like 32MB. so we will risk devices for 68MB? not on my watch


secure wipe is a very complex issue and there's an awful big can of worms there, believe me. it'll try to paint a picture.

ssds have a bunch of 'trim' commands. there's ERASE and DISCARD, and later TRIM was added, all with slightly different semantics. ans they all come in standard and secure flavors. most recently you can come across the standard non-queued commands or the new queued variants.

the non-secure flavored commands are performance-oriented: they are hints to help the ssd. the drive can ignore them if it wants. it can ignore requests for short ranges but honor requests for large extents, or whatever.

more recently devices can implement DRAT and RZAT (deterministic read after trim and read zero after trim), ending the previous non-deterministic behavior. take a look:
http://www.t13.org/documents/uploade...ifications.pdf

but there are a million bugs in ssd firmware so linux blacklists broken functionality. like RZAT in many drives (you can google it), even if the drive says it supports it.

in any case RZAT drives just alter the FTL (flash translation layer) structures to unmap the block, they don't erase flash, so your data is typically still there but normally inaccessible. and there is probably even a history of previous snapshots of the block, not just the latest.

that's where the secure commands enter the picture: supposedly the firmware must actually erase from flash all copies of the targeted blocks. in reality, firmwares are so buggy i wouldn't trust them for that, except maybe if the drive is intel brand.


back to the real world... the exynos:

>Does the wipe trigger some type of NAND erase cycle? This would be problematic on n7000 given the hard brick issues with NAND firmware there, and on the n7000 IIRC the ioctl() is filtered and purposely ignored, maybe this is also an issue with i9100? I don't recall.

you are living in the past. more than two years ago i started arguing that non-secure trim commands should in all probability work fine and could be used to speed up the S2 family. rationale is complex but you can google my threads about it. no-one listened so 2 years ago i learned to build kernels and did some tests with volunteers and began publishing trimming kernels (google i9100 trim for a bit of history). finally in 2016 trim was finally added to official CM 13, 12.1 and 11.

you could be trimming your device without knowing: if you are using recent official CM, you are already trimming. many other kernels switched to trim too.

but... in the S2, secure trim kills the eMMC, so only non-secure variants are issued by trim kernels. secure erase is not a possibility.

i don't know if the eMMC is RZAT, but i wouldn't trust the firmware anyway. if you want to wipe, dd is your best option. but don't use zeros!!! some ssd's compress data. use a pseudo random stream instead. after all, non-secure trim is not very different from a write, in the best case, so just write for safety and be done with it.

yes, dd won't wipe reserved blocks. no way to do that except:
-MAYBE... an eMMC full reset (including bootloader) by resizing the boot partitions (google) which is very dangerous and can easily hard brick the device.
-putting a power drill to you beloved S2


regarding what repit does:
-it trims only if the kernel has trim enabled.
-and it trims only ext4 partitions.

thanks!
The Following 7 Users Say Thank You to Lanchon For This Useful Post: [ View ] Gift Lanchon Ad-Free
16th April 2016, 02:20 PM |#9  
Senior Member
Thanks Meter: 123
 
More
Thanks for the detailed reply.

I'm currently using i9100 CM12.1 & n7000 CM13/Nightowl, and have been trimming vfat partitions.

Now you remind me, I do recall reading threads about trim safe a while ago, but I think I was more irritated at the time by the seemingly random kernel crashes & process terminations that eventually were tracked down to kernel interrupt fp register save/restore, and went down the Sony path for a while while the n7000 was unusable. Amusingly, the n7000 now has CM13, while the Sony Z Ultra is languishing and isn't looking good for CM13 at the moment.

While I agree that for general SSDs, zero blocks could be compressed, and blocks could be deduped, do you really think this is happening in n7000/i9100 emmc? I dont expect so, seems they seem too old. I agree that a /dev/urandom would be a better if= than /dev/zero for dd, however this is going to use much more power, and I'm usually wiping a phone with limited time and power.

I'm not trying to protect from something as serious as direct flash chip access, just want to be reasonably sure that whatever was on the phone has been overwritten and is not easily available to standard and even mildly esoteric extraction methods.
16th April 2016, 09:02 PM |#10  
Lanchon's Avatar
OP Senior Member
Thanks Meter: 4,451
 
Donate to Me
More
Quote:
Originally Posted by samarium

Thanks for the detailed reply.

I'm currently using i9100 CM12.1 & n7000 CM13/Nightowl, and have been trimming vfat partitions.

Now you remind me, I do recall reading threads about trim safe a while ago, but I think I was more irritated at the time by the seemingly random kernel crashes & process terminations that eventually were tracked down to kernel interrupt fp register save/restore, and went down the Sony path for a while while the n7000 was unusable. Amusingly, the n7000 now has CM13, while the Sony Z Ultra is languishing and isn't looking good for CM13 at the moment.

While I agree that for general SSDs, zero blocks could be compressed, and blocks could be deduped, do you really think this is happening in n7000/i9100 emmc? I dont expect so, seems they seem too old. I agree that a /dev/urandom would be a better if= than /dev/zero for dd, however this is going to use much more power, and I'm usually wiping a phone with limited time and power.

I'm not trying to protect from something as serious as direct flash chip access, just want to be reasonably sure that whatever was on the phone has been overwritten and is not easily available to standard and even mildly esoteric extraction methods.

ok. then i would format in ext4 and trim. you can use repit for doing both in a single shot, but you need a trimming kernel. take a dd snapshot of one or a couple of short pieces of the partition, both before and after the operation. compare them and post here, i'd surely like to know .

but... keep in mind that there are several different emmcs out there in the S2s, so you'd need to validate for each one. which reminds me, also post your device emmc IDs! use the eMMC brickbug check app for instance.

regarding the /dev/urandom vs /dev/zero thing, i'm not religious, i don't hold unwarranted beliefs about what i don't know. i investigate, i have no gut feelings on stuff

but if you want to know: i'm a bit obsessive, i certainly would have done at least something if i was coding the FTL, even if it is old. if your design is RZAT, the least you can do is trim the block instead of writing it when data is all zeros. you may think this would slow the emmc down, but this can be implemented in pseudo-zero time: writing usually entails generating some kind of checksum of the data. so note the magic checksum that corresponds to an all-zero block, and only if the checksum of the data being written matches the magic, actually check for all-zero data before writing. of course this can be 'attacked' by intentionally generating checksum collisions but who cares. the time saved by not garbage collecting, not using a free block, and not writing the block with all-zeros certainly pays for the checksum comparison against the magic value. also note that straight brute force comparison of all blocks is mostly ok too, as most written blocks will fail early anyway (ie, after one or a couple of bytes).

of course The One True Solution(R) is to encrypt the phone before using it...... assuming that you can actually wipe the key when you need to lol. ideally the key is in a separate hardware keystore adept at wiping keys. but on the S2 it just in the same eMMC . so this is a bit like explaining where the universe came from by saying that god created it, and then conveniently forget to explain where did god come from lol.

the power drill solution still mostly works on the S2 though
The Following 2 Users Say Thank You to Lanchon For This Useful Post: [ View ] Gift Lanchon Ad-Free
21st April 2016, 02:52 AM |#11  
Junior Member
Thanks Meter: 0
 
More
Pls help
##################################
Lanchon REPIT
A Data-Sparing Repartitioning Tool
Version: 2016-04-15
Device: i9100
Copyright 2016, Lanchon (GPLv3)
####################################

===== PRELIMINARY CHECKS =====
info: valid package names: <prefix>[-(system|data|sdcard|preload)=<conf>]...<suffix>
info: valid partition <conf> values: [<size-in-GiB>|same|min|max][+[keep|wipe][+[ext4|vfat|f2fs|swap|raw]]]

----- DEFAULTS -----
system = size:same + content:keep + fs:ext4
data = size:same + content:keep + fs:ext4
sdcard = size:same + content:keep + fs:vfat
preload = size:same + content:keep + fs:ext4

info: parsing package name

----- CONFIGURATION -----
system = size:1.0 + content:keep + fs:ext4
data = size:6 + content:keep + fs:ext4
sdcard = size:max + content:keep + fs:vfat
preload = size:min + content:keep + fs:ext4

info: disabling swap
BusyBox v1.22.1 bionic (2016-01-10 12:49 +0530) multi-call binary.

Usage: dirname FILENAME

Strip non-directory suffix from FILENAME

info: copying package to '/tmp'
cp: '/tmp/lanchon-repit-20160415-system=1.0-data=6-sdcard=max-preload=min wipe-i9100.zip' and '/tmp/lanchon-repit-20160415-system=1.0-data=6-sdcard=max-preload=min wipe-i9100.zip' are the same file

[ERROR 1]

Whats wrong
Post Reply Subscribe to Thread

Guest Quick Reply (no urls or BBcode)
Message:
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes