why do hackers love strings?

Hackers have been trying to steal information since the beginning of the information age. Buffer overflow attacks have been one of the ways they do it. By taking advantage of logic bugs in programs, hackers have been able to get access to computers and steal information which they later sell on the dark web. Buffer overflows have been one of the most common ways they get in.

In C, strings are a little weird. Because there is no length encoded with the string type, string functions in C are extremely easy to use incorrectly. When used in an unsafe way, hackers can abuse the way that functions call each other to give them access to your computer.

🛒 GREAT BOOKS FOR THE LOWEST LEVEL🛒

🔥🔥🔥 SOCIALS 🔥🔥🔥

[anon_y_mousse]

Most important message to be conveyed here, *never* trust user input. Always check it, always restrict what you do with it.

[RobbCorp]

Be really fun to see your 'secure' server broken live and record the actual memory. Great video!

[sledgex]

Technically you must read at most 63 bytes/characters. The 64th byte in the array is the null byte. And you need to remember to set it to null when creating the array.

[eluraedae]

In this reality some hackers love strings more than physicists.

[mkvoq]

And all this just because someone decided that extra few bytes for storing the length is too expensive.
Which is kinda strange, because in fact pre-determined length can increase performance dramatically. There is a known recent story about GTA modder who cut the game loading time by 70% just by eliminating strlen() calls.

[FreshSmog]

You can always implement strings as structs and store the length data. It's C, you can do anything. Unfortunately, you still need to get the data back out pretty frequently as the usual null terminated char arrays in order to use other functions.

[jorgeherrera]

Honestly there are no excuses for buffer overflows in your programs today. With all the tools available to devs you have no reason for this to still happen.

[ReptilianXHologram]

I think you should make a course on how to program in C securely/safely for beginners.

[garyhalsey]

Having just completed my CompTIA Network+, Security+ & PenTest+, this is a perfect example of the need for sanitisation of user input!!! Great video and you’ve just got a new subscriber!!

[coolbrotherf]

That's why the newer secure versions of these input functions also include a max data value so they can ignore any input over the intended amount making them much more difficult to exploit with buffer over flows.

[SchalaArchivesish]

In Pascal-style strings, the length is encoded as a byte at string[0], or sometimes the first 2 bytes (first 2 indices). This is a practice that the Macintosh pre-Intel era used in its API, and how strings are usually stored in binary file formats.

[donjindra]

As a C programmer I would never uses gets() in a professional program. I always bound check when copying to buffers.

[HenrikBerg]

If someone reads this know that strncpy is broken and should not be used.
If input is larger than buffer, no nul is added to the buffer. Never use strncpy without the line after:
buffer[sizeof(buffer) - 1] = ‘\0’;
If you don’t like to write this every time, use strlcpy.

[Agryphos]

We should all be grateful that code is getting safter

[quipyowert]

4:59 "Randomize Memory Data Structure" Perl 5 does this with hashes starting in 5.8.1 and the Perl porters improved the feature in version 5.18. It's in the perlsec manual under the section "Algorithmic Complexity Attacks".

[wtfdoiputhere]

more buffer overflow please because I've always watched videos about them but never have "clicked" as simple as this one

[hanzo]

great video ! how did you get the function description in c 2:30 ? as a beginner that would really help me understanding the functions in depth

[younesmdarhrialaoui]

I have to say this channel is very, very, very good. You really are delivering quality wise.

[Jmcgee]

Read the gets(3) man page if you feel like having some fun. It's not long. Opens with "Never use this function" and ends with "ISO C11 removes the specification of gets() from the C language." It also mentions that "there can be no guarantees that the function will even return" - which is due to the return address manipulation exploit in this video.

5:14 I wouldn't recommend using strncpy(3). It does not guarantee that the result will be null-terminated, so it's just another thing to keep in mind when copying. Use snprintf(3) instead, even if strncpy(3) is technically safe.

[omegahaxors-]

Even a small buffer over/underflow can result in complete arbitrary code execution.