Last active
September 12, 2015 10:05
-
-
Save pmauduit/78363edb3d50f4faf0d7 to your computer and use it in GitHub Desktop.
func pointer
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
#include <stdio.h> | |
#include <stdlib.h> | |
void sample() { | |
int i = 0; | |
char * test = malloc(10 * sizeof(char)); | |
for (i = 0 ; i < 10 ; i++) { | |
test[i] = 'a'; | |
} | |
test[9] = '\0'; | |
free(test); | |
} | |
int main(void) { | |
void (* sample_ptr) (); | |
sample_ptr = sample; | |
/* | |
* - Launch the program once, get the @ of sample_ptr (does not change across launches) | |
* - Disassemble | |
* - Erase the opcodes situated at the real address of sample in the binary, | |
* by putting an arbitrary string. | |
* - s/%p/%s/ | |
* | |
* => Hopla, changed the meaning of .text portion (code section), replacing it by | |
* arbitrary data. | |
* | |
* Question: Why addresses at decompilation / runtime does not correspond to the hex | |
* offset of the file ? Can it be guessed somehow ? (probably because radare2 is able | |
* to do so). | |
* | |
* @ at runtime seems == offset in the binary + 0x400000 | |
* seems that it is decided at linking time by ld: | |
* http://stackoverflow.com/questions/14314021/why-linux-gnu-linker-chose-address-0x400000 | |
*/ | |
printf("address sym.sample @: %p\n", sample_ptr); | |
return 0; | |
} |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment