[HN Gopher] Snaprecovery: Recover old Snaps that have "disappear...
___________________________________________________________________
Snaprecovery: Recover old Snaps that have "disappeared" from
Snapchat
Author : blopeur
Score : 46 points
Date : 2021-08-08 19:36 UTC (1 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| treesknees wrote:
| >We don't need any forensics tools. We can simply use adb pull to
| fetch the files because they are never deleted. But once you
| logout from the app and after Snapchat deletes the Snaps, you
| will need the right forensics tools to recover the files.
|
| This feels like a bug, no? I don't see any logical reason for
| Snapchat to keep the files around that long.
| RicoElectrico wrote:
| App developers on Android rarely bother to clean their app
| caches. Open Apps in settings, sort by size, check top entries
| and you'll be surprised. Explain to me why the hell does
| Instagram need 500 MB of cache.
|
| Kind of a bummer I don't know of any method to mass clear cache
| data of all apps on my non-rooted Galaxy S8. It'd save a lot of
| space and _was_ possible on ancient HTC phones with Android
| 2.3.5.
|
| Edit: I experimented with wiping cache partition in recovery
| mode, but this ain't it - as the name suggests it's a separate
| partition.
| neilv wrote:
| If an app can accumulate 500MB of cache without pain to the
| app developer, I suspect cache management programming will
| remain a practice&skill mostly only for only systems
| programmers and the more bespoke backend programmers.
|
| I assume Insta invests in engineering for whatever cache
| expiration they do. And if there's 500MB cache, probably it's
| a conscious engineering decision.
|
| But maybe the majority app developers, if they could fill up
| cache, probably aren't thinking that far ahead -- not
| thinking about that non-visual, non-customer-story aspects.
| So most wouldn't have occasion to learn how to do cache
| management sufficiently well that they don't cause stability
| or performance problems.
| Ashanmaril wrote:
| Doesn't seem much better on iOS. I just checked and I've got
| Twitter with 2.59GB, Instagram with 1.27GB, TikTok with
| 1.21GB, etc.
| [deleted]
| lazyjeff wrote:
| At the end of the day, the data has to live somewhere. If not
| on disk, then in memory or straight from the network. If the
| device is rooted, then the user would technically have access
| to any of these, so it doesn't really matter.
| rideontime wrote:
| But these are opened snaps. They don't have to live somewhere
| because they're supposed to be dead.
| dexterhaslem wrote:
| yea this is ridiculous, they have lied through their teeth
| about what happens on Android. tho of course its probably
| half clueless negligence or a missed change, half not
| caring. all the same
| DavidPeiffer wrote:
| I believe Snapchat has an option to reopen the snap you
| just viewed, but I don't think it's available for very long
| - maybe a couple minutes after viewing tops?
|
| No excuse I can think of for the media existing for more
| than a few minutes post-viewing.
| jjeaff wrote:
| I don't think an app has the kind of low level access required
| to actually wipe something from memory. Unless android has an
| API with a function to do so. I assume you are just telling the
| OS to delete the file and the OS does that however it normally
| does that. Truly wiping a file from storage requires
| overwriting it with random data.
| jaywalk wrote:
| That doesn't seem to be the case here, because the files are
| actually deleted once the user logs out of Snapchat. So it's
| obviously the Snapchat app itself that is triggering the file
| deletion, not the OS.
| pessimizer wrote:
| The person you're replying to is referring to making the
| files unrecoverable. The word most often used is "shred."
|
| edit: The Snapchat app, like the vast majority of
| applications, asks the OS to delete files. It very probably
| doesn't have any direct access to I/O.
| fragmede wrote:
| With wear leveling and modern filesystems, it's harder than
| that _actually_ overwrite the file on disk (for modern
| definitions of the word disk). The operating system will ask
| the storage device to delete the data, but there aren 't
| actually guarantees that the storage device actually listened
| to the operating system's request to delete the data.
| m4rtink wrote:
| Which is why if you care about sensitive data not being
| recoverable from failed media (eq. banking database, PII,
| mediacal records, etc.) you should always use full disk
| encryption (LUKS, bitkeeper, veracrypt, etc.).
|
| That way anything one could recover from that device
| afterwards would be effectively random noise to them
| without the decryption key, regardless how the firmware of
| the device actually wrote the individual data blocks.
| forgotmypw17 wrote:
| Snapchat is user disempowerment patterns taken to their logical
| conclusion: The developer has full access to all their data,
| while the users have none.
|
| The other big players have been moving in that direction, making
| it less and less accessible and exportable, but Snap takes the
| cake.
| [deleted]
| heavyset_go wrote:
| Last time I looked back in ~2016, Snapchat also persisted chat
| text contents in the Android app's SQLite database even after the
| messages "expired".
___________________________________________________________________
(page generated 2021-08-09 23:01 UTC)