можно ли программно изменить значение лексемы в сегменте констант

Лексема это ассоциированное имя
Компилятор masm32 по умолчанию
сегменты глобальных данных распологает так:

1 сегмент - .const (константные лексемы)
2 сегмент - .data (инициализированные лексемы)
3 сегмент - .data? (неинициализированные лексемы)

Например в начале программы мы запустили функцию

Код (ASM):

1.  
2. invoke GetModuleHandle,0
3. mov hInstance,eax
4.  

лексему - hInstance
соответственно заранее прописали в сегменте - .data?
и в надежде что теперь можно весь кодинг пользоватся этим значением
но вот если например мы в сегменте - .data
объявили какой нибудь буфер под массив
и в процессе выполнения программы данные которые мы будем
записывать в этот буфер окажутся слишком большими
то с определённой долей вероятности
эти данные просто сотрут значение - hInstance

Можно конечно для этой лексемы сделать такой ход
сначала объявить её самую первую в сегменте - .data
с каким нибудь например нулевым значением
а потом изменить это значение функцией - GetModuleHandle

Но интересно а можно ли
как то это значение поместить в сегмент - .const
чтобы сама программа оберегала это значение
Вопрос кто в теме
можно ли это как то сделать
например пошаманить
или это просто не возможно в принцыпи

 

Лексема (информатика) — последовательность допустимых символов языка программирования, имеющая смысл для транслятора.

В данном случае вероятнее всего речь идет о переменных.
Переменные и в самом деле могут быть инициализированными, неинициализированными и постоянными.
Сегменты, в которых они располагаются, отличаются также первичной инициализацией при загрузке приложения в память, и атрибутами защиты.
"Сама программа" ничего "оберегать" не будет, это вам не джава. Просто при выходе за границу доступных на запись страниц случится ошибка и вылет.
Транслятор масм, насколько я помню, раньше располагал переменные в сегментах по желанию программиста, разве сейчас это уже не так? Даже если сейчас он раскидывает переменные автоматом, наверняка их расположение можно указать прямо.

Что касается переполнения буфера - ну дык, не допускайте этого переполнения. Или используйте язык, который все сделает за вас. Зачем тогда вообще ассемблер?

--- Сообщение объединено, 9 янв 2020 ---

Разве вызов GetModuleHandle(0) проверяет, откуда он был сделан?

--- Сообщение объединено, 9 янв 2020 ---

Регистрация в 2011... Хмм...

 

Я открою тебе секрет, только никому не говори. Переполнения буффера - это плохо вне зависимости от того, где ты этот буффер указал (на стеке, на куче, в статических данных, где угодно). С определенной очень большой долей вероятности программа после переполнения буффера будет работать некорректно. Поэтому тебе в процессе программирования стоит задуматься о том, как не переполнять буффер, а не о том, что буффер переполниться и что-либо там затрет.

 

Ну зачем так категорично... Переполнение буфера это не только плохо, но и, при некоторых обстоятельствах, хорошо.

 

Но GetModuleHandle это все-таки API, и насколько я помню, а также согласно документации

Т.е. вызов GetModuleHandle(0) должен вернуть базу именно .exe, независимо от того, вызван он из кода .exe или .dll, разве нет?

 

Не обязательно 400000h (32-bit), вы хотели сказать? Потому, что .exe процесса не всегда будет иметь базовый адрес 400000h. Почему GetModuleHandle(0) должен возвращать 10000000h, как-то вообще непонятно.

Разве там не принудительное перемещение будет? Или библиотека вообще не загрузится? Вы проверяли?

 

Она и не должна, в случае с DLL она вернет базовый адрес экзешника, который породил процесс, а никак не базовый адрес DLL. В DLL её базовый адрес передает загрузчик венды первым параметром DllMain.

 

Тема конечно бесценна.
- можно ли программно менять содержимое секции?
- можно сразу, если у секции есть атрибут MEM_WRITE, можно после установки PAGE_READWRITE для нужной страницы VirtualProtect()'ом, и можно потом вернуть все как было, чтобы программа "оберегала" свои "лексемы".

ЗЫ: я вообще плохо представляю зачем в программе больше 3 секций. Секция кода (чтение-исполнение, код-релоки), секция статичных данных (чтение, ресурсы-экспорт-данные), секция данных (чтение-запись, импорт-инициализированные данные-неинициализированные данные, причем все неинициализированные в конце, а - аптимизация).

 

При желании это можно сделать скриптами/параметрами линкера. Я, когда делал шеллы на плюсах, сводил всё в одну RWX секцию, потом вырезал ее objdump'ом.

 

Уважаемые участники обсуждения темы
предлагаю забыть об этом несчастном значении от - GetModuleHandle

Прошу вас ответить на главный вопрос темы

Можно ли программно изменить значение лексемы в сегменте констант

Просто ответить да или нет
и если да то как это сделать

 

Выражение "значение лексемы" не имеет смысла.
Можно изменить значение переменной в сегменте констант. Для этого нужно изменить доступ для страницы памяти, где эта константа находится. Сделать это можно, к примеру, при помощи VirtualProtect (см. ответ f13nd).
Изменив значение, нужно поменять доступ снова на read-only.

 

assch,

> Можно ли программно изменить значение лексемы в сегменте констант

Помесь понятий из скриптов и архитектуры, вы сошли с ума ?

Есть область данных и её размер. Размер определяется в скрипте, при дефейне переменных. Что вам есчо нужно ?

Вы хотите обмануть компилер и создать расширяемый буфер

Это не возможно, для этого есть лишь один механизм на нт - стек, причём он расширяется вниз, в отличие от расширения обычных буферов.

Имхо полный бред. ТС пили менеджер памяти или используй динамические буфера.

 

Что вам не понятно? Вам подробно ответили в #3 и #12 . 'Просто' ответить 'да или нет' на некоторые вопросы нельзя корректно , без оговорок, ибо в начальной постановке они бредовые, и ответ получится некорректным.
Лексема, как вам написали, - это понятие компилятора на фазах прохода, программно вы можете менять только значение именованных ячеек памяти, т.е , переменных.

Может, человек в запое был ..

 

njeen,

Ты туго соображаешь, он в статике пытается сделать то, что не позволяет система.

 

Да, можно, если сначала назначить странице виртуальной памяти права на запись, в противном случае при попытке записи будет эксепшн.

--- Сообщение объединено, 10 янв 2020 ---

куча, не?

 

Rel,

Нет, механизм расширения памяти она не поддерживает. Там можно только переопределить размер резерв области. При этом должны быть запросы на аллокацию, а не прямые выборки как в задаче тс. Такое только ядро со стеком делает и вниз, что не подходит тс в любом случае, так как любой буфер растёт вверх по адресам.