Hi guys just to begin with this is not for malicious purposes but I just find the concept of buffer overflow attacks fascinating,it's low level and really helps you understand programming at a lower level thats one of the reasons why I want to understand it,also I am a cyber security student and am contemplating doing my group project on buffer overflow exploits(if anybody wants proof email me and I will gladly prove I'm a student)
anyway I don't understand how this attack works first off he is using an object called byte but in c++ byte is not a data type I would have used char since it's a byte,but he used byte,I am guessing it is a type from one of the header files he has included and it is used in C,anyway char probably would have worked also right? so then he names the byte array teste and copies the values HELO respectively into each byte,obviously the array is only 24 bytes long but he writes past the 24th byte,but how does this lead to a buffer overlow exploit?
I'm guessing main which is put on to the stack is 24 bytes long not including the ESP and EBP?
if anybody doesn't want to reply in this section( for obvious purposes) please pm me,this isn't essential but I would like to know a little before deciding on my project it will be between this and possibly a keylogger
memory is a big linear vector, conceptually.
the operating system functions are stored in memory, often around location zero actually.
if you took a pointer to location 1, you could, if allowed to do so, start to over-write OS functionality with your own executable statements that do whatever !!!
Modern OS defend against this internally, so you can't do it anymore (you actually could way back when, and it was not uncommon to do so to enhance the OS).
Buffer overflow attacks are similar to the above, they just localize it to a piece of software instead of the OS. If you can find a pointer to critical code in the executable part of the program in memory, and modify it, you can make it do pretty much anything you want. If you can find some place to enter text, for example, and it allows say 50 characters to be input, well... starting at location 51 or 52 or so, you can start to inject statements and those might be executed by the program (or they may be another variable). A bit of trial and error often leads to finding a pointer that you can get at that leads to exectutable areas though, and bam, you can hack from there.
That is how it works in a high level nutshell. The specific code you place in whatever specific location is irrelevant really -- it varies from OS and program to program.
I once hacked notepad against my joystick so all my joystick commands were logged into the open notepad instance as text to 'record' what commands I sent to play back. You can do all kinds of nifty stuff when you get down into the bits and bytes of memory.
c++ and higher level ... I got the process ID info for the notepad instance and sent it false events via the windows OS framework stuff.
assembly helps here... as you learn that, you will see a data segment and a program segment etc for the memory of the program, ... you are targeting the program segment.
Modern OS religiously defend the program segments from being tampered with by intent or accident. It is doable, but as often as not the OS will crash the program intentionally and tell you that you tried to access prohibited memory locations.
so from my research I think there is a lot of misconception when it comes to buffer overflow attacks,many say buffer overflow exploits can be used to gain access to a system I really don't think this is true and if it is I don't understand how it would be possible to bring up a shell or even remote desktop on a remote computer?
from what I can see is it's mainly used to open a shell with root privileges on a system where you don't have root access
just a question regarding the exploits I read this from another thread it's an answer to a post
The stack contains both data and return address when you jump into a subroutine. If you manage to put a specific address on the stack where the return address is, you can force the CPU to jump to a particular memory location, the one where y ou put your own code.
but why do you have to tell it jump to a certain point to execute "your" code which will be shellcode why can't use just place the shell code or malicious code in the function itself?
more secure systems will notice if you jack an actual program onto them, but if you just shove bytes into memory and tell the computer to start execution there, its pretty much a normal thing to tell the computer to do... that is what programs DO when they execute ... so if you can trick a host program into letting you drop the code into memory and run it, that MAY be easier than dropping a virus on the disk and shoving an entry into the 'startup' folder which are monitored more closely by cheap virus software.
Honestly it seems like a lot of trouble to me too, but its been done. A lot of hax are just to prove you can do it more than any practical approach.
its like sql injection -- the program fires up and executes normally until the bad user accesses the system. The bad user (which could be a program/virus/etc, or a remote bot, or a person) feeds the bad code into the input of the program at that point. The bad code does not generally even exist on the target machine until the remote user feeds it into a compromised input.
Changing the return address directs the program to 'go to this memory location and execute here'. Normal function calls, it returns where it stopped to execute a subroutine. This overrules that and sends it to another location. The nature of code is that one would have a 'get user input' subroutine that returns afterwards... and the attack is focused on the user input ... its natural to hit here.