Rework third chapter

[0xAX]

Description

This PR provides rework of the third chapter.

[klaudiagrz]

Review of all files except the main post

[klaudiagrz]

Please adjust the descriptions also in the code sample of the third post.

[klaudiagrz]

Review of the intro section

[klaudiagrz]

Leftovers from the previous review

[klaudiagrz]

Review of the "Stack operations" section

[Yimura]

I came here because I was quite confused by the div instruction (where does the quotient go and what happens to the dropped number/remainder of the integer?).

Basically what I've done is fixed some of the sentence structuring and typo's related to this.
Review comments with indentation in them means that you've used mixed indentations across lines. For example the below piece of assembly:

    ;; This will give us the numeric value of the character.
	sub bl, 48

The comment is indented with spaces and the assembly is indented with a HARD tab \t.
To the compiler this makes no difference but for the reader it comes off as messy.

[0xAX]

@Yimura thank you very much for your comments, I will fix in the near time.

[klaudiagrz]

Comments to the code sample

[klaudiagrz]

Suggested change

	;; Convert the sum from number to string to print the result on the screen.
	;; Convert the sum from a number to a string to print the result on the screen.

[klaudiagrz]

Suggested change

	;; Fetch the number of arguments from the stack and store it in the rcx register
	;; Fetch the number of arguments from the stack and store it in the rcx register.

[klaudiagrz]

Suggested change

	;; Compare the first element in the given string with the NUL terminator (end of string).
	;; Compare the first element in the given string with the NUL terminator (end of the string).

[klaudiagrz]

Suggested change

	;; Repeat until we do not reach the end of the string.
	;; Repeat until we reach the end of the string.

[klaudiagrz]

Suggested change

	;; Convert the sum to string and print it on the screen.
	;; Convert the sum to a string and print it on the screen.

[klaudiagrz]

Suggested change

	;; If it is not zero yet, continue to convert it to string.
	;; If it is not zero, continue to convert it to string.

[klaudiagrz]

Suggested change

	;; Otherwise print the result.
	;; Otherwise, print the result.

[klaudiagrz]

Suggested change

	;; Put the number of symbols within the string to the rax register.
	;; Put the number of string characters to the rax register.

[klaudiagrz]

Suggested change

	;; Number of `sys_write` system call
	;; Number of the `sys_write` system call

[klaudiagrz]

Suggested change

	;; Number of `sys_exit` system call
	;; Number of the `sys_exit` system call

[klaudiagrz]

Suggestions till "Converting integer to string"

[klaudiagrz]

Suggested change

	2. Take the first byte of the string and subtract the value `48` from it. Each byte in a string is an [ASCII](https://en.wikipedia.org/wiki/ASCII) symbol with its own code. The symbol 0 has code `48`, the symbol 1 has code `49`, and so on. If we subtract `48` from the ASCII code of the given symbol, we get an integer representation of the current digit from the given string.
	2. Take the first byte of the string and subtract the value `48` from it. Each byte in a string is an [ASCII](https://en.wikipedia.org/wiki/ASCII) character with its own code. The character 0 has code `48`, the character 1 has code `49`, and so on. If we subtract `48` from the ASCII code of the given character, we get an integer representation of the current digit from the given string.

[klaudiagrz]

Suggested change

Returning to the table from the section above, we may see that pointers to the command line arguments are located on the stack right above the number of command line arguments. So if we fetch the first value from the stack after we already fetched the number of arguments, it will be a pointer to the string which is the first command line argument. If we will pop the next value from the stack, it will be the second command line argument passed to the program.

Returning to the table from the section above, we can see that pointers to the command-line arguments are located on the stack right above the number of command-line arguments. So, after we pop the number of arguments (ARGC), the stack pointer will point to the address of the first command-line argument (ARGV[0]). If we pop the next value from the stack, it will point to the second command-line argument (ARGV[1]) passed to the program.

[klaudiagrz]

Suggested change

	Now if we will take a look at the `str_to_int` procedure it should be clear without any additional details:
	Now the `str_to_int` procedure should be more clear:

[klaudiagrz]

Suggested change

	As soon as we converted both command line arguments to integer numbers, we can calculate their sum:
	As soon as we converted both command-line arguments to integer numbers, we can calculate their sum:

[klaudiagrz]

Suggested change

	Since we have our result, we just need to print it. But before printing it we have to convert the numeric result to string. This we will see in the next section.
	Now that we have our result, we just need to print it. But before printing it, we have to convert the numeric result back to a string.

[klaudiagrz]

Suggested change

	### Converting integer to string
	### Converting an integer to a string

[klaudiagrz]

Comments till "Security considerations"

[klaudiagrz]

Suggested change

	In the end of the previous section we calculated the sum of two numbers and put the result in the `r10` register. The `sys_write` system call can print only string. So we need to convert our numeric sum to string before we can print it. We will achieve this by the `int_to_str` sobroutine:
	In the previous section, we calculated the sum of two numbers and put the result in the `r10` register. As the `sys_write` system call can only print a string, now we need to convert our numeric sum into a string. To do so, we will use the `int_to_str` subroutine:

[klaudiagrz]

Suggested change

	Before jumping to the `int_to_str` sobroutine, we need to do some preparations. As you may see we put the value of our sum in the `rax` register and initialize the counter (`rcx` register) with zero. This counter will store the number of symbols in the our future string. Note that we are using new instruction to initialize the counter - `xor`. This instruction is a [bitwise XOR](https://en.wikipedia.org/wiki/Bitwise_operation#XOR) operator which resets bits of the operands to 0 if they are the same.
	Before jumping to the `int_to_str` subroutine, we must prepare the data with two instructions:
	1. First, we put the value of our sum in the `rax` register using the `mov` instruction.
	2. Then, we initialize the counter (`rcx` register) with zero. This counter will store the number of symbols in our future string. To initialize the counter, we use a new instruction - `xor`. This instruction is a [bitwise XOR](https://en.wikipedia.org/wiki/Bitwise_operation#XOR) operator which resets bits of the operands to 0 if they are the same.

[klaudiagrz]

Suggested change

The algorithm of the `int_to_str` sobroutine is pretty simple as well. We divide our number by `10` to get the digit and add the value `48` to the result of the division. Remember about ASCII codes? If yes it should be clear why we are doing it. As soon as we got the symbolic representation of the current digit we push it on the stack. As soon as the given digit is converted we increase our counter of numbers of symbols within the string and check our sum number. If it is zero it means we have the resulted string. If not, we just repeat the all operations.

The algorithm of the `int_to_str` subroutine is pretty simple. We divide our number by `10` to get the digit and add the value `48` to the result of the division. Remember about the ASCII codes? If yes, it should be clear why we are doing it. As soon as we get the symbolic representation of the current digit, we push it on the stack. When the given digit is converted, we increase our counter that represents the number of characters within the string. After that, we check the sum number. If it is zero, we have the resulting string. If not, we repeat all operations.

[klaudiagrz]

If yes, it should be clear why we are doing it:

1. As soon as we get the symbolic representation of the current digit, we push it on the stack.
2. When the given digit is converted, we increase our counter that represents the number of characters within the string.
3. After that, we check the sum number. If it is zero, we have the resulting string. If not, we repeat all operations.

[klaudiagrz]

^ consider the alternative formating of text in the form of ordered list

[klaudiagrz]

Suggested change

	As soon as we will collect all the digits of our sum, they will be stored on the stack. So we can print our string with the following code:
	Once we collect all the digits of the sum, they will be stored on the stack. Now we can print the string using the following code:

[klaudiagrz]

:)

[klaudiagrz]

Suggested change

Most of this code should be already well understandable for you as the most significant part of it consists of the initialization of data for the call of the `sys_write` and `sys_exit` exit calls. The most interesting part should be first four lines of code of the `printResult` subroutine. As you may remember the one of the parameters of the `sys_write` system call is a length of the string that we want to print on the screen. We have this number as we maintained a counter of symbols during converting the numeric sum to the string. This counter was stored in the `rcx` register. Our string is located on the stack. We pushed each digit with the `push` operator. But the `push` operator pushes `64` bits (or `8` bytes) while our symbol is only 1 byte. To get the whole length of the string for printing, we should multiple the number of symbols to `8`. This will give us the length of the string that we can use as a third argument of the `sys_write` system call.

Most of this code should already be understandable, as it mainly consists of the data initialization for the `sys_write` and `sys_exit` system calls. The most interesting part is the first four lines of the `printResult` subroutine. As you may remember, one of the parameters of the `sys_write` system call is the length of the string we want to print on the screen. We have this number because we maintained a counter of characters while converting the numeric sum to a string. This counter was stored in the `rcx` register. Our string is located on the stack, where we pushed each digit using the `push` operator. However, the `push` operator pushes `64` bits (or `8` bytes), while our symbol is only 1 byte. To calculate the total length of the string for printing, we should multiply the number of symbols by `8`. This will give us the length of the string that we can use as the third argument of the `sys_write` system call.

[klaudiagrz]

Suggested change

	As soon as all parameters of the system calls are ready, we can pass them as arguments to print the sum and print new line after it.
	Once all parameters of both system calls are ready, we can pass them as arguments to print the sum followed by a new line.

[klaudiagrz]

Suggested change

	Let's build our program with the usual commands:
	Now, let's build our program with the usual commands:

[klaudiagrz]

Suggested change

	And try to run it:
	Then, try to run it:

[klaudiagrz]

Suggested change

As we have seen in this and in the previous posts, the stack is a crucial concept that is used to manage function calls in our programs. Understanding of how the stack memory managed is not only important for writing programs with re-usable functions but also crucial for writing secure programs. The stack often has been a common source of security vulnerabilities, especially in low-level code and assembly routines. When you use `call` and `ret` instructions, the processor doesn’t verify if the return address is valid, but it just simply pops the address and jumps on it. One of the most common problems is the [stack overflow](https://en.wikipedia.org/wiki/Stack_overflow).

As seen in this and the previous posts, the stack is a crucial concept used to manage function calls in our programs. Understanding how the stack memory is managed is important for writing programs with reusable functions and crucial for writing secure programs. The stack is a common source of security vulnerabilities, especially in low-level code and assembly routines. When you use `call` and `ret` instructions, the processor doesn’t verify if the return address is valid, but it just simply pops the address and jumps on it. One of the most common problems is the [stack overflow](https://en.wikipedia.org/wiki/Stack_overflow).

[klaudiagrz]

Suggested change

	Let's take a look at the simple C function (the function is written on C for simplicity):
	Let's take a look at the simple C function:

[klaudiagrz]

I would remove that part; if you decide to keep it, correct the preposition -> written in C

[klaudiagrz]

Suggested change

	If we will try to build this program and run it, we'll see the following error instead of the *Program exited successfully* string:
	If we build and run this program, we'll see the following error instead of the `Program exited successfully` string:

[klaudiagrz]

Suggested change

The reason for this is that we put on the stack the value which is bigger than our 8 bytes buffer. Happily instead of overwriting of return address or segmentation fault error we have got "stack smashing detected" error. This check is done by the modern compiler to prevent overwriting of critical data. There are other techniques in modern compilers and operating system kernels to mitigate vulnerabilities related to stack, like:

The reason for this error is that we put on the stack a value bigger than our 8-byte buffer. Happily, instead of overwriting the return address or segmentation fault error, we get a `stack smashing detected` error. This check is done by a modern compiler to prevent overwriting critical data. There are also other techniques in modern compilers and operating system kernels to mitigate vulnerabilities related to stack, like:

[klaudiagrz]

Suggested change

	In any cases, despite all of these techniques may help you to protect your programs from stack related errors, you should be careful, especially with the data that your program receives from outside.
	Despite all of these techniques may help you to protect your programs from stack-related errors, you should be careful, especially with the external data that your program receives.

[klaudiagrz]

Suggested change

	This example might be a little bit artificial as unlikely you are going to use the `gets` function in your code. The [manual page](https://man7.org/linux/man-pages/man3/gets.3.html) of this function says:
	> Never use gets(). Because it is impossible to tell without knowing the data in advance how many characters gets() will read, and because gets() will continue to store characters past the end of the buffer, it is extremely dangerous to use. It has been used to break computer security. Use fgets() instead.
	Moreover this function is deprecated. But despite such artificial example, there can be real danger even if you are not using deprecated functions and use all the options of the compiler that help you to protect your program.
	This example might seem a bit artificial as unlikely you are going to use the deprecated `gets` function. However, even with such an unrealistic example, real risks still exist — even if you avoid deprecated functions and use all the compiler’s safety features to protect your program.

[klaudiagrz]

too much "screen time" for gets

[klaudiagrz]

Suggested change

The real world case when a wrong memory management led to serious consequences is [CVE-2017-1000253](https://nvd.nist.gov/vuln/detail/CVE-2017-1000253). This vulnerability was found in the Linux kernel and led to the [privilege escalation](https://en.wikipedia.org/wiki/Privilege_escalation). When the kernel runs a process, it needs to perform many different operations. One of such operations are to load the program into memory and initialize the stack. The binary itself is loaded and located below the stack memory. Besides that, there is a gap which is 128 megabytes. The loading of a big enough binary led to the situation when certain segments of the binary were loaded and mapped to this gap. The binaries with the big enough data segements (bingger than 128 megabytes) can end up mapped over the stack memory. All of this may lead to the situation when the [ELF .dynamic section](https://en.wikipedia.org/wiki/Executable_and_Linkable_Format) is overwritten by the stack. One may put a path to a shared library that will be loaded by the kernel and the code executed with the higher privileges. If you are interested in more details you can read the [report](https://www.qualys.com/2017/09/26/linux-pie-cve-2017-1000253/cve-2017-1000253.txt) and the [fix](https://github.com/torvalds/linux/commit/a87938b2e246b81b4fb713edb371a9fa3c5c3c86).

The real-world case when wrong memory management led to serious consequences is [CVE-2017-1000253](https://nvd.nist.gov/vuln/detail/CVE-2017-1000253). This vulnerability was found in the Linux kernel and led to the [privilege escalation](https://en.wikipedia.org/wiki/Privilege_escalation). When the kernel runs a process, it needs to perform many different operations, such as loading the program into memory and initializing the stack. After the program is loaded and stack initialized, the program is located below the stack memory, with a 128-megabyte gap between them. However, when a large program is loaded, it can overwrite the stack memory. Under certain conditions, it may lead to privilege escalation. If you are interested in more details, you can read the [report](https://www.qualys.com/2017/09/26/linux-pie-cve-2017-1000253/cve-2017-1000253.txt) and the [fix](https://github.com/torvalds/linux/commit/a87938b2e246b81b4fb713edb371a9fa3c5c3c86).

[klaudiagrz]

Suggested change

	As we've seen, subtle bugs in stack layout can lead to serious vulnerabilities.
	As you can see, subtle bugs in stack layout can lead to serious vulnerabilities.

[klaudiagrz]

Suggested change

	We’ve just written our third program using assembly — great job 🎉 In the next post, we’ll continue exploring assembly programming and see more details how to work with strings. If you have any questions or thoughts, feel free to reach out. See you in the next post!
	We’ve just written our third program using assembly — great job 🎉 In the next post, we’ll continue exploring assembly programming and see more details on how to work with strings. If you have any questions or thoughts, feel free to reach out. See you in the next post!