Этот пост будет интересно действительно тем, кто только начинает интересоваться этой темой. У людей с опытом он, возможно, вызовет только зевки. За исключением разве что, может быть, …
Реверс-инжиниринг в той менее легальной части, где он не касается отладки и оптимизации собственного продукта, касается в том числе и такой задачи: «узнать, а как у них это работает». Иначе говоря, восстановление исходного алгоритма программы, имея на руках ее исполнимый файл.
Для того, чтобы держаться азов и избежать некоторых проблем - «взломаем» не что-нибудь, а… кейген. В 90% он не будет запакован, зашифрован или иным способом защищен - в том числе и нормами международного права…
Открыв файл кейгена в Ida, видим список функций.
Проанализировав этот список, мы видим несколько стандартных функций (WinMain, start, DialogFunc) и кучу вспомогательных-системных. Все это стандартные функции, составляющие каркас.
Пользовательские функции, которые представляют реализацию задач программы, а не ее обертку из API-шных и системных вызовов, дизассемблер не распознает и называет попросту sub_цифры. Учитывая, что такая функция здесь всего одна - она и должна привлечь наше внимание как, скорее всего, содержащая интересующий нас алгоритм или его часть.
Давайте запустим кейген. Он просит ввести две 4-значных строки. Предположим, в функцию расчета ключа отправляются сразу восемь символов. Анализируем код функции sub_401100. Ответ на гипотезу содержится в первых двух строках:
var_4= dword ptr -4
arg_0= dword ptr 8
Найдем места в программе, где встречаются вызовы функции sub401100. Таковых оказывается действительно два: по адресу DialogFunc+97 и DialogFunc+113. Интересующие нас инструкции начинаются здесь:
Относительно длинный кусок кода
loc_401196: mov esi, mov edi, ds:SendDlgItemMessageA lea ecx, push ecx ; lParam push 0Ah ; wParam push 0Dh ; Msg push 3E8h ; nIDDlgItem push esi ; hDlg call edi ; SendDlgItemMessageA lea edx, push edx ; lParam push 0Ah ; wParam push 0Dh ; Msg push 3E9h ; nIDDlgItem push esi ; hDlg call edi ; SendDlgItemMessageA pusha movsx ecx, byte ptr movsx edx, byte ptr movsx eax, byte ptr shl eax, 8 or eax, ecx movsx ecx, byte ptr shl eax, 8 or eax, edx shl eax, 8 or eax, ecx mov , eax popa mov eax, push eax call sub_401100
Сначала подряд вызываются две функции SendDlgItemMessageA. Эта функция берет хэндл элемента и посылает ему системное сообщение Msg. В нашем случае Msg в обоих случаях равен 0Dh, что является шестнадцатиричным эквивалентом константы WM_GETTEXT. Здесь извлекаются значения двух текстовых полей, в которые пользователь ввел «две 4-символьных строки». Буква А в названии функции указывает, что используется формат ASCII - по одному байту на символ.
Первая строка записывается по смещению lParam, вторая, что очевидно - по смещению var_1C.
Итак, после выполнения функций SendDlgItemMessageA текущее состояние регистров сохраняется в стеке с помощью команды pusha, затем в регистры ecx, edx и eax записывается по одному байту одной из строк. В результате каждый из регистров принимает вид: 000000##. Затем:
В чем смысл этих операций? Выяснить очень просто даже на практике, без теории. Поставим в отладчике брейкпойнт, например, на инструкции push eax (перед самым вызовом подфункции) и запустим программу на выполнение. Кейген запустится, попросит ввести строки. Введя qwer и tyui и остановившись на брейкпойнте, смотрим значение еах: 72657771. Декодируем в текст: rewq. То есть физический смысл этих операций - инверсия строки.
Теперь мы знаем, что в sub_401100 передается одна из исходных строк, перевернутая задом наперед, в размере двойного слова, целиком умещающаяся в любом из стандартных регистров. Пожалуй, можно взглянуть на инструкции sub_401100.
Еще один относительно длинный кусок кода
sub_401100 proc near var_4= dword ptr -4 arg_0= dword ptr 8 push ebp mov ebp, esp push ecx push ebx push esi push edi pusha mov ecx, mov eax, ecx shl eax, 10h not eax add ecx, eax mov eax, ecx shr eax, 5 xor eax, ecx lea ecx, mov edx, ecx shr edx, 0Dh xor ecx, edx mov eax, ecx shl eax, 9 not eax add ecx, eax mov eax, ecx shr eax, 11h xor eax, ecx mov , eax popa mov eax, pop edi pop esi pop ebx mov esp, ebp pop ebp retn sub_401100 endp
Следующая команда LEA ecx, элегантно и непринужденно умножает еах на 9 и записывает результат в есх. Затем это значение копируется в edx и сдвигается вправо на 13 разрядов: получаем 73213 в еdx и E6427B23 в есх. Затем - снова ксорим есх и edx, записывая в есх E6454930. Копируем это в еах, сдвигаем влево на 9 разрядов: 8А926000, затем инвертируем это, получая 756D9FFF. Прибавляем это значение к регистру есх - имеем 5BB2E92F. Копируем это в еах, сдвигаем вправо аж на 17 разрядов - 2DD9 - и ксорим с есх. Получаем в итоге 5BB2C4F6. Затем… затем… что там у нас? Что, все?..
Итак, мы сохраняем это значение в область памяти по смещению var_4, загружаем из стека состояния регистров, снова берем из памяти итоговое значение и окончательно забираем из стека оставшиеся там состояния регистров, сохраненные в начале. Выходим из функции. Ура!.. впрочем, радоваться еще рано, пока что на выходе из первого вызова функции мы имеем максимум - четыре полупечатных символа, а ведь у нас еще целая необработанная строка есть, да и эту еще к божескому виду привести надо.
Перейдем на более высокий уровень анализа - от дизассемблера к декомпилятору. Представим всю функцию DialogFunc, в которой содержатся вызовы sub_401100, в виде С-подобного псевдокода. Собственно говоря, это дизассемблер называет его «псевдокодом», на деле это практически и есть код на С, только страшненький. Глядим:
Нужно больше кода. Нужно построить зиккурат.
SendDlgItemMessageA(hDlg, 1000, 0xDu, 0xAu, (LPARAM)&lParam); SendDlgItemMessageA(hDlg, 1001, 0xDu, 0xAu, (LPARAM)&v15); v5 = sub_401100((char)lParam | ((SBYTE1(lParam) | ((SBYTE2(lParam) | (SBYTE3(lParam) << 8)) << 8)) << 8)); v6 = 0; do { v21 = v5 % 0x24; v7 = v21; v5 /= 0x24u; if (v7 >= 10) v8 = v7 + 55; else v8 = v7 + 48; v21 = v8; } while (v6 < 4); v22 = 0; v9 = sub_401100(v15 | ((v16 | ((v17 | (v18 << 8)) << 8)) << 8)); v10 = 0; do { v19 = v9 % 0x24; v11 = v19; v9 /= 0x24u; if (v11 >= 10) v12 = v11 + 55; else v12 = v11 + 48; v19 = v12; } while (v10 < 4); v20 = 0; wsprintfA(&v13, "%s-%s-%s-%s", &lParam, &v15, v21, v19); SendDlgItemMessageA(hDlg, 1002, 0xCu, 0, (LPARAM)&v13);
Это уже легче читать, чем ассемблерный листинг. Однако не во всех случаях можно положиться на декомпилятор: нужно быть готовым часами следить за нитью ассемблерной логики, за состояниями регистров и стека в отладчике… а потом давать письменные объяснения сотрудникам ФСБ или ФБР. Под вечер у меня особенно смешные шутки.
Как я уже сказал, читать это легче, но до совершенства еще далеко. Давайте проанализируем код и дадим переменным более удобочитаемые названия. Ключевым переменным дадим понятные и логичные названия, а счетчикам и временным - попроще.
То же самое, только переведенное с китайского на индусский.
SendDlgItemMessageA(hDlg, 1000, 0xDu, 0xAu, (LPARAM)&first_given_string); SendDlgItemMessageA(hDlg, 1001, 0xDu, 0xAu, (LPARAM)&second_given_string); first_given_string_encoded = sub_401100((char)first_given_string | ((SBYTE1(first_given_string) | ((SBYTE2(first_given_string) | (SBYTE3(first_given_string) << 8)) << 8)) << 8)); i = 0; do { first_result_string[i] = first_string_encoded % 0x24; temp_char = first_result_string[i]; first_string_encoded /= 0x24u; if (temp_char >= 10) next_char = temp_char + 55; else next_char = temp_char + 48; first_result_string = next_char; } while (i < 4); some_kind_of_data = 0; second_string_encoded = sub_401100(byte1 | ((byte2 | ((byte3 | (byte4 << 8)) << 8)) << 8)); j = 0; do { second_result_string[j] = second_string_encoded % 0x24; temp_char2 = second_result_string[j]; second_string_encoded /= 0x24u; if (temp_char2 >= 10) next_char2 = temp_char2 + 55; else next_char2 = temp_char2 + 48; second_result_string = next_char2; } while (j < 4); yet_another_some_kind_of_data = 0; wsprintfA(&buffer, "%s-%s-%s-%s", &first_given_string, &second_given_string, first_result_string, second_result_string); SendDlgItemMessageA(hDlg, 1002, 0xCu, 0, (LPARAM)&buffer);
Порой кто-то хочет посмотреть, а какая же начинка в определённой программе? Тогда ему приходится использовать реверс-инжиниринг. Что это такое? Как действует? Каким образом происходит этот процесс? Обо всём этом вы сможете узнать из данной статьи.
Так называют процесс разбора приложения с целью понять, как оно работает, чтобы в будущем воссоздать этот процесс с внесением необходимых изменений. Обычно для этих целей используются отладчик и ассемблер. В зависимости от качества используемого программного обеспечения будут отличаться результат и количество времени, которое необходимо потратить на его приведение в нормальный вид. Объяснять реверс-инжиниринг для начинающих лучше всего на примере. В качестве оного выступит приложение, написанное для Android. А теперь давайте будет узнавать, что и как.
Для начала необходимо прояснить некоторые моменты. В приложениях используется байт-код и LogCat. Это местные аналоги ранее упомянутых отладчика и ассемблера. Также необходимо понимать структуру самих приложений. Так, каждая программа является файлом с расширением apk. Упаковывается он zip’ом. Нас интересует его содержимое - ресурсы приложения, classes.dex и AndroidManifest.xml. Если вы занимаетесь программированием на Android, то вопросов с первыми и последним быть не должно. А вот classes.dex - это байт-код программы, который компилируется специально для виртуальной машины. Выудить из него исходный код java представленными в интернете средствами не получиться. Но возможным является получение dalvik opcodes - специального набора команд, которые используются для виртуальной машины. Для аналогии можно сказать, что это ассемблер местного разлива. Также classes.dex может быть превращен в файл с расширением jar. Уже в таком случае после его декомпиляции можно получить java-код, который будет более-менее читаемым. По такому пути мы и пойдём.
Этот процесс будет проводиться с использованием программы Apk Manger. Прежде чем приступать к работе, необходимо убедиться, что есть нужные драйверы для работы девайса, а также функционирует режим USB-debugging. Первоначально нам необходимо будет переместить файл, который будет разбираться в директиву apk_manager\place-apk-here-for-modding. После этого следует запустить Script.bat. Если никаких проблем нет, то запуститься консоль, на которой будут зелёные надписи. Выбираем пункт номер девять - «Декомпилировать». После того как будет запущен процесс, необходимо не закрывать консоль. Потом следует открыть интересующий apk-файл с помощью архиватора и извлечь из него classes.dex, который нужно обработать программой dex2jar. Для необходимого нам результата его надо переместить на объект с расширением.bat. Появится файл, который будет заканчиваться на.jar. Пока что окно не закрываем.
Чтобы получить информацию о приложении, необходимо открыть его манифест. По нему определяем, что выступает в роли главной активности. Она-то и представляет для нас сейчас наибольшую важность. Также желательно посмотреть в самый низ программы. Если внизу будет информация о менеджере лицензий, то это существенно усложнит проведение реверсного инжиниринга. Если переключиться на jd-gui и развернуть дерево, то мы увидим несколько пространств имён. Допустим, что их три. В первом находятся файлы, связанные с рекламой. Во втором будут классы менеджера лицензий. В третьем находятся нам необходимые данные. В него-то мы и заходим. Здесь необходимо будет найти и удалить ключ, а потом и остальные строки, которые проверяют, является ли лицензионной работающая версия. Всё это нужно почистить. Потом в нашем Apk Manager ищем место, куда указано размещать байт-код. Теперь сделаем небольшое отступление и закомментируем команды, с которыми потенциально могут возникнуть проблемы. После этого нам осталось только скомпилировать программу.
В этом нам поможет всё тот же Apk Manager. В окне консоли, которое нами не закрывалось, выбираем пункт №14. Далее дело техники. Если приложение довольно сложное, то при запуске оно может частично или полностью потерять свою работоспособность. Не огорчайтесь, это значит, что мы только на полпути и есть ещё куда идти. Продолжаем проводить реверс-инжиниринг Android-приложений. Сказать, что нужно делать в конкретном случае, общими словами, увы, невозможно. Поэтому искать проблемное место придётся самостоятельно. Так, если окно приложения блокируется то необходимо просмотреть код и удалить ту его часть, что отвечает за данный диалог. Помочь с этим сможет jd-gui. Как видите, реверсный инжиниринг не является лёгким делом, и он требует наличия значительного багажа знаний. Даже если всё без проблем запустилось, необходимо будет протестировать работоспособность приложения. То есть реверс-инжиниринг является ещё затратным по времени действием. Продолжаем работать, пока не будут выявлены все проблемы.
А что, если нам нужна защита Android-приложений от реверс-инжиниринга? В таком случае есть два варианта: использование специальных программ или создание кодовой конструкции, которая будет мешать совершать разбор написанного. Последний вариант подходит исключительно опытным специалистам, поэтому мы рассмотрим только первый способ защиты. В качестве специализированного программного обеспечения используем ProGuard. Это приложение, которое используется для сокращения, обфускации и оптимизации кода. Если программу «прогнать» через него, то мы получим файл с расширением *.apk меньшего размера, чем он был. В таком случае его будет значительно сложней разобрать. Причем преимуществом данной программы является то, что она даже была внедрена в систему сборки Андроид-приложений с обновления r9. Поэтому воспользоваться ею может любой разработчик, который имеет стандартные инструменты создания и разработки.
Нельзя сказать, что реверс-инжиниринг можно представить как что-то однородно плохое или хорошее. Конечно, с точки зрения разработчиков, которые создали приложение, это совсем не радостное событие. Но с другой стороны, во многих случаях написание опытными программистами необходимых файлов может быть по времени менее затратным, нежели использование подобного инструментария. Хотя для начинающих разработчиков реверс-инжиниринг может сослужить неплохую службу, если нет представления о том, как реализовать что-то, даже примерные и не совсем понятные наброски могут помочь с достижением поставленной цели.
Этот пост будет интересно действительно тем, кто только начинает интересоваться этой темой. У людей с опытом он, возможно, вызовет только зевки. За исключением разве что, может быть, …
Реверс-инжиниринг в той менее легальной части, где он не касается отладки и оптимизации собственного продукта, касается в том числе и такой задачи: «узнать, а как у них это работает». Иначе говоря, восстановление исходного алгоритма программы, имея на руках ее исполнимый файл.
Для того, чтобы держаться азов и избежать некоторых проблем - «взломаем» не что-нибудь, а… кейген. В 90% он не будет запакован, зашифрован или иным способом защищен - в том числе и нормами международного права…
Открыв файл кейгена в Ida, видим список функций.
Проанализировав этот список, мы видим несколько стандартных функций (WinMain, start, DialogFunc) и кучу вспомогательных-системных. Все это стандартные функции, составляющие каркас.
Пользовательские функции, которые представляют реализацию задач программы, а не ее обертку из API-шных и системных вызовов, дизассемблер не распознает и называет попросту sub_цифры. Учитывая, что такая функция здесь всего одна - она и должна привлечь наше внимание как, скорее всего, содержащая интересующий нас алгоритм или его часть.
Давайте запустим кейген. Он просит ввести две 4-значных строки. Предположим, в функцию расчета ключа отправляются сразу восемь символов. Анализируем код функции sub_401100. Ответ на гипотезу содержится в первых двух строках:
var_4= dword ptr -4
arg_0= dword ptr 8
Найдем места в программе, где встречаются вызовы функции sub401100. Таковых оказывается действительно два: по адресу DialogFunc+97 и DialogFunc+113. Интересующие нас инструкции начинаются здесь:
Относительно длинный кусок кода
loc_401196: mov esi, mov edi, ds:SendDlgItemMessageA lea ecx, push ecx ; lParam push 0Ah ; wParam push 0Dh ; Msg push 3E8h ; nIDDlgItem push esi ; hDlg call edi ; SendDlgItemMessageA lea edx, push edx ; lParam push 0Ah ; wParam push 0Dh ; Msg push 3E9h ; nIDDlgItem push esi ; hDlg call edi ; SendDlgItemMessageA pusha movsx ecx, byte ptr movsx edx, byte ptr movsx eax, byte ptr shl eax, 8 or eax, ecx movsx ecx, byte ptr shl eax, 8 or eax, edx shl eax, 8 or eax, ecx mov , eax popa mov eax, push eax call sub_401100
Сначала подряд вызываются две функции SendDlgItemMessageA. Эта функция берет хэндл элемента и посылает ему системное сообщение Msg. В нашем случае Msg в обоих случаях равен 0Dh, что является шестнадцатиричным эквивалентом константы WM_GETTEXT. Здесь извлекаются значения двух текстовых полей, в которые пользователь ввел «две 4-символьных строки». Буква А в названии функции указывает, что используется формат ASCII - по одному байту на символ.
Первая строка записывается по смещению lParam, вторая, что очевидно - по смещению var_1C.
Итак, после выполнения функций SendDlgItemMessageA текущее состояние регистров сохраняется в стеке с помощью команды pusha, затем в регистры ecx, edx и eax записывается по одному байту одной из строк. В результате каждый из регистров принимает вид: 000000##. Затем:
В чем смысл этих операций? Выяснить очень просто даже на практике, без теории. Поставим в отладчике брейкпойнт, например, на инструкции push eax (перед самым вызовом подфункции) и запустим программу на выполнение. Кейген запустится, попросит ввести строки. Введя qwer и tyui и остановившись на брейкпойнте, смотрим значение еах: 72657771. Декодируем в текст: rewq. То есть физический смысл этих операций - инверсия строки.
Теперь мы знаем, что в sub_401100 передается одна из исходных строк, перевернутая задом наперед, в размере двойного слова, целиком умещающаяся в любом из стандартных регистров. Пожалуй, можно взглянуть на инструкции sub_401100.
Еще один относительно длинный кусок кода
sub_401100 proc near var_4= dword ptr -4 arg_0= dword ptr 8 push ebp mov ebp, esp push ecx push ebx push esi push edi pusha mov ecx, mov eax, ecx shl eax, 10h not eax add ecx, eax mov eax, ecx shr eax, 5 xor eax, ecx lea ecx, mov edx, ecx shr edx, 0Dh xor ecx, edx mov eax, ecx shl eax, 9 not eax add ecx, eax mov eax, ecx shr eax, 11h xor eax, ecx mov , eax popa mov eax, pop edi pop esi pop ebx mov esp, ebp pop ebp retn sub_401100 endp
Следующая команда LEA ecx, элегантно и непринужденно умножает еах на 9 и записывает результат в есх. Затем это значение копируется в edx и сдвигается вправо на 13 разрядов: получаем 73213 в еdx и E6427B23 в есх. Затем - снова ксорим есх и edx, записывая в есх E6454930. Копируем это в еах, сдвигаем влево на 9 разрядов: 8А926000, затем инвертируем это, получая 756D9FFF. Прибавляем это значение к регистру есх - имеем 5BB2E92F. Копируем это в еах, сдвигаем вправо аж на 17 разрядов - 2DD9 - и ксорим с есх. Получаем в итоге 5BB2C4F6. Затем… затем… что там у нас? Что, все?..
Итак, мы сохраняем это значение в область памяти по смещению var_4, загружаем из стека состояния регистров, снова берем из памяти итоговое значение и окончательно забираем из стека оставшиеся там состояния регистров, сохраненные в начале. Выходим из функции. Ура!.. впрочем, радоваться еще рано, пока что на выходе из первого вызова функции мы имеем максимум - четыре полупечатных символа, а ведь у нас еще целая необработанная строка есть, да и эту еще к божескому виду привести надо.
Перейдем на более высокий уровень анализа - от дизассемблера к декомпилятору. Представим всю функцию DialogFunc, в которой содержатся вызовы sub_401100, в виде С-подобного псевдокода. Собственно говоря, это дизассемблер называет его «псевдокодом», на деле это практически и есть код на С, только страшненький. Глядим:
Нужно больше кода. Нужно построить зиккурат.
SendDlgItemMessageA(hDlg, 1000, 0xDu, 0xAu, (LPARAM)&lParam); SendDlgItemMessageA(hDlg, 1001, 0xDu, 0xAu, (LPARAM)&v15); v5 = sub_401100((char)lParam | ((SBYTE1(lParam) | ((SBYTE2(lParam) | (SBYTE3(lParam) << 8)) << 8)) << 8)); v6 = 0; do { v21 = v5 % 0x24; v7 = v21; v5 /= 0x24u; if (v7 >= 10) v8 = v7 + 55; else v8 = v7 + 48; v21 = v8; } while (v6 < 4); v22 = 0; v9 = sub_401100(v15 | ((v16 | ((v17 | (v18 << 8)) << 8)) << 8)); v10 = 0; do { v19 = v9 % 0x24; v11 = v19; v9 /= 0x24u; if (v11 >= 10) v12 = v11 + 55; else v12 = v11 + 48; v19 = v12; } while (v10 < 4); v20 = 0; wsprintfA(&v13, "%s-%s-%s-%s", &lParam, &v15, v21, v19); SendDlgItemMessageA(hDlg, 1002, 0xCu, 0, (LPARAM)&v13);
Это уже легче читать, чем ассемблерный листинг. Однако не во всех случаях можно положиться на декомпилятор: нужно быть готовым часами следить за нитью ассемблерной логики, за состояниями регистров и стека в отладчике… а потом давать письменные объяснения сотрудникам ФСБ или ФБР. Под вечер у меня особенно смешные шутки.
Как я уже сказал, читать это легче, но до совершенства еще далеко. Давайте проанализируем код и дадим переменным более удобочитаемые названия. Ключевым переменным дадим понятные и логичные названия, а счетчикам и временным - попроще.
То же самое, только переведенное с китайского на индусский.
SendDlgItemMessageA(hDlg, 1000, 0xDu, 0xAu, (LPARAM)&first_given_string); SendDlgItemMessageA(hDlg, 1001, 0xDu, 0xAu, (LPARAM)&second_given_string); first_given_string_encoded = sub_401100((char)first_given_string | ((SBYTE1(first_given_string) | ((SBYTE2(first_given_string) | (SBYTE3(first_given_string) << 8)) << 8)) << 8)); i = 0; do { first_result_string[i] = first_string_encoded % 0x24; temp_char = first_result_string[i]; first_string_encoded /= 0x24u; if (temp_char >= 10) next_char = temp_char + 55; else next_char = temp_char + 48; first_result_string = next_char; } while (i < 4); some_kind_of_data = 0; second_string_encoded = sub_401100(byte1 | ((byte2 | ((byte3 | (byte4 << 8)) << 8)) << 8)); j = 0; do { second_result_string[j] = second_string_encoded % 0x24; temp_char2 = second_result_string[j]; second_string_encoded /= 0x24u; if (temp_char2 >= 10) next_char2 = temp_char2 + 55; else next_char2 = temp_char2 + 48; second_result_string = next_char2; } while (j < 4); yet_another_some_kind_of_data = 0; wsprintfA(&buffer, "%s-%s-%s-%s", &first_given_string, &second_given_string, first_result_string, second_result_string); SendDlgItemMessageA(hDlg, 1002, 0xCu, 0, (LPARAM)&buffer);
Рецепт прост до безобразия:
Если вам хочется
разбираться в каждой фиче, каждую новую программку ковырять, разбирать формат её файлов, каждую новую игру пытаться взломать, написать для неё бота, чит и т. п. Значит это ваше, просто продолжайте делать то, что делаете.
Если нет, то никакие книги не помогут. В этом деле нужна страсть и огромное терпение.
Матан никому не нужен в реверсе. Максимум решение систем линейных уравнений понадобится.
Важно скорее нестандартное мышление, умение брутфорсить в голове множество вариантов, подходов. Для этого нужно знать технологии. Т. е. буквально, знать нужно как можно больше
. Чем больше вы знаете, тем быстрее будет решена задача. Это абсолютно различные области: ОС, сети, способы шифрования, компрессии, хеширования, сериализации; знание баз данных и их языков запросов; знание компиляторов в плане, как они генерируют код; знание реализации той же стандартной библиотеки, понимание как компилируется один и тот же код разными компиляторами, понимать, как работают интерпретаторы байткода, виртуальные машины, и т. п.
Это, что касается общих технологий. А есть ещё такая штука, как архитектурные паттерны. Они обычно применяются в прикладных приложениях, малварь редко такое применяет. Т. е. нужно видеть в коде, например, паттерн Event, различные варианты паттерна MVC, и т. п. Например, вы реверсите продукт на Qt. Чтобы его понимать, вам нужно знать... Qt, и уметь на нём разрабатывать, читать его исходный код, знать что такое метаобъекты, как они хранятся, используются, вызываются. А если, внезапно, оно юзает что-то интерпретируемое, типа питона или луа, то вам, мало того, что нужно знать сами языки, так ещё и реализацию их интерпретаторов. А ещё бывает JIT...
Нужно ещё решить, что вы хотите реверсить. Малварь и прикладные приложения немного расходятся. В малвари нужно больше знать нестандартных вещей. Различных вариантов антиотладки, скрытия активности, багов операционной системы, поведения антивирусов. Малварь может быть ботнетом, например. Ботнеты обычно имеют командный сервер, который довольно трудно вычислить, он меняется динамически, как-то не даёт себя обнаружить. Для этого нужно знать как устроен интернет, как работает dns, разбираться в сетевых протоколах.
Короче, для реверсера нужно учить всё . Не нужно фильровать определённые технологии, вам понадобятся все они без исключения. Ибо всё, что было создано для вычислительных систем, в них используется, а соответственно, вам придётся это знать , чтобы реверсить.
Кстати, чуть не забыл.
Самая лучшая книга по реверсу на русском.
И ещё есть классический курс статей от Рикардо Нарвахи: «Введение в крэкинг с нуля, используя OllyDbg». Погуглите его. Если осилите книгу Юричева и этот курс, то сможете спокойно собеседоваться в Касперский. Хотя, поверьте, есть вещи поинтереснее касперского.
