Shellcode?
Shellcode?
I have googled for it, but i still don' really get it =P
1: What is shellcode?
2: Where do people get it from?
3: How do they know that it is right? (that it means the commands that they are after)
4: How does it work?, i know it is used in payloads and such, but how does it execute? blablabla etc.
Tell me this and me love you long time <3
1: What is shellcode?
2: Where do people get it from?
3: How do they know that it is right? (that it means the commands that they are after)
4: How does it work?, i know it is used in payloads and such, but how does it execute? blablabla etc.
Tell me this and me love you long time <3
"The best place to hide a tree, is in a forest"
- FrankB
- Ph. D. in Sucko'logics
- Posts: 315
- Joined: 06 Mar 2006, 17:00
- 18
- Location: Belgistahn
- Contact:
Re: Shellcode?
I don't want to explain THAT, no way. I need B_Brain's permission firstneo130 wrote:I have googled for it, but i still don' really get it =P
1: What is shellcode?
For you, at the moment, consider it as pure evil and certainly a thing not to try at home .
neo130 wrote: 2: Where do people get it from?
From Hell
Because they know what system the target is running and they eventually have discovered how the stack flow, the system threading/paging and memory allocation is organised.neo130 wrote: 3: How do they know that it is right? (that it means the commands that they are after)
There is plenty of documentation about that online. If i give an explanation on top of it, it will get you confused.neo130 wrote: 4: How does it work?, i know it is used in payloads and such, but how does it execute? blablabla etc.
Two keywords though : buffer overflow
[/quote]
- floodhound2
- ∑lectronic counselor
- Posts: 2117
- Joined: 03 Sep 2006, 16:00
- 17
- Location: 127.0.0.1
- Contact:
-
- cyber messiah
- Posts: 1201
- Joined: 30 Apr 2006, 16:00
- 17
- Location: 127.0.0.1
shellcode is an assembly program injected into a buffer which is caused to overflow, so the basic concept is like this....
there are arrays and they have a declared size, so when we tell arrays to hold more data than it can, things get messed up. This is buffer overflow
So a buffer overflow allows us to change the return address of a function.
In this way we can change the flow of execution of the program. To explain how that goes on i need to tell you everything about stacks, how they are implemented,the stack pointer, frame pointer, local base pointer etc.
So we place a code when we overflow buffer and that code returns the address within the address space usually in that bufffer(array) to avoid segmentation violation.. That code is executed and it spawns a shell and once you pwn a shell you are the king!!! lol
here's an example of code injected in that buffer...
(To mab:this is what you were asking that day)
And all this is REAL evil...
As frank said this is actually much complicated and requires you to have a very good understanding and accurate analysis... but as i always say who said hacking was easy?
This is something which script kiddies dont even dream of doing..
there are arrays and they have a declared size, so when we tell arrays to hold more data than it can, things get messed up. This is buffer overflow
So a buffer overflow allows us to change the return address of a function.
In this way we can change the flow of execution of the program. To explain how that goes on i need to tell you everything about stacks, how they are implemented,the stack pointer, frame pointer, local base pointer etc.
So we place a code when we overflow buffer and that code returns the address within the address space usually in that bufffer(array) to avoid segmentation violation.. That code is executed and it spawns a shell and once you pwn a shell you are the king!!! lol
here's an example of code injected in that buffer...
Code: Select all
char shellcode[] =
"\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b"
"\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd"
"\x80\xe8\xdc\xff\xff\xff/bin/sh";
And all this is REAL evil...
As frank said this is actually much complicated and requires you to have a very good understanding and accurate analysis... but as i always say who said hacking was easy?
This is something which script kiddies dont even dream of doing..
Now we're talking some real shit, finally suck-o got evil..lol..bad_brain wrote:permission given
- FrankB
- Ph. D. in Sucko'logics
- Posts: 315
- Joined: 06 Mar 2006, 17:00
- 18
- Location: Belgistahn
- Contact:
Very concise and good explanation, opcode !
I'l wait for eventual feedback from others to give more detailed info for anywone who wants it.
Also folks, things are not easy as pseudo_opcode stated above !
Shellcode for one architecture does not work for the other. The syscall of system processes is "randomised" in most modern systems .. except : UNIX/Linux.
All those security packs from Microsoft also help to have the adressing of the stack on a "random offset" , on daily/weekly patched Windows systems, it is therefor not easy to overflow the buffer of a thread or process started by a function, a routine in an executable or adressed by a DLL because the exploit code misses its target ( still creating a lot of damage though..)
That's why the primary target of worms resulting out of bufferoverflows aim at "LoadLibrary" and surely "GetProcAddress" that are always situated at an address in Kernel32.dll . - that's also why "shellcoding" is not discrete at all !
From there on, al the privileges Kernel32.dll has, becomes the one of the exploiter, and those privileges are at the highest in Windows.
On "tuned" Linux systems, the call to the assembler is even forbidden by the shell itself.
Buffer overflows are origialy coded to obtain a shell on a remote/local machine, that is true , although nowadays, "successful" shellcode and variants like injection code is such evil that by overflowing buffers and storing pieces of code here and there it mimics native processes and makes it do what it is coded to do : ex. Winword.exe would start makig TCP/IP connections and send compromising data over the Net, but to the system, it is plain old Winword.exe .. yes you got it : a Trojan or Virus ( when shellcode is mostly kind of 'polymorphic' and stores its data and passes its arguments and variables on victim processes ( the 'next', or 'previous' from an overflowed process' buffer ) : the native system doesn't notice a thing, it will only have some bad turns and strange exit codes.. until you download that new released patch from Symantec
I could go on and on and on about this but i have not very much time.
If there are questions, be precise.
Thanks and see you later.
I'l wait for eventual feedback from others to give more detailed info for anywone who wants it.
That's why i didn't want to do it at firstpseudo_opcode wrote: To explain how that goes on i need to tell you everything about stacks, how they are implemented,the stack pointer, frame pointer, local base pointer etc.
Also folks, things are not easy as pseudo_opcode stated above !
Shellcode for one architecture does not work for the other. The syscall of system processes is "randomised" in most modern systems .. except : UNIX/Linux.
All those security packs from Microsoft also help to have the adressing of the stack on a "random offset" , on daily/weekly patched Windows systems, it is therefor not easy to overflow the buffer of a thread or process started by a function, a routine in an executable or adressed by a DLL because the exploit code misses its target ( still creating a lot of damage though..)
That's why the primary target of worms resulting out of bufferoverflows aim at "LoadLibrary" and surely "GetProcAddress" that are always situated at an address in Kernel32.dll . - that's also why "shellcoding" is not discrete at all !
From there on, al the privileges Kernel32.dll has, becomes the one of the exploiter, and those privileges are at the highest in Windows.
On "tuned" Linux systems, the call to the assembler is even forbidden by the shell itself.
Buffer overflows are origialy coded to obtain a shell on a remote/local machine, that is true , although nowadays, "successful" shellcode and variants like injection code is such evil that by overflowing buffers and storing pieces of code here and there it mimics native processes and makes it do what it is coded to do : ex. Winword.exe would start makig TCP/IP connections and send compromising data over the Net, but to the system, it is plain old Winword.exe .. yes you got it : a Trojan or Virus ( when shellcode is mostly kind of 'polymorphic' and stores its data and passes its arguments and variables on victim processes ( the 'next', or 'previous' from an overflowed process' buffer ) : the native system doesn't notice a thing, it will only have some bad turns and strange exit codes.. until you download that new released patch from Symantec
I could go on and on and on about this but i have not very much time.
If there are questions, be precise.
Thanks and see you later.
Last edited by FrankB on 05 Mar 2007, 11:46, edited 1 time in total.
Thanks for the answers! ^^
another question, where can i find shellcode? i mean the shellcode like the ones that i see in exploits...where do they come from? =P i mean the programmer must have gotten it from somewhere, could you give me an example of where to find it so that i can see a "living" example for myself? ^^
oh, and any kind of tutorial on how to dig deeper in to the subject "like analyzing and getting it blablabla etc" would be appreciated
Thanks once again
another question, where can i find shellcode? i mean the shellcode like the ones that i see in exploits...where do they come from? =P i mean the programmer must have gotten it from somewhere, could you give me an example of where to find it so that i can see a "living" example for myself? ^^
oh, and any kind of tutorial on how to dig deeper in to the subject "like analyzing and getting it blablabla etc" would be appreciated
Thanks once again
"The best place to hide a tree, is in a forest"
FrankB wrote:See, that's why i didn't want to reply at first....neo130 wrote:Thanks for the answers! ^^
another question, where can i find shellcode?
Do NOT try this at home unless you know whet you are doing !
Well i am asking because i don't know and i think it is a interesting subject
"The best place to hide a tree, is in a forest"
- bad_brain
- Site Owner
- Posts: 11636
- Joined: 06 Apr 2005, 16:00
- 19
- Location: In your eye floaters.
- Contact:
yep, this is nothing you can learn by the good old try&error-method because it requires a deeper understanding of low-level programming. if you are really interested in this topic I recommend to read the The Shellcoder's Handbook, it's THE classic....be warned, it's not a picknick to read it, but still very interesting...
bad_brain wrote:yep, this is nothing you can learn by the good old try&error-method because it requires a deeper understanding of low-level programming. if you are really interested in this topic I recommend to read the The Shellcoder's Handbook, it's THE classic....be warned, it's not a picknick to read it, but still very interesting...
oki =P , learning Assembly atm in school...would that help any? =p
because i just noticed the row "shellcode is an assembly program injected into a buffer" which i somehow missed before
"The best place to hide a tree, is in a forest"
-
- cyber messiah
- Posts: 1201
- Joined: 30 Apr 2006, 16:00
- 17
- Location: 127.0.0.1
ok here's very nice tutorial for your reference since you are more than interested
pseudo_opcode wrote:ok here's very nice tutorial for your reference since you are more than interested
oh!, thanks!
"The best place to hide a tree, is in a forest"