This fourth video of the course discuss those mimic memory management in C and C++. In C we use the malloc and free to allocate and release memory. In C++ we do the same thing using the new and the delete operator. A very good question is, does malloc initialize the memory? The short answer is no. It can remove still contain what was in the memory that had been allocated for the new use. We need to add is some note here, just because in the debug configuration deliberately and that used to allocate memory will initialize memory with data view CDX for each byte of the allocated memory. Just recommend always initialize allocated memory with known value. As recommended for to look over variable always clear important data before releasing memory. The part of the program that will allocate it and get back this memory will not at access to important data that will get close to be in the released memory? We can have the same question when using the C Plus Plus language. Does the new operator initialize the memory? The correct answer is it depends. Then new operators called the Cloud constructor. If the Cloud constructor is correctly coded, the memory will be initialized. If the constructor class is not directly coded and some part of the instance memory it will not initialized and it would contain information that will be in the memory at the time allocation. Maybe important information that other part of the program leave in memory when really seeing it. The other thing that we absolutely need to take care of when we used a new operator, is that if we use the new operator for simple type that are not class and no constructor can be called. At this time, the memory is not initialize, and the content of memory is what was left when memory will be released by other part of the program. Note that as for malloc, if you are using the debug configuration, the new operator will initialize the memory with the value CD NX. As for the malloc I recommend to always initialize allocated memory. We can trust the constructor if we are creating them. Always clear important data before releasing memory. Where this recommendation is there for clearing array as the new char we saw in the slide, or also to clearing memory in the constructor of the class. Because you maybe not believe my own word, I just want to show that had malloc and new operator does not allocate memory and how easy can be actually data. I just create a some little example that is called dynamic memory. You have it here at two function in it. One to test with using malloc and one to test using new. The test is very simple, both test are very similar. We first, allocate memory, dump it to look at what is inside the memory ones we just allocated. Put some important information in memory. Release the memory, allocate a single in black and look at what is inside this in black. First remark that I'm in the debug configuration. It was start the program right now. The program run. The first time I allocate it, it was filled with CD for each byte, and the second time I look it is the same thing. As I explained in the two slides before. This what happen when we allocate memory, and when running in debug configuration. What changed for the release configuration? Start the program again. When I started it, we have a zero and not CD as expected, but is it always zero? Good question. We can try another time. We saw that, no, it's not always zero. It's depend on when the memory is allocated, what data was in the memory at this point. If we look into the first malloc, we saw that we get some data. The second malloc, we'd also some other data. First new, some data is present. The second malloc, we saw that. I just allocated the same memory that I released just before, so I get the very important information. It will not always be the case because it depend on how the memory is managed and how the windows library alloc and re-alloc the memory. But yes, it can lead to some data leak in some circumstance. We saw how easy it is to leak data, so it's important to always initialize memory we allocate and how we always clear important information before releasing memory. In the debug configuration, if you saw cdx byte in the data that's going out of your programs, in the output stream, in the output data file or on network connection, it's an important information, and it's saying that data leak can most probably exist, or it's a very big risk, so you clearly have to investigate where this CD byte came from and how to remove them. It's now time to talk about heap randomization. Heap randomization do not reduce data leak risk, but it make it very not predictable. It instructs the library to add some random when releasing and allocating new memory. This way, a program that use a predictable way to release analog memory will not get always the same result. When I show you the first sample, I disabled the heap randomization, by default it's enabled on Windows. We'll go back to the sample, we'll re-enable it and run it a few times just to see if we get the same pattern at each time. To activate the heap randomization, we'll go in the "Property" page of the project, in the "Linker" section, and in the "Advanced" sub-section, we have a Randomized Base Address, so it randomize a little bit more than the heap. It randomized so the base address where the DLL are loaded or where the stack is put in the memory and things like that. I can disable it or enable it. For this test, I will enable it. Recompile. It's important to recompile it because the change in the Property page is not considered as a change, and if we just start the executable, it would not complete it automatically. Restart the program. We have some data in the memory. Start again. We can see that we don't have the same data in the place. Without the heap randomization in a simple program like that, that do very, very few malloc and release, and do it in a very well-controlled sequence, we will get back always the same data. But with the heap randomization enabled, we do not see the same pattern each time. The data leak we saw the previous time is always possible, we just saw that in this execution, but it will not be always at the same place, always at the same time, so it makes it very hard for a hacker to take advantage of it. It can still get some valid information and interesting information sometime, but will not be able to get this constant the [inaudible] will not be able to treat it as it could have been possible without the heap randomization. Memory leak is very different from data leak. A program leak memory when it forget to release memory after it's no longer needed. It's a bug. It's clearly a bug. A program should always release memory after using it and when it's no longer needed. It's a problem for the security too. If hackers is able to cause some memory leak, it will be able to put the programming in a state that is no more working correctly, so it can be useful for denial-of-service attack or something like that. This is the end of this video. The next video is about buffer overflow.
