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.

@Ruhrpottpatriot

Жыл бұрын

You can still do this in Rust, but you need to be explicit about it. This gives the flexibility that is sometimes needed, but also clearly indicates to a maintainer where things could have gone wrong.

@pravargupta6285

Жыл бұрын

Umm, could you write a piece of code depicting it please? I want to see how it works.

@beckaddison5827

Жыл бұрын

I think people are struggling to maintain it because it is "tricky" to begin with - your using the very thing people tell you not to use in often a very platform-specific implementation that can be syntactically terrible to read in order to squeeze in a bit of efficiency - I think it's good that this practice fall by the way side for more semantic approaches to this sort of efficiency gain (like identifying this funky memory magic with keywords that explicate it's unsafety).

@labrat256

Жыл бұрын

@@pravargupta6285 This wasn't written in C and I'm not going to write the language as it'd dox me pretty heavily, but I can explain a simpleish example. I was fixing a Y2K-like bug in a system where the standard OS date-setting executable wouldn't set the date after 2027 (the system call accepted a 7-bit unsigned int, 1900 epoch+127 years) but the OS was otherwise happy with dates beyond this (internally, a 16-bit signed int was used with the absolute year). We didn't have the executable source to correct. The way the OS worked was that all of the OS structures could be navigated to from a pointer in the absolute memory value 0xA. So I wrote a program that ran with kernal-level privileges which, when passed an appropriate date-setting instruction, looked in 0xA, took that pointer to the OS structure (that we called the system block) which further had pointers to other parts of the OS, including the date-time block. So I navigate to the D-T block, get a pointer to the memory location, in absolute memory space, with the year. I have an array declared. I get the absolute pointer for index [0] of this array. I then subtract that pointer from the pointer I have in the D-T block, to get an int that is the difference, in words in absolute memory, between my array and the D-T block. So I use that as an array index to write the year to the OS, bypassing the intended mechanism.

@labrat256

Жыл бұрын

@@beckaddison5827 People will, but it's still something that is out there in the wild. I don't disagree at all with what you've said, it's sometimes necessary but far from desirable. But I see it as a skill along the lines of, say, coding in assembly where it's rarely useful or desirable but it was occasionally necessary and having the skills to understand and maintain it is sometimes necessary. A greenfield project should never be written that way, but a not-insignificant part of SW engineering heritage that we still rely on is built that way.

"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.

@LowLevelLearning

Жыл бұрын

Good point!

@navirc

Жыл бұрын

Also you can get a middle of the road approach by using tooling like static analysis, valgrind and alike! Those catch a bunch of memory bugs.

@yondaime500

Жыл бұрын

You can do all that in Rust, as long as you put it in an unsafe block. The point is that when you write code like that, you have to thoroughly review and test it to make sure it won't crash or allow for exploits, so Rust keeps these code sections small, contained and clearly marked. But it doesn't prevent you from doing anything you need to do with the hardware.

@jonnyso1

Жыл бұрын

Ins't unsafe rust just as free though ? I'm just a beginner with it but what I've like the most about rust so far is that any compromise you make is intentional and obvious. Get controll when you require it and deal with the responsibilities of that only when its required.

@31redorange08

Жыл бұрын

Using C because you feel powerful while writing the code? What?

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.

@rumplstiltztinkerstein

Жыл бұрын

Yes. Unsafe blocks are such a great feature. It gives an option for the developer to access memory however they want when needed. It creates something like a "danger zone", or "do not touch unless you are experienced enough to know what is happening here" zone. I think it makes it easier for junior developers to implement features in low level code.

@kayakMike1000

Жыл бұрын

C plus a decent linter and fixing such warnings results in memory safe. You don't really NEED a whole new language to do this. Just use better static analysis.

@raffimolero64

Жыл бұрын

@@kayakMike1000 the language *is* the static analysis. features like lifetimes and specially dedicated unsafe blocks are pretty much absent in other languages as well.

@SianaGearz

Жыл бұрын

@@kayakMike1000 Static analysis on C has a very limited insight depth and will always have a severely limited insight depth, you can make it work on toy programs comprehensively but it just explodes out of bound as the space that needs to be analysed gets larger. You'll always have leaky, overly permissive C analysis to some degree. You can't even prove aliasing on a C program. The one way you can fight this is a language that leans on the more restrictive side and puts analysis walls that don't need to be traversed, you only need to analyse both sides of the wall separately rather than across the wall. It was a decades long debate whether such a more restrictive language would be a complete menace to actually use, but now such a language exists, and it's fine, it's nice, it covers the usecases of C. It's worth celebrating.

@marcossidoruk8033

Жыл бұрын

Memory safe languages? You mean unicorns. Memory safe languages don't exist. Yes rust has nice statistic analysis and runtime environment but even then you can still Fuck up and in kernel level there is no such thing as a runtime and direct hardware access makes any sense of "memory safety" meaningless. Correct code is memory safe code, there are only languages that help you write correct code but no correct languages.

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.

@what42pizza

Жыл бұрын

I think that's too much of a fact to be considered a hot take lol

@traveller23e

Жыл бұрын

to be fair, C89 and C99 are a lot simpler than some of the more recent versions. Just do be sure your macros are doing what you think they're doing.

@yourmomsboyfriend3337

2 ай бұрын

Dude when I first discovered volatile in C++ it had taken me 15 hours of debugging to figure out that the compiler had completely optimized away my code 😭

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

the problem is between the chair and the screen monitor

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

@LowLevelLearning

Жыл бұрын

C does make for some fun programming experiences.

@williamdrum9899

Жыл бұрын

That's why I love assembly, you can do a lot of sleazy stuff that would make computer science teachers faint at the idea! Like memcpy() entire functions. Good luck doing that in C.

@blastygamez

Жыл бұрын

@@williamdrum9899 i am sure there ways to do it in c like just use inline assembly (x86 :( )

@VojtaJavora

Жыл бұрын

@@williamdrum9899 I did once write a function into a file, read it into a buffer, set the memory to be executable and ran the function in C

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.

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.

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.

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

@LowLevelLearning

Жыл бұрын

Rust is a great language!

@bravefastrabbit770

Жыл бұрын

@@LowLevelLearning Sadly the devs are chomos

@watynecc3309

Жыл бұрын

@@bravefastrabbit770 wtf you mean ?

@RenderingUser

Жыл бұрын

Same

@JayJay-ku8gp

Жыл бұрын

Rust is great and so is C. The learning curve with Rust can be difficult but rewarding

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

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.

@mage3690

Жыл бұрын

IDK who it was, but I watched a while 40 minute video on a security flaw in a core Linux kernel dependable that existed because strings in C are null-terminated arrays, yet the programmer somehow allowed the user to set that null terminating byte. I forget exactly how it went, but by setting that byte to be something else, the terminal would--with a bit of fiddling--run the next command as sudo. It was very well explained, too bad I can't remember the video name.

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.

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.

@Speykious

Жыл бұрын

While it is true that C is very efficient and easy to learn, no amount of tools has prevented codebases like Chromium to erradicate 70% of its bugs, which are related to memory safety. The same is true in Android, especially on the security side of things: in Android 13, the 1.5 million lines of Rust code that they wrote has had *net zero* memory-related CVEs so far, compared to an average of 1 CVE / 1k SLOC in their C++ code. Valgrind, address sanitizers, they can only get you so far with a language that was inherently not designed to be memory-safe in the first place. Besides, lots of companies are already using Rust instead of C and C++ for their codebase. C++ in particular is already being replaced here and there. They definitely are entrenched languages in the IT world, but it's becoming more and more viable to do the risky bet of taking the time to rewrite some C++ codebase in Rust, rather than continue to maintain a C++ code. And even when such a risk is not viable, people are integrating Rust in C++ codebases so that all new code is made in it (that's what Android is doing).

@matyasmarkkovacs8336

Жыл бұрын

@@Speykious Here and there C and C++ can be replaced but not in every cases. For example in game development C++ is still much better choice, for embedded systems C and Assembly are the king. Rust is rust, it's a bit different, for safety-critical tasks it might be better choice, but that's not everything... C and C++ is much more mature language, Rust is still new compared to them and it has much slower compile time and stricter compiler.

@Speykious

Жыл бұрын

@@matyasmarkkovacs8336 Rust definitely has potential in game development, with projects such as Bevy, Fyrox Engine and Macroquad/Miniquad. You're right, C and C++ are "more mature languages", or more precisely they have a way more mature ecosystem that is old and battle-tested, with standards such as Unreal Engine. But that doesn't mean that Rust cannot "replace" C and C++ in these areas: by that I mean, I'm sure that in a few years, Rust is going to be a much more viable choice for game development than today where it is still in its experiment phase. And of course I assume the same is true for embedded development, but I know way less about this field since I'm not really interested in it (yet?). About your last small thing: yeah, Rust has slow compile times, but it also has incremental compilation so generally it's only a problem when you build your huge project for the first time and when you do a release. As for the stricter compiler... That's kind of the whole advantage of Rust in the first place! That's what has prevented Android from having any kind of memory-related CVE in their huge Rust code. That's also part of why I personally love it. xD

@Izaltinodsouza

Жыл бұрын

I want to see more GUI programming in Rust.

Love these videos, just wish I could hear them!

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.

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

@what42pizza

Жыл бұрын

Having null pointers isn't really memory safety, that's just a feature of Go

@shimadabr

Жыл бұрын

You probably had a null object and tried to use it. That's something that happens on most languages (Java, Javascript, C#, Python, etc). One thing that could be mentioned on another video is memory leaks, which is still possible on garbage collected languages, albeit it's rare (involves specific instances of circular references as far as I know).

At least C doesn't have esoteric syntax that looks like somebody tried to write Python but had a stroke.

@matyasmarkkovacs8336

Жыл бұрын

Exactly! That's one of the main reasons why I prefer C/C++. Their syntax is much readable and easier.

@theabyss5647

Жыл бұрын

@@matyasmarkkovacs8336 Rust's syntax is like a fusion of Python, JavaScript and Lua with elements that look like C++. Also introduces concepts that don't exist in other languages. That's very uncomfortable.

This video makes a big leap from leveraging uaf and out of bounds indices to overwriting memory outside of the programs memory space. Memory safety in the above example would be a greater concern for injecting/reading data from the program.

Interesting topic! Thanks for the video!

That's why i love C, it even gives me the chance to make mistakes 🙂

@jonnyso1

Жыл бұрын

Rust doesn't stop you from making mistakes, it just lets you know immediatly.

@zactron1997

Жыл бұрын

I'd rather my mistakes happen at compile time than at 4am when things start breaking in production.

@ccgarciab

Жыл бұрын

Wouldn't you prefer to get educated on why what you did was wrong, rather than going about your life blissfully unaware that there's something wrong?

The reason why industry still and always will use C for years on : 1. C99. 2. Static Code analysis. 3. Memory leak/valgrind/helgrind and super variety tools for sanitizing. If you work in commercial projects you do all at once, static, dynamic analysis, unit tests and component testing. C is super simple in that regard.

@LowLevelLearning

Жыл бұрын

Fair!

@valcron-1000

Жыл бұрын

How is that simple compared to Rust where I only need to run the compiler?

@kuhluhOG

Жыл бұрын

@@valcron-1000 you don't need to rewrite your existing code in Rust and well, a lot of software is maintained for multiple decades if not even longer

@navirc

Жыл бұрын

@@valcron-1000 The rust compiler is doing more or less the same, but it's already set up. How to make that just as simple: Just like rust, configure the build system to run all the tools you need. I have a "template" Makefile that I use on most project, just adding the static analysis tooling there gets.

@stryderx1

Жыл бұрын

@@valcron-1000 Friend. In actual company there is always paid devops or geek who will make 1 command or 1 button function to do all possible checks.

I think its good to have and use Rust for programs that need memory safety to prevent exploits that could create critical damage, but I still prefer to have absolute controll over execution flow and memory management in programs that don't need to be memory safe. Having bugs and playing around with them is fun and actually a good way to learn how to prevent them and also gives me the ability to hack my calculator.

personally i use nim as my main programming language since it gives a nice blend between c and rust in terms of how much the developer is in control and it also has a lot of syntactic sugar packed in it but i can say that when i want to use a more obscure library or something like that, i will turn to rust or even c most of the time to avoid making bindings from scratch (which i still haven't figured out how to do, even in rust)

@Cookiekeks

Жыл бұрын

Both C and Rust give you the same level of freedom, what do you mean?

@luna_no197

Жыл бұрын

@@Cookiekeks rust is sometimes a bit too restrictive with its safety measures (at least for me), while c is so permissive that even with pedantic warnings i still sometimes end up with programs that behave strangely

@Cookiekeks

Жыл бұрын

@@luna_no197 What is still restrictive when using unsafe?

@Cookiekeks

Жыл бұрын

@Peter I do not know anything about this, what is MISRA and AUTOSAR? Also, why does Rust not have a formal specificatio

yes the vec_new() funtion is wrong, the Vec struct instance should be allocated dynamycly on that function. but i am still not sure if this kind of mistake is happenned in production code. well there is still a chance thought.

love your videos

@LowLevelLearning

Жыл бұрын

Thank you :)

@umikaliprivate

Жыл бұрын

But, go is better than rust.

Its not c its you at the end.

you configure neovim??

Its 2023 ... and my company still uses Ada ... don't expect C or C++ to be completely 'replaced'...

Is there any "compiler warpper" which can check your code to see if it has those errors before compiling and give you a warning (not an error beacuse that when you test your idea, you might be ok with having a fast and easy to write code in C even if it won't be memory safe)

@lepidoptera9337

Ай бұрын

No. There isn't. Turing complete languages are just that - Turing complete. You can't even guarantee that a program will terminate unless you remove the ability to express every possible algorithm. The simple fact is this: good programmers write good code in any language and poor programmers write crappy code in every language.

Small nitpick: at 5:00 your code is a bit wrong, your puts takes str directly, which is illegal as dynamically sized types (str itself is _any_ legal utf-8 byte sequence, including zero bytes and 10GB strings) cannot be passed directly to functions, only through a fat pointer like &str. Also a real puts would take a pointer to the first byte of a null-terminated string, e.g. *const c_char or *const i8.

good vid 👍

why is the scanf input "address of index(&index)" and not just "index"

i came here to comment that i will never watch clickbait videos. just came to post this, not watching the vid

I'm so glad I learned C/C++ as my second language, I pity the kids who would return an address to a stack variable. Oh wait, now I remember I definitely have done that at first year at uni and couldn't worked out why it doesn't work.

To be fair you are compiling without warnings on (I wish conpilers would do opt out instead of opt in for this). And the bugs in this code is not bugs any C coder will do, they are just basic C which you learn when you learn the language, just like any other language.

The first time I coded it was with the Warcraft 3 editor. It is moslty pseudocode, however it doesn't have garbage collector, this is specially worry because some variables grow exponentially and could render your game unplayable. The thing is I didn't know anything of this at the time, so when I asked why my dota clone was so slow they showed me a tool to detect memory leaks and it had around 3,000 leaks that I have to fix manually.

1. C and C++ will never go away. 2. Addressing the memory safety issue, pun intended, I noticed you weren’t using any compiler options that may help catch them. Nor were you using any sort of code or memory analysis tools, or project programming guidelines. All serious, safety critical C/C++ project use all of the above and also go through a code certification process.

@erikkonstas

Жыл бұрын

1) You're literally trying to predict the future. 2) Wow, imagine every little change in code triggering a whole certification process, like time and money is inconsumable...

the auto-generated chapter say that "C is not typesafe" instead of not "memory safe" I'm sure that would confuse some beginners who didn't fully watch this

@LowLevelLearning

Жыл бұрын

Should be fixed, thank you for that.

Wait a sec. Hackers don't normally have access to the source code. Only the binary. It doesn't matter if the language is 'safe' if the underlying binary uses pointers to accomplish the task.

@LowLevelLearning

Жыл бұрын

Sure but if the source code is from a safe language, then the binary's implementation of the pointers will also be safe.

@lucidmoses

Жыл бұрын

@@LowLevelLearning But the binary is not safe. It's machine code. It can never be 'safe'. For example, In order to prevent over indexing to an array off a pointer the machine code has to check the index every time. Hackers would have to go out of there wait to include that check.

@georgerogers1166

Жыл бұрын

@@lucidmoses Static analisis can do a ton

@Speykious

Жыл бұрын

Hackers don't modify the binary directly most of the time, except maybe people who crack local software. Try to imagine a hacker talking to some C program on a remote server, not having the permission to do anything else: they don't even have access to the binary. Then exploits like buffer overflows can be fatal to the software, since hackers just need to feed the program some malicious input and they'll be able to get their way into your system by making it execute a function _you_ wrote. So yes, it does matter a lot to have memory safety in regards to security. It's not about making the binary itself safe no matter the modifications you might do to it, it's about making your program secure _at runtime_ so that hackers can't exploit it with malicious input. And it turns out that a lot of these security problems are related to memory safety problems.

@TimeoutMegagameplays

Жыл бұрын

@@lucidmoses Rust does runtime array bound checks.

I agree with all of this, but I’d be very careful with rust. Rust -purports- to be memory safe, and that’s true from the programmer perspective, but not from the hacker perspective. There have been CVEs for overflows and memory corruption in Rust. Maybe it won’t let the programmer mess with memory , but an attacker can still come in because of bad language implementation. We expect more CVEs over time just like what happened to other langs. Still I do agree with the whole thing that C gives us a lot of power and responsibility and that can be a problem if you don’t manage it well. Not gonna stop me from coding segfaults tho. Tee hee.

Rather than throwing the baby out with the bath water (switching to another language), always test user input and always validate returns...

Hopefully someone will put together a Rust vs Ada challenge toward absolute safety...

@matyasmarkkovacs8336

Жыл бұрын

Yeah... At least Ada has a very nice and easy to read syntax, while Rust's right the opposite.

@user-wj8rh9dq4u

Жыл бұрын

@@matyasmarkkovacs8336 Have you ever tried to write a non-trivial program in Ada? It's *exhausting*! At least when writing Rust I don't have to look into the *****FUCKING LANGUAGE SPEC***** because I chose one of three redundant but slightly different ways to pretend to have inheritance instead of another.

@matyasmarkkovacs8336

Жыл бұрын

@@user-wj8rh9dq4u I have seen some complex source codes in Ada, and it's still much more readable than Rust in my opinion. Ada uses keywords wherever it can, instead of symbols.

@ccgarciab

Жыл бұрын

​@@matyasmarkkovacs8336 what do you mean symbols? The only Rust specific symbol I can think of is ', but its impact is minimal.

3:43 bruh yes there are reasons

i just write 87 line of code and got 1000+ direct/indirect memory leaks after X11 and GL binding using C/C++. just try something new for me🙂

Can't you fixed these issues with compiler flags? Also I'm not sure how this applies to C++ since Smart pointers are a thing

@dynfoxx

Жыл бұрын

You would need a new syntaxes and semantics to fix a lot of c/c++ issues. The compiler does not have enough information leading to false positives or lots of missed positives. That being said turn on all the warnings you can and run with sanitizers. They are helpful just not as helpful as Rusts tooling. The issue with C++ is that smart pointers are good but limited. They only provide ownership with allocation. If you are not allocating then they don't work to convey ownership. This is an issue for embedded or performance critical areas that don't want or can't deal with allocation. There are other limiting factors as unique pointer has some overhead vs a raw pointer. Shared pointer is always atomic even when you are not in a threaded scenario. Some times you just want to pass a pointer around and still convey ownership with no overhead. This is what Rust can give you that C/C++ cannot. Some side note issue with c++ smart pointers are nullability. When receiving a smart pointer they can be empty thus a null check is needed for every(safe) use. This makes api's a bit more unlear. A better solution is to use optional with your smart pointer but in c++ this takes up extra room and does not even remove the extra null check. In rust sizeof(&T)==sizeof(optinal) ==sizeof(box) == sizeof(optinal). This allows for no overhead when passing a pointer that can be missing. It also makes it clear when you have to check the pointer for nullability leading to less redundant checks. Hopefully that makes sense

@doomknight233

Жыл бұрын

@@dynfoxx Ah okay thank you for the nice and organized response. I'm still technically new to programming since I started 2 years ago (1 year to experiment learn basics phrases such as IDE and use multiple languages, and another year to understand concepts more such as OOP, learn Linux, and slowly reaching a level of intermediate although I'm still a beginner in various ways). I do not fully understand concepts such as threading, multi-threading, cocurrency, and atomic but I'll look more into them with key things you wrote about Rust. Forgive me but I have a hard time reading Rust syntax so I do not fully understand the code you wrote I just interpreted it as Rust doing the redundant checks for you. With that being said I'll keep what you wrote in-mind and if I ever need to work on things that requires tools that C++ doesn't excel at then I'll think about using Rust for the job.

@dynfoxx

Жыл бұрын

@@doomknight233 Yeah not a problem if you have questions just ask. It takes most people a while to fully understand concepts so take your time. Threading is difficult to wrap your head around at first. People have a lot of different ways to explain so let me know if this makes sense. Think of threads as different people in a podcast or radio show. Each one can do different things but in the end it comes out to one audio stream. When you talk over each other it's unclear what it will sound like. How do you solve this? One way is to only let one person talk at a time, that Is a mutex. Noone can be talking and everyone can just listen, in that case there is no issue. You could have individual microphones for each person, this would be attomics, thread local or something like that. Hopefully that makes sense to why there is a problem. Atomic are a bit hard to explain but think of it as a mutex for small data. Think if box as a unique pointer but otherwise it's basically just the same as c++ for sizeof. & is a pointer to some generic T.

I'd have expected you to talk about sanitizers, but otherwise, good video.

Where's the fun if I can't even have my severe security problems?

I sense HERESY!

C with Rust memory features added with libraries = Crust. Crust with jokes as error responds = Crusty.

the 69 and 420 example hahahah

If you want to convince people to switch to Rust you might want to show an example that any competent C programmer wouldn't spot in a second. Furthermore the examples you showed in this video aren't actually exploitable on a modern system without additional exploits as ASLR would prevent you from performing a ret2libc attack (without at least precomputing the LIBC location and somehow leaking the ASLR offset) and stack canaries are likely to stop your program in its track before you can overwrite the return pointer anyways unless you also somehow manage to leak it.

@LowLevelLearning

Жыл бұрын

I think that's my point. Unfortunately, tons of incompetent C programmers contribute to projects that run the world. The future of languages shouldn't allow the programmer to make memory mistakes. Also despite ASLR, RELRO, PIE binaries, stack canaries, memory corruption exploits are still super common. Maybe C is to blame.

@zaper2904

Жыл бұрын

@@LowLevelLearning Rust has had its own memory exploit CVEs happen and most of the exploits that do happen in that field are actually in C++. fact is high performance high complexity applications are always going to remain in the realm of unsafe and anything outside of that probably shouldn't be written in C/C++ in the first place.

@diadetediotedio6918

Жыл бұрын

@@zaper2904 It makes no sense to stall against security measures in languages like Rust, it goes without saying that there will be CVE's in literally any language that is using insecure code, and that obviously includes Rust, but that doesn't take away from the fact that real-world applications of the language, including in Android itself, resulted in memory bugs happening than more, and that in itself is a positive thing.

@beckaddison5827

Жыл бұрын

I think your comment is proving his point - the fact that all these vulnerabilities might not be exploitable on modern systems speaks to the fact that these mistakes have been made enough times before, by C programmers apparently competent enough to have their software released on modern systems and that software be popular enough to later be exploited. All this additional overhead, ASLR, stack canaries and the like are required to check behind a binary because of the long history of issues caused by C's (and other unsafe programming languages) inherent trust in the programmers ability to program perfectly. What happens if these basic examples were used in a small embedded platform with a stripped back, custom OS that is designed for that specific hardware? How can we be sure it isn't packed in with all the amenities of modern systems to prevent these basic vulnerabilities from being exploited? We can't, and as a result, IoT devices like those I've described have become some of the easiest targets for exploitation. Rust shifts the responsibility of memory safety off of the system and off of the programmer (except for explicitly unsafe code) and places it on the compiler. That way, we can have incompetent Rust programmers and incompetent OS developers be prevented from exposing simple exploits by using a competent compiler.

@zaper2904

Жыл бұрын

​@@diadetediotedio6918 Yeah there have indeed been less memory vulnerabilities in Android after they've switched to safe languages 80% of which were Java and Kotlin lmao. As to why not switch? oh idk maybe Rust not having even remotely the same support as either C/C++ only being able to target a limited number of architectures not having a stable ABI and having a tiny developer population (despite what the internet will tell you) . Rust is a new fad language its tbd if it actually grows up into a usable language like Java or C++ or dies a painful death like Pascal or Ada for now you're better off using industry standard languages and investing in security tools.

Hi all... I am a mobile app developer. Want to learn embedded system but using rust not C. Can any one share a good source to learn the same. Both free and paid. Thanx!

@lepidoptera9337

Ай бұрын

On an embedded system you have to be able to randomly access hardware registers. That's far easier than you think, but you just have to LEARN that skill. You can not expect library developers to take care of everything for you that requires actual LEARNING. And even if you could, you shouldn't because eventually you will be a better coder than those library developers. Most libraries for embedded systems are written by disinterested semiconductor company employees. They are underperforming and buggy. Not to mention that most embedded hardware is buggy and you have to find workarounds for YOUR application.

Let's be honest. C++ is memory safe these days. You just need to understand its basics like object life times and use its smart pointers for dynamic allocations. You also need to turn on most of the major warning options. That's basically it.

@ohwow2074

Жыл бұрын

@@SimonWoodburyForget are you comparing the speed of a GC with smart pointers? Smart pointers are still much more efficient than what a typical GC does. And also in C++ standard library, the only smart pointer that has some cost is the shared_ptr. The unique_ptr and weak_ptr are zero cost which means they're as fast as raw pointers. And there are also atomic implementations of shared ptr like pointers that perform faster than standard library's shared_ptr. So not many problems in that regard.

@ohwow2074

Жыл бұрын

@@SimonWoodburyForget so doesn't rust call any destructors when trying to end the life of an object?

NERD!! lol, I really want to understand this but it's over my head, need less technical explanation. Will return after learning more! Thanks and I'm sure this is extremely useful to anyone who has basic coding skills

@lepidoptera9337

Ай бұрын

No, it isn't. ;-)

But of course Rust is a safe language. How a language that has nothing written in can be unsafe after all? P. S. It's a joke guys. It's not even mine, saw it somewhere, couldn't resist an urge to use it.

@allocator7520

Жыл бұрын

hahahah all noobs program in C with 0 knowledge about how machine code works and then complain boohooo i have memory leak boohooo i cant allocate memory

You're explanation and guidance were very clear, easy to follow - via the incognito mode. However, via the Office app, it is only a free 5-day trial. Am I doing something wrong?

For a videogame, being memory unsafe can be really neat sometimes...

@malcolmx86

Жыл бұрын

True that

@williamdrum9899

Жыл бұрын

It's what gives Missingno its iconic look. Although it was obviously unintentional, the game took some section of ROM and ran it through the sprite decompression algorithm. It's like if you could typecast a word document as a JPEG and get a bunch of noise as an image.

Meh, I think I'll be sticking with C. Thanks though!

Yeah, programming in 'safe' Rust using unsafe Rust and C under the hood.

bet i can do worse

When the people that I was defending tell me that they are replacing me.

I am not a programmer even though i know the fundamentals because i happen to like programming but i am pretty sure that, when any language isn't memory safe it doesn't necessarily mean it's a bad thing, because it's about freedom and accountability, because it gives you the opportunity to f up and learn from it, because if you are programming in a language which allows you to write memory safe code, you will very like never be made aware what makes the code you are writing safe, but that's the trial and error method, of course you can learn to write memory safe code by learning it fundamentally correctly from the begging specifically.

I do see a world where you don't plague my youtube suggestion....

The other thing about writing off into lala land with a pointer in C is that it can create some really screwy bugs. If you had a state machine variable that was located in memory right above your array and you started writing into it at weird times then your state machine starts doing screwy things and you're looking in the wrong place for your bug. I'm probably balder than I should be because of this kind of thing. Having said that, I have 15 years of legacy code at work written in C, C++, C#, Java and javascript. If I tried to get everyone to start using yet another language they'd probably kill me.

@williamdrum9899

Жыл бұрын

I had a similar problem where my joystick logic was causing my Commodore 64 program to crash. As the old saying goes, 6 hours of debugging can save you 15 minutes of reading the documentation. It turns out I was using address $0000 to store the joystick reading, which is also the location of the C64's memory management unit settings.

make a video on lifetime parameters in rust

I tell people who ride bicycles that the most important piece of safety equipment is the thing inside the helmet. Same thing goes here. Your knowledge of a programming language and how it can be unsafe is the most important protection you have against writing unsafe code. No language will protect you from everything. Just as wearing a bicycle helmet isn't going to protect you from a car hitting you at high speed. The dangers are always there. Relying solely on safety equipment to protect you shouldn't be your primary plan. Know what can go wrong. Anticipate what can go wrong. Develop skills and habits that catch or avoid those problems.

@erikkonstas

Жыл бұрын

Your "thing inside a helmet" is infallible...?

the vulnerable code source. i wan't to test my exp :) or idk just a referance

This is why I hate coding in C, why the heck does it compile if it's not gonna work! Runtime errors suck

@williamdrum9899

Жыл бұрын

*cries in assembly*

@allocator7520

Жыл бұрын

because the people that write in C are not supposed to be potatoes with 0 knowledge in computer science if you want "easy" life go with python

@maybeanonymous6846

Жыл бұрын

@@allocator7520 Python is even worse, the error messages don't give info other than it being a traceback

@allocator7520

Жыл бұрын

@@maybeanonymous6846 c:

You're acting like it's hard to fix these faults in it. Data Oriented programming and data validation are two things easy to implement in your coding habits.

@williamdrum9899

Жыл бұрын

I program assembly on retro game consoles as a hobby and I'd argue it's even easier since you usually know in advance how much ram you have from the beginning. A few techniques I've come up with are: * A "dummy" function that immediately returns. This is useful for padding jump tables or loading as an interrupt vector when none is needed, in the event of a spurious interrupt * Using a bitwise AND to constrain an array index to always be in bounds before performing the lookup. * Don't allow bad input to begin with, rather than trying to fix it later. * If you suspect the user may misunderstand what to do, either rephrase it or make what actually happens the same regardless. For example if I ask a user for a file name, rather than just saying "Don't include the file extension" I'll secretly strip it off then append it back. That way, regardless of whether the user enters "MyFile" or "MyFile.txt" the program turns it into "MyFile.txt" before going any further. The user doesn't need to be "correct" about how to do it!

@LinucNerd

Жыл бұрын

If you don't mind, could you explain how DOP and data validation solve the issue of memory safety and bugs?

There you have it. Rust is designed to take away developer freedom by hand holding and babysitting the developer.

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

do the same video but with zig

And thanks again👍

@LowLevelLearning

Жыл бұрын

No problem 👍

RUST is nice but there might be solutions needed which cannot be accomplished in an efficient way with it, for example if you need to write a garbage collector. Anyway, any serious developer should learn C which helps a lot with other programming languages as well..

C created to do anything, so … take care… field mine .

I would love to see Javascript engines of today replaced with Rust versions. Makinb exploits in Javascript less likely would help ward off attacks like malvertising.

@lepidoptera9337

Ай бұрын

How safe Javascript is has nothing to do with Javascript. It depends entirely on your browser. Unless you wrote your own there is NOTHING you can do about that.

I am mostly interested in low level programming, high efficiency projects like renderers etc. Therefore rust doesn't make sense for me because for example using vulkan would require me to use unsafe keyword every 10lines. And I think that for a lot of people that's the case. Also toolchains for programming microcontrollers are not so good as for C. (Here I mostly mean cubeMX for stm32s).

@ccgarciab

Жыл бұрын

That's incorrect. Vulkan bindings for Rust already exist and you can use them safely. The idea of Rust is wrapping necessary unsafe operations in safe abstractions (functions or types) which take care of ensuring correct usage. People have written GPU drivers with Rust to great effect. They had to use unsafe code, ofc, but that didn't hamper their developer experience and instead made it cleaner. You don't get much lower level than a GPU driver.

Sometimes I write in c when I want to punish myself

@LowLevelLearning

Жыл бұрын

same honestly.

i'm gonna make my own version of c that's safer

@LowLevelLearning

Жыл бұрын

*rust has entered the chat*

@williamdrum9899

Жыл бұрын

I was going to make one called C-- bit that already exists... Then I was gonna call it C Flat but that already exists

@williamdrum9899

Жыл бұрын

Just make one where semicolons aren't required at the end of each line

@jhgvvetyjj6589

Жыл бұрын

@@williamdrum9899 You could put semicolons in C in start of the next line or something

Genuine question: is there any reason to learn/write C since Rust exists?

@LowLevelLearning

Жыл бұрын

That’s a great question.

@serginhofromhell666

Жыл бұрын

Yes.

@miguelborges7913

Жыл бұрын

Compiles faster. A lot more compile targets. A lot simpler to work in.

Those mistakes are really dumb and don't depict the problem at all. I swear that if you had an LSP on some of those errors would be marked as such, they are that obvious. The real problem comes with threads and the kind of memory safety issue that works correctly in all conceivably usecase but it has that one insane edgecase that you are only going to get by forcing it that then turns into an exploit.

Rust is pretty neat. I think it's good, overall. C will still exist for shenanigans, but the safety of Rust is really nice. Like you said, there's a lot of stuff that programmers really shouldn't be doing in a normal program, and Rust will prevent entire categories of bugs, just by enforcing some rules at compile time!

When second baby monitor hacking video?

@LowLevelLearning

Жыл бұрын

It's coming :)

we are going to remove the throttle pedal from your car because you can push it too hard if you want to. make programmers skilled, let them be low level, let them use their creativity and teach them how to write safe code using "unsafe" langages.

I was taught C in college because I spent most of my time programming microcontrollers. Of course, I have been out of it for several years now, but one thing I remember being taught was to be extremely careful with what you allow the user to have access to. One of the big ones was to never let the user have direct access to memory. I was taught to take the inputs in first, test them for validity and safety, and then work with them. That anyone would wrote code with direct or dangling memory access just seems, at best, lazy or, at worst, malicious to me.

@erikkonstas

Жыл бұрын

Malicious in what sense? That they're purposefully leaving a backdoor so that they can come back later under a different alias and release their malware for it?

@VTdarkangel

Жыл бұрын

@@erikkonstas that would be one way. Purposely leaving a means of hacking the program.

If you're wondering why C lets you index out of bounds, it's because CPUs are dumb. C knows what type your array is, and how many elements are in it, but your compiled program does not.

@tf9350

Жыл бұрын

Because there are no sanity checks when indexing an array in C

@jhgvvetyjj6589

Жыл бұрын

C array access is literally adding the index to the array pointer and dereferencing it

I'm not a fan of Rust. I don't get why people try to push it to replace C. Personally, C is an amazing language compared to Rust.

LLG! LESS FUCKIN GOOOOO

@LowLevelLearning

Жыл бұрын

GANGSHIT

It is not the code of language being unsafe, it is a programmer being unsafe))

@erikkonstas

Жыл бұрын

Wow, spoken like a true entitled and infallible being...

Self-taught with C / C++. If you're making mistakes with memory, you're not doing your job right, it's simple as that.

@matyasmarkkovacs8336

Жыл бұрын

Well said

With great power comes great responsibility if you bad then go program in python

If memory unsafety wasn't allowed, memory scrapers literally would not exist. It physically would not be possible to see the memory of another program (or even your own for that matter) in extremely useful ways. It's literally how a debugger functions. By peeking into memory that it technically doesn't have access to, but needs to see anyways. Lol.

@williamdrum9899

Жыл бұрын

Laughs in memcpy

Memory safe languages don't stop hackers because most hackers are not looking for memory holes anymore. Dudes. You need to get a life. ;-)

fsanitize=address

Wdym by giving developer too much power? Is this video the reflection of modern society? I am as salty as it is from living trough 2021,2022 and now 20223, you didn't need to shill rust to make me saltier.

Basically C gives you hammer and file to make anything you want but at the same time it allows you to build pistol that explodes in your hand if you spin 3 times

The problem with 'memory safe' languages is they produce code that is often horribly inefficient and promote bad programming practices. For instance, if I've got an indexed field, I need only validate a given index value once. Whereas a 'memory safe' language will generate code to check the value of the index every time it is used. The result is executing code that serves no purpose and the larger program size due to these unnecessary instructions.

@AmeSoftware

Жыл бұрын

You can optimize the code with the compiler. It produce almost exactly the same code, at least with Rust.