Complete newbie alert so apologies on what you're about to read.

I've an executable I'm working with to achieve buffer overflow on. This is for an old CTF that has been and gone but I chose it to practice on. I've ran objdump on it and a snippet can be seen below:

 8048821:   e8 ea fc ff ff          call   8048510 <__isoc99_sscanf@plt>  // Gets input???
 8048826:   8b 44 24 78             mov    0x78(%esp),%eax // Moves ??? to %eax
 804882a:   3b 84 24 88 00 00 00    cmp    0x88(%esp),%eax //  Does a comparison?
 8048831:   75 14                   jne    8048847 <close@plt+0x317>  // Jump to 8048847 if it's not equal?
 8048833:   e8 49 fe ff ff          call   8048681 <close@plt+0x151>
 8048838:   a1 50 a0 04 08          mov    0x804a050,%eax
 804883d:   89 04 24                mov    %eax,(%esp)
 8048840:   e8 6b fc ff ff          call   80484b0 <puts@plt>
 8048845:   eb 0d                   jmp    8048854 <close@plt+0x324>
 8048847:   a1 54 a0 04 08          mov    0x804a054,%eax
 804884c:   89 04 24                mov    %eax,(%esp)
 804884f:   e8 5c fc ff ff          call   80484b0 <puts@plt>
 8048854:   b8 00 00 00 00          mov    $0x0,%eax
 8048859:   c9                      leave  
 804885a:   c3                      ret    
 804885b:   66 90                   xchg   %ax,%ax
 804885d:   66 90                   xchg   %ax,%ax
 804885f:   90                      nop
 8048860:   55                      push   %ebp
 8048861:   57                      push   %edi
 8048862:   31 ff                   xor    %edi,%edi
 8048864:   56                      push   %esi
 8048865:   53                      push   %ebx
 8048866:   e8 05 fd ff ff          call   8048570 <close@plt+0x40>
 804886b:   81 c3 95 17 00 00       add    $0x1795,%ebx
 8048871:   83 ec 1c                sub    $0x1c,%esp
 8048874:   8b 6c 24 30             mov    0x30(%esp),%ebp
 8048878:   8d b3 0c ff ff ff       lea    -0xf4(%ebx),%esi
 804887e:   e8 b1 fb ff ff          call   8048434 <read@plt-0x3c>
 8048883:   8d 83 08 ff ff ff       lea    -0xf8(%ebx),%eax
 8048889:   29 c6                   sub    %eax,%esi
 804888b:   c1 fe 02                sar    $0x2,%esi
 804888e:   85 f6                   test   %esi,%esi
 8048890:   74 27                   je     80488b9 <close@plt+0x389>
 8048892:   8d b6 00 00 00 00       lea    0x0(%esi),%esi
 8048898:   8b 44 24 38             mov    0x38(%esp),%eax
 804889c:   89 2c 24                mov    %ebp,(%esp)
 804889f:   89 44 24 08             mov    %eax,0x8(%esp)
 80488a3:   8b 44 24 34             mov    0x34(%esp),%eax
 80488a7:   89 44 24 04             mov    %eax,0x4(%esp)
 80488ab:   ff 94 bb 08 ff ff ff    call   *-0xf8(%ebx,%edi,4)
 80488b2:   83 c7 01                add    $0x1,%edi
 80488b5:   39 f7                   cmp    %esi,%edi
 80488b7:   75 df                   jne    8048898 <close@plt+0x368>
 80488b9:   83 c4 1c                add    $0x1c,%esp
 80488bc:   5b                      pop    %ebx
 80488bd:   5e                      pop    %esi
 80488be:   5f                      pop    %edi
 80488bf:   5d                      pop    %ebp
 80488c0:   c3                      ret    
 80488c1:   eb 0d                   jmp    80488d0 <close@plt+0x3a0>
 80488c3:   90                      nop
 80488c4:   90                      nop
 80488c5:   90                      nop
 80488c6:   90                      nop
 80488c7:   90                      nop
 80488c8:   90                      nop
 80488c9:   90                      nop
 80488ca:   90                      nop
 80488cb:   90                      nop
 80488cc:   90                      nop
 80488cd:   90                      nop
 80488ce:   90                      nop
 80488cf:   90                      nop
 80488d0:   f3 c3                   repz ret 

I don't need an answer (I do!) just some pointers (excuse pun) in the right direction of what's going on

The executable is stripped. Should I read more on it all or is it worth my time diving in?

HEX'd version of the executable I'm working with: http://pastebin.com/cmwgRMGP. I noticed the hex actually had 4 repeated sections, when split out, would run independently also!


  • What exactly are the difficulties you're facing here? – NirIzr Jan 15 '17 at 19:37
  • I'm not sure what's going and any hints to finding an exploit... – pee2pee Jan 15 '17 at 19:37
  • I tried focusing on what I think would be most helpful, instead of what will help you solve this particular unclear challenge. – NirIzr Jan 15 '17 at 20:20

As OP's question is a bit vague and it seems he's more interested in general tips rather than an actual solution, I'm intentionally not focusing on answering the question at hand.

If the vulnerable part is related to the call to __isoc99_sscanf (as suggested by the title), you should really focus on the code preceding the call and specifically, the arguments passed to that function and the function's documentation (it often highlights problematic use cases).

If you're just starting with reverse engineering and vulnerability discovery, I'll list a few general tips and work-process suggestions:

  1. I suggest you try separating the reverse engineering and vulnerability discovery. You should first convert the relevant functions back to a higher level language (C in this case), and only after you get a decent C code (doesn't have to compile), you should move on to figuring out what is the vulnerable part of it. Yes, you really should write C pseudo-code if you're new to vulnerability discovery.
  2. You should use a tool more sophisticated than objdump when reverse engineering. IDA, radare2 are good examples.
  3. Focus on input paths and flows that can be manipulated by the user, make sure you're not reversing code that is not reachable/influenceable by the user.
  4. A good intro into these topics might be trying CTFs for a short while and moving on to reading a walkthrough/solution.
| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.