fasm 1.73.04
к посту о фасм ранее
https://yadi.sk/d/e-ejtYnHTKLc_w (ссылка все та же, обновлена)
добавлено: копия SYSTEMCOLORS, и проверка при отрисовке окна (если SYSTEMCOLORS не обновились - они не применяются к контролам по новой) (не сказать, что код проверки короче, чем код применения SYSTEMCOLORS к контролам, но это логично, что должно быть так) - ну и соответственно функции для всего этого.
в остальном изменена структура исходников немного (папки structures и equates).
Что я хочу увидеть в Колибри завтра....
Добрый вечер. Кто работал с программой Olly debug, подскажите что означает следующее сообщение?
Я примерно понимаю что в нем говорится о каких-то испорченных точках остановки, но неясно что это такое. Предполагаю что это окно наблюдается если я в код программы вношу какие-либо изменения, которые сдвигают расположение функций. Но как оно знает что функции сдвинулись Ах олдскулеры(
точка останова падает на начало инструкции до патча, а после патча на середину инструкции.
мне ломанная ида про больше нравится как отлдадчик и дизассемблер, чем олька. Не призываю (но информирую).
Но после патча целевого файла (а не его образа в иде, образ то можно патчить и переотлаживать сколько угодно) ида сталкивается с теми же проблемами.
точка останова падает на начало инструкции до патча, а после патча на середину инструкции.
мне ломанная ида про больше нравится как отлдадчик и дизассемблер, чем олька. Не призываю (но информирую).
Но после патча целевого файла (а не его образа в иде, образ то можно патчить и переотлаживать сколько угодно) ида сталкивается с теми же проблемами.
структура репозитария: в корне выделить папки
1.structures - для определения структур (kernel.inc для самых базовых, остальные по именам модулей к которым они относятся),
2.equates - для определения констант (опять же kernel.inc для самых базовых, остальные по именам модулей к которым они относятся),
3.macros - для определения макросов (те же принципы),
все вышеперечисленные файлы не должны содержать ни одного байта генерируемого кода, будучи лишь вспомогательными файлами для удобства синтаксиса программы
4.helperprocs - для определения вспомогательных функций которые могут быть многократно востребованы в большинстве компилируемых программ.
Сейчас в каждой программе (а вернее объектном модуле) - все это свалено в файлик *.mac интуитивно ожидается что там должно быть только определение макросов, но не тут то было - определение всего свалено в кучу, так еще могут присутствовать директивы определения данных.
tinypad & textedit присутствуют одновременно.
Что если как текстовый редактор оставить только textedit, а tinypad сцепить с фасмом в полноценное иде? Например для более настраиваемой подсветки синтаксиса tinypadу понадобятся таблицы используемые фасмом для парсинга - довольно большие - не дублировать же, а будучи одним файлом с фасмом он получит к ним доступ.
пример fasm с такой подсветкой, но для Windows: https://yadi.sk/d/ZctCe5onzFz6mQ
1.structures - для определения структур (kernel.inc для самых базовых, остальные по именам модулей к которым они относятся),
2.equates - для определения констант (опять же kernel.inc для самых базовых, остальные по именам модулей к которым они относятся),
3.macros - для определения макросов (те же принципы),
все вышеперечисленные файлы не должны содержать ни одного байта генерируемого кода, будучи лишь вспомогательными файлами для удобства синтаксиса программы
4.helperprocs - для определения вспомогательных функций которые могут быть многократно востребованы в большинстве компилируемых программ.
Сейчас в каждой программе (а вернее объектном модуле) - все это свалено в файлик *.mac интуитивно ожидается что там должно быть только определение макросов, но не тут то было - определение всего свалено в кучу, так еще могут присутствовать директивы определения данных.
tinypad & textedit присутствуют одновременно.
Что если как текстовый редактор оставить только textedit, а tinypad сцепить с фасмом в полноценное иде? Например для более настраиваемой подсветки синтаксиса tinypadу понадобятся таблицы используемые фасмом для парсинга - довольно большие - не дублировать же, а будучи одним файлом с фасмом он получит к ним доступ.
пример fasm с такой подсветкой, но для Windows: https://yadi.sk/d/ZctCe5onzFz6mQ
Last edited by ProMiNick on Wed Jan 09, 2019 11:52 am, edited 1 time in total.
Внимание!
Снимается секретность с подопытной программы, о которой я писал ранее здесь. Моей подопытной программой был компилятор Borland C++ 5.02, в архиве результаты исследований: Пока что до портирования под Колибри очень далеко, но с полученными файлами можно проводить эксперименты в Виндовсе. Может кому-то они пригодятся для извлечения отдельных функций.
Снимается секретность с подопытной программы, о которой я писал ранее здесь. Моей подопытной программой был компилятор Borland C++ 5.02, в архиве результаты исследований: Пока что до портирования под Колибри очень далеко, но с полученными файлами можно проводить эксперименты в Виндовсе. Может кому-то они пригодятся для извлечения отдельных функций.
IgorA, это не реверсинг((((( дизассемблинг не более((((
ты расписал хорошо и так документированные функции.
Куда интереснее если бы было описание неизвестных. Всем переменным присвоены адресные имена вместо смысловых (хотя бы части переменных можно было бы присвоить какие-то смысловые имена). В фасме есть такие штуки как структуры данных, неплохо было бы выделить в данных подобные структуры. Единственный плюс - Импорт и экспорт - хотя бы через макросы.
из retn ? и add esp,-? или sub esp,? можно было делать доп инфо о параметрах и локальных переменных, что-то вроде:
и вместо ebp+/-что-то использовать эти символьные имена, а может даже подобрать смысловое имя одного из аргументов, или определить структуры в локальном фрейме.
Я думаю, если что-то портируется - нужно отделить полезную логику (попробовать ее понять - определить структуры данных над которыми она осуществляется) от ХЛЛ-льного мусора определить места соприкосновения этой логики с функциями специфичными для операционной системы. И портировать ТОЛЬКО полезную логику. Раз это компилятор - в данных должны присутствовать таблицы разбора - совокупности идентификаторов возможно вместе с сылками на их обработчики. С++ вроде однопроходный компилятор - значит все переменные в момент использования предопределены. И раз компилятор ХЛЛльный, значит в нем присутствует код добавления в выходной файл мета части - врятли в колибри она нужна.
ты расписал хорошо и так документированные функции.
Куда интереснее если бы было описание неизвестных. Всем переменным присвоены адресные имена вместо смысловых (хотя бы части переменных можно было бы присвоить какие-то смысловые имена). В фасме есть такие штуки как структуры данных, неплохо было бы выделить в данных подобные структуры. Единственный плюс - Импорт и экспорт - хотя бы через макросы.
из retn ? и add esp,-? или sub esp,? можно было делать доп инфо о параметрах и локальных переменных, что-то вроде:
Code: Select all
virtual at ebp-8
.loc1 dd ?
.loc2 dd ?
.oldebp dd ?
.retaddr dd ?
.arg1 dd ?
.arg2 dd ?
end virtual
Я думаю, если что-то портируется - нужно отделить полезную логику (попробовать ее понять - определить структуры данных над которыми она осуществляется) от ХЛЛ-льного мусора определить места соприкосновения этой логики с функциями специфичными для операционной системы. И портировать ТОЛЬКО полезную логику. Раз это компилятор - в данных должны присутствовать таблицы разбора - совокупности идентификаторов возможно вместе с сылками на их обработчики. С++ вроде однопроходный компилятор - значит все переменные в момент использования предопределены. И раз компилятор ХЛЛльный, значит в нем присутствует код добавления в выходной файл мета части - врятли в колибри она нужна.
В том то и проблема что у нас нет исходного кода. Потому о назначении неизвестных функций можно только догадываться смотря на сам код функций.ProMiNick wrote:ты расписал хорошо и так документированные функции.
Куда интереснее если бы было описание неизвестных
Там просто очень много переменных и всем им присваивать имена очень трудно. Все-таки больше 3 мб кода... Хотя многим строковым переменным дизассемблер присвоил имена исходя из того текста который в них есть.ProMiNick wrote:Всем переменным присвоены адресные имена вместо смысловых (хотя бы части переменных можно было бы присвоить какие-то смысловые имена).
Я тоже так думаю, но пока что не понятно как точно определить где именно эта полезная логика спрятана. Кроме метода комментирования участков кода и просмотра поведения программы ничего придумать не могу. Но и это не дает гарантии ведь можно убрать что-то нужное, которое в данном случае не используется, но может пригодится в последствии.ProMiNick wrote:Я думаю, если что-то портируется - нужно отделить полезную логику (попробовать ее понять - определить структуры данных над которыми она осуществляется) от ХЛЛ-льного мусора определить места соприкосновения этой логики с функциями специфичными для операционной системы. И портировать ТОЛЬКО полезную логику.
Задача портирования очень трудна, но теоретически возможна для выполнения. Даже получить компилируемый fasm-овский код, который при этом еще и работает тоже нелегко, ведь дизассеблер не выдает всегда правильный код. Бывало, что некоторые куски кода шли просто байтами и приходилось востанавливать их из нескольких программ.
Еще вопрос, что такое ХЛЛльный компилятор?
ХЛЛльный компилятор - компилятор языка высокого уровня (ХЛЛ -High Level Language)
про выделение структур...
например, по адресу метки L0049C96C начинается таблица, каждый элемент которой имеет вид:
почти вся секция данных, это либо текстовые строки, либо таблицы, конечно элементы других таблиц имеют struct отличный от описанного в примере выше.
еще можно прооверрайдить директиву dt в fasm`е одноименным макросом
macro dt по аналогии.
там есть таблица dtшек - чтоб она не разрывалась вкраплениями констант бесконечности и NaN как раз вышеописанный оверррайд.
Но можно и без макросов (идея пришла 25.01.2019, дописал сюда):
синтаксис использования:
про выделение структур...
например, по адресу метки L0049C96C начинается таблица, каждый элемент которой имеет вид:
Code: Select all
struct someelement
pString dd ?
index dd ?;с шагом 2? нет не индекс конечно, непонятная внутренняя ересь компилятора
elementClass db ?;подозреваю что это внутренний класс элемента (лучше использовать единую нотацию или decimal или hexadec...)
elementsubClass db ?;подозреваю что это внутренний подкласс элемента, используется не везде (значение по умолчанию (-1) или $FF)
elementID db ?; подозреваю что это ID, по крайней мере для регистров
db 0;не используется, выравнивает структуру на 4хбайтовую границу
end struct
Code: Select all
L0049C96C:
._1 someelement SSZ0049CB58__EAX, 2*0,10,10,17,
._2 someelement SSZ0049CB5D__EDX, 2*1,10,13,19,
._3 someelement SSZ0049CB62__EBX, 2*2,10,11,20,
._4 someelement SSZ0049CB67__ECX, 2*3,10,12,18,
._5 someelement SSZ0049CB6C__ESI, 2*4,10,14,23,
._6 someelement SSZ0049CB71__EDI, 2*5-1,10,15,24,
._7 someelement SSZ0049CB76__EBP, 2*6-2,10,-1,22,
._8 someelement SSZ0049CB7B__ESP, 2*7-3,10,-1,21,
и т.д.
еще можно прооверрайдить директиву dt в fasm`е одноименным макросом
Code: Select all
struc dt [arg] {
if arg eqtype 1.0
dt arg
else
match sign value,arg {
match =INF,value { dq $8000000000000000 \\}
match =NaN,value { dq $C000000000000001 \\}
dw $7FFF - (sign $4000 - $4000) \}
end if }
там есть таблица dtшек - чтоб она не разрывалась вкраплениями констант бесконечности и NaN как раз вышеописанный оверррайд.
Но можно и без макросов (идея пришла 25.01.2019, дописал сюда):
Code: Select all
Inf equ -$4000+$4000+$7FFF:$8000000000000000
NaN equ Inf or
Code: Select all
dt Inf,+Inf,-Inf,+NaN(Index),-NaN(Index); где Index - любое число от 1 до $7FFFFFFFFFFFFFFF
Last edited by ProMiNick on Fri Jan 25, 2019 11:32 am, edited 1 time in total.
Структуры нужно сокращать, потому что в коде они распознаны хаотично. Очень часто по байту на каждую строку выделило, там где можно например dd поставить и сэкономить место.
А, есть ли возможность для IDA указать Мар файл с адресами и названиями меток (не корректируя данные вручную при этом)
P.S. Для общего понимания кода IDA может выдавать листинг и в псевдо Си коде. Это используется?
P.S. Для общего понимания кода IDA может выдавать листинг и в псевдо Си коде. Это используется?
Про возможности ИДА представить код в псевдо Си не знаю. Возможно для анализа функций вещь полезная.
Но я вел речь о предшествующей анализу функции стадии - стадии анализа данных.
И речь не о хаотичном преобразовании любых 4х db подряд в 1 dd. А в поиске таблиц!!! Таблица - или иначе статический массив однородных элементов. Каждый такой однородный элемент логично представлять в 1 строчке кода ассемблера, предварительно создав определение для структуры этого однородного элемента. И повторюсь - анализируется компилятор, поэтому 90% всех данных занимают таблицы и текстовые строки, на которые ссылаются элементы этих таблиц.
П.С. некоторые 4 идущих подряд db и вовсе не нужно объединять в dd - если каждый из них в отдельности определяет независимый подкласс элемента, напротив если они образуют единое битовое поле, а темболее 4хразрядное число - то объединять нужно.
На примере предложенной мной структуры someelement, даже дизассемблер однозначно определил первое его поле как dword ссылку на текстовую строку.
Второй элемент я обозвал индекс - он все время возрастает (если мы делаем допущение что возрастает он не просто как однобайтовое число, а как 4хбайтовое - не находим никаких противоречий - верхние разряды обнулены) - он тоже dword.
Но следующие далее в структуре байты меняют свои значения хаотично - значит каждый из них характеризует что-то самостоятельное. а последний всегда 0 - он выравнивает структуру на границу 4х байт.
Если анализа данных не сделать, то IgorA, все кому понадобиться извлечь отдельные функции, повторят весь твой труд - т.к. для анализа функций не достает готового анализа данных, а чтоб его получить проще работать с образом в дизассемблере, чем с просто текстом кода.
мой опыт реверсинга - я шел от обратного - объяснить каждую процедуру шаг за шагом, оптимизировать функцию, и только когда у меня сформируется общее представление - скомпилировать готовую программу. До готовой еще не дошел.
вот ссылка "shellex x86 & x64: what HLL (VC++6,7) hides over the sources" https://board.flatassembler.net/topic.php?t=20785
Моя цель - в проекте по ссылке - дать возможность каждому fasm-еру писать расширения оболочки Windows под ассемблером.
Файлы для анализа выбрал самые маленькие 23кб для x86, 30кб для x64, 86кб для еще одной версии для сравнения.
Но я вел речь о предшествующей анализу функции стадии - стадии анализа данных.
И речь не о хаотичном преобразовании любых 4х db подряд в 1 dd. А в поиске таблиц!!! Таблица - или иначе статический массив однородных элементов. Каждый такой однородный элемент логично представлять в 1 строчке кода ассемблера, предварительно создав определение для структуры этого однородного элемента. И повторюсь - анализируется компилятор, поэтому 90% всех данных занимают таблицы и текстовые строки, на которые ссылаются элементы этих таблиц.
П.С. некоторые 4 идущих подряд db и вовсе не нужно объединять в dd - если каждый из них в отдельности определяет независимый подкласс элемента, напротив если они образуют единое битовое поле, а темболее 4хразрядное число - то объединять нужно.
На примере предложенной мной структуры someelement, даже дизассемблер однозначно определил первое его поле как dword ссылку на текстовую строку.
Второй элемент я обозвал индекс - он все время возрастает (если мы делаем допущение что возрастает он не просто как однобайтовое число, а как 4хбайтовое - не находим никаких противоречий - верхние разряды обнулены) - он тоже dword.
Но следующие далее в структуре байты меняют свои значения хаотично - значит каждый из них характеризует что-то самостоятельное. а последний всегда 0 - он выравнивает структуру на границу 4х байт.
Если анализа данных не сделать, то IgorA, все кому понадобиться извлечь отдельные функции, повторят весь твой труд - т.к. для анализа функций не достает готового анализа данных, а чтоб его получить проще работать с образом в дизассемблере, чем с просто текстом кода.
мой опыт реверсинга - я шел от обратного - объяснить каждую процедуру шаг за шагом, оптимизировать функцию, и только когда у меня сформируется общее представление - скомпилировать готовую программу. До готовой еще не дошел.
вот ссылка "shellex x86 & x64: what HLL (VC++6,7) hides over the sources" https://board.flatassembler.net/topic.php?t=20785
Моя цель - в проекте по ссылке - дать возможность каждому fasm-еру писать расширения оболочки Windows под ассемблером.
Файлы для анализа выбрал самые маленькие 23кб для x86, 30кб для x64, 86кб для еще одной версии для сравнения.
Пока что эта возможность не использовалась, я в основном использовал PE Explorer вместе с Olly Dbg и из этих программ составлял получившийся код. Когда ProMiNick написал о IDA pro, тогда работы по приведению кода в компилируемый вид уже были выполнены. От IDA я взял адреса и названия некоторых стандартных функций, но еще не все эти названия перенесены в основной файл.Kopa wrote:Для общего понимания кода IDA может выдавать листинг и в псевдо Си коде. Это используется?
В общем понятно что нужен анализ функций что-бы сделать из них что-то полезное. Но если предположим они определят что им нужны определенные функции с определенными адресами, то как тогда они без готового кода будут его компилировать? В таком случае им прийдется самим этот код редактировать вручную. А если файл с кодом уже есть тогда можно просто взять его и копировать функции куда нужно. Ведь дизассемблер не дает готового кода подходящего для компиляции.ProMiNick wrote:Если анализа данных не сделать, то IgorA, все кому понадобиться извлечь отдельные функции, повторят весь твой труд - т.к. для анализа функций не достает готового анализа данных, а чтоб его получить проще работать с образом в дизассемблере, чем с просто текстом кода.
IgorA, когда есть связка нужных функций и структур данных - компилируемый код можно написать уже и от руки.
Рабочий дизассемблированный код нужен только для патчей. Весь анализ проводится только с образом исполняемого файла в дизассемблере(отладчике).
Ведь при портировании потребуется изменить определенный функционал: создавать выходные исполняемые файлы в формате колибри, убрать обработку исключений специфичную для винды автоматически встраиваемую компилятором в выходной файл. (Иначе зачем разрабатывать для винды из под колибри) - так что простое дизассемблирование тут бесполезно.
Рабочий дизассемблированный код нужен только для патчей. Весь анализ проводится только с образом исполняемого файла в дизассемблере(отладчике).
Ведь при портировании потребуется изменить определенный функционал: создавать выходные исполняемые файлы в формате колибри, убрать обработку исключений специфичную для винды автоматически встраиваемую компилятором в выходной файл. (Иначе зачем разрабатывать для винды из под колибри) - так что простое дизассемблирование тут бесполезно.
Доброго дня всем,
полноэкранный режим для приложений не плохо было бы.
Извините, если это уже обсуждалось.
полноэкранный режим для приложений не плохо было бы.
Извините, если это уже обсуждалось.
Да, это обсуждалось, но никто ничего не сделал либо руки не дошли.
У некоторых приложений окно развернуть на весь экран можно два раза кликнув по заголовку окна.
У некоторых приложений окно развернуть на весь экран можно два раза кликнув по заголовку окна.
Who is online
Users browsing this forum: No registered users and 2 guests