Я впервые встретил это слово в вопросе StackOverflow "С# Теоретический: напишите JMP на кодек в asm." Я вижу, что согласно Wiktionary, пещера кода:
неиспользуемый блок памяти, который может использовать кто-то, как правило, программный взломщик пользовательский программный код для изменения поведения программы.
Я нашел правильное определение? Если да, есть ли законное использование для кодовой пещеры?
Я использовал их, хотя до сегодняшнего дня я никогда не слышал певца кода кода. Определение Wiktionary предполагает, что пещера кода - это то, что взломщик находит в исполняемом файле, который он или она пытается взломать. Вопрос, который вы цитируете, не использует его таким образом. Вместо этого предлагается, чтобы пещера кода выделялась с помощью VirtualAllocEx, чтобы создать новый блок памяти в целевом процессе. Это устраняет необходимость поиска неиспользуемого пространства в целевом объекте, и это гарантирует, что у вас будет достаточно места для размещения всего вашего нового кода.
В конечном счете, я думаю, что "пещера кода" - это просто место для хранения кода, созданного во время выполнения. Для этого кода не должно быть какой-либо гнусной цели. И в этот момент вопрос о том, что кодовая пещера становится совершенно неинтересным. Интересные части - вот причины для генерации кода во время выполнения и какие существуют методы для обеспечения того, чтобы новый код запускался, когда вы этого хотите.
Можно было бы преднамеренно создать пещерку кода в качестве части самообновляющегося кода .
Предполагая, конечно, что это безумие.
Кодовые пещеры обычно создаются компиляторами для alignment и часто расположены между функциями в больших количествах. Также должны существовать кодовые пещеры между структурами и переходами (в некоторых архитектурах), но обычно не в каких-либо значительных количествах.
Вы также можете искать блок с нулевой памятью, но нет гарантии, что программа не будет их использовать.
Я полагаю, что теоретически, если вы потеряли исходный код, вы можете исправить свою баггированную программу, используя их, и ваша программа не будет расти в размерах.
Edit
Для тех из вас, кто предлагает кодовые пещеры, только для кода, сгенерированного во время выполнения: это неполное определение. Много раз я написал структуру данных в "пещере кода" и обновил указатели, чтобы указать туда, и я подозреваю, что я не единственный человек, который это сделал.
некоторые законные способы использования: исправление исполняемых файлов в реальном времени без перезагрузки (MS делает это), подключение низкоуровневой функциональности ОС (файловая система, сеть) для брандмауэра и антивируса, расширение приложения, когда вы не выполняете имеют исходный код (например, соскабливание низкоуровневых OS-вызовов к DrawText, чтобы вы могли читать их вслух для слепых)
Способ, описанный здесь, напоминает мне patchpoints - законное использование.
Не знакомы с термином, но механизмы hot-patching могут использовать зарезервированное пространство для хранения патчей кода. Вы подключаетесь к неисправной функции и перенаправляете ее на новую улучшенную функцию. Это можно сделать "на лету" без снятия критического оборудования (крупные телекоммуникационные коммутаторы).
Он может использоваться для ввода кода во время выполнения. Его можно использовать для написания самомодифицирующего кода на статических языках, предполагая, что ОС позволяет вам (бит NX не установлен и т.д.). Для этого есть использование, но это не то, о чем вы должны думать в своем типичном бизнес-приложении.
Это звучит как правильное определение для меня.
Что касается законного использования, позвольте мне сказать следующее: не делайте этого, если вы просто не экспериментируете ради экспериментов и не готовы принять последствия.
Нет никакого способа, чтобы этот тип вещи когда-либо переходил в производственный код:
Самомодифицирующийся код не следует рассматривать легко, но иногда может принести большой прирост производительности. Если вы программируете очень долго, вы, вероятно, использовали его, не осознавая этого.
До широкого использования 486 и выше многие ПК не включали аппаратную плавучую поддержку. Это заставило людей писать программы с плавающей точкой с дилеммой. Если они скомпилировали свою программу для использования встроенных команд с плавающей запятой, она быстро работала бы на машине с процессором с плавающей запятой, а не на машинах без одного. Если они скомпилировали свою программу с программной эмуляцией с плавающей запятой, она будет работать на всех машинах, но медленно даже на машинах с аппаратной плавающей точкой.
Многие библиотеки компиляторов использовали интересный трюк с самомодифицирующимся кодом. Поведение по умолчанию заключалось в том, чтобы поместить команду trap, где нужна операция с плавающей запятой. Обработчик ловушки будет либо эмулировать инструкцию в программном обеспечении, либо если он обнаружит, что он работает на машине с аппаратным обеспечением с плавающей запятой, он изменит код, заменив команду trap на соответствующую аппаратную инструкцию с плавающей запятой и выполнив ее. Результатом было программное обеспечение, которое выполнялось на всех машинах, и выполнялось почти так же быстро на машине с аппаратным обеспечением с плавающей точкой, как если бы код был скомпилирован для использования аппаратных средств с плавающей запятой напрямую (поскольку большинство операций с интенсивностью с плавающей запятой происходят в циклах, которые выполняются много раз).