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

У меня есть два exe-файла: один исходный файл, а другой - взломанный exe-файл программного обеспечения Vector magi c и взломанный файл 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

Исходный ex e's декомпилирован. c файл

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

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

    _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."
                         );

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

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

1 Ответ

1 голос
/ 21 июня 2020

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

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

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

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

...