to post messages and comments.

← All posts tagged Haxe

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

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

Повтыкав недельку в код, который получается, если скомпилировать haXe через C++ в ARM, я уже могу нормально смотреть на эти инструкции. Благодаря неявной метаинформации haXe код читаю пока ещё не как открытую книгу, но всё же на удивление много информации получается извлечь. Собственно, самый интересный метод — это hx.Object.__Field, который в каждом классе переопределяется. Находить этот метод можно по VMT. Смещения в VMT я вычислил, вглядевшись в hx/Object.h и отметив там каждый virtual. Дальше у любого другого класса можно находить все те же методы, но __Field — самый интерсный. Если смотреть его реализацию, он сравнивает свой аргумент со всем, что есть в классе, и при совпадении создаёт завёрнутый в Dynamic объект. Если это было поле, он вызывает конструктор, который завернёт число, строку или объект в Dynamic, и так можно понять, по какому смещению и какого типа находится поле. Каждый метод haXe соответствует собственно его реализации в C++, а также есть невиртуальная обёртка, которая на вход получает аргументы типа Dynamic&, и результат у неё тоже Dynamic. В __Field оно идёт подряд — memcmp с названием методом, и если да, то обёртка заворачивается в Dynamic. Смотрим, что внутри обёртки, а там, допустим, в первых строках:

LDR.W R2, [R0,#0xEC]Это значит, что реализация метода будет по смещению EC. Так, прочесав реализацию __Field, можно понять структуру и экземпляров, и VMT. Кроме того, в Dynamic–обёртках для методов делается приведение типов к Dynamic и обратно, и так можно определить типы аргументов и результата. Тип аргумента–объекта видно по вызовам __dynamic_cast. RTTI G++ не богат, но там есть замангленное название класса, а по обратной ссылке (Xref) можно от RTTI перейти к VMT, в VMT найти __Field и тоже проименовать все функции. Таким образом, когда читаешь код метода, можно понять, с объектами какого типа он работает и какие методы аргументов косвенно вызываются. А вот с полями и результатами такое не получается. Надо полагать, в обратном направлении любой объект к hx.Object перед завёртыванием в Dynamic приводится без RTTI, поэтому нет __dynamic_cast, и его точный тип статическим анализом не определить так просто.

IDA грешит тем, что не всегда в теле __Field нормально определяет адреса названий методов и Dynamic–обёрток. Смотришь, а там тупо большие числа, что странно. Ситуацию усугубляет то, что смещения везде относительные. Во многих местах IDA эти относительные смещения нормально просчитывает, но в __Field очень часто почему–то — нет. Лечится Ctrl+R, "_GLOBAL_OFFSET_TABLE_", Enter на каждом странном большом числе.

OpenFL Setup Windows
In order to build Neko applications for Windows, no further dependencies are required. However, in order to build C++ applications for Windows, you must have a compatible version of Visual Studio C++ installed on your system.
Currently, OpenFL requires a version of Visual Studio capable of targeting Win32. For newer versions of Visual Studio, this requires the "Windows Desktop" version of the software.
Что у них вместо мозгов? Выбирать компилятор от Microsoft? Чем они вообще думали? У меня уже есть компилятор C++, интегрированный с компилятором Ады и есть совместимый с Delphi C++ Builder. Зачем кто–то тащит ничем не интересный компилятор от Microsoft?

Это уже напоминает Яндекс.Бар, производитель которого доплачивает тем, кто спамит этим УГ в своих программах.

You can only target Windows from a Windows system right now
Ну ещё бы. Думать же надо было

Жуйк, а есть ли в NekoVM возможность делать песочницы? То есть, допустим, моя программа на haXe декларирует API, загружает Neko модули, и эти модули должны иметь доступ только к API.