New answers tagged

5

Your code is wrong: #include <stdio.h> int main(){ char *buffer[64]; gets(buffer); return 0; } The char *buffer[64] creates an array of pointers to chars. Try again with this: #include <stdio.h> int main(){ char buffer[64]; gets(buffer); return 0; } Run it at IDEone. Actually, I can see quite a few reasons why ...


0

If you are running this from the command line, and you are using the < to feed the shellcode from a file, the shell will immediately terminate when it reaches the end of input. If you want it to remain keyboard interactive, do this: cat shellcode.hex - | ./vulnerable_program The - is stdin (keyboard input in this case), so you can type as you wish ...


0

I am pretty sure when assembly programmers first heard of high-level system programming languages like C they must have thought some classes of the bugs will never be seen again. What happened is we have exactly the same classes of bugs but under different disguises. Typical command/data confusion (which is behind most injection attacks) will occur no ...


0

You are overlooking the fact of the OSI Layers 8, 9 and 10 problem. Technology has been in place to prevent, minimize, and or disrupt most attacks for years. It does not matter how much more technology you create, theorize, adore, if the processes are broken. Most organizations that have been breached had more than sufficient technology to minimize access, ...


3

There is whole world of vulnerabilities out there which don't need buffer overflows or bad crypto. Just have a look at web applications where you have all these web based insecurities like Cross Site Scripting (XSS) or Cross Site Request Forgery (CSRF). Then take a look at code injections like SQL injection or Remote File Inclusion. If this is not enough ...



Top 50 recent answers are included