views:

1668

answers:

10

I encountered this word for the first time in the StackOverflow question "C# Theoretical: Write a JMP to a codecave in asm." I see that according to Wiktionary, a code cave is:

an unused block of memory that someone, typically a software cracker, can use to inject custom programming code to modify the behavior of a program.

Did I find the correct definition? If so, is there any legitimate use for a code cave?

+3  A: 

It can be used to inject code at runtime. It can be used to write self-modifying code in static languages assuming that the OS lets you (NX bit not set, etc). There are uses for it, but it's not something you should be thinking about in your typical business app.

jfclavette
+10  A: 

One might wish to intentionally create a code cave as a part of using self-modifying code.

Assuming, of course, that one is insane.

chaos
SkyNet got started as a code-cave.
TheTXI
Gotta love programming techniques that, while completely valid, are predicated on the programmer being insane...
Shog9
An interesting answer, but is there any guarantee your code wouldn't be overwritten? Wouldn't someone writing self-modifying code protect that memory space?
altCognito
Sure. It'd be just as protected as any other part of the program (modulo executable space protection, which could not be applied to the code cave). The cracking utility of a code cave isn't based on it being exempted from OS memory protection; to be used at all, the cracker has to have some way of getting data into it (like running the program under a debugger).
chaos
+1: Too funny. It hadn't occurred to me that this could be used as a deliberate self-modifying code mechanism. Wayyy back in the day (mid 80's) this used to be all the rage ... when 4k was a moderate amount of RAM and tricks had to be used to make your code fit into the allotted space.
Eddie
+7  A: 

Code cave is what I call the basement. :-)

Brian Knoblauch
+1 When I saw this question, I thought they were talking about a place where you write code.
Zifre
+10  A: 

Code caves are usually created by compilers for alignment and are often located between functions in copious amounts. There should also be code caves between structures and jumps (in some architectures), but usually not in any significant amounts.

You also might search for a block of zeroed memory, but there's no guarantee that the program won't use them.

I suppose theoretically, if you lost your source code, you could patch your buggy program by using them, and your program wouldn't grow in size.

Edit

To those of you suggesting code caves are only for run-time generated code: that is an incomplete definition. Many times I have written a data structure in a "code cave" and updated pointers to point there, and I suspect I am not the only person to do so.

Unknown
+3  A: 
e.James
"If it is possible to inject code into memory and then execute it" ummmmm on windows, you can do this to every single process, i presume you can do it with root privs on any OS.
Dustin Getz
"It is a code maintenance nightmare and debugging nightmare" no sane coder is going to be injecting code at runtime if they can modify the source. you do this when you're an absolute expert with no alternatives.
Dustin Getz
@Dustin Getz, Re point #1: An experienced programmer with root access can do just about anything. I am referring to the dangers of having an unprotected code cave in production software, which could leave the program open to malicious users who do not have root access.
e.James
@Dustin Getz, Re point #2: I agree. As I said in the second line of my answer, you have to be willing to accept the consequences. The rest of the warnings are there for the coders who are not sane, and I can tell you from experience that they do exist.
e.James
the presence of a code cave has zero impact on the security of an app. they're just compiler artifacts.
Dustin Getz
I don't think that is correct, especially in the context of this question. The question that Eddie links to describes an intentional code cave, as do many of the answers. If your production software includes a facility to inject and execute code, that is undoubtedly a security concern, and not simply a compiler artifact.
e.James
+6  A: 

The way it's described here reminds me of patchpoints -- a legit use.

Dan
+4  A: 

Unfamiliar with the term but hot-patching mechanisms could use reserved space to store code patches. You hook into the defective function and redirect it to the new-improved function. It can be done on-the-fly without taking down critical equipment (large telecom switches).

DanM
+2  A: 

Self-modifying code should not be considered lightly, but can sometimes bring big performance gains. If you've been programming for very long, you've probably used it without realizing it.

Prior to the widespread use of the 486 and higher, many PCs did not include hardware floating support. This left people writing programs involving floating point with a dilemma. If they compiled their program to use in-line floating point instructions it would run fast on a machine with a floating point processor, and not at all on machines without one. If they compiled their program with software floating point emulation, it would run on all machines, but slowly even on machines with hardware floating point.

Many compilers libraries used an interesting trick with self-modifying code. The default behavior was to put a trap instruction where a floating point operation was needed. The trap handler would either emulate the instruction in software, or if it detected it was running on a machine with floating point hardware, it would modify the code by replacing the trap instruction with the appropriate hardware floating point instruction and execute it. The result was software that ran on all machines, and ran almost as fast on a machine with floating point hardware as if the code had been compiled to use floating point hardware directly (since most floating point intensive operations occur in loops that are executed many times).

Stephen C. Steel
I knew about self-modifying code. (Used to play with ASM in the early 80s on microprocessors. 6809, 6502, Z-80, etc.) But hadn't considered a code cave as a mechanism for allowing purposeful self modifying code!
Eddie
+4  A: 

some legitimate uses: patching live OS binaries without a reboot (MS does this), hooking low level OS functionality (filesystem, network) for firewall and antivirus, extending an application when you don't have source code (like scraping low level OS calls to DrawText so you can read them aloud for blind people)

Dustin Getz
+5  A: 

I've used them, although I'd never heard the term code cave until today. The Wiktionary definition suggests that a code cave is something the cracker finds in the executable he or she is attempting to crack. The question you cite doesn't use it that way. Instead, it suggests the code cave is being allocated with VirtualAllocEx to create a brand new block of memory in the target process. That removes the need to search for unused space in the target, and it guarantees you'll have enough space to put all your new code.

Ultimately, I think a "code cave" is just a place to store run-time-generated code. There doesn't have to be any nefarious purpose to that code. And at that point, the question of what a code cave is becomes entirely uninteresting. The interesting parts are what reasons there are for generating code at run time, and what techniques there are for making sure that new code gets run when you want it.

Rob Kennedy
There are many good answers, but I selected yours because you addressed not only my question but also the question that caused me to wonder what a code cave is. (To the folks not selected as the answer who still gave good answers ... I voted up several good answers. Thank you!)
Eddie