Live data from Hacker News

F* file system – file search that reads SSD directly bypassing OS kernel

github.com

31–40 of 54 posts

Re: F* file system – file search that reads SSD directly bypassing OS kernel

#31
post #30
post #27

Earlier quoted context omitted.

I gave Sonnet 4.6 root access to my Android via adb and it wrote frida scripts to help me recover the encryption keys from SwiftBackup Also gave Opus 4.6 access to a Kubernetes container and it was able to use pyrasite (a Python replacement that attached to a running process with gdb) to debug a "memory leak" in Python I don't think I'd let them run unattended on anything I care about especially if there weren't back…

It's been a while but last year I'd see posts like "Claude nuked my homedir / entire drive" on a regular basis. I don't know if they fixed that (or just made it very rare).

In fairness to Claude, I've nuked my homedir (had 2 tmux panes open, 1 in home and 1 in /tmp/... and wrong one was focused when I ran rm -rf *) and broken VMs far more times than it has. I now embrace IaC and backups

Re: F* file system – file search that reads SSD directly bypassing OS kernel

#32
post #2

This is practically the most useless project becuase you can not run it without sudo permissions, but it was insanely fun to work on it supports ext4, btrfs, and apfs. Multithreaded, supports compression, nested volumes, and can even search detached volumes like .iso and .dmg without mounting An interesting bonus point: you can't really vibe code it cause clankers can not run sudo commands

I think it's more that the harnesses created by the labs are... not always the most thoughtful.

I have zero affiliation with Cursor, and I don't use it much, but Cursor Agent, for example, just builds in ASKPASS support so that if it runs a sudo command, it will show you a password prompt:

https://cleanshot.com/share/fgHYMZyz

Re: F* file system – file search that reads SSD directly bypassing OS kernel

#33
Run this once per boot:

  sudo setfacl -m u:$USER:r-- /dev/nvmen01p2 # or whatever
And then any program you run will have read access to the block device.

Or if you want to only give fff access,

  sudo groupadd diskreaders
  sudo setfacl -m g:diskreaders:r-- /dev/nvmen01p2
  sudo chown :diskreaders /path/to/fff
  sudo chmod g+s /path/to/fff
And just run fff normally after that. Here too, the facl command has to be run every boot. Just crontab it. Everything else runs once.

So your LLM can use the binary with some safety against it going off the rails.

Re: F* file system – file search that reads SSD directly bypassing OS kernel

#35
post #2

This is practically the most useless project becuase you can not run it without sudo permissions, but it was insanely fun to work on it supports ext4, btrfs, and apfs. Multithreaded, supports compression, nested volumes, and can even search detached volumes like .iso and .dmg without mounting An interesting bonus point: you can't really vibe code it cause clankers can not run sudo commands

> run sudo commands

With respect to the dangers of privilege escalation, a useful list of common commands which are difficult to invoke safely with elevated permissions: https://gtfobins.org/

> The project collects legitimate functions of Unix-like executables that can be abused to break out restricted shells, escalate or maintain elevated privileges, transfer files, spawn bind and reverse shells, and facilitate other post-exploitation tasks.

Prior discussion: https://news.ycombinator.com/item?id=47931035

Re: F* file system – file search that reads SSD directly bypassing OS kernel

#36
post #2

This is practically the most useless project becuase you can not run it without sudo permissions, but it was insanely fun to work on it supports ext4, btrfs, and apfs. Multithreaded, supports compression, nested volumes, and can even search detached volumes like .iso and .dmg without mounting An interesting bonus point: you can't really vibe code it cause clankers can not run sudo commands

> This is practically the most useless project becuase you can not run it without sudo permissions Well, you could whitelist the tool in sudoers. This would let LLMs use it too.

Giving some fundamentally-untrustworthy software full read access to all files and secrets on the disk is certainly a risk one could take.

Re: F* file system – file search that reads SSD directly bypassing OS kernel

#37
post #7

But can it bypass the magic performed by the SSD controller? In particular, can it be certain that a flush is really a flush?

Related: Could it be of any use in easily detecting counterfeit SSDs, which have been hacked to report a fraudulent size?

Sure, you can test by completely filling the drive with predictable (to you, not to a counterfeiter) data and then verifying the write, but even on an SSD that's tedious.

Post reply on HN