Странно...

gdbserver смог подключиться к процессу только с sudo. Это — нормально?

Это немного не правильно. У Вас в wine должен быть запущен процесс под отладкой в WineDbg, а к нему уже должен цепляться gdb.

Т.е., всё это должно выглядеть примерно так: - Стартуем в wine — winedbg --gdb --no-start PACKED_CRACKME.EXE [дополнительные параметры, если они есть]

- Стартуем gdb (ну или ddd, если его используете) и там открываем исполняемый файл, коорый хотим отлаживать и, далее, даём команду на подключение к сессии WineDbg — target remote localhost:12345

Должно в принципе работать. Wine сейчас нет, пишу на память.

UPD. Собственно, да. Здесь — https://linux.die.net/man/1/winedbg

--gdb

winedbg will be used as a proxy for gdb. gdb will be the front end for command handling, and winedbg will proxy all debugging requests from gdb to the Win32 APIs.

А IDA как подключать? Помимо матрёшки IDA-GDB-Winedbg-программа.

Может тебе ещё и бабу рыжую? Офис 2016 поди до сих пор не запускается...

У IDA Pro есть нативные версии под Linux. Зачем Wine? Никто не даёт гарантии, что это будет вообще хоть как-то работать нормально. Так что наиболее рабочий вариант – виртуалка с виндой, если у тебя нет нативной IDA Pro.

У IDA Pro есть нативные версии под Linux. Зачем Wine?

Для запуска виндовой программы, которая в процессе работы себя распаковывает. С целью дизассемблирования нативной линуксовой IDA.

Никто не даёт гарантии, что это будет вообще хоть как-то работать нормально.

Без отладчика и со следящим GDB эта программа под вайном отработала нормально.

Так что наиболее рабочий вариант – виртуалка с виндой

Кстати, не посоветуешь, как дизассемблировать линуксовыми программами экзешник, работающий в виртуальной машине? Лучше XP-32 и 7-64 в VMware Player, так как для них у меня есть готовые образы.

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

Для запуска виндовой программы, которая в процессе работы себя распаковывает. С целью дизассемблирования нативной линуксовой IDA.

А, то есть IDA Pro у тебя нативная. Если честно – не знаю, как эта прослойка отладки заработает в связке с Wine. Возможно имеет смысл провернуть всё это в виртуалке без Wine.

Кстати, не посоветуешь, как дизассемблировать линуксовыми программами экзешник, работающий в виртуальной машине?

Зачем ты усложняешь себе жизнь? Нужно проанализировать что-то виндовое – используй нативные дизассемблеры под Windows в виртуалке. Нужно проанализировать что-то линуксовое – используй нативные дизассемблеры под Linux на своём хосте.

Меньше различных прослоек – меньше проблем. Или у тебя задача стоит в том, чтобы в бинарнике сделать какие-то модификации, дабы он не отваливался под Wine’ом?

Если честно...

Я тут больше склоняюсь к ранее высказавшимся ораторам про виртуалку. И нативную виндовую версию Иды.

Хотя, в Иде есть возможность выставить альтернативный remote debugger. Там выбор есть — gdb, win32 debugger и, по-моему, ещё что-то. Имеет смысл попробовать. Хотя, скорее всего, матрёшка и получится.

Я, в своё время, больше по OllyDbg упарывался, если честно. Сейчас приоритеты малость сменились, так что emerge radare2 dev-util/clutter это наше всё. Вместе они довольно удачно эмулируют Иду, а в приоритетах у меня сейчас вовсе не винды. У радара, вроде, есть плагин к winedbg, но насколько он рабочий не скажу.

Зачем ты усложняешь себе жизнь?

Осваиваю инструмент.

Нужно проанализировать что-то виндовое – используй нативные дизассемблеры под Windows в виртуалке. Нужно проанализировать что-то линуксовое – используй нативные дизассемблеры под Linux на своём хосте.

Если есть Вайн, и программа под ним работает, может оказаться проще под ним, чем скачивать 50-гигабайтную ВМ.

И что делать с программой под MS-DOS? Скомпилирована Watcom C, но в досовом отладчике от OpenWatcom стабильно падает :)

Хотя, в Иде есть возможность выставить альтернативный remote debugger. Там выбор есть — gdb, win32 debugger и, по-моему, ещё что-то. Имеет смысл попробовать. Хотя, скорее всего, матрёшка и получится.

Как поступить с программой под MS-DOS?

А вот с Ваткомом аккуратнее...

У меня где-то был древний сидюк с Watcom 10.0, ибо не столько MS DOS, сколько QNX, OS/2 (и Warp и Merlin поддерживались и WorkPlace Shell и Presentation Manager) и NLM (для Novell NetWare, да, там отдельный адок был).

Если я не ошибаюсь, то версия OpenWatcom просто не до конца совместима с «родным» Watcom. Была.

Вдобавок, в MS DOSовской приблуде мог быть использован MS DOS Extender (в игорях его использовали), тогда отладчик вообще может не осилить.

Но DOS... в наши времена... =)

Да вот хрен его знает...

Как поступить с программой под MS-DOS?

Даже и не знаю что сказать. =)))

Качать-то зачем?

чем скачивать 50-гигабайтную ВМ.

KVM-QEMU в помощь и поставить туда просто винду. Заодно, что бывает иной раз полезно, сделать несколько разных VM, с разными виндами, т.к. поведение приблуды в разных виндах может слегка, но отличаться. Правда, потом винды апдейтами заколебут, но мы все понимаем что по-другому, это очень больно. =)

Но DOS... в наши времена... =)

В 1990-е я не смог пройти одну игру из-за того, что она начинала стабильно падать через 4-8 часов игры. Прохождения есть, но они следуют строго одной сюжетной линии — «идеальной». Судя по извлечённым стрингам, предусматриваются несколько альтернативных решений для ряда задач. Статическое дизассемблирование усложняется тем, что большинство квестов реализованы через подгружаемые экзешники странного формата.

Вдобавок, в MS DOSовской приблуде мог быть использован MS DOS Extender (в игорях его использовали), тогда отладчик вообще может не осилить.

Да, там DOS/4GW. В Досбоксе отладчик без проблем запускает основную программу и проводит инициализацию, но падает при переключении графического режима.

Правда, потом винды апдейтами заколебут,

ВМ, которой не пользовались год, тратит на обновление около 2 рабочих дней.

Oh, shit!

Не знал, если честно... И после этого моя генточка «долго собирается»? =)))

А! Это оверлеи!

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

Да, тогда иной раз использовали оверлеи. Это некий такой аналог существующих сейчас разделяемых библиотек, но только без ф-ий вида dlopen(), dlsym(), dlclose(), dlerror(), т.е., и неспецифицированный и нестандартизированный. Причём, оверлеи писались в интересах одного приложения.

Так делали по разным причинам. Отчасти из-за пресловутого «640К хватит всем», а код тупо не помещался, отчасти из-за «защиты от отладки», отчасти из-за попыток создать некую модульность приложения.

Но, т.к. всё это было нестандартизировано, то каждый извращался как мог. Как оно работало? Да херово работало. Иногда работало, иногда нет. Просто потому, что в тот же регистр IP мы не можем напрямую записать адрес следующей исполняемой инструкции и тупо передать на неё управление.

Так что, тут дебажить надо две вещи (по хорошему, три, но не столь суть). Во-первых, разобраться с тем, как оверлей подгружается в адресное пространство процесса. А он подгружается, т.к. больше ему грузиться некуда. Во-вторых, посмотреть как ему передаётся управление. Стартует он вообще или нет. Ну и в третьих, как он возвращает управление родительскому процессу. На деле, падает как правило в первых двух вариантах (либо не смог загрузить, либо е смог передать управление). Вся эта беда как правило, писалась на ассемблере, а ассемблер на ассемблер для разных процов не приходился. Дело не в наборе инструкций (он-то был одинаков), дело было в том, как эти инструкции на разных процах работали (см. ниже).

Да, там DOS/4GW. В Досбоксе отладчик без проблем запускает основную программу и проводит инициализацию, но падает при переключении графического режима.

Рискну предположить что там ещё и переключение в защищённый режим может быть. Беда в том, что он появился ещё на 286х, ЕМНИП. Но защищённый режим на 286 и 386 (и старше) это несколько разные защищённые режимы. В 286 он весьма куцый, т.к. проц 16 бит и нет страничной организации памяти. Тут надо бы понять какой именно проц нужен, что, собственно, эмулируется.

На деле, падает как правило в первых двух вариантах (либо не смог загрузить, либо е смог передать управление).

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

Тут надо бы понять какой именно проц нужен, что, собственно, эмулируется.

Согласно мануалу, 386 и выше. Программа — 32-битная «flat mode». Специфичных для 486 инструкций нет.

оверлеи. Это некий такой аналог существующих сейчас разделяемых библиотек, но только без ф-ий вида dlopen(), dlsym(), dlclose(), dlerror(), т.е., и неспецифицированный и нестандартизированный.

По-моему, были системные вызовы DOS для работы с оверлеями, но я их в программе не нашёл, поэтому решил, что это называется иначе. Выходит, оверлеями называлось всё подгружаемое?

Во-первых, разобраться с тем, как оверлей подгружается в адресное пространство процесса.

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

Во-вторых, посмотреть как ему передаётся управление. Стартует он вообще или нет.

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

Видел следующую конструкцию:

cseg01:0004DDF6  mov  dword ptr [eax], offset sub_4DEA0
cseg01:0004DDFC  mov  eax, [edx]
cseg01:0004DDFE  mov  dword ptr [eax+4], offset sub_4DEC0
cseg01:0004DE05  mov  eax, [edx]
...
cseg01:0004DE6A  mov  dword ptr [eax+34h], offset sub_4E740
cseg01:0004DE71  mov  eax, [edx]
cseg01:0004DE73  mov  dword ptr [eax+38h], offset sub_4E7B0

Ну и в третьих, как он возвращает управление родительскому процессу.

retn. Но из-за джампов сложно понять, куда.

Судя по описанию...

Чуваки пытались написать некое такое «двигло» с «плагинами». Сложилось такое впечатление, возможно, я и не прав.

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

Согласно мануалу, 386 и выше. Программа — 32-битная «flat mode». Специфичных для 486 инструкций нет.

Да. Небрежно написали, видимо.

По-моему, были системные вызовы DOS для работы с оверлеями, но я их в программе не нашёл, поэтому решил, что это называется иначе.

Не помню чтобы было отдельное API для MS DOS. возможно, в последней наиболее употребительной версии ДОС (6.22) что-то и было, но к тому времени это уже было не важно.

Выходит, оверлеями называлось всё подгружаемое?

Программный код, да. Тогда этот код оформляли в вид файлов с расширениями .bin или .ovl, но «народное творчество» тут было просто безгранично. Отдельные индивидуумы даже графику умудрялись подгружать как строки. Так что, там всё что угодно может быть.

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

Отчасти. возможно, это и объясняет падения программы после нескольких часов работы. Выделенные сегменты заканчиваются. Стоило бы проверить. Поработать сколько-то, засейвиться, а потом перезапуститься и посмотреть куда что ляжет и будут ли свободные участки памяти.

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

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

Похоже на то.

retn. Но из-за джампов сложно понять, куда.

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