My Journey into eCXD – eLearnSecurity Certified eXploit Developer

Exploit Developer Student – XDS Course Review

I first want to thank eLearnSecurity for creating such a course on this topic of exploit development. I have always been a big fan of the Windows operating system. For the past few years, I have spent a lot of time on Windows reverse engineering, Windows internals and exploit development on Windows. However, the thing I liked the most about this course is about the diversity they have with both Windows and Linux both x86 and x86_64. I spent quite a good amount of time on learning Linux exploit development and internals and I totally loved to understand those concepts no matter how hard they were to grasp. It is a feeling I cannot explain 😊

I will share my thoughts on each section.

Linux Exploit Development

Module 1: Linux Stack Smashing

As usual, this is the introductory module where you will get a nice understanding of Linux internals and basics of stack-based buffer overflows and identifying them.

The labs included for this module are:

  • Hidden Function
  • Linux Basic Stack Overflow
  • Linux x64 Basic Stack Overflow

Module 2: Linux Exploit Countermeasures & Bypasses

This section was an intense module on bypassing Linux exploitation mitigation techniques. The following were covered in-depth with examples. I believe this was the largest module in this section. I’ve learned a lot of internals, theory and new things in this module in the world of *nix.

  • NX
  • ASLR
  • Stack Cookies
  • PIE

Module 3: Linux Return Oriented Programming

This module explains the concepts of Return Oriented Programming (ROP) and how to utilize this technique to bypass anti-exploit mechanisms. I would recommend to first study Module 2 related to anti-exploit mechanisms and then move on to this module and do the labs. As you need theory from both of these modules for the labs.

The labs included for these 2 modules are:

  • Linux NX Bypass (ret2libc)
  • Overcome ret2libc Limitations
  • Linux x64 ASLR Bypass
  • Linux x64 Stack Canary, NX & ASLR Bypass
  • Linux x64 NX Bypass (ret2libc + ROP)

Module 4: Linux Shellcoding

This module explains about developing Linux shellcode and concepts such as Egghunters to detect the shellcode in memory when there’s lack of space in the stack. A full walkthrough of 32-bit reverse TCP shellcode is explained with socket internals. Furthermore, developing 64-bit shellcode on Linux is explained.

The lab included for this module is:

  • Linux Shellcoding

Module 5: Linux Advanced Exploitation

To come to this module, make sure you study all the previous module well. This module explains in-depth about exploiting format string vulnerabilities and how it could be abused to bypassing anti-exploit mechanisms. Also covers bypassing hardened systems. This module has some intense labs and it was very challenging to understand the exploitation process. I loved this module a lot as these types of vulnerabilities can be abused to bypass modern anti-exploit mechanisms and are still being reported in the real world in commercial applications.

  • Linux NX & ASLR Bypass (Format String Exploitation + ROP)
  • Strict Firewall Bypass (Format String Exploitation + Socket Reuse Shellcode)

Windows Exploit Development

Module 1: Windows Stack Smashing

This module explains the basics of exploiting stack-based buffer overflows in Windows systems. You will learn different tools to automated certain tasks and internals.

The labs included for this module are:

  • Windows Basic Stack Overflow

Module 2: Windows SEH-based Overflows

This module explains about abusing software which utilized the Structured Exception Handling mechanism under Windows systems. The labs will provide you more understanding practically how it works under a debugger.

The labs included for this module are:

  • Windows SEH Overflow (MP3 Studio)
  • Windows SEH Overflow (EasyChat)

Module 4: Unicode Buffer Overflows

This module explains the process of creating venetian shellcode and utilizing it in Unicode Buffer Overflow exploits. This technique is useful if the application changes user input in case of translation.

Module 5: Windows Shellcoding

This module explains the art of shellcoding in Windows. It also goes in-depth on developing position independent shellcode on Windows. This module also includes a socket reuse shellcode and about backdooring PE files

The labs included for this module are:

  • Windows Shellcoding

Module 6: Windows Return Oriented Programming

This module explains the Return Oriented Programming (ROP) theory on Windows. This module was also intense as it dives deep into manual ROP chaining. I really loved this module as I learned a lot about developing my own manual ROP chains.

The labs included for this module are:

  • Windows ROP (Scenario 1)
  • Windows ROP (Scenario 2)

Fuzzing Windows Software

This was another lab exercise on explaining the usage of the SPIKE fuzzer.

The Exam

The exam was challenging. It was of 3 days and another 2 days were provided for the report. Since there were 3 days I did not have that much stress. There were 5 challenges in total for both Windows and Linux environments x86 and x86_64. There are no multiple-choice questions and it’s a full practical exam. You are supposed to develop a proof-of-concept for each challenge and document down your process, tools used, etc. Everything is well taught in the course and if you study the materials and do the labs your passing chances are high.

The following knowledge domains will be assessed in the exam.

  • Windows and Linux internals
  • Reverse engineering (x86 and x64 platforms)
  • Software debugging
  • Shellcoding
  • Windows and Linux exploit development (including scripting knowledge)
  • Bypassing modern anti-exploit mechanisms (ASLR/PIE, Stack Cookie, NX/DEP, RELRO etc.)
  • Exploiting hardened hosts and overcoming limitations

A huge thanks to Łukasz Mikuła for creating this course and for assessing my exam report. Special thanks to Dimitrios Bougioukas from eLearnSecurity 🙂

More information about the XDS Course:


Alternatives to Extract Tables and Columns from MySQL and MariaDB

I’ve previously published a post on extracting table names when /or/i was filtered which leads to filtering of the word information_schema. I did some more research into this area on my own and found many other tables where you can extract the table names. These are all the databases and tables I found where we can extract table names apart from ‘information_schema.tables’. I have tested the following in 5.7.29 MySQL and 10.3.18 MariaDB. There are 39 queries in total.


These views were added in MySQL 5.7.9.


Bypassing the WebARX Web Application Firewall (WAF)

WebARX is a web application firewall where you can protect your website from malicious attacks. As you can see it was mentioned in TheHackerNews as well and has good ratings if you do some Googling.

It was found out that the WebARX WAF could be easily bypassed by passing a whitelist string. As you see the request won’t be processed by the WAF if it detects a whitelist string.

Let’s first try on their own website. This is a simple LFi payload.


WQL Injection

Generally in application security, the user input must be sanitized. When it comes to SQL injection the root cause most of the time is because the input not being sanitized properly. I was curious about Windows Management Instrumentation Query Language – WQL which is the SQL for WMI. Can we abuse WQL if the input is not sanitized?

I wrote a simple application in C++ which gets the service information from the Win32_Service class. It will display members such as Name, ProcessId, PathName, Description, etc.

This is the WQL Query.

As you can see I am using the IWbemServices::ExecQuery method to execute the query and enumerte its members using the IEnumWbemClassObject::Next method. (more…)

Unloading the Sysmon Minifilter Driver

The binary fltMC.exe is used to manage minifilter drivers. You can easily load and unload minifilters using this binary. To unload the Sysmon driver you can use:

fltMC unload SysmonDrv

If this binary is flagged, we can unload the minifilter driver by calling the ‘FilterUnload’ which is the Win32 equivalent of ‘FltUnloadFilter’. It will call the minifilter’s ‘FilterUnloadCallback’ (PFLT_FILTER_UNLOAD_CALLBACK) routine. This is as same as using fltMC which is a Non-mandatory unload.
For calling this API SeLoadDriverPrivilege is required. To obtain this privelege adminsitrative permissions are required.

Here’s a simple C code I wrote to call the ‘FilterUnload’ API.

MiniDumpWriteDump via Faultrep!CreateMinidump

I found out this old undocumented API “CreateMinidumpW” inside the faultrep.dll on Windows XP and Windows Server 2003. This API ends up calling the dbghelp!MiniDumpWriteDump to dump the process by dynamically loading the dbghelp.dll on runtime.

The function takes 3 arguments. I really have no clue what this 3rd argument’s structure is. I passed 0 as the pointer to the structure so by default we end up getting 0x21 as the MINIDUMP_TYPE.


Running Shellcode Directly in C

Here’s a cool thing I figured out in position-independent code. I would rephrase the title as running position-independent code instead of shellcode. Check my previous article Executing Shellcode Directly where I used a minimal PE and pointed the AddressofEntryPoint to the beginning of the PIC.

So the goal is to run shellcode in C without any function pointers or any functions at all, not even a main function 🙂 For example, this is all the code. I declare the variable name as “main”. I am using the Microsoft’s Visual C compiler with no parameters.

After compiling it won’t of course run. Why? Well, the initialized data will end up in the “.data” section.


Converting an EXE to a DLL

I’ve been doing some crazy experiments on running an EXE as a DLL. Here are some parts of my research.

Case #1

Let’s take a simple example like a MessageBox.

After compiling to an EXE we have to change the characteristics under NT Header->File Header to a DLL file. I will use the value 0x2000 | 0x2| 0x100 = 0x2102.


Random Compiler Experiments on Arrays

One day a guy asked me how to print a 2d string array in C. So I coded an example for him. But just for curiosity, I examined the assembly code. In C both string[0][1] and *(*string + 1) are the same. But in reality, the compiler writes the assembly code in 2 different ways. If we use string[0][1] it will directly move the value from the stack. When we dereference a pointer *(*string + 1) it will actually dereference the address pointed inside the register. This happens only in the MinGW GCC compiler. I compiled this using the latest on Windows which is 8.2.0-3 by the time I am writing this.

The assembly code in the left is this one.

#include <stdio.h>
int main() {
    char *string[][2] = { 
    printf("%s %s\n", string[0][0], string[0][1]);

The assembly code on the right is this.

#include <stdio.h>
int main() {
    char *string[][2] = { 
    printf("%s %s\n", **string, *(*string + 1));