I’m an android user and I shred my files using a app that uses an algorithm that overwritten that bytes of the file

I suspect that it doesn’t actually work. I mean, they can overwrite the logical positions in the file file if they want, but that doesn’t entail that it actually overwrites the underlying physical blocks, for a number of reasons, starting with some of the stuff at the drive level, but also because of higher-level issues. What filesystem does Android use?

googles

Looks like yaffs2, at least on this system.

https://stackoverflow.com/questions/2421826/what-is-androids-file-system

rootfs / rootfs ro 0 0
tmpfs /dev tmpfs rw,mode=755 0 0
devpts /dev/pts devpts rw,mode=600 0 0
proc /proc proc rw 0 0
sysfs /sys sysfs rw 0 0
tmpfs /sqlite_stmt_journals tmpfs rw,size=4096k 0 0
none /dev/cpuctl cgroup rw,cpu 0 0
/dev/block/mtdblock0 /system yaffs2 ro 0 0
/dev/block/mtdblock1 /data yaffs2 rw,nosuid,nodev 0 0
/dev/block/mtdblock2 /cache yaffs2 rw,nosuid,nodev 0 0
/dev/block//vold/179:0 /sdcard vfat rw,dirsync,nosuid,nodev,noexec,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0

https://en.wikipedia.org/wiki/YAFFS

YAFFS is a robust log-structured file system that holds data integrity as a high priority. A secondary YAFFS goal is high performance. YAFFS will typically outperform most alternatives.[3] It is also designed to be portable and has been used on Linux, WinCE, pSOS, RTEMS, eCos, ThreadX, and various special-purpose OSes. A variant ‘YAFFS/Direct’ is used in situations where there is no OS, embedded OSes or bootloaders: it has the same core filesystem but simpler interfacing to both the higher and lower level code and the NAND flash hardware.

Yeah, note the “log-structured” bit there.

https://en.wikipedia.org/wiki/Log-structured_file_system

A log-structured filesystem is a file system in which data and metadata are written sequentially to a circular buffer, called a log.

So, what happens is that when you write, it’s going to the log, and then there’s a metadata update once the write is complete saying “I wrote to the log”. The app probably isn’t writing to the previous location of the data on the disk, because writing to byte offset 32,000 the second time in a file will go to a different logical location on the storage device than the first time you wrote it, causing the thing to not actually be overwritten.

googles

https://arxiv.org/pdf/1106.0917

Secure Deletion on Log-structured File Systems

We address the problem of secure data deletion on log-structured file systems. We focus on the YAFFS file system, widely used on Android smartphones. We show that these systems provide no temporal guarantees on data deletion and that deleted data still persists for nearly 44 hours with average phone use and indefinitely if the phone is not used after the deletion. Furthermore, we show that file overwriting and encryption, methods commonly used for secure deletion on block-structured file systems, do not ensure data deletion in log-structured file systems.

I’d also note that this is a lead-up to proposed solutions, but that’s only handling things down to the level that the OS sees, not what the flash device sees; they don’t mention things like wear leveling, so they probably aren’t taking that into consideration.

EDIT: Oh, they do mention it, but just to say that some of their approach might work (like, what they mean is that if it writes enough data in the background, it might eventually overwrite whatever, even if the OS has no control as to what’s being written):

Wei et al. [16] have considered secure deletion on flash storage in the context of solid state drives (SDDs). An SSD makes use of a Flash Translation Layer (FTL). This layer allows a regular block-based file system (such as FAT) to be used on flash memory by handling the nuances of erase blocks opaquely through the FTL’s layer of indirection. This layer has the same effect as a log-structured file system, where the FTL writes new entries at empty locations, so old entries remain until the entire erase block can be reclaimed. They executed traditional block-based approaches to secure deletion and determined that they do not properly sanitize data on flash storage. They also showed alarmingly that some built-in sanitization methods do not function correctly either. They propose to address this concern by having flash hardware manufacturers make use of zero overwriting, and add it into the FTL hardware. They state that circumventing the problem of a lack of secure deletion requires changes in the FTL, but depending on how the FTL is implemented, our userlevel approaches may also succeed similarly without requiring hardware changes.