I have been conducting some minor research into the various forms of exploitation, such as buffer overflows and similar.
Most tutorials seem to focus on executing shellcode, that is code which executes a shell. I was wondering if the cause of this is because of limited space available, otherwise why not execute an entire payload?
On average, how many vulnerabilities provide enough 'space' to execute a payload, such as a trojan, instead of some small shellcode?
Shellcode is actually a generic term for "payload the executes a program"; it's named that because historically the program in question was usually a shell, but it doesn't have to be (and these days, it would usually be some form of reverse shell or other backdoor that connects out to the attacker, since the attacked machine is usually a server that the attacker can't necessarily directly connect to).
Shellcode is used partially because it tends to be relatively short, and that does matter sometimes - for example, if you're exploiting a buffer overflow due to an off-by-one error, your entire payload has to fit in the original buffer size and that might not be very big - and partially because it's the easiest way to gain ongoing arbitrary code execution. Generally when an attacker achieves code execution, they don't want to just take one action; they want to be able to take unlimited actions, in real time, interactively. Repeatedly exploiting the same vector might work for that, but a reverse shell or backdoor agent that allows persistent control is more convenient and also (depending on the original exploit) possibly more useful (e.g. maybe the original exploit doesn't give a way to see the output of whatever code you run). Additionally, if you have a shell (or other tool for running additional code) you can install do / anything else you want (though it probably wouldn't be a Trojan, since that refers to a specific way of getting malware onto a machine which is entirely irrelevant here).
A maximum payload size may (or may not, in any practical sense) exist for any given exploit, but there's no general answer to your question. One thing to note, though, is that the exploit and the payload don't have to be anywhere near one another in memory, nor do they need to be input at the same time. One approach is a "heap spray" where the attacker fills as much of memory as possible with copies of payload (e.g. by uploading a bunch of data to a server, all of which will at least temporarily live in memory somewhere) and then the payload can be tiny - just change a single address - such that the stack pointer or instruction pointer or whatever ends up within the heap spray at a suitable offset. Usually this attack is somewhat random in whether it succeeds or fails - maybe the address you picked isn't actually somewhere the vulnerable program put your heap spray, or maybe the offset within the spray is wrong - but it works often enough. There are ways you can make it more reliable too, such as doing a huge heap spray consisting mostly of no-ops, with the actual payload at the end; assuming you can control the instruction pointer and the sprayed addresses are executable, then all you need to do is get the IP somewhere into the giant "nop sled" and "slide" your way down into the payload.
The maximum payload size depends on the next factors:
In general shellcodes are really small, some hundreds bytes, so from my point of view basically there is no limitation in terms of functionality that you can put on a shellcode
