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