I fucking hate this low level programming shit. The fucking buffer overflow attacks and the whole understanding of the system architecture just goes over my mind. Can anyone who has found relatively useful resources be kind enough to refer them to me so my stupid mind can understand that better?

I'm doing mostly bare metal programming (no OS) in C.

What's your background, do you come from a higher level language like Java? What is is that you want, understanding a buffer overflow, writing code without buffer overflows or understanding how a buffer overflow attack works when a given piece of code has such a vulnerability?

@Fast-Nop I've worked with mostly c++. The problem I have is with understanding buffer overflows, and the whole memory address structure and how it works. Like I can sort of understand and have an idea of how it works, but if someone asked me to explain it to them I don't have enough understanding to explain it all completely.

@sarc ok, so the bits that are missing is basically the call stack, which the compiler in both C and C++ manages automatically for you and that you normally are not involved with.

I think this here explains that stuff quite well: https://dhavalkapil.com/blogs/...

@Fast-Nop thanks man, his seems descriptive yet simple enough

Why the fuck am I reading it "butter overflow" every time?!

Understanding low-level programming, if really understood well, will make you feel like you have been programming for years, therefore will mentally increase your "experience" which will boost your confidence in choosing a right method/algorithm for sloving most problems.
I wanted to get myself knowing everything about low level programming. Impossible.
I finished a book on AVR programming which gave me a solid and practical foundation for some lower-level programming. And most importantly I felt like I had fun, even though, most of the time, I have been troubleshooting inexplicable things.

So, I decided to gain some academical knowledge and I found the book:

https://apress.com/gp/book/...

I have not yet finished the whole book. But I must recommend you if you, some day, decide to grow in this field. Because of this two books and interest in quantum mechanics I will probably choose my major to be micro/nano -electronics

Didn't expect comment to be this long 😅

@Cyanide perhaps if I read it like that I'd find it less intimidating 😂

@tetris thanks for the link will try to get into it. Considering I'm opting for going towards software development I consider this to be a necessary thing I need to master. To be honest it really scares me but I realise I need to nonetheless get out of my comfort zone and truly grind if I'm to make that change.

📍

Try "The Shellcoders Handbook" to understand numerous attacks on low-level.

Watch some of liveoverflows stuff on YouTube, he can give some good explanations to things!

Maybe also some simplified notes on the call stack would be helpful. When calling a function, the calling function needs to preserve its state. So it will push the CPU registers onto the stack (a LIFO data structure). Also the next address where the program shall continue after the function call (the "return address"). Then also possible function parameters in case they are not put into the CPU registers. And then there's a jump to the called function.

When that function is "over", it will put its results into some registers and then get the return address from the stack, i.e. "pop" that address from the stack into the program counter (which tells the CPU where the current code execution is).

Since the called function has also its local variables on the stack, just like the return address, it can modify the return address. In that case, when the function is over, the code execution continues at that modified address and not at the place where the function had been called.

Besides stack overflow attacks, this is also the basis how to implement simple multitasking - the "called" function is in fact the timer interrupt, and if this modifies the return address plus of course some other parameters, then execution will continue in another thread, not in the one that had been running when the timer interrupt started.

But back to the stack overflow - imagine that you don't enter a name or so in a string array as the programmer intended, but binary data that happen to be executable CPU instructions. Imagine also that you overwrite the return address so that when it gets loaded after the function end, it jumps right into these binary data that you had put into the entered string. Bamm, your string suddenly gets executed as code! Very similar to an SQL injection when input escaping is not done properly.

That is possible because most real machines these days are von-Neumann architecture (see WP) that doesn't discern between data memory and code memory. It gets worked around by the "no execute" bit that software can set e.g. for the stack memory, in which case that trick doesn't work anymore.

This is also the point behind the address layout randomisation in Windows and Linux that makes it difficult to predict the address of your string.

Tanenbaum books will do