Преамбула

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

Пример тестового бинарного файла (в Linux):



В Windows:



Понятно, что напечатать это нельзя, для распечатки надо преобразовать бинарный RAW-формат в что-то удобопечатоемое, например в строки, содержащие шестнадцатеричные цифры:

EA 38 B6 C1 18 1A 4F B3 5F 81 B7 A4 1B 50 89 18 B3 0B 24 27 36 59 57 D0 3A 78 1C
3E D6 F2 27 01 13 4B 54 65 6E 44 61 23 7D D4 ED 60 CE 8E C1 A2 58 45 BB 35 84 A7
69 28 D4 09 5F 99 F5 27 CA 30

Linux

В Linux есть сразу несколько инструментов, позволяющих выполнить дамп файла в набор шестнадцатеричных значений, причем "из коробки". Не зря же эта ОС изначально писалась программистами для программистов.

Кратко ознакомиться с этими инструментами можно здесь:

Convert Binary Data to Hexadecimal (оригинал статьи на буржуйском)
Преобразование двоичных данных в шестнадцатеричный формат (Перевод на русский, PDF)

Я воспользовался утилитой hexdump, и написал небольшой скрипт, который при вызове его с параметром, содержащим путь к файлу, создает в каталоге с оригинальным файлом файл имя_оригинального_файла.dump, который содержит шестнадцатеричное представление исходного файла:

dumpfile <имя_файла>

Основной алгоритм укладывается в одну строку:

cat $1|hexdump -e '27/1 "%02X " "\n"' >$1.dump

1. Читаем файл, переданный на вход скрипта командой cat.
2. Передаем в pipe (|) данные hexdump'у
3. Скидываем вывод (>) в файл $1.dump

Скрипт на GitHub

Windows

В винде, как обычно - в таких случаях все через жопу, слава Ктулху, нашлись умные люди, которые все сделали за меня на BAT/CMD и доступном в системе JScript.

Совместимость - начиная с Windows XP

Перевод справки BAT-файла.

HEXDUMP [/Опция [Значение]]...

Записывает содержимое стандартного ввода в шестнадцатеричном виде в стандартный вывод, по 16 байт на строку, используя следующий формат:

ООООООО ХХ ХХ ХХ ХХ ХХ ХХ ХХ ХХ ХХ ХХ ХХ ХХ ХХ ХХ ХХ ХХ ХХ ХХ ХХ ХХ ААААААААААААААААА

где:

0000000 = шестнадцатеричное смещение в пределах файла
XX = шестнадцатеричное значение байта
AAAAAAAAAAAAAAAA = байты в формате ASCII (управляющие коды и не-ASCII в виде . [символ точка])

Вывод кодируется как ASCII, каждая строка завершается символом CarriageReturn - перевод строки.

Поведение можно изменить, добавив любую комбинацию следующих параметров:

- /I InFile — ввод из InFile вместо стандартного ввода
- /O OutFile — вывод в OutFile вместо stdout: — перезаписывает InFile
- /NA - отключить вывод ASCII-символов.
- /NO - отключить вывод смещений
- /R - Необработанный шестнадцатеричный код в одной строке без пробелов между байтами.
- /LF - LineFeed как признак конца строки (UNIX-формат) вместо CarriageReturn LineFeed (по умолчанию, формат Windows)
- /NL - без разделителей строк, весь вывод в одной строке без разделителей строк
- /U - вывод в кодировке Unicode с BOM (UTF-16)
- /V - Вывести информацию о версии
- /? - Вывести эту справку

HEXDUMP.BAT версии 2.1 был написан Дэйвом Бенхамом.
и поддерживается на https://www.dostips.com/forum/viewtopic.php?f=3&t=8816

Нужные (мне) параметры

Вывод в файл (пример):

hex_dump.bat /I test.temp /O test.temp.dump /NA /NO

Вывод на консоль:

hex_dump.bat /I test.temp /NA /NO

Пример вывода на консоль:

60 ab 2b b8 4a 3f 0d 91  a0 a4 09 f0 8f 4b 51 95
3a 22 1b 0e 5b 6d d0 3f  80 96 c5 22 98 dc 4a 2b
89 38 52 96 42 c0 ab 04  c4 8e b8 87 dd 7c 4a b2
e1 6a b1 c2 30 66 82 54  21 5a 40 a2 bb f8 19 89

Скачать BAT-файл

С GitHub
Перевод помощи к скрипту

Источник

Это репост с сайта http://tolik-punkoff.com
Оригинал: https://tolik-punkoff.com/2023/07/25/preobrazovanie-dvoichnyh-raw-dannyh-v-tekstovyj-shestnadtsaterichnyj-format/

Преамбула

На самом деле, многими реверсерскими командами создана куча генераторов автопатчеров, подсовываешь ему оригинальный и измененный экзешник, и тебе генерируется автопатчер, даже с красивой картинкой и восьмибитной музыкой. Но "есть проблема" (ц) Патриарх Кирилл:

- Не на все автопатчеры хорошо реагируют антивирусы
- Автопатчеры нестандартны, кто в лес, кто по дрова.

Неплохо бы сделать так, чтоб и антивирусы не ругались, и оно хоть как-то относительно стандартно выглядело. И такое решение есть - модуль VPatch для системы установки NSIS. Далее расскажу, как этим модулем воспользоваться, чтобы пропатчить уже установленную программу, а также, немного расширю пример, покажу как в патч "зашить" еще и отмену патча. Естественно, чтобы все повторить, у вас должен быть установлен NSIS хотя бы в минимальной комплектации.

Подготовка #1

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

Для генерации данных для патча, VPatch использует свои утилиты командной строки, которые в комплекте идут, но устанавливаются криво, так что качаем утилиты отдельно и устанавливаем их (установятся в %WINDIR%).

Скачать установщик здесь

Подготовка #2

Теперь нужна лабораторная крыса, т.е. программа, которую будем патчить, возьмем оригинальный CrackMe из предыдущего примера (копия) и напишем ему стандартный инсталлятор:

Исходник инсталлятора
Готовый инсталлятор тестовой программы
Исходник CarckMe

Устанавливаем ее.

Для патча нужен оригинальный экзешник

И пропатченный вручную

( Подробное описание патча )

Проверка

Патч:



Восстановление:



Источники

- VPatch - Free Patch Generator
- VPatch plug-in
- Документация и исходники оригинального примера
- NSIS: контрольная сумма (MD5), сравнение файлов. (копия)
- NSIS: Получение списка файлов с MD5-хешами. (копия)
- NSIS: Получение даты и времени. (копия)

Исходник примера

Пример полностью на GitHub
Основной исходник

Это репост с сайта http://tolik-punkoff.com
Оригинал: https://tolik-punkoff.com/2023/03/30/patch-na-nsis-s-vozmozhnostyu-otmeny/

Преамбула

Попросили показать самый простой пример по реверсингу. Ну ладно, сделал простейшую программу, окно где надо ввести пароль:



Ввели правильно, получаем окно одобрямса:



Ввели неверно, программа отправляет на повторный ввод с сообщением об ошибке:



Если нажать Cancel - программа просто завершится.

Сам CrackMe сделан на базе прошлого примера окна типа InputBox (копия), не стал даже с закрытием "пароля" "звездочками" заморачиваться, говорю же, очень простой CrackMe, естественно, без всякой упаковки и навесных защит.

Вообще, пароль можно подсмотреть, открыв экзешник, например, в просмотровщике Far Manager по F3:



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

Но мы пойдем другим путем, как завещал великий Ленин! Хотя способ будет не сильно далеким от "подсмотра", чтоб было слегка посложнее и интереснее - не будем пользоваться отладчиком, а воспользуемся дизассемблированием. В отладчике вместо одного шага (простого подсмотра пароля) будет полтора, а так все же веселее.

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

( Читать далее )

Ссылки

1. Исходник CrackMe
2. Бинарный файл
3. Чтоб два раза не вставать: Разница между инструкциями test и cmp Копия в PDF

Это репост с сайта http://tolik-punkoff.com
Оригинал: https://tolik-punkoff.com/2023/03/03/sovsem-prostoj-crackme-i-kak-ego-slomat/

Преамбула



Когда-то писал о том, что в новых версиях Foxit Reader пропал PDF-принтер и Foxit PDF Creator (копия). Так вот, новая гадость пришла откуда не ждали, теперь он сносит PDF-принтер при обновлениях.

Штатного способа отключить обновления нет

Решение

Сама программа обновления имеется в двух экземплярах:

В каталоге Foxit:
C:\Program Files (x86)\Foxit Software\Foxit Reader\FoxitUpdater.exe

И в каталоге Application Data:
C:\Users\<username>\Application Data\Foxit Software\Addon\Foxit Reader\FoxitReaderUpdater.exe, вместо <username> - ваше имя пользователя.

Просто снести два экзешника не получится, точнее получится, но Foxit Reader будет при каждом запуске ругаться, что не нашел свой обновлятор. Зато не будет ругаться, если обновлятор (оба файла) просто заменить на экзешник, который ничего не делает, а такой я уже делал (копия), правда по другому поводу. Сделал еще и версию на MASM

Написал патч на NSIS

И для себя, если винды переустанавливать, и для клиентов, на всякий случай.

Репозиторий на GitHub
Исходник NSIS
Копия (без дополнительных файлов) на PasteBin
Скачать готовый патч

Дополнительно
В принципе, исходник достаточно простой, оставлю только ссылку на получение MD5-суммы файла в NSIS: NSIS: контрольная сумма (MD5), сравнение файлов. (копия).

Примечание: почему-то MD5-сумма, получаемая NSIS-плагином (md5dll.dll) отличается от MD5-суммы, полученной средствами Windows (копия). Почему, пока не разобрался. Может, позже напишу.

Это репост с сайта http://tolik-punkoff.com
Оригинал: https://tolik-punkoff.com/2022/06/13/otklyuchenie-obnovleniya-foxit-pdf-reader-v-8-3-2-25013/

Преамбула

В принципе, патч или кряк для программы можно сделать с помощью NSIS, конечно, это будет не классический патч, т.е., когда меняешь в исходном экзешнике несколько байт, а архив с готовым экзешником и сценарием установки. Но зато и возможностей больше, можно Реестр или INI-файлы подправить, например.

Но одна из главных задач любого патча, перед началом работы проверить, а не пропатчен ли файл уже. Делается это обычно так - берется контрольная сумма MD5 или CRC32 оригинального файла и сравнивается с заранее известной суммой. Если совпадает - файл наш, можно патчить. Можно и наоборот - сравнить контрольную сумму оригинального файла с известной контрольной суммой пропатченного, если они равны - файл уже модифицирован, сообщаем пользователю и завершаем работу.

Получение MD5-суммы в NSIS.

Для получения MD5 в NSIS имеется плагин MD5 Plugin.

Скачиваем архив, копируем md5dll.dll из директории ANSI архива в директорию ANSI-плагинов NSIS (у меня C:\Program Files (x86)\NSIS\Plugins\x86-ansi\), а из директории UNICODE архива в директорию UNICODE-плагинов (C:\Program Files (x86)\NSIS\Plugins\x86-unicode). Понятно, что пути к вашим каталогам плагинов могут отличаться, т.к. зависят от того, куда установлен NSIS/

Примеры использования

Вычисление контрольной суммы строки:

#generate MD5sum of string
md5dll::GetMD5String "TestString"
Pop $0
DetailPrint "MD5 (string): [$0]"

Вывод:
MD5 (string): [5b56f40f8828701f97fa4511ddcd25fb]

Получение случайного хэша MD5:

#generate random MD5sum
md5dll::GetMD5Random
Pop $0
DetailPrint "MD5 (random): [$0]"

Вывод:

MD5 (random): [864fd151525efad56947f25fa3daeb75]

Получение контрольной суммы файла:

#generate MD5sum of file
DetailPrint "MD5 sum of file $EXEDIR\test\1.exe"
md5dll::GetMD5File "$EXEDIR\test\1.exe"
Pop $0
DetailPrint "MD5 (file): [$0]"

Вывод:

MD5 sum of file C:\!\Installers\MD5Sample\test\1.exe
MD5 (file): [03f3ba055d9f325c9abc90181f82657b]

Сравнение файлов

Для более красивого кода сравнения, рекомендую подключить инклюд с макросами логических операторов LogicLib.nsh (есть в комплекте NSIS):

!include LogicLib.nsh

Пример:

md5dll::GetMD5File "$EXEDIR\test\1.exe"
Pop $0
md5dll::GetMD5File "$EXEDIR\test\3.exe"
Pop $1
DetailPrint "Files $EXEDIR\test\1.exe"
DetailPrint "and   $EXEDIR\test\3.exe"
DetailPrint "MD5: $0" 
DetailPrint "and   $1"
${If} $0 == $1
	DetailPrint "IS IDENTICAL!"
${Else}
	DetailPrint "IS DIFFERENT!"
${EndIf}

Пример вывода (сравниваются два одинаковых файла, а потом два разных):

Files C:\!\Installers\MD5Sample\test\1.exe
and C:\!\Installers\MD5Sample\test\2.exe
MD5: 03f3ba055d9f325c9abc90181f82657b
and 03f3ba055d9f325c9abc90181f82657b
IS IDENTICAL!
Files C:\!\Installers\MD5Sample\test\1.exe
and C:\!\Installers\MD5Sample\test\3.exe
MD5: 03f3ba055d9f325c9abc90181f82657b
and 7baeee10b3cd6c210c4fcd61b92b8e1e
IS DIFFERENT!

Ошибки при работе библиотеки MD5

Если файл отсутствует, то функция md5dll::GetMD5File может выдать непредсказуемый результат, строку случайных символов, поэтому, перед использованием md5dll::GetMD5File следует проверять наличие и доступность файлов.



Ссылки

Библиотека:
- Описание на официальном сайте: MD5 plugin
- Скачать с официального сайта
- Зеркало
- Копия (v 0.5) на Mega.nz

Пример из заметки целиком на GitHub

Это репост с сайта http://tolik-punkoff.com
Оригинал: https://tolik-punkoff.com/2022/05/10/nsis-kontrolnaya-summa-md5-sravnenie-fajlov/

Преамбула

Понадобилась мне одна программка, которая, почему-то не захотела ставиться на мою систему, причем не захотела без всяких ошибок и вылетаний. Инсталлятор просто висел на 1% и дальше двигаться не хотел. Зная, что поддержка винды у этой софтины зависит исключительно от бодуна разработчиков (то они винду вообще не поддерживали, потом прошлая версия прекрасно ставилась и работала, а тут вдруг опять нет), решил я в софтине поковыряться, небось, софтина-то работает, а инсталлятор кривой. Но о том, как я возился с софтиной, напишу как-нибудь позже. А тут будет такой простенький заметк про реверсинг инсталлятора.

Определение инсталлятора

Я уже как-то упоминал (копия), что инсталляторов и упаковщиков есть туева хуча на свете, и для начала надо определить, с каким именно инсталлером мы имеем дело. Для этого воспользуюсь программкой Detect It Easy (DiE), которая по своей базе сигнатур может определять тип экзешника, чем он упакован, чем скомпилирован, а если это инсталлятор - определить и его тип. Программка работает примерно также, как антивирусный сканер, определяя по сигнатурам, с чем мы имеем дело. Благо, почти все упаковщики, компиляторы или сборщики инсталляционных пакетов, так или иначе оставляют свою сигнатуру в файле.

Итак, скармливаю DiE исследуемый инсталлятор.



Видим тип - QT installer.

Об автоматической распаковке и дальнейших мыслях

Естественно, о ней я и подумал сразу же, не изобретать же велосипед, до нас его более умные люди изобрели. А не тут-то было! Автоматического распаковщика не нашел, так что стал думать... Qt проект открытый, значит, скорее всего, они особо не заморачивались, и инсталлятор представляет из себя самораспаковывающийся архив, который по структуре выглядит как-то так, как выглядят самораспаковывающиеся архивы RAR WinZip или 7Zip - в начале файла EXE-модуль, а после него данные, которые EXE-модуль распаковывает:



В принципе, что я иду верным путем, можно было понять из главного окна DiE, тот недвусмысленно сообщал про overlay (оверлей), в котором находятся QT installer data, т.е. данные QT-установщика.

( Далее под катом )

Инструменты

Detect It Easy (DiE):

- На Exe-Lab
- На Mega.nz

qresExtract:

- Binary for Windows x86
- Sources

WinHex 19.9:

- Скачать с rutracker.org
- Ссылка на Torrent-файл

Это репост с сайта http://tolik-punkoff.com
Оригинал: https://tolik-punkoff.com/2021/11/02/analiz-i-raspakovka-ustanovshhika-qtinstaller-vruchnuyu-s-pomoshhyu-hex-redaktora-i-takoj-to-materi/

Наверное, это самый смешной реверсинг во всей вселенной и даже в куче параллельных.

Итак, попросили меня бухгалтерши найти им "шарики", чтоб на обеде было во что на обеде поиграть. Нашел им бесплатный Снукер (копия), но Снукер оказался с подвохом, бесплатный-то он бесплатный, но до загрузки игры показывал рекламу, а после закрытия, отправлял на сайт, где предлагалось скачать очередной Яндекс.Спам.

"Ну ты же хакер", взмолились бухгалтерши. "Сделай так, чтоб оно никуда не ходило и ничего не просило!" А я не хакер, и даже не реверсер. Сисадмин я. Администрирую грудь.

Ок, подумал я, и уже думал скормить экзешник отладчику, ну чего же для родных бухгалтерш не сделаешь, как обнаружил в директории программы (C:\Program Files (x86)\Бесплатные игры Atarata\Снукер) два экзешника - game.exe и game.wrp.exe. game.exe - это фигня, отвечающая за показ рекламы (а чтоб не крякали, за таблицу рекордов и рестарт игры сначала), а game.wrp.exe - сама игра. Т.е. достаточно game.exe удалить или переименовать в game.exe.bak, а потом game.wrp.exe переименовать в game.exe.

crack.bat:

ren game.exe game.bak
ren game.wrp.exe game.exe

ФАНФАРЫ! Даже ярлыки не надо менять.

- Игра начинается с сохраненной до выхода.
- Нет таблицы рекордов

+ Такой кряк не нарушает лицензионное соглашение - "законы Матрицы, это законы компьютерной системы - одни можно обойти, другие поломать".

Это репост с сайта http://tolik-punkoff.com
Оригинал: http://tolik-punkoff.com/2020/11/22/detskij-kryak/

Преамбула

В заметке про пропавший из Foxit PDF Reader PDF-принтер (копия) я упомянул, что хотел расковырять старый инсталлятор, чтоб принтер оттуда вытащить (если это возможно).

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

Примечание: это не инструкция "как распаковать совсем вообще любой инсталлятор", ибо типов инсталляторов довольно много и появляются новые, а бывают вообще самописные со свистелками и вувузелами, так что покажу общий подход и совсем простой пример, на том же инсталляторе Foxit PDF Reader'а

Ссылки на все инструменты в конце заметки.

Определение типа инсталлятора

Как я сказал, типов инсталляторов очень много: Nullsoft Installer, WISE, Inno Setup, Microsoft Installer (MSI), InstallShield, и это те, которые я вспомнил просто так, не посещая гугль.

Соответственно, надо определить, с чем мы имеем дело. Как говорится, знай своего врага в лицо. И это не только первый принцип разведчика, но и первый принцип реверсера, т.е. того, кто занимается обратным инженерингом, или, говоря вульгарно, взломом, крякингом программ. За "крякиннг", котики, от настоящего реверсера можно получить кружкой пива по голове. Крякают утки, а мы будем исследовать. Но что-то я запизделся.

С виду тип инсталлятора определить довольно непросто (хотя гуру могут), так что воспользуемся специальной программой DiE (Detect it easy) 2.05, которая пришла на смену PEiD. Что это такое? Это специальная утилита, способная определять что за экзешник перед нами: тип инсталлятора (если это инсталлятор), тип компилятора, которым экзешник скомпилирован, EXE-упаковщик или т.н. "навесную защиту", если экзешник упакован или защищен от взлома специальной программой. Делает это он также, как антивирус определяет наличие вируса, по сигнатурам, т.е. определенным последовательностям байт, характерных для того или иного компилятора, упаковщика, инсталлятора и т.д.

Итак, запускаем DiE и скармливаем ей наш инсталлятор:



Как видим, инсталлятор создан в Inno Setup, осталось найти распаковщик, и в данном случае это просто (потому и взял, как простой пример). Распаковщик есть. Кладем инсталлятор в отдельную папку, копируем распаковщик в нее же, или же в папку, которая есть в переменной PATH и выполняем:

innounp -x FoxitReader806.909_prom_L10N_Setup.exe

Идет распаковка:



В результате образовалась структура каталогов, характерных для этого инсталлятора, где каталог {app}, то, что будет распаковано в каталог программы (например C:\Program Files\Foxit Reader), каталог {sd} - ProgramData, а каталог {tmp}, то, что будет распаковано во временный каталог системы. К тому же есть и install_script.iss - скрипт установщика (в его формате, и оттуда можно почерпнуть информацию, как и что делает установщик, если знаете формат скрипта).

А еще его можно интегрировать в Far-manager, см. Readme.



Выводы

Ну вот, это был маленький урок реверсинга для комментатора, определили установщик и его распаковали.
Заодно, если вы хотите заняться реверсингом, рекомендую посетить сайт https://exelab.ru/

Скачать

DiE (Detect it easy):
- На Exelab
- C Mega.nz

innounp:
- Официальный сайт
- Мой пакет (innounp распаковывается в C:\Windows)

Это репост с сайта http://tolik-punkoff.com
Оригинал: http://tolik-punkoff.com/2020/08/17/raspakovka-installyatora-na-primere-installyatora-foxit-pdf-reader/

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

Разборка оригинального bootdisk.img и подключение ramdisk'а

#!/bin/bash

RDMP="/mnt/ramzes"
LDRKRNLPATH="./ldrkrnl/"
LDRKRNLNAME="ldrkrnl.img"

echo "Making dirs"
mkdir $RDPATH
mkdir $RDMP
mkdir $LDRKRNLPATH

echo "Extracting RAMDISK..."
dd bs=1 if=$IMGPATH of=$RDPATH$RDGZNAME skip=464896

echo "Extracting loader and kernel"
dd bs=1 if=$IMGPATH of=$LDRKRNLPATH$LDRKRNLNAME count=464896

echo "Unpacking RAMDISK..."
cd $RDPATH
gzip -d $RDGZNAME
cd ..

echo "Mount RAMDISK"
mount -o loop $RDPATH$RDNAME $RDMP


Удаление AVP

#!/bin/bash

RDMP="/mnt/ramzes"

echo "Remove AVP"

cd $RDMP

cd root/.AVP
rm *
cd ..
rmdir .AVP
rm $RDMP"/usr/bin/AVPLinux"

cd $RDMP
cd opt
cd AVP
rm *
cd ..
rmdir AVP

cd $RDMP

Сборка модифицированного bootdisk.img

#!/bin/bash

IMGPATH="./mbootdisk.img"
RDPATH="./ramdisk/"
LDRKRNL="./ldrkrnl/ldrkrnl.img"
RDNAME="ramdisk"
RDMP="/mnt/ramzes"

echo "Umount RAMDISK"
umount $RDMP

echo "Packing RAMDISK"
cd $RDPATH
gzip -9 $RDNAME
cd ..

echo "Make bootdisk"
cat $LDRKRNL $RDPATH$RDNAME".gz" >$IMGPATH
echo "Complete!"

Ссылки и файлы

Разборка оригинального диска на PasteBin
Удаление AVP из образа на PasteBin
Сборка модифицированного образа на PasteBin
Архив со скриптами
Часть I
Часть II
Все статьи (PDF, ZIP)

Это репост с сайта http://tolik-punkoff.com
Оригинал: http://tolik-punkoff.com/2017/12/15/analiz-drevnej-diskety-avp-z-e-s-linux-skripty-na-zakusku/

Надо ж выдумать такое, во дурак!

Я, почему-то, не принял во внимание ясные надписи серым по черному, и попытался распаковать полученный ramdisk, думая, будто бы это стандартный initrd. А почему? Да потому что внимательнее мануалы читать надо, и гуглить лучше, если сам чего-то не знаешь.

Ramdisk, Ramdisk, only Ramdisk.

Оказывается, при создании дискеты была применена более старая технология создания диска в оперативной памяти
Полученный на прошлом этапе ramdisk.gz оказался действительно виртуальным диском в оперативной памяти, сжатым gzip'ом
Правда, при распаковке в Линуксе, gzip выдал предупреждение:
Пытаемся распаковать ранее вырезанный ramdisk.gz:

gzip -d ramdisk.gz
gzip: ramdisk.gz: decompression OK, trailing garbage ignored

Так, какой-то "мусор" после конца архива был игнорирован при распаковке. Как позже выяснится, фактически он ни на что не влияет, и на предупреждение gzip'а можно забить.

В конце образа дописано некоторое количество байт F6 (Ў) и нечто похожее на контрольную сумму и цифровую подпись.



Хотя, для чистоты эксперимента, ничто не мешает получить "чистый" архив, размером 876114 байт:
dd bs=1 count=876114 if=ramdisk.gz of=ramdiskcln.gz
И "мусорный" хвост (остаток размером 133614 байт).
dd bs=1 skip=876114 if=ramdisk.gz of=endimg

Пробую распаковать ramdiskcln.gz - никаких предупреждений, распаковка успешна:


Доступ к ramdisk'у и его модификация

Сначала создается точка монтирования:
mkdir /mnt/ramzes

Теперь монтирование распакованного образа:
mount -o loop ramdiskcln /mnt/ramzes


Доступ у ФС ramdisk'а получен

Все успешно примонтировалось, видно структуру каталогов оригинального ramdisk'а AVP Z.E.S Linux. Места, правда, маловато. Всего 3 с хвостиком Мб, а осталось свободными вообще 806 К. Но все равно, кое-что можно сделать, например, для первого раза:
- выкинуть сам AVP (директория AVP в opt, скрипт avp.run из sbin, ссылку usr/bin/AVPLinux и директорию .AVP из root)
- подправить скрипт etc/rc.d/rc.sysinit, чтоб выкинуть команды вызова AVP

Сборка модифицированного образа AVP Z.E.S Linux

1. Отмонтируем ramdisk:
umount /mnt/ramzes

2. Запакуем образ ramdisk'а:
gzip -9 ramdiskcln

3. Соберем образ диска обратно. От предыдущих экспериментов должен остаться файл ldrkrnl.img, содержащий начальный загрузчик и ядро Z.E.S. Его нужно скопировать в директорию с измененным и запакованным ramdisk'ом, и просто слить в новый образ с помощью cat:
ldrkrnl.img ramdiskcln.gz >mbootdisk.img

Но мы прошли туман!

И все-таки попытку модификации исходного образа удалось завершить, хотя бы для демонстрации того, что "а так можно было?"
Например, в образ добавлен минималистичный текстовый редактор qed, написанный на Free Pascal:



Или даже мощный консольный редактор, переделанный из примера, поставляющегося с Free Pascal:




Фейлы

-Размер ramdisk'а сильно ограничен, поэтому некоторый софт, даже статически скомпилированный, туда не влез. Либо нарушалась идея "чтоб влезло на одну дискету".
-Постоянные проблемы с shared-библиотеками даже у того, что влезло. Так понимаю, что какие-то библиотеки устарели настолько, что новое не запускается, а старое, если заменить библиотеки - не работает. Или я что-то неправильно делал.

Итог

Поигрались и хватит, все равно для практического применения этот дистрибьютив не совсем подходит. Но есть и плюсы - классно поковырялся, в процессе узнал новое, в общем, удовольствие получено. Осталось даже несколько идей на будущее, например, очень понравился Free Pascal и некоторые возможности Linux, реализуемые им без геморроя, которым страдает программер на C/C++.

Источники и файлы

Начало
Использование ramdisk в Linux (ramdisk, ramfs, tmpfs)
или препарирование рамдисков
How to Create/Modify an RAM disk Image (на английском), PDF, скачать
Оригинальный образ bootdisk.img

Это репост с сайта http://tolik-punkoff.com
Оригинал: http://tolik-punkoff.com/2017/12/15/preparirovanie-avp-z-e-s-linux-glava-2/

Чисто от нефиг делать…

Истерический экскурс

В состав древних версий Касперского антивируса входила утилита, для создания спасательной дискеты, включающая образ диска bootdisk.img и собственно утилиту, копировавшую этот образ на дискету №1, а на все остальные 2-3 штуки - антивирусные базы.
Дискеты с базами были самые обычные, они нас не интересуют, а вот на первой дискете был малюсенький Linux со встроенным антивирем. Linux автоматически монтировал локальные диски, причем поддерживал FAT, FAT32, NTFS, HPFS, EXT2, т.е. все самые популярные на 1999-2001 г. файловые системы.
После загрузки Касперского надо было вставить дискеты с базами, дождаться загрузки баз и далее шла проверка. Если же дискеты с базами не вставить, то выбрасывало в линуксовую консоль, в последней версии без всяких вопросов, а в более ранней надо было ввести имя пользователя root и аналогичный пароль. Далее, зная команды, можно было бродить по дискам, читать файлы с помощью cat, копировать их, и т.д.
Касперский линукс был неприхотлив, для работы ему хватало то ли 4, то ли 8 Мб оперативки, и нам с товарищем удавалось запустить его даже на 486 машине, а вот на 386 не получилось, памяти не хватило.
Сама же дискета не открывалась ни в 98 винде, ни в NT и 2000, ни в Линуксе. Линукс мы знали совсем мало-мало, винды ругались на то, что диск не форматирован, мануалов особо не было, интернета и подавно. В общем решили мы, что хитрый Касперский дискету зашифровал, чтоб чуть что ее вирусы не заразили ненароком, и решили, что тягаться с самим Валентинычем нам не под силу, да и забили на это дело.

Иногда они возвращаются.

Недавно товарищ вновь объявился на горизонте и принес тот самый bootdisk.img из дистрибутива AVP 5, правда, огорчил, что доступные ему виртуалки образом подавились. Microsoft Virtual PC свалилась вместе с виндовозом в синий экран, а Virtualbox и вовсе отказался принимать это за образ дискеты.
Я высказал предположение, что дискета в формате RAW и на ней просто последовательно без всякой файловой системы записаны загрузчик, ядро Линукса и что-нибудь типа initrd, откуда и запускается все остальное, скинул образ на флэшку, и опять забыл.

Дело было вечером, делать было нечего…

Точнее мне не хотелось слушать разговоры слесарей о машинах и футболе, мне они так же непонятны, как слесарям разговоры о Линуксе, и мне же о бабах, потому что про глючные девайсы я и в интернете могу почитать. Бухать тоже не перло, но на автобазе было тепло, а снаружи дул холодный ветер и сыпал мерзкий снег. К тому же обнаружился ЁЁЁ-писюк с модемом, а в кармане валялась та самая флешка с образом и Хрювером, он же HIEW. А пуркуа бы не па...

Обратный отсчет. Поехали!

Скачиваю QEMU, ставлю и скармливаю ей образ дискетки:

qemu-system-i386.exe -fda bootdisk.img -boot a

Надо же, загрузились, какие мы молодцы!



Тааак… Если загрузились, должен быть и загрузчик. Вот, кстати он работает:



Вспоминаем устройство загрузочных дисков. Сначала BIOS загружает первые 512 байт, которым передает управление. Можно попробовать эти 512 байт отрезать и посмотреть, что получится.
Устанавливаю dd
И делаю вот так:
dd bs=1 count=512 if=bootdisk.img of=512.img
bs=1 - размер блока 1 байт
count=512 - количество блоков
if=bootdisk.img - откуда читать
of=512.img - куда писать

Пробую скормить выходной файл QEMU:



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

Пространственное сжатие

Ладно, с налета, с шашкой наголо закономерно ничего не вышло, будем наблюдать дальше. Загрузимся опять с оригинального образа.
Момент раз:



Момент два, чуть погодя:



Ага! Uncompressing Linux! Compressed image found at block 454!

Похоже, моя гипотеза подтверждается: загрузчик, за ним сжатое ядро, в которое встроены необходимые модули, а за ним сжатый образ со всем остальным.
За следующую гипотезу приму то, что Касперский не изобретал крутых велосипедов, а ограничился стандартным gzip-сжатием.
Недолгое гугление дало, что gzip-архив начинается с сигнатуры 1F 8B 08 00, хорошо, что на флешке завалялся HIEW.
Загружаем в него оригинальный образ, переключаемся в HEX-режим (F4) и пробуем поискать сигнатуру архива.



Вот первое совпадение по смещению 4344h т.е. на 17221 байте от начала файла (HIEW ведет счет с 0).



А вот и второе по смещению 71800h, т.е. на 464897 байте от начала файла.
Больше сигнатур обнаружено не было. Пока с моими гипотезами все в порядке.

Мы режем, режем, режем...

Чтобы окончательно убедиться в своей правоте, я решил разделить файл на несколько частей и посмотреть на их поведение при запуске, все равно слесарей по домам еще не развозили, а на улице погода и не думала улучшаться.

Сначала оставлю один загрузчик, чтобы посмотреть, как он поведет себя без всего остального.
Копирую bootdisk.img под именем loader.img, открываю loader.img в HIEW. Далее надо переключиться в HEX-режим и провести поиск первого вхождения сигнатуры 1F 8B 08 00.
Теперь переключаемся в режим редактирования (F3) и обрезаем файл с этой позиции включительно (Trunc, F10)
Выходим из HIEW, получился файл размером ровно 17220 байт. Скармливаю его QEMU.



Точно загрузчик. Не обнаружил сигнатуры запакованного gzip'ом ядра, отругался и оставил нас.

Попробую теперь повторить операцию, оставив в файле загрузчик и предполагаемое ядро. Копирую оригинальный файл под именем ldrkrnl.img и делаю все то же самое, что и в первом случае, только ищу второе вхождение. В итоге получился файл размером 464896 байт. Пробую запустить.



Ага! Ядро! Вроде бы загрузка поначалу шла нормально, но потом RAMDISK не нашел образа диска на своем месте и драйвер VFS потребовал с нас дискету с корневой файловой системой. Естественно, т.к. у дискеты нестандартный формат, то смонтировать ее не удалось и получилась kernel panic. Хотя, забегая вперед, это дает возможность отвязаться от ограничений RAMDISK и модифицировать систему как угодно. Фактически это, конечно, не нужно, проще уж что-то свое собрать, чем идти таким странным способом.
Но ради развлечения я все-таки систему модифицирую, не зря же ковырялся.

Встаньте под образа!

Раз уж речь зашла о модификации, то нАчать надо с того, чтобы извлечь образ ramdisk'а.
Это последнее, что я сделал в теплом гараже и на винде. Для остального уже Линукс надобен.
Итак, имеем ldrkrnl.img размером 464 896 байт, и оригинальный bootdisk.img. Чтобы вырезать рамдиск, можно воспользоваться dd:
dd bs=1 if=bootdisk.img of=ramdisk.gz skip=464896
skip=464896 - количество блоков размером в 1 байт (bs=1), которые нужно пропустить с начала файла bootdisk.img

На выходе получился файл ramdisk.gz размером мегабайт с хвостиком, имеющий в начале вышеупомянутую сигнатуру gzip-архива. Файл успешно открылся в WinRar, и тест показал, что ошибок не обнаружено.

Начинался новый день…

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

Продолжение следует...

О gzip-архиве и сигнатуре ея
QEMU для Windows XP
dd для Windows


Это репост с сайта http://tolik-punkoff.com
Оригинал: http://tolik-punkoff.com/2017/11/28/avp-z-e-s-linux-ili-issledovanie-obraza-odnoj-drevnej-diskety/