Добрый день! Возможно кто-то сталкивался со следующей проблемой. Есть ПО для unix, которое я подписываю через “VMProtect_con.exe %appname %new_appname -pf %projectname.vmp”. И есть необходимость запускать его на Astra Linux с включенной замкнутой программной средой. Для этого подписываю его через bsign, указывая uid приватного ключа в параметрах и пароль. Как итог, вместо x-executable получаю octet-stream файл, т.е. файл ломается (100 мб становятся 702 байтами). Если сначала подписать файл через bsign, а потом уже использовать vmprotect_con, то получаю обработанный VMP исполняемый файл, но с неправильной подписью (invalid hash). Если не обрабатывать через vmprotect_con, а просто подписать bsign’ом, то все хорошо, но файл будет требовать VMProtectSDK64.so, что тоже ненормально.
Подписывать файл нужно уже после обработки в VMProtect. А вот почему bsign делает из 100 Мб файл на 702 байт - это лучше спросить разработчиков этой утилиты.
С помощью команды file я пытаюсь получить информацию об исполняемом файле до и после обработки через vmprotect_con.
До:
ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux, 3.2.0, BuildID[sha1]=***, stripped
После:
ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, no section header.
Как раз отсутствие хэдера, судя по всему, и мешает нормально подписать файл для Астры. Почему так происходит?
А bsign закрывается с каким return value?
Я про это: bsign(1) — bsign — Debian testing — Debian Manpages
На днях проверю сам на AstraLinux (ФСТЭК 4 уровень). Если у вас не будет доступа обратиться к ТП, могу попробовать сам спросить в чём проблема.
It embeds a secure hash of the file contents in the file and optionally signs this hash value.
(bsign(1) — bsign — Debian testing — Debian Manpages)
Скорее всего тут может и зарываться проблема.
До протекта, bsign спокойно и вставит свой securehash, но вот протект меняет ваш файл и толку 0.
А после протекта, bsign скорее всего не может обработать ваш ELF файл, так как он запротекчен.
Пробуйте вырубать защиту в VMP и смотреть что вам поможет…
UPD: Скорее всего вам прилетит Exitcode, судя по сурсам:
Завершается с 0.
Запустил с выводом подробной информации. Сначала идет этап процессинга, потом на этапе самой подписи оказывается, что файл уже не ELF формата.
Лог вот такой:
section ‘(null)’ [0x0], update size 0x0 ->0xa
section header table offset moved 0x0 → 0x10
section ‘(null)’ [0x0], update size 0x0 → 0x200
section header table offset moved 0x10 → 0x200
bsign: file ‘%appname’ is not an ELF object
И далее идет пропуск этого файла. Т.е. все ломает препроцессинг
Ну вот мои опасения и подтвердились. По сути протект мешает работе bsign.
По логам если судить, даже если бы bsign подписал файл, ваше ПО не запустилось, так как произошла модификация, чеки vmp не прошли бы…
Честно сказать, моей компании тоже нужно будет bsign заводить.
Следовательно вопрос: Есть ли вариант в VMP (хотя-бы в Linux версии) подружить с bsign?
Просто сами понимаете какая ситуация вырисовывается…
Судя по исходным кодам автор вообще не сильно знаком с ELF форматом и видимо не знает, что секции не являются обязательными для запуска бинарника (ядро при проекции файла в память оперирует исключительно program header-ами). Поэтому отсутствует даже минимальная проверка на ibHdrSection == 0 и весь дальнейший процесс “подписывания” приводит к тупому затиранию заголовка самого файла.
Следовательно вопрос: Есть ли вариант в VMP (хотя-бы в Linux версии) подружить с bsign?
По хорошему bsign нужно дописывать (хотя бы в составе Astra Linux), т.к. он банально сырой.
P.S. Приложите к топику какой-нить подписанный “hello world” и оригинал.
Во вложении архив с “hello world” и он же, подписанный VMP
hello_world.zip (6.19 MB)
Я не вижу в вашем архиве подписанный bsign-ом оригинальный hello_world.
А это те же файлы, но подписанные bsign’ом (оригинал все еще работает, а версия, обработанная vmprotect’ом, подтёрта)
hello_world.zip (3.29 KB)
Чтобы обойти баги в bsign попробуйте следующее:
- Подпишите приложение bsign-ом (bsign создаст секцию с типом 0x80736967)
- Обработайте VMProtect (секции с типами >= 0x80000000 не удаляются)
- Подпишите защищенное приложение bsign-ом
К сожалению это не помогло. Да, теперь файл не затирается полностью, весит он столько же, сколько и до подписи. Но теперь он не запускается с ошибкой “unable to execute: отказано в доступе”. Сравнение файла до подписи и после с помощью утилиты readelf говорит о том, что bsign подтирает динамический раздел.
До:
Динамический раздел со смещением 0x7e92ee0 содержит 51 элемент:
Тег Тип Имя/Знач
0x0000000000000001 (NEEDED) Совм. исп. библиотека: [libX11.so.6]
***
0x0000000000000000 (NULL) 0x0
После:
Динамический раздел со смещением 0x7e92ee0 содержит 1 элемент:
Тег Тип Имя/Знач
0x0000000000000000 (NULL) 0x0
Также есть разница в заголовке программы.
До:
[Запрашиваемый интерпретатор программы: /lib64/ld-linux-x86-64.so.2]
После:
[Запрашиваемый интерпретатор программы: ]
т.е. отсутствует информация об интерпретаторе.
Пишите в поддержку Astra Linux - пусть правят баги в своем ПО.
P.S. Приложил к сообщению оригинальный hello_world у которого нет секций. Передайте его разработчикам Astra Linux, пусть доводят свою утилиту до ума.
hello_world_no_sections.zip (2.9 KB)
Для версии 3.9 можно использовать следующий скрипт:
function OnBeforeSaveFile()
local file = vmprotect.core():outputArchitecture()
local section = file:sections():itemByName('.shstrtab')
if section then
section:setExcludedFromStrip(true)
end
end
При этом в файле останется как минимум одна секция даже если выбрана опция “Удалять отладочную информацию”.