how can memory safe code STOP HACKERS?

Hmm, as an 'old school' programmer, we used to (sometimes do) use such memory unsafety as a feature, not as a bug (e.g. following arbitrary pointers that the engineer knows about to get a desired value, then calculating the offset between the desired location and an array under your control, then addressing that location using an array index that's out of bounds of the original declared intent). We did this for efficiency and speed at a time when memory and CPU resources were massively more constrained than they are. I'm kind of glad that such acts are dying out, but there's a twinge of nostalgia and a worry that future SW engineers will come across such code and not be able to understand its function and thus, struggle to maintain it.

"The author of this code managed to pack 7 bugs into it" That would sound like me, but I don't program in C/C++.

Nice video! I believe there's another point to be considered; safety versus freedom. Specially in C, you are absolutely free as programmer, you can freely read and write to memory, reinterpret it, execute memory as code, do whatever. That's a powerful feeling and gives you a sense of control over the hardware. I do think safety is extremely important and the main problem in C, but I think that's why both Rust and C have their places.

I really like that you emphasized the last part "Memory Safe != Memory Secure" since I hear many times that unsafe code is insecure code. But the same could be true with safe code if not implemented properly as well. Although, I believe that memory safe languages can help lessen the time to fix memory related bugs or security issues.

3:45 That's quite the hot take, and I'd have to agree. They don't call C "portable assembly" for nothing. Whether intended or not, it assumes the programmer understands at least one assembly language and computer architecture in general, without giving you the ability to micromanage it. Hell, even I understand assembly and still find C difficult to use. If I have to interact directly with hardware ports I find assembly much easier to write. None of that *(volatile unsigned int*) mumbo jumbo.

I'd be really cool to see how you would take control of the system using this code if you could also set the point values. Exploiting something like this is something that I hear a lot about, but nobody really ever shows an example of it in action to drive the point home and show how this stuff actually works.

It's really important to consider these things. Your vids are much appreciated

At work I've used mostly Rust but also C, I think my C code is better as a result of being scolded by the rust compiler over and over again.

Any chance on you creating a course or series on how to write C programs securely ?

I like unsafe memory because i like jailbreak exploits and i love the c programming language (not only for that).

Hey, I just want to say I love these videos as I'm learning reverse engineering. I've seen a few similar bug walkthroughs on your channel but it helps to have it revised a few times.

I actually never had to debug a rust program i wrote using gdb or something similar! At most some println! macros where all i needed to find semantic issues in my program.

Could you please talk about memory safety in other languajes like go or python where we don't really have control of it? Recently i got a null pointer de-reference error in go, and was really hard to debug

things I did and still do in C: detours: replacing opcodes behind function pointers with relative jumps to hook functions. this allows me to interject flow for a moment to fix upstream bugs in a video game server. direct access: writing and reading from bus bound hardware interfaces. other stuff too.

Well, everybody who knows C is aware that C is unsafe, but it's also very efficient and easy to learn. And there are tools like Valgrind which helps you to prevent memory leaks, segfaults, etc. C/C++ is so entrenched in the IT world, that I highly doubt it will be replaced in the near future by something like Rust.

this only makes sense to me now because I started learning Rust (started out with Python 😪), thanks for this demo with C!

There are many footguns in programming, but memory safety is easily the foot-BFG9000. I'll go out on a limb and say most exploit chains are going to take advantage of memory unsoundness in some form, unless you're lucky (or really determined) to find a chain of logic errors to get you where you want to go.

Go check out Brilliant and get a 30 day premium free trial! www.brilliant.org/LowLevelLearning

the problem is between the chair and the screen monitor

Love these videos, just wish I could hear them!