Есть необходимость изменения программы к которой нет исходных текстов. Прога достает из файлов формата DLIS некоторые данные. В проге есть ограничение на число каналов в файле - 1024 канала. Я хочу изменить ограничение, скажем до 2048 каналов. Проблема в том, что массив размером 1024*4 создается на стеке, а затем, в этой же функции (EBP не меняется - 12FF80), на стеке, создается еще куча данных, и обращение к этим данным едет через EBP - смещение. Я увеличил размер массива до 2048, это было не сложно. Заменить "EBP - смещение" на "EBP - 1024 - смещение" оказалось гораздо сложнее, и походу я что-то упустил - прога падает. Опыт работы с ассемблером у меня небольшой, я пишу на с++. И у меня два вопроса:
1. Эта задача вообще решается? Может есть другой способ?
2. Как мне отследить все обращения к стеку, которые адресуются через 12FF80 - смещение.

| Сообщение посчитали полезным:

перенесите массив после всех переменных, а не все переменные отодвигайте. Отследить зависимости будет проще.

| Сообщение посчитали полезным:

Возможно адреса некоторых переменных хранятся где-нибудь в этом же стеке. Например если в функции есть переменная и указатель на нее. Посмотрите отладчиком на какой инструкции прога падает и мысленно пролистайте код обратно.

| Сообщение посчитали полезным:

"EBP - 4096 - смещение" ?

| Сообщение посчитали полезным:

ant_man пишет:
"EBP - 4096 - смещение" ?
тогда уж 8192 (2048*4)

| Сообщение посчитали полезным:

ant_man Вы правы, конечно - "EBP - 1024*4 - смещение".

Azur1d Нет, именно "EBP - 1024*4 - смещение", поскольку оригинальная адресация "EBP - смещение". Т.е. в смещениии уже учтен оригинальный массив размером 1024 элемента.

izl3sa Спасибо. Очень дельный совет. То есть, нужно создать новый массив на 2048 элементов (8192 байт) после всех переменных, причем создание старого на 1024 элемента, нужно оставить как есть. Тогда смещения для переменных не изменятся.

Azur1d Искал, но не смог найти, как поймать unhandled exception в Syser'e. Или для этого нужен OlyDbg?

| Сообщение посчитали полезным:

А я бы решил по-програмистски: выделял бы массив в памяти, в конце функции память высвобождал. Тогда бы и стек не пришлось двигать, только регистр, в котором указатель на массив заменил бы... Хотя это на код посмотреть, может там так просто и не выкрутиться.

-----
Реверсивная инженерия - написание кода идентичного натуральному

| Сообщение посчитали полезным:

Снизу стек ограничен сторожевой страницей(PAGE_GUARD). При обращении к ней ядро расширяет стек на одну страницу. Ниже память не выделена, при обращении к ней возникнет #AV. Тоже самое происходит изза размера локального фрейма превышающего размер страницы(0x1000). Выполняйте обращение к стеку последовательно начиная с текущей границы с шагом в одну страницу. Число итераций берите равным REGION_SIZE/X86_PAGE_SIZE(0x1000). После этого загружайте в стек необходимые данные.

| Сообщение посчитали полезным:

Сделал как предлагал izl3sa. Вроде все работает. Мне повезло, поскольку все обращения к массиву были только через "EBP - смещение", и я просто изменил это смещение. Всего около 130 мест. Причем использовались разные команды (регистры). Мне кажется, что это оптимальный вариант, в отличии от выделения памяти, как предложил Hexxx. Скажите если я не прав, но мне кажется, в этом случае пришлось бы где то хранить адрес массива, постоянно доставать его оттуда в какой-то регистр, а это инструкции для которых нет места. Придется раздвигать код, и т.д.

Всем спасибо!!!

| Сообщение посчитали полезным:

Clerk
Этого я не знал, но я так понял, что код выполняющий эти итерации уже есть в этой проге.

Вот так в оригинале выделяется на стеке область размером 16FC


Я лишь заменил 16FC на 36FC. А итерации в 0х1000, происходят внутри процедуры по адресу 411750



От модератора: если забыл, для этого Правка есть

| Сообщение посчитали полезным:

Модератор
Спасибо. Жаль что предпросмотра нет.

| Сообщение посчитали полезным: