Как взломать x64dbg из соответствующих инструкций ghidra?

ProgramBox

Как взломать x64dbg из соответствующих инструкций ghidra?

Post author:admin
Запись опубликована:24 ноября, 2022
Post category:Вопросы по программированию

#debugging #assembly #breakpoints #ghidra #x64dbg

#отладка #сборка #точки останова #гидра #x64dbg

Вопрос:

У меня есть x64dbg и ghidra, синхронизированные через ret-sync. Я нашел интересный момент в гидре:

 1800382b1   4d 8b e0      MOV              R12,rebitData
1800382b4   48 63 f2      MOVSXD           packetSize_,packetSize

в представлении списка; файл мой.dll начинается с 180000000.
Итак, затем в x64dbg я добавляю разрыв dll для my.dll , и когда я вхожу, я перехожу к смещению файла с помощью ctrl shift g и ввожу 328b4, но в итоге оказываюсь на (первой строке):

 00007FF8B2FB32B4 | 06                       | ???             
00007FF8B2FB32B5 | E9 80000000              | jmp my.7FF8B2FB333A    
00007FF8B2FB32BA | 45:8BC6                  | mov r8d,r14d        
00007FF8B2FB32BD | EB 7B                    | jmp my.7FF8B2FB333A   
00007FF8B2FB32BF | 3BFB                     | cmp edi,ebx 
00007FF8B2FB32C1 | 73 22                    | jae my.7FF8B2FB32E5 
00007FF8B2FB32C3 | 41:3BDB                  | cmp ebx,r11d 
00007FF8B2FB32C6 | 76 18                    | jbe my.7FF8B2FB32E0

где в x64dbg файл начинается с: 00007FF8B2F81000 (вкладка CPU, модуль my.dll , основная нить X, PID Y).

Очевидно, что инструкции не совпадают. (Я считаю, что я сделал перебазирование правильно)

Как я могу создать соответствие ghidra -> x64dbg и выполнить разрыв в x64dbg в «том же месте», т.Е. В тех же инструкциях?

1. Этот вопрос также может лучше подойти для обмена стеками RE, но вы уже знаете об этом, поэтому я предполагаю, что вы намеренно разместили его здесь?

2. @FlorianMagin Да, я знаю. Но выбор между отладкой и реверсом здесь произволен, поэтому я решил сделать его более общим и выбрал debugging, который лучше подходит для SO. Я признаю, что использование гидры может настоятельно рекомендовать обратить вспять или, в конечном счете, проанализировать.

3. Ах, хорошее рассуждение, и оно проясняет, в чем суть вашего вопроса. Я согласен, если основное внимание уделяется общему аспекту отладки, то SO может быть лучше подходящим.

Ответ №1:

ret-sync позволяет добавлять точку останова непосредственно из ghidra (в x64dbg) с помощью F2: https://github.com/bootleg/ret-sync#ghidra-usage

Однако это не работает, когда ret-sync встроен в release, только в отладочной версии. Это ошибка.

Для ручного перебазирования перехода из x64dbg можно ввести смещение (текущее смещение — базовое смещение) expression в калькуляторе x64dbg и попросить follow in disassembler перейти непосредственно к смещению. Можно вычислить выражение, которое выполняет перебазирование или более сложную функцию (например, смещение размер X * Ntimes).
Если известно окончательное смещение, другим способом перехода к желаемому смещению в x64dbg является ctrl shift g ( go to file offset ) , если требуемый модуль находится в процессе разборки процессора. Если нет, нужно перейти к symbols и следовать интересующему модулю при разборке процессора, а затем go to file offset .

Ответ №2:

Вы сказали, что хотите перейти к 328b4 , но ваш второй фрагмент находится в ...32B4 и выглядит так, как будто вы оказались в середине инструкции. Я бы ожидал, что правильный адрес будет 0x00007FF8B2F81000 0x328b4 = 0x7ff8b2fb38b4.

Я не знаю о ret-sync поддержке установки точек останова, но вы можете выполнить преобразование адреса проще, либо получив относительное смещение при наведении курсора мыши

Источник: https://twitter.com/dev747368/status/1347360276476293125

а затем добавляем x64dbg смещение 00007FF8B2F81000 к смещению ( 2008h на скриншоте, в вашем случае 328b4h )

Или вы можете создать сценарий, запустив currentAddress.subtract(currentProgram.imageBase) его в командной оболочке, чтобы получить относительное смещение для текущего адреса (опять 328b4h же в вашем примере), а затем добавить x64dbg смещение. Таким образом, полная команда будет следующей: currentAddress.subtract(currentProgram.imageBase).add(0x00007FF8B2F81000) запустите это в Python REPL, и x64dbg в результате должен быть получен правильный адрес для текущего адреса.

1. Итак, ctrl shift g (перейти к смещению файла) — это неправильный путь туда, куда я хочу (с автоматической перебазировкой)? Почему это так? разве у нас нет копии программы в пространстве памяти процесса?

2. ctrl shift g в x64dbg ? На самом деле я никогда не использовал отладчик Windows вне IDA, в основном я выполняю статический запуск с помощью ghidra. Если x64dbg вы можете выполнить сам pam_xauth.so 2008h перевод, тогда это становится еще проще, и вы можете просто передать смещение 0x2008 x64dbg в любым способом, который имеет смысл

3. В x64dbg есть текстовое поле «command», но оно не принимает вашу команду python REPL (я ее не нашел). Следовательно, остаются два варианта: «перейти к смещению файла» и калькулятор, в который я помещаю смещение строки желаемое смещение в dll (взятое из ghidra), а затем спрашиваю «следовать в дизассемблере», что дает желаемый результат.

4. Ах, моя команда Python REPL предназначена для Ghidra Python REPL. currentAddress это волшебная переменная, которая будет иметь значение адреса, по которому вы в данный момент находитесь в Ghidra. Итак, если вы находитесь по интересующему адресу в Ghidra, вы можете запустить эту команду в Ghidra и получите результирующий адрес x64dbg или просто смещение внутри файла, если вы оставите последнюю .add() часть