10615
HTBPicoCTF 2018 - Core -(Forensic)
|
This program was about to print the flag when it died. Maybe the flag is still in this core file that it dumped? Also available at /problems/core_3_bbdfe8f633bce938028c1339013a4865 on the shell server. |
| A binary and it core dump |
Binary analysis
The main function is pretty trivial, it just calls two functions : load_strings and print_flag.
int main(int argc, const char **argv, const char **envp)
{
load_strings();
print_flag();
return 0;
}
void print_flag()
{
printf("your flag is: picoCTF{%s}\n", strs[1337]);
}
The function print_flag, is just printing the value associated to the address stored at the 1337th position in the variable strs.
So we have to determinate how this buffer is filled, let's analyse the function load_strings.
This code is pretty simple, first we use an unknow seed to seed srand (it is impossible in this case to recover the seed).
In a loop we allocate 0x271 (10Kd) * 0x21 (33d) bytes in the heap then the address returned via malloc is filled thanks to the load_garbage function with 32 hex characters and a null byte.
This address is finally stored in the variable strs which is a pointer on a array of 10000 chars stored in .bss.
But at the offset 1337 of strs the address of the flag is stored, and because of the core dump of this program we can inspect the memory and find the flag !
Analysis the core dump
switch :: ~/CTF/pico2018/core » gdb ./print_flag core -q
Reading symbols from ./print_flag...done.
gdb-peda$ p &strs
$21 = (char *(*)[10000]) 0x804a080 <strs>
gdb-peda$ p 0x804a080 + (4 * 1337)
$22 = 0x804b564
gdb-peda$ x/xw 0x804b564
0x804b564 <strs+5348>: 0x080610f0
gdb-peda$ x/s 0x080610f0
0x80610f0: "8a1f03cbcf407a296fa0bcf149fc5879"
gdb-peda$ p strs[1337]
$23 = 0x80610f0 "8a1f03cbcf407a296fa0bcf149fc5879"
gdb-peda$
- p &strs return the address of strs.
- we calculate the address of the 1337 item. (strs is an array of char pointer, a char pointer, for a x86 binary, is 4 bytes long so we need to go 4 bytes x 1337) at 0x804b564.
- 0x804b564 contains the address returned by malloc so we display it : 0x080610f0.
- and finally 0x080610f0 contains our lovely string : 8a1f03cbcf407a296fa0bcf149fc5879
- (We could have used p to directly display the data but it's funnier like we did ehe)
That's lot of address :|