First Time Writing a BoF Exploit (Stuck)

[BigMac]

Metasploit Framework - /modules/exploits/windows/ftp/3cdaemon_ftp_user.rb - Metasploit Redmine Interface

here is the source to the 3com user exploit

[oib111]

I'm not trying the USER exploit, I'm trying a exploit on the MKD command. I''ll look in ntdll, but I'm not sure how to search for a sequence of commands in Olly, especially something like POP POP RET where the things being popped don't exactly matter and it's more like a wildcard type search

[trojanrs]

You can use msfpescan -p [TARGET], the program will search for POP POP RETs for you and show the addresses in the screen. =)

[oib111]

I did that before, it didn't get any that didn't start with 0x00. I just went into the Executable Modules list in Olly, found ntdll and searched for pop edi and pop esi neither of which helped so I just searched for ret and found a POP POP RET that started with 0x77.

[lupin]

Originally Posted by oib111

I tested it and if I overwrite EIP with 0x42424242 it does the same thing. But if I remove the the jump it works...?

Is it the \xeb character or the \x0a character in your jump sequence thats causing the problem? My guess is that its the \x0a - (check its ASCII value for a clue as to why it would be causing a problem)

Originally Posted by oib111

I did that before, it didn't get any that didn't start with 0x00. I just went into the Executable Modules list in Olly, found ntdll and searched for pop edi and pop esi neither of which helped so I just searched for ret and found a POP POP RET that started with 0x77.

Use msfpescan to search for the pop, pop, ret, find the exact sequence of commands from that file (e.g. pop esi, pop ecx, ret) then search for those using ollydbg to get a relative address for the command. If its for an SEH overwrite, use the SafeSEH plugin in Olly to find dlls with SEH disabled (and don't use an address within the main program itself).

[oib111]

Ah, a new line feed. How do I get around this, just jump a little farther? Also, I believe I asked this question in the thread, but it went unanswered, how do I know which characters I can't use in an exploit?

[lupin]

Originally Posted by oib111

Ah, a new line feed. How do I get around this, just jump a little farther?

Yep. Yes, you get around it by jumping a little further, or you could move your jump instruction two places forward and have the two padding NOPs after it.

Originally Posted by oib111

Also, I believe I asked this question in the thread, but it went unanswered, how do I know which characters I can't use in an exploit?

You'll find out by trial and error. When you feed something into a buffer that stops your program from crashing in the same way, its usually because of a restricted character.

You can find out which character/s is/are bad by the process of elimination - feed in bits of your buffer at a time with other known good characters as padding - and see when the problem starts. You can also try and examine the contents of memory after feeding your buffer in, but this method isnt always that reliable (depending on the bad character its not always obvious what has caused your buffer to get mangled).

[oib111]

Now, if the problem persists, it is possible that 0xEB is a bad character, right?

[Lincoln]

SHORT Jump Instructions

[oib111]

Thanks for the link. Also, I was doing some investigating and I followed the third address on the stack (the one that points back into my buffer) in the stack instead of in the dump and I got this:

0294FBC0   0FEB9090  Pointer to next SEH record
0294FBC4   42424242  SE handler

I don't know much about SEH, but I feel like that 0x0feb9090 as the pointer to the next SEH record is causing some problems.