I'm taking the liberty to lock this, as opposed to other methods.
hadi: You don't appear skilled enough to do this and your question is unanswerable. You ask us to help inject some shellcode (but in hex?) into some code that's obviously not vulnerable as far as I see, and with gdb? I have no idea what you are trying to do. What you are asking appears malicious and raises ethical questions whether we should help you (on the other hand, if you can gdb attach to a process, you are already on the other side of the airtight hatchway). You appear to have solved the first part of your problem by using mysterious shell code and gdb, now you need help solving the second impossible part.
There is however value in understanding actual attacks in depth and discussing them, this is not bad at all. That doesn't seem to be point of this topic here, or am I misunderstanding you?
A real attack takes advantage of a lot of specifics about a program, the architecture, the ABI, the standard library and the compiler. You need to supply some of these details if you want help doing an attack. Not all code is attackable, such code is called secure. You can however determine whether code is exploitable/malfunctioning easily, making an actual attack is much harder. For instance:
Code: Select all
void vulnerable()
{
char buffer[16];
gets(buffer);
}
This function is vulnerable if stdin contains a line longer than 16 characters including the NUL byte. This is often rather exploitable as stdin is rarely fully controlled. If we assume something like a naive i386 operating system, you'll find the return pointer just after the buffer on the stack. You can fill the buffer with malicious instructions that doesn't contain NUL bytes or newline bytes. You can then guess the stack location and make the return pointer point to the buffer. If you do that, then suddenly the program is running your instructions resulting in remote code execution. If you are clever, you can make the process execve a shell and if you control stdin, you must got shell access to that user.
Of course, this attack is seriously mitigated on any decent operating system. For instance, the operating system could enforce a W^X policy (a page cannot be executable and writeable). This makes that naive impossible. You then have to make the return pointer point to existing code in the process (return to libc attack). This can be mitigated again by employing address space randomization that makes it very hard to guess the right addresses, but you might get it right if you try enough times. This particular attack can be made even harder if the compiler uses stack smash protection where a magic value is placed on the stack, if you corrupt that, then the program aborts. Of course, you could be lucky and guess that as well. Even better operating systems don't even have the gets function in the first place, but it could happen in many other cases, such as bad strcpy use.
This is why actually exploiting a vulnerability requires knowing a lot of specifics about the program. Your question was too simple and wasn't answerable. Additionally, you didn't know enough basic things about this topic, this is not the best forum for you to use. I'm very much willing to discuss this seriously, but you should give a more suitable forum and read the GDB documentation.
Edit: Looking around, I find
this that might be of interest.
