Два скомпилированных двоичных файла с одним и тем же кодом сборки по-разному ведут себя при взломе двоичного файла? Или я что-то упускаю?

Question

У меня есть два exe-файла: один - оригинальный, а другой - взломанный exe-файл программного обеспечения Vector magic, а взломанный файл - vmbe.zip. Оба файла имеют точно такой же размер.

Я использую ghidra для декомпиляции этих двоичных файлов. Затем я просто экспортирую эти файлы в программу формата c/ C++, просто используя опцию File->Export Program (O)

затем я открываю эти файлы в Visual Studio и применяю расширение Diff, чтобы найти разницу между этими файлами, и я могу перейти к различиям, просто нажав ALT+F5

Затем я заметил, что некоторые функции просто не удалось декомпилировать, показывая следующую ошибку, но я просто ищу эти функции в Ghidra, используя Windows->Functions, и снова я декомпилировал эти функции одну за другой, а затем поместил эти функции в общий файл.c в соответствующих местах.

/*
Unable to decompile 'FUN_004475d0'
Cause: Exception while decompiling 004475d0: process: timeout
*/

Теперь у меня есть два файла.c, один - это декомпилированная версия исходного exe-файла, а другой - взломанный exe-файл, и после исправления меньшего количества имен переменных мы можем легко обнаружить, что есть только одно различие между этими двумя файлами в конце функции. FUN_0043a620

Декомпилированный файл.c оригинального exe

    _bVar2 = uVar3 & 0xffffff00 | (uint)bVar2;
  }
  *in_FS_OFFSET = local_c;
  return _bVar2;
}

Декомпилированный файл.c Cracked exe

    _bVar2 = uVar3 & 0xffffff00 | 1;
  }
  *in_FS_OFFSET = local_c;
  return _bVar2;
}

И в Ghidra мы видим, что только одна инструкция по сборке изменена в ячейке памяти. 0043a687

Исходный файл

        0043a687 b3  01           MOV        BL,AL

Треснувший файл

        0043a687 b3  01           MOV        BL,0x1

Теперь я изменил эту инструкцию в исходном exe-файле и просто экспортирую двоичный файл из опции File->Export Program (O)

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

И этот патч выглядит как правильное решение, потому что это функция, которая определяет, зарегистрировано ли программное обеспечение или нет, просто наблюдая за возвращаемым значением, и мы просто делаем это всегда return 1. Мы можем искать варианты использования этой функцииFUN_0043a620в разложенном.c файле
Например

 if (local_65 != 0) {
    uVar5 = FUN_0043a620();
    if ((char)uVar5 != '\0') {
      pQVar7 = (QString *)FUN_0043a580((char *)&local_54,"Thank you for activating!");
      local_4._0_1_ = 5;
      pQVar8 = (QString *)FUN_0043a580((char *)&param_1,"Activation succeeded");

А также

 uVar4 = FUN_0043a620();
  if ((char)uVar4 == '\0') {
    pQVar5 = (QString *)
             FUN_0044b910((char *)&local_14,

                          "Not activated. Click the \'Activate\' button on the first page to enable saving."
                         );

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

Я хочу знать, почему моя взломанная версия не работает, даже если я скопировал точно измененную инструкцию по сборке из рабочего взломанного файла?

Answer 1

Используйте шестнадцатеричные редакторы (FlexHex, BeyondCompare, ...) и ищите различия между двумя файлами, возможно, есть другие отличия, которые не являются различиями кода, например - некоторые изменения в глобальных данных.

Чтобы понять, что это за другие байты, вы можете проанализировать двоичный файл либо

1. статически: открыть в Ghidra или IDAи ищите ссылки на эти данные и где они использовались. Скорее всего, это как-то связано с другим изменением, которое вы заметили в коде.

2. динамически: попробуйте установить аппаратную точку останова при доступе к этому месту.