anchor.diff:  
   After reading the articles linked above, you might start to see how a Use-After-Free vulnerability can be exploited. Because it is extremely expensive for a process to allocate memory through syscalls like *sbrk()* and *mmap()*, glibc *malloc()* avoids this as much as possible by maintaining sorted "bins" of unallocated memory.
   
  -When *malloc()* is called, It first uses a best-fit algorithm and searches through it's binlists for the first free chunk of adequate size. If one is found, It resizes the chunk (if necessary) and returns a pointer to the start of the chunk's data section.
  +When *malloc()* is called, It searches through its binlists for the first free chunk of adequate size. If one is found, It resizes the chunk (if necessary) and returns a pointer to the start of the chunk's data section.
   That means if we *free()* and object, then _allocate something of the same size_, there is a 99% chance that we will get a pointer to *exact same chunk that we just free'd.*
   
   But how can this be exploited?
  
positive.code: 
  > [1] Call the *introduce()* method of both the Man and Woman objects.
  
  Notice that both the Man* and Woman* from the *new* keyword are cast to *Human**. Clearly, this objects are in the same class heirarchy, and Human is a common superclass. Further still, notice that we call introduce(), _A function with the same prototype, using two upcasted objects._ Either we are calling the *introduce()* method of the Human class, or there's some as yet unseen polymorphism mechanism that de-obfuscates our function call. Running the code, you can see that *Man->introduce()* and *Woman->introduce()* _do not produce the same output for identical calls_, therefore, *they must be virtual functions.*
  
  (This is, of course, extremely obvious because the classes are both defined in this same readable file, but you can still figure out a lot without the class definitions.)
  
  
negative.code: Thinking back to the description of Vtables above, We can start to piece together what is happening here.
  
  1. *local_18h* is the start of the Vtable for this object
  2. *The second entry* of the vtable (local_18h+0x8) is the method we are calling.
  3. looking to the second *call instruction*, we can see that it uses a *the very next address* as its vtable pointer, and *the exact same 0x8 offset*.
  
  Now, thinking back to the offsets used for the Vtable pointer: We know that the Vtables of related classes *must have the same ordering*, so *local_18h+0x8* and *local_20h+0x8* must be different implementations of the same function (in this case, *introduce()*). But if *introduce()* is the second method in both these classes, What is the first? What is *local_18h*?
  
  #### Exploitation
  
  One last time, let's go back to the source code, this time looking at the *Human* class.
  
  image::/images/blog/uaf/human.png["Human class"]
  
  We can see that there is indeed a method defined before *introduce()*, which is *give_shell()*. Now all the pieces snap into place. Since *Man* and *Woman* are derived classes of *Human*, they *inherit the give_shell() function!*
  Since this is very first method defined in the class heirarchy, this must be the first method in the vtable, *local_18h* and *local_20h* (remember, inherited methods will point to the same function.)
  