to post messages and comments.

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

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

Если NGEN.EXE в .NET создаёт обычный машинный код, то и вызовы методов там должны быть какие-то такие, чтобы переживать изменения в зависимостях. В частности, про NGEN пишут такое (источник цитаты не понятен, но есть подозрение, что «CLR via C#» Джеффри Рихтера):
NGEN can't make as many assumptions about the execution environment as the JIT compiler can and therefore will produce unoptimized code.
For example: it adds indirections for static field access because the actual address of the static fields is known only at run time.

То есть, такой неафишируемый аналог SOM по сути, ведь после закрытия лавочки в IBM над .NET те же люди работали, Дженнифер Гамильтон, в частности. Ковырнул библиотечку из Native Image Cache в IDA, там какой-то ужас. Многочисленные нормально выглядящие поначалу функции вдруг содержат на ровном месте db 4 dup (0CCh), ломающий анализатор кода. Ни прыжка, ни потенциально безвозвратного вызова перед ними нет, ничего. Те же функции, которые были распознаны, не имеют перекрёстных ссылок. Надо, видимо, какой-нибудь класс экспортировать в COM, пройтись по нему NGEN.EXE, написать программу, которая создаст объект этого класса и войдёт в метод, чтоб иметь возможность сравнить результат деятельности NGEN.EXE с исходным кодом. Как это всё сшивается, по сравнению с SOM пока совсем не понятно.


Wt: License check failure (CheckLicense)
Cr:f Restricted — unregistered license, download limit of 8K
Nt: Loading ELF file 'blinky.axf' at location 00000000

‰ cat crt_emu_lpc11_13_nxp.dif
This difference file has been created by IDA Pro

crt_emu_lpc11_13_nxp
00006944: 84 90
00006945: C0 90
00006946: 74 90
00006947: 1F 90
00006948: A1 90
00006949: AC 90
0000694A: E9 90
0000694B: 10 90
0000694C: 08 90
0000694D: C7 90
0000694E: 44 90
0000694F: 24 90
00006950: 04 90
00006951: 40 90
00006952: 69 90
00006953: 0C 90
00006954: 08 90
00006955: 89 90
00006956: 04 90
00006957: 24 90
00006958: E8 90
00006959: 00 90
0000695A: A6 90
0000695B: 01 90
0000695C: 00 90
0000695D: BB 90
0000695E: 00 90
0000695F: 00 90
00006960: 00 90
00006961: 00 90
00006962: E9 90
00006963: 42 90
00006964: 10 90
00006965: 00 90
00006966: 00 90

Кстати об утечке IDA у ESET. Кто-то (не мне и не тут) задавал вопрос — не может ли быть такой утечки у ЛК. Я стоял рядом и слушал... Ответ был шикарным. Нет, утечки ИДА у ЛК быть не может, т.к. у нас ее нет. =)

ida

Забавная фишка в IDA: если на offset навести курсор, во всплывающем окне появляется дизассемблированный текст того места, на которое ссылается offset. А фишка в том, что колёсиком мыши можно прокрутить всплывающее окно, если что–то сразу не видно.

ida

Настройка IDA на cp1251 делается довольно причудливо. В IDA.CFG редактировал XlatAsciiName, а выяснилось, что нужно было редактировать XlatAsciiOutput. Причём, подсказки в IDA (типа "; ы" в неразобранной строке "db 0EBh ; ы") как были, так и показываются в DOS кодировке (не прочитать), а вот если подействовать на них клавишей A, то они собираются в читабельную русскую строку aZagruzkaKoll_0 db 'Загрузка коллекции...',0