Hot answers tagged shellcode
26
Address Space Layout Randomisation (ASLR) is a technology used to help prevent shellcode from being successful. It does this by randomly offsetting the location of modules and certain in-memory structures. Data Execution Prevention (DEP) prevents certain memory sectors, e.g. the stack, from being executed. When combined it becomes exceedingly difficult to ...
15
It is perfectly valid to write shellcode in any language that gets compiled down to machine code instructions. Provided no external libraries that are not linked by the victim program are required for its operation.
However, it is almost never the case that directly compiled code (even from just C) is a valid, injectable shellcode. The most common reason ...
12
The Linux kernel can be viewed as a kind of ultimate shell code, since it is "injected" on a raw machine (which only has the BIOS code at that point) and then provides a lot of functionality. That kernel is written in C.
If you write shell code in C or C++, you will run into trouble with library calls and linking, which are two facets of the same issue.
...
11
To complement @Polynomial's self-answer: DEP can actually be enforced on older x86 machines (which predate the NX bit), but at a price.
The easy but limited way to do DEP on old x86 hardware is to use segment registers. With current operating systems on such systems, addresses are 32-bit values in a flat 4 GB address space, but internally each memory access ...
10
In assembly code, NOP is short for No OPeration. This is most popularly known for x86 chips as 0x90. When a processor loads that instruction, it simply does nothing (at least useful) for the one cycle and then advances the register to the next instruction.
NOPs keep the payload sizes consistent
... by ensuring that any space not used by other code ...
6
If you are stepping through one instruction at a time, and the segfault occurs immediately upon jumping (and not when hitting some potentially broken shellcode at the end of the NOP sled, which could also cause a segfault), and you are certain that the address is correct, points to valid memory and that your NOP sled itself isn't broken, then yes it seems ...
5
It is very unlikely that this would be a viable route to dropping a web shell. The input is probably stored in a database, not in a file, so the interpreter (ASP, PHP, etc) will not process it as source code. A much more likely attack vector is Cross Site Scripting, if the filter is not strict enough.
EDIT to answer 2 points added later:
There is no way ...
4
You do not call functions inside the kernel. The kernel resides in another privilege level; its memory pages are not accessible from normal code. To jump into kernel code, application code performs a system call which entails using a specific doorway which handles the temporary privilege escalation. On a 32-bit x86 system running Linux, this is done with int ...
4
You don't always have to overwrite the return address in order to exploit a stack based buffer overflow (also has a great diagram of the stack layout). With a stack based buffer overflow you can corrupt other variables declared in the local scope of the function which can produce interesting results.
For instance lets say there is an authentication ...
3
Since shellcode is just a raw block of instructions, these tools aren't really suited.
Wat? Executables are just raw blocks of instructions too! No really. Ok, maybe there's bits of data in there for PE/ELF headers or the like, or just plain program data, but the data is the same binary as instructions. To the point sections of executables are labelled ...
3
A stack canary is still a problem, because you cannot control the EIP in a stack based buffer overflow without overwriting the return address (which is above the carny). Further more the function that contained the stack based buffer overflow must return before the corrupted return address becomes the new EIP.
This is not a problem for dangling pointers.
...
3
That's the other way round: you overflow a stack buffer so that you get to overwrite the field with which EIP will be loaded when the function returns.
In usual architectures, the stack grows downwards, so that the "return address" pushed on the stack when the function was called lies a few bytes after the local variables. By overflowing a local buffer, you ...
3
This is not obfuscated code, it is just base64. You can decode it on this site. It is an email containing a flight reservation confirmation. I don't know if it should be publicly available, maybe you should edit your post. You can read more about email encoding here.
3
"Leaky Pointers" or more commonly known as "Dangling Pointers" is useful to create an attack chain to bypass a layered security system.
The idea behind DEP is that you are making regions of memory non-executable, such that shellcode in this area cannot be executed. DEP alone is really easy to bypass, you can just ret-to-lib, and call any function you ...
3
You could begin looking at Symantec: http://www.symantec.com/connect/articles/windows-anti-debug-reference
And there is a question in Stackoverflow about anti-debugging tricks.
2
you can use scdbg with the raw binary shellcode file to get a runtime log of all of the api it uses. Execution is done in the libemu emulation envirnoment. The -d option will create a dump of the memory once finished if it detects any memory modifications (self decoding). The tool also supports locating shellcode start offsets (in case of ROP prefix), and an ...
2
Your memcpy utilization needs a review - please follow:
Your original post:
memcpy(buffer+(sizeof(buffer)-1)/2,shellcode,strlen(shellcode));
For starters, you use buffer without referring to it as a pointer - &buffer
actually, there are some compiler that can handle it, so it's not necessarily what stops you from exploiting the stack.
Now, you try to ...
2
Graphical shells are heavy on the bandwidth, unreasonably complex, and usually unnecessary anyway. "Shell" in an exploitation context usually refers to a text-only shell; bash or sh or zsh for example. Or cmd.exe on windows. The idea is that if you can only run one command, then the one to run is a shell, bind STDIN/STDOUT to a network interface, and then ...
2
How do you start analysis? Do you start at main and spread out from there, or do you have a better method?
Start on exhausting basic analysis (both dynamic and static) - enumerate exports, imports, function use, syscalls, winapi, mutex, dll dependencies, strings and some grepping on that.
Run dynamic analysis on basic sandboxes to come to some, ...
2
This isn't really a security question, it's a low-level architecture one. But to get you started, I'd suggest looking in to what a Segmentation Fault actually represents.
Specifically, it happens on an attempt to read or write on a memory address to which the process does not access. The act of copying one register to another does not access memory, so it ...
2
There's a good way to solve problems (2) and (3) in the described manual binding process but I'm reluctant to publish good and elaborated public tutorial about designing shellcode here on StackExchange. ^_^ So, there's a hint for you of using crcs for (2) and indirect calls for (3) - you seem familiar enough with the manual binding process to deduce the ...
2
SafeSEH is a mechanism that protects stack-based exception handler chains from being overwritten. However, on x64 and Itanium architectures, the exception handlers are table-based (i.e. stored in PDATA) and therefore cannot be overwritten directly by a stack buffer overflow - they're simply not on the stack. As such, SafeSEH is irrelevant to those systems.
2
Yes it's still worth learning. People who are in the early stages of learning exploit development are not going to come out of the gate knowing everything. It's good to use the buffer overflow, that you reference and shell code writing to get ppl's interest piqued and to use as a stepping stone to becoming a professional exploit developer. You never know, ...
2
how does the program know where to jump to if kernel32.dll function addresses are no longer reliable? Does the loader intervene in this process?
The bear has given you the general overview of ASLR. There are a number of points specific to Windows that you need to take away, however:
Actually, DLLs have always had to cope with relocation. They contain ...
1
So far the answers have mentioned only the knowledge part that one gains from learning how to shell code. However, shell code knowledge is required for performing real world attacks and the knowledge is used by the attackers for remaining stealthy as well as for performing a task specific to a particular environment.
In order to give an example, look ...
1
There are several reasons why shellcoding is still interesting, first of all it learns you how the operating system works at low level. Having good understanding of how these things work is still important.
Furthermore if you look at the numbers, bufferoverflow vulnerabilities are still being found, so it's still relevant, albeit these days it might be a ...
1
ASLR involves randomizing the location of objects in memory. For instance, the heap might be moved to a random offset in memory.
If you somehow manage to learn the address of an object in the heap, then you've gained a lot of information about the location of the heap in memory. This may be enough to enable you to predict the location of other objects in ...
1
One method which I love is to use a API Monitoring software. My favorite is the one by Rohitab (google it) . I debug the malware in question and step through while I monitor API calls made on the software. This will provide you with a lot of information on what the malware is doing. For ex: monitoring FileRead and FileWrite calls will let you know what files ...
Only top voted, non community-wiki answers of a minimum length are eligible
