функции которая строит поле address - имеет какую-то запутанную подпрограмму, которая при определённых условиях делает поле address вида "0x1234+EAX".
Но во-первых я со своими программами не встречал никогда такого (обращаю внимание что это адрес кода, а не аргумент в команде),
во-вторых если посмотреть SDK x64dbg - то у него функция сопоставления имени или коммента (_dbg_addrinfoset) не принимает подобных адресов.
Так что надо написать в фасме, чтобы он создал файл с такой вот адресацией кода?
Нет. Мне в принципе не нравится идеология x64dbg_dd. Я делаю плагин для прямой загрузки исходника. И в процессе исследования x64dbg_dd (x64dbg_ddp) увидел несколько непоняток и расхождений с FAS.TXT. Такое подозрение что x64dbg_dd вообще писалось не для x64dbg, а потом допилили для нужного формата. Или автор не читал документации. Не понятно вобщем. Функция формирующая поле address, как в метках так и в комментах, может писать просто 0x1234 (из Row of the assembly dump - Value of $ address), а может при каких-то условиях писать 0x1234+EAX (регистр формируется из полей Extended SIB for the $ address). В доке фасма вот: Table 4 Row of the assembly dump | +8 | qword | Value of $ address. | +16 | dword | Extended SIB for the $ address, the first two bytes are register codes and the second two bytes are corresponding scales. Но при каких обстоятельствах фасм создаёт эти Extended SIB к адресу? Что мне в исходнике сделать чтобы получить fas-файл с таким примером? SIB коды кстати некоторые не совпадают в мануале и в x64dbg_dd: 0x94 = 'eip' FAS.TXT, 0xF4 = 'eip' x64dd_dbg
Не знаю, у меня для локальных меток не выводилось module: и text: нормально, там другая функция включалась именно на локальные метки, какая то кривая, я там заджампился в конец кода на эту проверку, переписал формирование этих секций и вывод отправил на функцию вывода для глобальных меток, на сколько я вспомню сейчас. Вроде ок работает тут вроде никто не жаловался на глюки
А зачем вообще dd32 файл делать? Не проще ли сразу грузить fas в отладчик?
Да это было бы удобнее, для xdbg был такой плагин но он у меня не работал для x32 для x64 вроде работал говорили я не проверял, у меня винда 32x потому что. А для ollyDbg есть такой плагин рабочий!
наоборот, для х64 не работал. а насчет dd32. не забывайте что сам х64dbg с тех пор мог и обновиться по форматам и поэтому dd уже плохо работает
x64dbg_dd работает, вопрос в другом. У него в коде есть возможность создания разных непонятных конструкций, которые непонятно как вообще будут импортированы в x64dbg, и не понятно при каких обстоятельствах они создаются. Я не понимаю что такое extended SIB в адресе. Я понимаю в команде - типа [ebp+n] или [eax*4+edx]. Но как это может быть в адресе размещения кода?!
а то что ты написал как раз похоже на относительные адреса
Угу. И что надо написать в исходнике для фасма, чтобы он выдал код располагаемый по адресу 0x1234+EAX*4 например? Я не понимаю этого. Адреса кода всегда ведь только числовые.
надо вставлять в код перед такими коммандами db и опкоды этого sib байта с настройками на сколько я понимаю тоже в виде опкодов т.к эти опкоды находятся в служебной области левее получается чем сами комманды (выше по адресам) так вроде, надо доки смотреть, такая конструкция будет по идее для компилятора и внутреннего линкера означать, что адрес надо подставлять относительно чего там в опциях этого sib указано и линкер тогда из следующей за sib c настройками комманды, выцепит этот регистр например и будет его как базу использовать, наверное так
А вообще лучше s54816 спроси он стопудово знает!
Ну у тебя же .fas есть со всей информацией. Возьми да посмотри, какой код это сгенерировал. Но я думаю, что ты говоришь о чём-то вроде: label foo at ebx+ecx*4+0xcafebabe mov eax,[foo] ; а нужно оно, чтобы делать так ret Ну и собственно все ненормальные адреса надо просто пропускать. А нормально выглядящие фильтровать, проверяя, что они попадают внутрь модуля (например, если в этом примере убрать регистры, адрес будет простой, но в небо).
Обсуждают сегодня