Ребят, пытаюсь изучить алгоритм проги на делфи. Эта прога принимает бинарный файл, в котором записаны характеристики движения: скорость, ускорение и прочее. Я просмотром этого бинаря так на глаз не смог все эти параметры в нем увидеть, видимо из-за того, что они float, там еще есть константные значения целые, их там нашел в хех формате. Я вот хочу разобрать как прога считывает этот файл и какие параметры где там в нем хранятся. Я через IDR нашел обработчик нужной мне кнопки, которая собственно строит график. Ставлю бряки на CreateFileA и ReadFile, тут все получается, я ловлю в буфер содержимое этого файла, но проблема в том, что эта прога, как я заметил много раз считывает этот файл и начинает его копировать в множество мест. Да вот на считанный файл я ставлю бряк на доступ и после этого попадаю на инструкцию копирования этого всего в другое место. Инструкция такая: rep movs [edi],[esi]. После нее ставлю бряк на вторую область тоже и теперь она из второго места такой же инструкций копирует в третье место и так происходило раз 5-6 пока наконец она не стала именно считывать из дампа параметры. Вот как бы с этим бороться. Заметил, что делфи проги любят данные копировать много раз по памяти прежде чем начнут с ними работать.
С этим бороться не нужно, это просто вызовы подпроцедур и подфункций, так же гапша от борландовского линкера. Нужно сидеть и разбирать каждый call, смотреть на адреса, найти где хранятся константы и переменные. p.s.: постить тему нужно было в категории Реверсинг
А то есть это не сам разработчик ПО так задумал, чтобы данные копировались много раз ? Правильно ли я понимаю, что в случае с делфи бряк можно убирать с данных в первом месте, когда они копируются в другое. А то просто железных бряков только 4. А что это такое расскажите.
c бОльшей долей вероятности, оптимизация борландовских ликеров оставляет желать лучшего и написав программу из одной строчки nop, ты получишь EXE'шник весом в мегабайт с кучей мусора. Про гапшу это и имелось в виду. Куча мусорного кода, большинство из которого не выполняется, другая часть выполняется, но совершенно не нужна, а оставшаяся часть реального кода программиста очень сильно перемешана с мусором от компилятора. Дельфя не ищет простых путей, если не писать на WinAPI. Обычный вызов ShowWindow, посредством дельфового Form.Show будет проходить через кучу мусорного кода и борландских костылей/перемычек, аналогично и работа с памятью. Поэтому ты получаешь множественное копирование данных и бесполезное выделение памяти. Тяжело объяснить более подробно, просто нужно писать на делфи, тогда поймешь)) p.s.: я пьяный немного, но мысль вроде изложил верно)
я бы для начала сгенерил map файл в том же IDR, и подгрузил его в отладчик, это немного облегчит задачу и позволит пропускать кучу вызовов стандартных делфи библиотек, про что справедливо написал #colorblind выше, ну а дальше раскручивал бы цепочку с процедуры чтения файла, хотя парой, по опыту скажу, проще внимательней посмотреть на файл, чем лезть в дебри кода в отладчике. Хотя подход будет очень сильно зависеть от конкретного пациента
Пишу на нем и на C#. Собственно так и делаю, еще в идр ищу адреса обработчиков кнопок перед тем как лезть в дебагер.
Да, но вот прога этот бинарный файл читает как раз не в этих стандартных библиотеках, которые идр отмечает, а как раз в своем коде. При чем она зачем-то его кучу раз открывает, считывает размер и закрывает. Эти бестолковые операции она делает в цикле, только после этого цикла она начинает его снова открывать и уже копировать из него данные.
в делфях читать файлы можно стандартной оберткой TFileStream или напрямую дергая WinAPI методы, остальное будет, по большому счету, извращение. Скорее всего написан какой-либо класс TReader = class(TFileStream), который и выполняет десериализацию из файла, а все эти "кучу раз открывает..." и т.д. инициализация и заполнение его полей. Можно конечно пробовать в ida поковырять, восстанавливая методы и поля класса, но времени на это скорей уйдет не мало они же, если память не изменяет, должны уже быть в map файле
