Exploit Development 5 - DEP Bypass with WriteProcessMemory

Subscribers:
178,000
Published on ● Video Link: https://www.youtube.com/watch?v=8kYTDK9oKV8



Duration: 19:40
10,594 views
0


DEP Bypass again, but this time using WriteProcessMemory instead of VirtualAlloc
Support us on GH: https://guidedhacking.com/register/
Support us on Patreon:   / guidedhacking  
Support us on YT:    / @guidedhacking  

DEP Bypass with WriteProcessMemory Article:
https://guidedhacking.com/threads/bin...

WriteProcessMemory is a useful option instead of VirtualAlloc in avoiding DEP exploits. Which method to use commonly depends on the circumstances, so it is important to know the various approaches a hacker may use.

0:00 Introduction
0:30 WPM Overview
2:19 Code Caves
3:45 Setting up and using code caver
9:00 Obtaining the IAT
10:33 Writing the ROP chain
17:00 Testing the exploit

DEP was created to prevent exploitation of vulnerabilities like Buffer Overflows. It uses the NX/XD bit to designate certain memory areas as non-executable, so if shellcode from a Buffer Overflow is placed on the stack, an access violation will occur as the stack isn't meant to contain anything executable. Last time, DEP was circumvented via a ROP chain calling VirtualAlloc to make the shellcode page executable (0x40). This time, WriteProcessMemory will be used in the ROP chain to bypass DEP stack protection. This DEP Bypass tutorial will teach you exactly how to use it to your advantage.

WriteProcessMemory (WPM) is a Windows API function which can be utilized to avoid DEP, similar to VirtualAlloc. The WPM prototype is simple, but also necessitates some runtime computations.

A code cave is an empty memory region created by a compiler that has READ and EXECUTE permissions, necessary for the WriteProcessMemory technique to work. It is there that our exploit's shellcode can be executed to start our DEP bypass.

Note that WRITE permissions are not required; this is due to WriteProcessMemory making the memory region writable when getting called, then copying the data and restoring the original permissions again before returning. Using a code cave isn't necessary, but rewriting memory with code or data in used areas could lead to a crash. It's best to prevent this, especially if re-exploiting is needed.

That sums up part 5 of our DEP bypass tutorial series.

Follow us on Facebook : http://bit.ly/2vvHfhk
Follow us on Twitter : http://bit.ly/3bC7J1i
Follow us on Twitch : http://bit.ly/39ywOZ2
Follow us on Reddit : http://bit.ly/3bvOB57
Follow us on GitHub : http://bit.ly/2HoNXIS
Follow us on Instagram : http://bit.ly/2SoDOlu

DEP Bypass with WriteProcessMemory
binary exploitation
return oriented programming
Exploit Development
dep bypass
data execution prevention
binary exploitation tutorial
binary exploitation rop
data execution prevention exception
binary exploitation full course
data execution prevention windows
binary exploitation course
buffer overflow
bypass dep
how to dep bypass







Tags:
binary exploitation
return oriented programming
data execution prevention
binary exploitation tutorial
binary exploitation rop
binary exploitation full course
binary exploitation course
buffer overflow
data execution prevention exception
data execution prevention windows
dep bypass
bypass dep
how to dep bypass
exploit development tutorial
exploit development
exploit development course