Исследование swap-раздела ОС, ушедшей в suspend to disk

Это хорошо, что ты вынес обсуждение из Talks. А в выводе команд из той темы ты видишь Escape-последовательности? (посмотри направив конец трубы в less например, наверняка ты хоть раз запускал ncurses приложения, да тот же top наконец) Если да, то почитай man script, может быть ты решил записать свои действия?

Очень интересно.
Нагрепал логи консоли юзера на /dev/sdb2
При том что /dev/sdb2 расположен на SSD, где нет (и никогда небыло) ни свапа ни /var ни /home.

Такс.
В моем случае, кажется, проблема ясна.
У меня /tmp в на SSD, а не в памяти, унесу и завтра опять проверю.

Сохранять данные в незанятой области ФС слишком ненадёжный способ - очень велика вероятность, что они будут затёрты каким-нибудь новым файлом. Пометить эти сектора диска как занятые - fsck может выдать предупреждение, что сектора заняты, но не принадлежат ни одному файлу (я в этом не уверен, но это было бы логично). Поэтому никакой руткит так хранить логи действия юзера не будет. Объяснение простое - был создан временный файл (например, для IPC), а потом удалён.

Ну а в свопе так вообще вы очень много подобных строк найдёте. Как минимум, потому что там будут все консольные буферы. В том числе и уже не существующие (тут аналогично с файлами - память при освобождении не затирается тут же нулями, а потеряет своё содержимое, только когда будет выделена повторно уже другой задаче).

Понятно, что кто-то создаёт файлы в /tmp. Да только не понятно, кто.

то почитай man script, может быть ты решил записать свои действия?

Я знаю, что такое script, но если бы это был он, то запись осталась бы в каком-нибудь файле и я бы его нашел через debugfs.

А вынес из талксов я потому что мне интересно, можно ли как-то расковырять swap-файл более интеллектуальным способом чем strings, что бы найти там данные конкретного приложения.

Или восстановить содержимое открытых файлов.

Сохранять данные в незанятой области ФС слишком ненадёжный способ - очень велика вероятность, что они будут затёрты каким-нибудь новым файлом.

Иногда скрытность важнее надёжности.

никакой руткит так хранить логи действия юзера не будет

Может и будет

Ну а в свопе так вообще вы очень много подобных строк найдёте.

Это понятно, мне интересно, есть ли вообще методы оффлайнового анализа свопа

очень велика вероятность, что они будут затёрты каким-нибудь новым файлом

Если руткит ядерный, он может модифицировать таблицу занятых секторов в самом ядре, тогда fsck, который работает напрямую с блочным устройством, ничего не найдёт. Плюс, дескрипторы не освобождаются пока приложение их не закроет, так что модифицированный Terminal может например наоткрывать файлов и сразу их удалить, а потом смело писать в них логи и может быть даже отправлять по сети...

Прочитал тот тред и быстренько просмотрел файлики, которые наоткрывала tilda через vte. В одном виден весь текстовый вывод терминала, как он и есть в tilda. Файл обычно получает от open() номер 13. У тех, у кого /tmp не на tmpfs и возникают такие штуки. Сам файл удалённый, поэтому прочитать его можно из /proc, пока ещё захвачен дескриптор.
% less /proc/$(pgrep -x tilda)/fd/13
Все претензии к разработчикам vte.

Программа обычно получает от open() номер 13

Криво выразился, можно считать, что я этого не писал (забыл стереть)

И в заключение обо всём этом - (u)rxvt такой хернёй не страдает, учтите это.

И в заключение обо всём этом - (u)rxvt такой хернёй не страдает, учтите это.

А чем они отличаются друг от друга и от xterm?

А чем они отличаются друг от друга и от xterm?

[offtop] (u)rxvt шустро работают даже на старых видюхах без аппаратного ускорения 2d. Намного шустрее xterm. Особенно заметно при выводе большого количества текста (ls -lR /etc/, например) . xterm будет не спеша выводить строчку за строчкой и перематывать текст, а rxvt сразу покажет текущее состояние, без показной перемотки предыдущего.

мне интересно, есть ли вообще методы оффлайнового анализа свопа

100% есть, но не паблик-методы. Так что если если вы за свою систему переживаете - то всё на luks вместе со свопом.

100% есть, но не паблик-методы. Так что если если вы за свою систему переживаете - то всё на luks вместе со свопом.

Почему не паблик?

Впрочем конечно самый простой и очевидный способ — через dd снять полный дамп винта, записать его на внешний носитель, который потом отключить.

А после этого дать системе проснуться. Хотя, если пароль запросит, то уже сложнее, надо вначале найти на свопе например память процесса xlock и изменить её так что бы он сегфолтнулся после пробуждения...

Вот я про это и создал тему — интересно, есть ли готовые программы для того что бы найти память конкретной программы, не гадая по strings и grep вслепую.

Почему не паблик?

Просто потому что те, кто использует эти методы, как правило не пишет для паблик, а если и пишет - то еще найти такие статьи надо постораться сильно
Утилиты то есть в составе всяких CAINE, а вот «методы» - ... вобщем только на всяких спецкурсах

Утилиты то есть в составе всяких CAINE

Ну уже хоть что-то...

на всяких спецкурсах

А разве манов утилит мало? debugfs я же научился применять...
И почему только на спецкурсах? Мне вот как простому юзеру нужно.

Ну дайте юзеру gdb м ман к нему, что, он сразу реверсинженером станет чтоли?

Ну дайте юзеру gdb м ман к нему, что, он сразу реверсинженером станет чтоли?

Не сразу, а когда полностью изучит его, научится применять все функции и поймёт их смысл... да и вроде GDB не для реверса, а только для отладки программ с открытым кодом.

Но если он плюс к дебаггеру и прочим утилитам изучит ещё и ассемблер, то вполне.