Самопроизвольное изменение исполняемого файла

1. Изменяются ли другие файлы?
2. Дата изменения /usr/lib/chromium/chromium совпадает с тем, когда он был установлен?
3. Если изменяются или возможно изменяются, а дата совпадает, но файл всё равно изменился, можно в первую очередь проверить HDD/SSD — может сыпется.

Это взлом?

Такой возможности тоже исключать нельзя. Но какой-то странный взлом, от которого браузер вместо того, чтобы нормально работать, но при этом молча стучать/майнить/итд, зачем-то просто падает.

Это взлом?

Не обязательно. Есть ещё вариант, что откисает диск. Как вариант, можно попробовать глянуть smart и/или проверить файловую систему на ошибки.

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

Посмотри что там изменено то, какие байты? А ещё сравни вывод stat на исправной системе и после того как она испортится.

Это взлом?

Нет.

Это жёсткий диск приказывает оч. долго жить.

Это жёсткий диск приказывает оч. долго жить.

Могу я поинтересоваться, где скачать свежую версию libastral?

Поинтересоваться можно, скачать нельзя, распространяется только на дискетках.

Only hardcore.

Другие файлы не изменяются. Сразу после переустановки (или спустя пару часов) изменений в файле не наблюдается. Проверил диск из gnome-disk-utilities - все ОК! До кучи проверил с помощью Crystal Disk Info из Windows XP - состояние диска хорошее.

Это взлом?

нет

SMART глянул через gmome-disk-utilities, все - ОК! Файловую систему проверил, загрузившись с флешки, файловая система исправна.

какой у тебя тип файловой системы?
имхо, вместо chmod a=rx /usr/lib/chromium/chromium нужно использовать chattr +i /usr/lib/chromium/chromium (хотя намного лучше было бы узнать, кто портит сам файл)

Хорошее — это какое? Конкретные цифры.

Ну и что с остальным? Дата изменения файла меняется?

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

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

а каков характер изменений? Что если каким-нибудь биндиффом пройтись?

Проверь память memtest’ом.

Возможно кэш, конфиги, или ещё что-то сломалось.

Сразу после переустановки (или спустя пару часов) изменений в файле не наблюдается.

М.б. сбойный сектор? Если файл, при переустановке, записывается поверх существующего, по тем же самым секторам, то пока он в кеше - работает нормально. Через некоторое время его вытесняет, происходит чтение с диска, и всё начинает крашиться.

Попробуйте сразу после переустановки браузера, загрузиться из чистого окружения, например с live-флешки, и проверить контрольную сумму сбойного файла.

UPD: Перечитал стартовое сообщение темы:

Хватает на несколько часов или до перезагрузки; затем, все - по новой.

Сильно похоже что у Вас накопитель «капризничает»…

Обождите. Эксперементирую.

Пока, только это.

https://www.linux.org.ru/help/markdown.md

Исправлено:

Сделать спойлер не получается:

>>>  
<<<  

Если исключить тупняк (типа браузер автоматически обновляется или какой-нибудь, прости господи, антивирус «удаляет вирус»), то очень похоже на взлом.

Я бы переустановил всю систему и очень аккуратно бы восстанавливал данные из бэкапа, считая, что он заражён.

Версию с диском не поддерживаю. Диск или работает или выдаёт ошибки. Чтобы диск выдавал неверные данные - такого не бывает. С битой оперативкой могут быть приколы, но не такие, что на диске самопроизвольно меняются файлы. Погонять мемтест лишним не будет.

Спойлеры в комментариях и не будут работать – просто оберни вывод команд в блок кода.

Проверил диск из gnome-disk-utilities - все ОК! До кучи проверил с помощью Crystal Disk Info из Windows XP - состояние диска хорошее.

Вы с винды пришли? Зачем вам тонна сторонних утилит если вся нужная инфа выдается через smartctl?

Raw_Read_Error_Rate 109 из 006
Seek_Error_Rate 089 из 030
Hardware_ECC_Recovered 083 из 000

Ну да, ну да, а так с диском всё в порядке, ага.

Как я и сказал, выкиньте эти ссаные гуёвые тулзы, они хню показывают.

Из него и выудил инфу последний раз.

Чтобы диск выдавал неверные данные - такого не бывает.

Прекрасно бывает, особенно когда диск говно или старый. Еще кайфово, когда пишешь файл, write выдает OK, читаешь, а там говно и хорошо если в dmesg это видно.

Короче диск в помойку. Можно попробовать отформатить, прокатить полный анализ с форматированием на поиск битых секторов, переназначить чтобы их не трогало, создать новую ФС, но если он начал сыпаться - то это с концами. Заказывайте новый, этот будет сбоить дальше и сильнее. То что это попало на хром - повезло что заметили.

Прекрасно бывает, особенно когда диск говно или старый.

Не бывает. На современных дисках все данные хранятся в зашифрованном виде с информацией о восстановлении. Изменение битов это нормальная ситуация, а если битов слишком много изменилось, то блок уже не расшифруется.

Еще кайфово, когда пишешь файл, write выдает OK, читаешь, а там говно и хорошо если в dmesg это видно.

Потому, что write пишет в дисковый кеш. На диск пишет отдельный ядерный процесс. fsync в такой ситуации вернёт ошибку.

На современных дисках все данные хранятся в зашифрованном виде с информацией о восстановлении.

Спуститесь с небес на землю.

Хуже нету, когда то работает, то не работает. Последний раз перезагрузился - chromium не изменился. Интересно, если полностью удалить chromium, и потом установить заново, он установится на те же сектора? На то же место, с точки зрения железа?

А кстати у меня было полгода назад - один файл показывал признаки битости, после отправки куда-то в /proc/ то ли /sys/ команды сброса дисковых кеешй - починился.

Вместо гаданий всё-таки сравни побайтово битый файл с небитым, и проверь изменилось ли что-то в выводе stat про него (кроме строчки с временем последнего чтения) после того как он побился.

Memtest:
Pass 1; Errors 0

root@serfer:/home/serfer# stat /usr/lib/chromium/chromium  
Файл: /usr/lib/chromium/chromium  
Размер: 217059512 Блоков: 423960 Блок В/В: 4096 обычный файл  
Устройство: 802h/2050d Инода: 1835021 Ссылки: 1  
Доступ: (0555/-r-xr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)  
Доступ: 2024-05-06 19:56:49.341276817 +0500  
Модифицирован: 2024-01-17 01:35:05.000000000 +0500  
Изменён: 2024-05-05 00:09:55.374954800 +0500  
Создан: 2024-05-04 23:16:45.571011400 +0500

Странно: даты создания и изменения не совпадают, но debsums говорит, что файл не изменен.

Это был тот memtest, который загружается вместо ОС? Если нет, то стоит протестировать им. И ещё имеет смысл поискать там среди тестов bitfade test и включить его, потому что по умолчанию он отключен. Bitfade может обнаружить ошибки, которые не видны при активном использовании памяти в основном наборе тестов.

Несколько часов ставил опыты над системой. Команды и их выхлопы приводить не буду. Суть такова:
До и после изменения /usr/lib/chromium/chromium права доступа не меняются (0555).
Когда debsums говорил, что файл не изменен, я его скопировал на Рабочий стол. Какое-то время помучал chromium, пока он не стал падать. debsums сказал, что файл изменился. Я создал контрольные суммы обоих файлов (md5sum): /usr/lib/chromium/chromium и того, что скопировал на Рабочий стол - они совпали. Я переустановил chromium # apt reinstall chromium (время создания и изменения файла изменились на текущие), создал контрольную сумму. Все три контрольные суммы совпали.
Т.е. дело, скорее всего, не в винчестере. Может быть, система совсем убита?

Файловая система та, что ставится по - умолчанию: ext4.

Когда debsums сказал, что файл изменился, дата изменения не поменялась. Но и сам файл, по - факту, не изменился (я создал контрольные суммы до и после).

Кэш я вычищаю ручкми (из домашней директории). Конфиги изменились только те, которые я сам менял.

Браузер установлен из репозитория - сам не обновляется, наверное. Антивирусного монитора тоже нету. Переустановить систему можно, но где гарантия, что ее не взломают в тот же день?

Но и сам файл, по - факту, не изменился (я создал контрольные суммы до и после).

Значит он таки не меняется? Проблема, видимо, в чём-то другом совсем.

Если перезапустить комп ничего не переустанавливая - всё чинится?

debsums сравнивает контрольные суммы с /var/lib/dpkg/info/имя_пакета.md5sums - там сумма совпадает или отличается от этих? И проверь её после только что перезапущеного компа ещё раз когда сломается.

И ещё сделай diff бекапа с битым файлом - он тоже скажет что они одинаковые?

Для начала надо убедиться, что ФС не задействует CoW когда товарищ копирует файл. Потому что так как фс считает, что файл не поменялся - то при активном CoW он будет снимать чексумму одного и того же блока.

Как вариант - скопировать файл до модификации куда-то на другой физический диск и то же самое сделать после «поломки»

говорит, ext4. А там нет CoW.

Пробовал включать логи у браузера? Хотелось бы посмотреть, что он выдаёт после падения, а то так можно долго гадать на кофейной гуще.

Да просканировал memtest_ом, который загружается из меню grub.

Прошу отложить обсуждение на пару - тройку дней. У меня уже шарики за ролики закатились. ;О).

удваиваю Dr64h

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

ну и в dmesg после падения посмотри - может там что-то интересное появляется (apparmor, например)

Откуда установлен хромиум? Может ли так быть, что хромиум установлен из апта, а потом сверху перезатерт хромиумом другой версии из какого-нибудь снапа?

если хочешь попробовать убрать подозрения с винчестера/ssd переименуй каталог к примеру в «/usr/lib/chromium2/». И просто переустанови хромиум. Если это влияние битого сектора, то оно останется со старым катлогом(если на новый битый сектор не наткнется)

Насколько я понял, bitfade test - один из стандартных тестов memtest (девятый, вроде бы). Запускать его отдельно не имеет смысла.