coding in c until my program is unsafe
ฝัง
- เผยแพร่เมื่อ 9 เม.ย. 2022
- C Programming isn't all it's cracked up to be boys and girls.
IT TAKES GUTS. GRIT. DETERMINATION. SELF HATE. LUST?
🏫 COURSES 🏫 Check out my C Programming courses at lowlevel.academy
🙌 SUPPORT THE CHANNEL 🙌 Become a Low Level Associate and support the channel at / lowlevellearning
Why Are Switch Statements so HECKIN fast? • why are switch stateme...
Why Do Header Files Exist? • why do header files ev...
How Does Return Work? • do you know how "retur...
🔥 SOCIALS 🔥
Low Level Merch!: www.linktr.ee/lowlevellearning
Follow me on Twitter: / lowlevellearni1
Follow me on Twitch: / lowlevellearning
Join me on Discord!: / discord - บันเทิง
🔥Want to learn to write SAFE C?🔥 Check out my course at lowlevel.academy
Ok
Safe C is such an oxymoron, but I’m here for it.
Safe? That doesn’t sound as fun :3
👌🏼
Safe C??? That isn't a thing.
"Read a string from the user"
"Make the code completely safe"
Ah yes, a classic impossible task
Reading an exact amount of characters and flushing the buffer: hello
**You need to process it more**
Reading an exact amount of characters and flushing the buffer: goodbye
It's not impossible. (The womp rats in Beggar's Canyon are not much bigger.)
@@davidwuhrer6704 until you meet Unicode
What about in Python?
@@eldrago19 We don't talk about Python. We want low-level learning, but Python is awesome.
just saying "C" and "strings" in one sentence is enough to make me sweat
Facts
literally
Better than using "assembly" and "strings" in same sentence
or "assembly" and "floating point"
@@mdev790 What's bad about that?
@@thev01d85 idk about floating point because x86 has special instructions for floats, but strings in assembly are just char arrays
"there's gonna be 3 characters so gonna create 3 rooms for it"
null terminator: bonjor
There a lot more to it than missing the null terminator, this is a classic buffer overflow
I really like the fact that the null terminator is french 😁🤣
It's a mistake no professional would ever make, which is why there has never been a buffer overflow in professional C programs
@@TheStuartstardust incorrectly spelled at that.
Makes it better though
facts right here
C assignment: "Read a string from the user"
Me, shouting at the screen: "IT'S A TRAP"
They requested the hardest thing to do in C :[ So mean!
All input is bad input
I'm new too, why is this unsafe?
@@vfryhn2
"Dog" is 4 character but he type "char buff[3]" and "strcpy(buff, argv[1]);" has Overflow.
@@atduyar i thought it's for storing "cat" and "dog"
real c programmer:
There’s gonna be a string of length 5. I’m going to allocate 2000 bytes on the stack for this
2000 bytes of text plus a null terminator say hello.
Aha, just to be safe.
nah, 0xFF would sound more professional
@@martymarty8137 it depends on how the flags are set on the specific platform.
i feel called out
Why the program was not safe:
1. He did not check if argc was equal to 0, 1, or any other number.
2. He did not terminate the program when outside of parameters e.g. if argc > 2, exit program.
3. He used strcpy, which is considered unsafe as it may be used in buffer overflow attacks. Use strncpy instead.
Probably missed something.
Thanks
Yeah, reason 4: he was coding in c
(Edit: Unless this video is using C99 or later, which implicitly inserts a `return 0;` at the very end of main and only main,) no `return 0;` at the end of `int main` either; though whether this results in an unsafe program or no program at all depends on whether the compiler is configured to treat "control reaches end of non-void function" as a warning or error, respectively.
I'm only a JS scrub, but isn't there supposed to be room for null terminator?
@@FaridAbbasbayli I also find the rules around null termination to be unclear. People often recommend adding null termination, but rarely do you ever see people do it in practice nor does it seem like it's always required
Don't forget to reference your dereference in the pointer to a pointer to determine the number of bits per byte in a parallel universe where we are glad that we have pass by reference.
True dat
Ong
Passing by reference? Impossible. Let's pass by address.
You also have to make sure you take into account your QPU alignment making sure you're on a multiple of 4 before returning to walkable terrain
just read CHAR_BIT to get the number of bits in a byte
That escalated quickly.
That escalated faster than russian tanks in a minefield
That escalated faster than that one austrian artist in military ranks
I’m kinda clueless can someone explain
@@thebus3181 as an intermediate programmer i think the issue is the possibility that the array could be empty, so he would be using a null object throughout his code.
basically he needs to do a presence check (a type of data validation) so it'll only run if there is something in the array.
@@TetyLike3 thanks
Programming in C is like holding a gun, except that it's legal in England.
idk even though i live there
i feel like this joke is too high iq for me
cleaning a loaded gun pointed at your foot.
the reply count is cursed
and the gun is aimed at yourself
This program wasn't unsafe at this point, because without a semicolon it could not be compiled.
The computer powered down right as he pressed the semicolon key. Because at that point the code would compile, and was considered unsafe. We just didn't see the semicolon be added as the GPU was too slow to handle it.
@@sctjkc01 it should have powered down instantly when he didnt check argc
@@bobuccman1424 ...which would imply that an empty Main block would be inherently unsafe.
@@sctjkc01 Are you going to sit there and tell me it isn't lol
@@garrettb2663 yes
FYI: Nothing wrong with just looking at argv directly, you're only reading it after all so copying it to a buffer on the stack is a waste (and more ways your program can go wrong).
Could cause a page fault in theory
Edit: as someone pointed out I meant to say segfault, not page fault.
Edit2: after research it turns out that according to most standards argv itself is null terminated.
Edit3: after further research it seems that it is possible for argc to be 0, and argv to have a single element, null. But it is sane and reasonable to assume that it has at least one argument followed by a null terminator.
@@m.sierra5258 huh how?
Sometimes it can help to copy out the buffer to remove the effects of pointer aliasing
@@m.sierra5258 How does looking at argv directly cause a pagefault? Writing to argv might do that. But if looking at argv directly is a problem then calling strcpy, or any other functions on argv[x] will cause pagefaults too since you're just shifting the looking part to the implementation of these functions.
@@Notevenmad955 TL;DR: if the program is executed without any command-line parameters, argv[1] will cause the program to crash.
argv is an "array" (technically pointer to pointer to char), its size depends on how many parameters are passed to a program, except for argv[0] (it always exist because it is the path to the application executable). Since the memory for argv[1] may not exist (f.i.: when no parameters are passed), argv[1] may point to any memory address, since it may contain garbage or some other process' memory. Reading from non-owned/protected/freed memory has undefined behavior, and may cause SIGSEGV (segmentation fault).
funny watching him walk into a textbook buffer overflow attack
One that's used by every introductory course into binary exploitation too lel
Doesn’t the program have to be specifically compiled with -fno-stack-protector to get tampered with in the first place ?
@@karimzermaini4988 Even if you compiled without setting the -fno-stack-protector option, it is still possible to launch a stack buffer overflow attack under certain circumstances where the canary value can be determined. This means that the most important thing is to avoid using vulnerable functions.
Not really an attack in this case, more like painting a target on yourself and walking into the range
The moment you said “strings” is when I started laughing hysterically.
You mean char arrays?😅
"Take a string from the user"
*proceeds to NOT include *
the most terrifying thing I ever did in a computer science course was to feed a C program unsafe strings to execute arbitrary code. wild shit
in reality all you have to do is use exit codes(within the string) that the interpreter recognizes right? Surely many programs have a layer between user input and the code that circumvent this, but I'm even more curious how many don't.
@@15shekels ah, but c doesn't have an interpreter, it generates machine instructions which get processed directly by the CPU, and it doesn't have many safeguards to protect against program corruption. If you need to safely handle strings from the user, there are big benefits to using c++, rust, or really any other language that gives tools to easily and safely handle strings
If I ever feel like bricking an old computer, I now know what I can do
Mine was in an embedded system running some insanely complex code; six FOR loops in and I want out of them all. I honestly began thinking to myself "one little GOTO statement should be perfectly fine, right?".
P.S.
It wasn't fine.
@@odomobo Many C compilers don't implement effective safeguards - input limits and filters vs illegal characters, etc. And many C programmers don't either.
But if you're programming anything which requires valid inputs and involves potentially destructive/malicious user exploits then you'll choose a compiler, library, or instructions which implement the necessary safeguards.
Bad code is bad code. But bad coding choices and bad coding practices are worse.
"there is a string"
"i should make a buffer 63352482 times larger than the string just in case"
The most unsafe thing in this video is that monitor placement
Well, I mean C is extremely explicit and doesn’t protect you against anything. Great power is not without great responsibility.
Yes and no. Great power and zero protection are not the same thing. There are other languages like Rust that give you the same explicit power but make it much more obvious if you do something dangerous.
Of course 10 years ago C was amazing, but better alternatives arise nowadays.
Exactly, and that's why you shouldn't use a nuke to kill a snake.
@@m.sierra5258 rust shill detected
@@thev01d85 its pretty relevant to the topic of the video and comment, is it not?
@@wrong1029 I never said it's OT
If you don't know what the problem is:
1. He didn't take into account the null terminator, meaning that using that as a string will result in an undefined behavior.
2. He didn't add any check that ensured the parameter input from the command console would be 2 characters or less (otherwise it would overflow from the array) or any limiter that cut the input within the limits of the array.
TLDR: You can easily go beyond the array with the user input which is not gonna end well.
He also didn’t make sure that argc was >= 2
Im grateful that people out there have coded things in c , that we web developers take for granted..
Thank you C lords
Amen, brother
I see the other side of the coin. I love coding in C and I don't like web development, so I'm grateful I don't have to bother with web things lmao
Still not a C lord though, I'm only a student for now
@@rosskrt I am the C lord. I can take any algorithm and malloc() my way through it without leaking a single byte of memory. The code that the world's computers depend on flows from my fingertips.
Just practice a few command line apps for data handling in C++ and C#. C is fun, especially when you are getting into microcontrollers for iot.
@@miles7267 "Daddy Lord C" is a french rapper from thirty years ago. Due to his name I consider him to be the daddy of all C lords.
C is that one friend you once had great memories with but you're happy not being with now
Why is this so accurate?
I study at 42 now so I'll be friends with C for a LONG time :3
no, I'm currently back to C after 20 or so years and I'm very happy with it.
@@nandakoryaaa1401 :3
Me, a non programmer: I don't know why everyone is frightened by this but I'm just gonna pretend that I also am
So in C programming you have direct access to memory, which is useful in some cases (system programming, embedded, stuff that's EXTREMELY performance sensitive), but it's *incredibly* dangerous as there's basically nothing to stop you reading or writing memory that your program doesn't own (or that your program DOES own but is using for other things). Handling strings is a particularly common pain point due to the way they're handled by default -- most text handling involves walking through memory until you get to the end of the text. If you somehow manage to not end the text properly, you can overrun the memory assigned for the text and start reading/writing whatever comes next in memory. This sort of stuff wasn't TOO bad when C was first being developed in the 70's, since you generally trusted the people writing and using the programs, but on modern machines, connected to a hostile internet, it's pretty disastrous. It's *technically* possible to write anything safely but it requires extreme levels of paranoia and basically no-one can do it consistently for a large program.
@@birdrun4246 so nowadays it is basically impossible to write a safe complex program in C working solo?
@@turanlaborator7274 it's extremely difficult, if not impossible. Of course it depends on what sort of work you're trying to do, and in what environment -- a program dealing with potentially hostile data off the internet is way more dangerous than something in an embedded environment, or an application that only takes data from the local user, for example.
Other people, a programmer: I will enlighten you to my ways and make you join us
@@turanlaborator7274 It isn't due to advanced static analysis tools letting you know when you do unsafe things for the most part. Assuming you're concious of these things and take the time to run your codebase through the static analysis tools and fix all the warnings
Today we are going to show you how to use strings in C, but first we need to talk about parallel universes
When he declared that char array I started sweating
I dont get it, whats the dis advantage of a char array vs an allocated pointer vs a non allocated pointer? whats the joke lol thanks. does it have to do with heap memory vs stack memory?
@@anthonygalbo9348 Because a lot of security issues are caused by mixing user inputs with char array unsafely.
In this case, when declaring it without malloc you are allocating it in the stack, if you call malloc I think it goes to the heap.
Whats special about the stack is that you are very near in memory to the return address.
Basically, if the user inputs a text with more than two chars (because there's always a null char at the end) it will overflow that char buffer and user input will override other values in memory.
Overriding the return address is the entry point for you to execute whatever you want in the program.
In short, when declaring a char array I feel the danger of of having a buffer overflow in my code
@@santiagobarrera2387 thanks for ypur explanation, i was not really getting it before
@@santiagobarrera2387 thanks mate
@@anthonygalbo9348 That's not the problem here. If we're reading three characters, we need FOUR bytes of storage. If we're reading N characters, we need N+1. That's because the last character in a string is a null-terminator, which will get written out of bounds if we don't declare sufficient space in the char array. And, per specification, the behavior of accessing/writing an array out of bounds is undefined.
Buffer isn't large enough for null char, no checking argc, strcpy instead of strncpy, just beautiful code all around
Would we really need place for null char? I mean, we know that the word is gonna be either DOG or CAT, so we will only take into consideration first three chars, won't we?
@@idenix7589 argv contains null-terminated strings, so you have to allocate enough space to fit null as well if you're using strcpy. Also, you can't know the length of user input, so you have to check it first, what if there's 1 char + null? But yeah, knowing that there's exactly 3 chars+null, we can copy only 3 chars, and check them againts CAT or DOG. Also, I think strncpy allows to specify buffer size, so maybe we can copy only 3 chars with it, without null
@@teaboy9614fair enough
@@teaboy9614 If I remember correctly:
In this situation, you would want to use strncopy and specify a max length of 3 (the buffer length). This is actually safe assuming we fix the issue with not checking argc. However, it leads to a logic error - input longer than 3 characters (such as "DOGMA") will still trigger the condition.
Thus, we need space for the null character - we need to know that the first three characters are "DOG", and that the string ends there.
@@idenix7589 You're right, for such a simple program you'd only need to copy the first three chars and use strncmp with n=3.
I also the like suggestion in a different comment that you could just compare argv[1] directly with no copying whatsoever.
Your program: *vulnerable to buffer overflow*
Stack canary: i got your back bro
before considering a programming language to make a project in i usually consider c... but then again i remember that a) my project usually involves string handling, and b) i like std::string too much
if you want real good strings (but without good number support) you should try shell scripting
@@kurtmayer2041 if you want both good strings and numbers support, Python is for you
Main experience is with c++ too, but I recently started to learn Rust and its user experience is AMAZING
you should give it a shot and see if you like it! c:
C++ strings are a mess. Try linking multiple libraries that use std::string.
Python strings go "b" + "r" * 10
Reminds me of team project at university where we all worked on different parts of the program. When we met up to put it all together, we quickly realized one of us did NOT compile their part at all from the very beginning. Months.
It says it all when you see comparing strings like: if (variable == "DOG")...
bruh
thats is indeed a bruh moment
I'm a beginner in C, is that bad? Should he have used strcmp()?
Maybe that's because you can cheat the system if the variable is equal to an int that has the same value as the string?
@@whannabi If I get it correctly "DOG" is a const char* so it is just the address to the first character not the whole string. so if variable is at a different address this will evaluate to false rather than test if both strings contain the same characters.
The thought of someone not knowing to run their code to see if it works terrifies me. That’s the type of person who’s going to somehow slide by with a degree and force all their coworkers wipe their ass for them.
*Lost children will be taught the C programming language.*
I love the fact that you took your time to explain everything into details
>uses strcpy on user input
>buffer overflow: allow me to introduce myself
LLL : *Uses str instead of manually implementing string logic*
Every C programmer out there : "I took that personally."
As Death said in the Hogfather (Terry Pratchett)
"It's a sword. It's not meant to be safe."
Knowing C, as soon as I read the title I knew it was going to be a short video... Writing C in a safe way is a real pain.
I love C. I still have a copy of K&R on my shelf. Remember, it's designed as a replacement for assembly language.
It's designed as a crude imitation of BCPL.
@@davidwuhrer6704 *B language, after BCPL
Love your channel man, you're seriously underrated!
For those who dont get it, there were a few problems. First he did not check in argc if there even were an argv[1] - potentially unsafe program. Second he did not make sure the string he is copying is actually three bytes - incase the string is larger he will overflow the buffer he allocated - potentially unsafe.
Wait, so which one’s unsafe?
the overflow from the null terminator given a valid input,
the overflow given any sufficiently long invalid input, or
the segfault or memory access violation given no input?
Yes.
word
strcpy() is inherently unsafe; it can allow what is known as a buffer overflow (look up heartbleed). Use strncpy().
Yes
@@Matt64714 so that's why companies like qualcomm ask questions like implement your own memcpy to mess with us?
I love this format! Please make more😆
I would love an explanation video on why is this unsafe, not new but amateur to embeded c software
Firstly C strings are null terminated (well should be), so buffer should have space for 4 char's at a minimum to hold "DOG" or "CAT".
Second, strcpy doesn't know how long the buffer is but blindly copies until it gets to the null byte in the source. This is a buffer overflow fix it by using strcpy_s.
Thirdly, if no program name or arguments were passed argv[1] would pull an environment variable - This could be a problem. (if only 1 of arguments or program name is provided it will be null). Fix it by checking number of arguments passed (argc).
Lastly, why even bother copying that string? You're more likely to just strncmp on argv[1] after confirming argc > 1.
@@aliraheem6135 Rust dev with a Java & JS background here. Just want you to know, your explanation is highly appreciated. Thanks!
First it use stack memory … can overflow second he use strcpy … does not assure it will have a \0 like strlcpy and the size of the container is too small …and another one could be he assume the number of input will be correct
There's nothing stopping the user from inputting a string longer than 3 letters. A malicious user could easily turn that strcpy into "goto argv;" with the right input
@@scheimong Same. I only noticed #2, I didn't even think about the possibility of problem #1
General rule for strings in C that I learned in my operating systems class: just use malloc and allocate one extra memory slot for the null terminator. I used to think using the heap was a pain in the ass but in C it actually reduces a lot of issues with seg faults and garbage values overwriting your buffers value.
I agree, the safest way to program in C is to use heap memory and operate on one character at a time while checking if you need to realloc() as you go - it can be more tedious to code this way, but it's a very good habit to get into.
Of course, if you want to really be safe, you would use an alternative C string library (or make your own) that packs the strings into structs and attaches a size_t counter to keep track of how long they are. This is basically how strings in C++ work and it's much safer than relying on the C null terminated strings.
That depends. In this case neither a buffer nor allocation are needed. The simplest, fastest and safest way would be directly checking the input.
And if performance is a consideration (which is why C is still used so much) then an allocation for something as small as this is out of question.
@@ABaumstumpf The key word in my statement is “general”. Obviously in this case allocation is not needed but most programs of any significant size using strings are going to need to store the string value into a variable. An allocation is going to be needed since using buffers stored in the stack later can be problematic and generally I find using malloc properly reduces the number of seg faults you’re going to have when using string.h functions.
In embedded programming we want to avoid using malloc. Use static buffers where possible.
In application programming we want to avoid static buffers. Use malloc where needed. Except in Windows. Malloc is slow in Windows.
C programmers never die they just cast into void
so trippy, literally had a uni lecture on buffer overflow with strcpy last night and now im seeing this video
Walking down the street until it's unsafe: at some point the poor guy forgets advancing one of his legs, and as a product of the inertia he had already gained, simply falls. Walking is so hard...
It was unsafe when main had an empty body since the exit code is undefined at that point.
No, having no "return" in a main is allowed in C, just up to C99 the value returned to the operating system was unspecified if the return-value was omitted.
Also don't forget that argc can be 0 in which case argv[1] is an environment variable; don't make the pkexec mistake ;)
What I really found weird was when that bug came to light, even many people I knew who code in Linux environment for years were like "how can it ever be zero?". Crazy how so many people overlooked that system calls are not the ones to actually ever put that one argument
@@cortexauth4094 I still don't understand how it can be zero and don't know how to invoke a program with a zero-length argument array, but since I'm not a pentester it's enough for me to know not to make any assumptions about the environment that aren't either explicitly stated somewhere I can reference or under my control. I don't like to assume that the file system root is readable either.
@@tacticalassaultanteater9678 I guess the args can be 0 when you execute the binary outside a shell, i.e. with execve and passing a null pointer to the argv argument, or in a shell that doesn't provide args to the program. Usually shells provide first arg which is usually the path to the binary.
This is also how the original PoC attack for pkexec was done, executing the binary directly inside a C program, passing a null pointer to argv.
Never assume that your program is executed in a safe shell environment :P
@@dealloc Yeah, the first argument to be a program name is just a UNIX convention and exec system call does not enforce the convention
@@cortexauth4094 when i did my first ROP attack for a CTF my mind physically blew up when i figured out that it's the programmer who specifies the filename versus the kernel
shit's wild
It's reminding me of my operating systems class days. I had to write the simplest device driver, one so dumb it was practically useless. The whole thing made me realize I was in control of a machine that did exactly what I told it even if it meant destroying itself.
Now do this in Rust without using "unsafe" or "extern".
idk if you're joking but here. might be bad practice or something, I'm still learning
use std::env;
fn main() {
let argsv: Vec = env::args().collect();
match argsv.len() {
0 | 1 => {},
2 | _ => {
let arg = argsv[1].as_str();
if arg == "CAT" {
println!("Meow");
} else if arg == "DOG" {
println!("Woof");
}
}
}
}
use std::io::stdin;
fn main() {
let mut input = "".to_owned();
stdin().read_line(&mut input).unwrap();
input.pop();
match input.as_str(){
"CAT"=>println!("Meow"),
"DOG"=>println!("Woof"),
_=>()
}
}
Not hard to pull off.
yep. you can do it with almost the same code.
writing with mem safe languages is for pussies :P
if(argc < 2)
{
std::cout
I sure do love my C namespaces, classes and overloaded operators
I have never started learning C because of people saying how hard it is, so I never get the jokes like these but I act like I do.
People you don't need a null terminator if you know the length.
More than one errors. U have to check argc to be 2 or more. Then u have to check strlen of argv[1] to be 3. Then u need a buffer of 4 characters to store the terminating null. Then u use strncpy_s
You don't really need strlen, just compare argv[1] directly to "cat" and "dog". Even if the string is longer, the comparison will end after 3 letters.
As a person who doesn't understand C, I can confirm, this is very unsafe
The second I heard "strcopy" red alarm bells went off in my head. Well played, sir and/or madam.
I actually laughted a lot! xD I love your channel!
Yay, thank you!
As an embedded programmer who uses a lot of C. Always use the *n* versions of string functions (I.E. strncpy). It won't prevent everything bad from happening, but it prevents a lot of bad stuff from happening.
A really noob C learner here, but I find it funny that some really usable code, the ncdu utility from Linux for example, does not use any of the safety or best practices that I saw in this comment section XD. How is it to be a professional C programmer? How did you get into the market?
Can't forget making space for that terminator value "\0"
I had a homework in C dealing with strings such as substring,replace,append .. it was a nightmare .
I think I just found the perfect idea for my company's interview question
ah yes, C and string, the dynamic duo
Well, why would you copy it at all? You've got a perfectly valid string just waiting to be accessed. Just write a simple if statement for all the characters, or use strncmp if you feel too fancy for a low-level solution.
Low level:
extern(asm)
High level:
if (pid = fork()) exec("bash", …
I have no idea what happened but it still made me laugh for some reason
I'm starting a job as an Operating Systems developer at IBM next month so I guess I'm a good fit for the low level gang xD
0:19 already unsafe.
As a high-level user can one of my friends from the depths explain in detail how the exploit would take place?
(P.s.I sense buffer issues with some playing around with Nulls and overflow)
A C array is basically saying here is a location in memory with n points of reserved space, but there are no safe guards for using more than the reserved space, so you can read/write in the non-reserved space too. "strcpy" will not and cannot check to see if there is enough space to copy the entire string and will continue to write in the non reserved sections of memory succeeding the array.
In C strings, the minimum length for a buffer is the actual length of the string + 1 (null character). While dog and cat both are of length 3, you actually need a buffer of length 4 if you are going to copy the string with strcpy. This leads to an infamous error.
@@sfcs3743 Even if he reserved more memory, he never checks user input size, so it would still be unsafe.
that taught me more than most tutorials do
My operating systems class projects are all in c. And are super complex for me. This is indeed hard
I appreciate you guys that write C. The only ones I respect more are those that can code in assembly. Never understood all this inter-lingual animosity. That having been said, I'm happy with Python and Java, I just don't have this in my soul, but I'm glad someone out there does.
Edit: Recently started making Android apps with Kivy. One step in the packaging process is to take the Python code and compile it into native C/C++. Every time I watch that part of the stdout, I spare a happy thought for all you C programmers out there. Even Python's written in C.
Programmers tend to be a little bit elitist, i'ts just pride I think with C programmers. Watch them go quiet when an assembler programmer turns up.
The reason for the Interlingual animosity is that Interlingua and Esperanto are more widely known.
@@SerBallister There is no such thing as "assembler programmer", most of those guys program in c most of the time.
@@user-zb8tq5pr4x Yeah mostly, maybe emulator or vm people study this a still today
Only safe c program: int main() {return 0;} :)
Actually, empty parentheses means not that function takes no arguments (for that you explicitly typing "void" inside), but that it takes undefined ammount of arguments. Still don't know how to use this feature, but I have a feeling that something like printf() works that way.
@@rogo7330 printf is a variadic function.
@@michaelespinoza4562 yep, you're right, it's another thing, thanks
I don't program in C, but playing with it for some time ago taught me to be more careful when programming in other languages.
if there are no arguments, there might be an out of bounds read, as you are reading the first environment variable after the null separator.
Use strcpy_s() instead, defined by standard to avoid buffer overflows...
what actually caused bufferoverflow here? can you please explain it?
that is what "strncpy()" is for...
Strncpy allows you to only copy n chars which helps as well
@@santhoshg8154 it was explained in another comment "alex ghilas" was asking. youtube keeps deleting comments so I can't link it.
@@santhoshg8154 strcpy copies bytes until the first null byte it finds. therefore, even "DOG" overflow since it's 4 bytes. (also, the user can input any string, so all 3+ char strings will overflow buff)
Actually it was unsafe from the curlies and not returning anything
it was unsafe because you can exploit a buffer overflow, he didn't specify the maximium number of character on strcpy, so it will copy until it reaches the null ch, so you can input something longer than 3 characters, and manipulate the values on the stack (variables)
not exactly, the compiler will put a return 0 at the end of the main function(yes it is the standard) if you don't do it explicitly. The problem is the potential of buffer overflow via strcpy. Hell the video could have ended the moment he wrote argv[1] instead of actually finishing the function call, since he never checks argc to see if argv[1] is actually valid.
@@Notevenmad955 this ^
@@Notevenmad955 That's not *unsafe*, though, just *bad*. There's nothing you can get from looking at argv[1] when argc < 2 that you couldn't also get supplied directly as a cmd line argument.
Now that would be intersting to make a video on how to make it safe, or even EXTRA safe 😁
how much i love buffer overflow❤❤
every time I look at C code and ask myself: "Is this string null terminated?"
whoever cam up with this bullshit: *puts hands together like bond villain* "Well well well, wouldn't you like to know!"
all strings are null terminated unless you are also given the length
All strings are null-terminated in C.
Not all char-arrays are strings.
In Pascal, and in some network protocols, strings are preceded by their length.
Most languages have operators for string comparison. C has a function in string.h.
One could say the same on higher level language where you don't quite know whether it is deep or shallow copying an array of objects. Well, call me silly! :-D
HLLs: "People dont understand pointers so we're getting rid of them"
Also HLLs: "Why does everyone mix up deep and shallow copying?"
@@williamdrum9899 , I don't know about you but I see address dereferencing in high level language all the time!
True but in managed languages it wouldn't make the program unsafe
@@test40323 Only HLL (if it's considered that) I've used is Python which let's be honest is just C wearing a trench coat
when the unskippable ad is almost as long as the main video
I am far too new and inexperienced in the field to get this, but I will be back one day to hopefully understand it and get a good laugh
seeya then!
Then you'll eventually realize it is cringe dumpster tier humor.
Minor correction: including stdio.h is not including a library. The library is already being implicitly included by your compiler.
The header file (stdio.h) just includes the forward declarations.
This can be seen clearly if you were to either:
a) try to compile your stdio.h including code with -no-std or something
b) didn’t include stdio.h, but pasted function prototypes for the functions you’d like to use at the top of your c file (it would still work)
Those who dont know, strcpy() is unsafe and can cause buffer overflow. Anyone can overwrite return address on stack to change the execution flow of the program
It was the moment, when declared that array to store string of unknown size
this is an old school art that is mostly gone, I had the honor to write in C but i wont go back
Man I laughed so hard after the screen got black :D
Well done putting the stars (pointer) after the type definition to be actually part of the variable name :)
C is hard. Use Rust. It's like C except you loudly shout when things are unsafe and do them anyways.
Rust is like C++
@FichDich InDemArsch Rust has some good ideas, but it has the C++ disease of adding too many features and spoiling the broth.
I mostly agree with what Drew Devault has said about Rust on his blog.
After 3 years in C, your best friend is calloc, you can allocate memory and it replace it with null chars.
Not writing your own implementation of standart library functions from scratch? This is already a non-C way to go
What
yes
Low Level Gang For Live
That's possibly unsafe in most languages lol.
The only difference is that other languages make you handle it or warn you.
Or Rust, where unsafe code simply won't compile, unless you literally use an "unsafe" block around your unsafe code.
buffer overflow: "i am going to end this mans whole career"
as soon as the opening brace is on its own line the computer should have burst in flames.
i meannnn there are safe alternatives for all unsafe c functions that arent that hard to use
Just a tip for improving your typing, you can actually buy keywords which come with this cool feature where all the keys are labeled so you can actually remember what the fuck they are
thanks TH-cam for recommending me a video I no way to comprehend
Splendid description
C is just like that, such a beautiful language... full of... of... pitfalls and dangers for the young and novice... it is nor even fun to speedrun this sort of thing, since it would boil down to who can type the fastest, no skill required! trust me... as someone who done and still does a lot of bad C(war crime level kind of bad, this is no laughing matter!) and still does, yes... still bad, if not worse.... from buffer overflows to blowing up the memory stack.... I tried to use openbsd libbsd, where we have reallocarray and strlcpy... but it just gets worse... at least I sort of know that is wrong and bad... but I am not sure if what actually works is any good or any safe...
you don't need strlcpy, you need strncpy
@@figboot I kinda do.. I still have nightmares with strncpy... plus, strlcpy is null terminate guarantee, regardless of the size of the buffer, though if you are not careful, you stand to lose data... but I have that any day over a buffer overflow that I can not always see.
Most compilers have warnings for unsafe functions I find though and I've also been compiling stuff with the address sanitizer turned on and it's the best fucking thing it catches mistakes so early
@@dummybugstudios6450 right! who needs a garbage collector when you have address sanitizer?
@@dummybugstudios6450 and just now I know this?! shame on me!
strncpy or even better snprintf
Or even better add ++ to the C and use std::string 😉
I prefer std::u16string
As someone who wants to get into coding, I have no idea what just happened😵💫
Should we reserve 5 bytes of memory, place the first four chars the user enters on the keyboard into reserved memory, ignore/delete anything the user entered afterward, append null terminator, compare the char string, perform conditional output/return, clear 5 bytes reserved, end program?