Восстановить удалённый файл через /proc hard
- name
recover-deleted- image
labctl-base:3.12- timeout
- 30s
- tags
- filesystem, internals, recovery
задание
Восстановить удалённый файл через /proc
Демон secret-writer открыл /data/secret.txt на запись и продолжает
дописывать туда данные (лог-стиль). Кто-то случайно сделал rm /data/secret.txt.
Самого файла на диске уже нет, но процесс всё ещё держит его открытым через
файловый дескриптор — а значит, содержимое всё ещё доступно через /proc.
Задача
Восстановите текущее содержимое в файл /tmp/recovered-secret.txt. Конкретно:
там должна оказаться строка, начинающаяся с the-password-is- (маркер лабы),
за которой идёт сам пароль.
Симптомы
$ ls /data/secret.txt
ls: cannot access '/data/secret.txt': No such file or directory
$ ls -l /proc/$(pgrep -f secret-writer)/fd/ 2>/dev/null | head
total 0
lrwx------ 1 root root 64 ... 0 -> /dev/null
lrwx------ 1 root root 64 ... 1 -> /dev/null
lrwx------ 1 root root 64 ... 2 -> /dev/null
l-wx------ 1 root root 64 ... 3 -> /data/secret.txt (deleted) ← вот оно
Видите (deleted) у FD — это и есть «удалённый, но открытый» файл.
Как восстановить
Файл доступен как /proc/<pid>/fd/<n> — это символическая ссылка на inode
(пусть и помечена deleted). Можно её просто скопировать:
$ cp /proc/<pid>/fd/3 /tmp/recovered-secret.txt
$ cat /tmp/recovered-secret.txt
the-password-is-s3cret
<pid> = PID процесса secret-writer, <n> = номер FD со ссылкой на
удалённый файл.
Почему это hard
Это классический трюк с LKSF/forensics: «думали, файл пропал, а процесс его
держит». Реальные сценарии — случайно удалённые логи nginx/mysql, которые
продолжают занимать место на диске (FD жив → inode не освобождён), или
вытащить ключ из памяти работающего сервиса. Лабра учит читать /proc/<pid>/fd
и понимать разницу между именем файла и inode.
терминал
закрывается при остановке сессии · Ctrl+D чтобы выйти · F11 полный экран
подсказки
⚠ открытые подсказки учитываются в рейтинге
попытки
- загрузка…