If I have a function like this
void check(char *buffer)
{
//some stuff that only needs to be run once
}
Is there any way I could go about 'deleting' this function from memory after I call it once?
I could easily go about doing this in pure ASM. But I was wondering if there is a more standard way of doing it.
The C++ standard (or even the C one) consider the totality of the code of your program as immutable. So it makes no sense to "delete" a function.
But let's be pragmatic. Most of the time your C++ program is compiled into some executable running in some operating system (I'll suppose that OS is Linux, but you could adapt my answer to other OSes). For a general overview on OSes, read Operating Systems: Three Easy Pieces (freely downloadable)
Then, when your program is starting (probably by your shell doing a fork(2) then an execve(2)) in some process, a new virtual address space is created (and managed by the kernel which configures the MMU and handle page faults by paging appropriate data e.g. from disk).
In general, the ELF executable of your program contains a code segment which is memory-mapped in some read only and executable segment of your virtual address space. Since that part is read only you cannot "delete" or "write" it. With shared libraries the virtual address space is more complex and contains several code segments (perhaps one or more per library).
I could easily go about doing this in pure ASM.
Wrong for a program running on some (modern) OS. Because the code segment is read-only, so you need to alter your virtual address space (the only way to do that is thru appropriate system calls like mmap, munmap, mprotect; you can invoke them in C++, in C, or even in ASM). The fact that some function has been coded in assembler don't change that. And even an assembler code cannot overwrite the code segment (you'll still get some segmentation fault in that case) without altering your virtual address space before.
You could play low-level tricks, for example use the munmap(2) system call -from some C++ code or C code or assembler code -, to alter your virtual address space and remove some pages from it. I strongly recommend not doing that. But if you go that route, you need to understand all the details of your ELF executable and shared objects and of your virtual address space. Be aware of ASLR, elf(5), ld-linux(8), vdso(7). Use objdump(1) & readelf(1) & see ld(1) to understand the details of your ELF executable.
You might put your code (of your check and several other functions) into some plugin, but in your case you probably should not. In that case, you could dynamically load that plugin and later unload it. You'll use dlopen(3) to load the plugin, and dlclose to unload it. The dlopen-ing of a plugin does several mmap(2) (so grows the virtual address space) and process relocations and its dlclose does several munmap(2) (so shrinks the virtual address space).
Play with /proc/ on Linux (see proc(5)). Try cat /proc/self/maps and cat /proc/$$/maps and cat /proc/$$/status in a terminal. And read /proc/self/maps from your C++ program (for example, see this).
For example, fish is a shell coded in C++. It runs in the process of pid 4735 right now on my desktop. Its virtual address space has 69 segments, as counted with wc /proc/4735/maps. Its code segment is mapped (read only and executable):
556dad571000-556dad697000 r-xp 00000000 08:01 11272485 /usr/bin/fish
the code segment of my C standard library is probably at
7fa96bcb3000-7fa96be4c000 r-xp 00000000 08:01 1704209 /lib/x86_64-linux-gnu/libc-2.25.so
I don't understand your security concerns (mentioned only in a comment, which should go into the question), since your code segment is read-only. Indeed, a malicious function could change the protection of some code segment (using mprotect(2)) and then alter it. But you need to explain how the code injection (of that malicious function) happens in the first place (you can code a program relying on process isolation and proven with formal methods to avoid that happenning, assuming that your Linux kernel is trustable).
Maybe you have privacy concerns (but that makes a different question). Obviously you don't want to keep passwords as clear text in your code.
Maybe (but quite unlikely) you are coding a standalone program (without any OS) e.g. for an embedded system and its microcontroller (e.g. Arduino like). In that case, your code is in flash memory. And how to alter or delete it becomes hardware specific. BTW, overwriting flash memory several times is harming the hardware.
You can do it like this, with a slight performance hit (irrelevant if you want to call the function just once):
In .c file:
static void check_private(char *buffer)
{
//some stuff that only needs to be run once
check = NULL; // disable calling this ever again
}
// declare check as pointer to function (pointer to char) returning void
// and intialize to check_private
void (*check)(char*) = check_private;
In corresponding .h file:
extern void (*check)(char*);
As long as you strip debug symbols, and don't store it elsewhere in the program, check pointer will be the only place where address of check_private is stored, so once you overwrite it, it is gone.
NULL is a decent disable value if you know you are running on a normal OS with memory protection, as the UB it will produce will be segfault then, and it is easy to check.
If you don't want segfault, you could set it to point to another function, for example:
static void check_disabled(char *buffer)
{
(void)buffer; // disable compilation warning about unused parameter
abort(); // maybe this
exit(EXIT_FAILURE); // or this
return; // or this for no-op
for(;;); // or even this on some tiny embedded system
}
If this is a library and you want some kind of rudimentary hard protection against invalid use, then instead of a pointer, you could have this exported function:
void check(char *buffer)
{
static int called = 0;
if (!called) {
called = 1;
check_private(buffer);
} else {
// called 2nd time, do something, see above for suggestions
}
}
Again, as long as debug symbols are stripped, only place where address of called variable is stored is inside this function's code, so there is no way to gain access to it. Well, except by invoking UB of somehow guessing its address and using a pointer to modify it, but especially with modern optimizing compilers, this really is UB and not just hack, as there's no guarantee what assembly and data compiler actually produces for this C code.
