shellcoding basic understanding

[dimaash]

Hi everyone.

I've read a lot of the basic tutorials and documentation about shellcoding and buffer overflows. However there are some things that I just cant' picture. First, I will mention what I do understand.
I do understand how to spawn /bin/sh using some C code.
I do understand how to represent that C code in asm.
I do understand how to extract op-codes from that asm code.
I do understand that those op-codes will be the actual shell code.
I do understand that those op-codes will be in a string which we use to overflow vulnerable buffers with.
I do understand that 1 on the method's used is to pad the beginning of our string with nop's, place shell code in a middle and the rest will be the address of our "attack" string.


What I don't understand is how that "attack" string is going to end up in the vulnerable buffer in case if that program's vulnerable buffer is not the one to which we copy argv[ ] (Like in case of those examples in different tutorials). Say if a vulnreable buffer is somewhere in some function and the program just prompts the user for some data. How is it possible to overflow the buffer in that case?. As far as I understand in that case we can't deliver our shellcode via enviorement variable nor via `perl -e 'print "A"x(say 512 for instance)'``printf '\addr2shellcode'`. If i understand correctly this only works for passing stuff to main() before we run it.
And another thing that i can't understand is: say i have guessed or somehow obtained the address of my shellcode somewhere in memory. It is still not in a memory layout of the vulnerable program. Can the vulnreable program access memory which is not in its layout. Or is there something that i missed here?
So these are the basic but i think important things that i can't visualize at the moment. I would appriciate if some one could enlighten me on this.

Thanks in advance.

[dimaash]

shellcoding basic understanding

Hi everyone.

I've read a lot of the basic tutorials and documentation about shellcoding and buffer overflows. However there are some things that I just cant' picture. First, I will mention what I do understand.
I do understand how to spawn /bin/sh using some C code.
I do understand how to represent that C code in asm.
I do understand how to extract op-codes from that asm code.
I do understand that those op-codes will be the actual shell code.
I do understand that those op-codes will be in a string which we use to overflow vulnerable buffers with.
I do understand that 1 on the method's used is to pad the beginning of our string with nop's, place shell code in a middle and the rest will be the address of our "attack" string.


What I don't understand is how that "attack" string is going to end up in the vulnerable buffer in case if that program's vulnerable buffer is not the one to which we copy argv[ ] (Like in case of those examples in different tutorials). Say if a vulnreable buffer is somewhere in some function and the program just prompts the user for some data. How is it possible to overflow the buffer in that case?. As far as I understand in that case we can't deliver our shellcode via enviorement variable nor via `perl -e 'print "A"x(say 512 for instance)'``printf '\addr2shellcode'`. If i understand correctly this only works for passing stuff to main() before we run it.
And another thing that i can't understand is: say i have guessed or somehow obtained the address of my shellcode somewhere in memory. It is still not in a memory layout of the vulnerable program. Can the vulnreable program access memory which is not in its layout. Or is there something that i missed here?
So these are the basic but i think important things that i can't visualize at the moment. I would appriciate if some one could enlighten me on this.

Thanks in advance.

[allentrace]

Basically you are asking how to hack which is against the rules of the forum, you want to open up a command interpreter which is the shell part on whatever system you chose to attack and then you can type in commands like someone authorized on the system or an system administrator. And considering Shellcoding is used hand in hand with buffer overflow vulnerabilities the question leads back to "Teach me how to Hack" which is against the rules as is double posting. Besides I do not think you would understand the assembly language required....or at least preferable.

[dimaash]

Basically you are asking how to hack which is against the rules of the forum.

Alright, sorry. Can you then point me to some more serious example (but working) then this (which is in most of tutorials)

int main(int argc, char *argv[])
{
char buff[512];
if(argc < 2)
{
printf("Usage: %s \n", argv[0]);
exit(0);
}
strcpy(buff, argv[1]);
printf("Your name: %s\n", buff);
return 0;
}

And by the way i have more then enough knowledge of asm, trust me. I've been reconstructing op-codes from electrical signals on the data bus.

[TheCotMan]

First, posting your question in two different threads is a violation of the rules:

5. Spamming, Power posting, and Advertising
...[spamming] also includes posting the same text multiple times in a row...

This is your warning.

Though this is close to a request to hack, it is technical [and specific] enough (IMO) to pass. [Any other mod may disagree with me and /dev/null and/or ban you though.]

Some partial answers related to this:

If there is a buffer overrun potential in a function that is not availble (directly) to the "bad user" then a "back track" from places where that function is called, to examine the variables and data that are passed to this to see if there is a route where data is not fully cleaned and bounds-checkedbefore eventually getting to the function with risk may help to find a way to exploit these "hidden" holes.

Perl's "taint" checking is very nice for helping to limit risk of user supplied data being checked before being passed to functions at risk (DB Lookup for example.)
Though Perl is not the same as C/C++, there is still value in having programmers check and clean variables submitted from untrusted sources.

As for buffer overrun to stack execution, many modern OS have been including code to deny execution of stack-space data. (Non-executable stack.) Additions of other kernel features such as address randomization on load, use of compiler additions like "canaries" with encrypted return address duplicated above the stack pushed return address with decryption before return of the encrypted address for compare with the actual return address to force kernel to force process death, AND the newish support from hardware vendors for flags to restrict use of memory segments (assuming kernel support) seem (to me) to have the happy-color-festival-pf-exploit-mania with buffer overruns to take a backseat to other security holes.

This does not mean "buffer overrun problems are cured" but it does mean they likely won't be as common as they have been.

We have a few threads on the forums where issues like this have been discussed. One example., and then another example where a user quoted a resource and yet another one.

Here is my suggestion:
Search through existing threads, look at the resources they provide and consider keyword searches with google based on what you read.
Many examples of shellcode exist "out there" including some outdated tutorials (only outdated due to changes in compiles since then, and which mostly seem to work with slight modification to OS Security options and addresses used.)

Let's see if any shelcode testers come out to play here.
Be patient, as they don't check the forums every day.

[allentrace]

First, posting your question in two different threads is a violation of the rules:


This is your warning.

Though this is close to a request to hack, it is technical enough (IMO) to pass. [Any other mod may disagree with me and /dev/null and/or ban you though.]

Some partial answers related to this:

Ty Cotman, I read /bin/sh and thought "ohh great" another teach me to question.... Guess I was a little misguided in my criticism I did not read your question through. Guess I will leave it upto the mods next time.

[TheCotMan]

Ty Cotman, I read /bin/sh and thought "ohh great" another teach me to question.... Guess I was a little misguided in my criticism I did not read your question through. Guess I will leave it upto the mods next time.

It is a tough call to make. I initially moved this to /dev/null, then moved it back.

Most of the previous shellcode discussions were not moved to /dev/null and this part of the reason I spent time with this one and moved it back.

Here is an example:
The Hacking through routers? thread (/dev/null) had the potential to be a great discussion, but was worded in such a way as to make it appear (to me) to be asking how to hack through routers. (Perhaps the question in the thread title.) Unlike other threads I move there, it was left open in case people wanted to respond. That is one of a handful of thread I might have moved back if discussion were productive.

Moderating can be tricky.