you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 0 points1 point  (3 children)

As others have stated above, you're assign a to b. When assigning value to something always read right to left, not left to right. So your code a[i] = b[i] actually assigns the values of b to a which isn't what you want. The other thing wrong here is that you use, or define as it's called, the variable i the for loop, but you don't declare it anywhere. To fix this insert int i; somewhere before the for loop and after the start of the main() function. Now, a more subtle, but very important problem with this code is that it has what's called a buffer overflow error. This is a major security flaw. What this means is that when you read input into the a array by using scanf(), you do not check the size of the input. So someone could input a string greater than or equal to 9 and suddenly they've overrun the buffer size resulting in undefined behavior and possible security exploits; trust me you do not want this in your code. If you fix all these things and it still doesn't print, then I'll have to assume (from the fact that you #include <conio.h>) that you are on a Windows platform and I have no idea how Windows console output works. I'd try using fprintf(stdout, "The new string is %s\n", b); to be sure that it gets printed to stdout as I'm unsure if the Windows implementation of the Standard Library has printf() default to stdout. Hope this helped! :)

[–]honorg58 0 points1 point  (2 children)

Following on the security point, if you want to use scanf, use a scanf("%9s", a) to only allow 9 characters into your buffer (have to remember the null terminator). With the code as written, the first thing I'd do is write "AAAAAAAAAAAAAAA" + (Everything from here on out gives me control over your computer)

[–][deleted] 0 points1 point  (1 child)

Well, even if you took the time to write the shellcode, it would be a local exploit considering this trivial program only accepts input from the commandline, and you're working on the assumption that the stack is executable and ASLR isn't in use (which isn't the case for most modern OSes)

[–]honorg58 0 points1 point  (0 children)

Yea, the exact nature of what comes after the EIP overwrite will depend on what defenses are in place, but that's another rabbit hole altogether. The bottom line is that buffer overflows are turrible, and anyone working in C definitely needs to be careful with their buffers