From 8135d3835810455936222d78f9e2e5626513e9c0 Mon Sep 17 00:00:00 2001
From: thexappy <10898152+theXappy@users.noreply.github.com>
Date: Sat, 8 Feb 2025 10:37:43 +0200
Subject: [PATCH] Update README.md

---
 src/README.md | 51 ++++++++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 50 insertions(+), 1 deletion(-)

diff --git a/src/README.md b/src/README.md
index a58c69c7..13c32a90 100644
--- a/src/README.md
+++ b/src/README.md
@@ -12,6 +12,55 @@ But in case the internal structure interests you (or you want to contribute/fix
 6. **RemoteNET** (C#) - The one to rule them all. This library handles both injecting the Diver into the target and further communication with it (querying objects, examining them, creating new ones...).
 7. **DebuggableDummy** (C#) - A short program that runs a Diver in itself. Used for debugging.
 
+### Architecture
+When using the program, you'll be running in one of two configurations, depending on the target's type.
+The difference is "regular" apps vs UWP apps.
+
+For "regular" apps, this is where the different dlls/assemblies go:
+```mermaid
+graph LR;
+    subgraph Attacker["Attacker Process"]
+        AInner["RemoteNET"]
+    end
+    
+    subgraph Target["Target Process"]
+        TInner["ScubaDiver"]
+    end
+    
+    AInner -->|HTTP Req| TInner
+    TInner -->|HTTP Resp| AInner
+```
+
+UWP apps are run sandboxed with less networking capabilities.  
+Running a HTTP server in an arbitrary UWP app was too hard to figure out, so we use a "trick" for those:  
+Creating outgoing TCP Connections from UWP apps is often permitted. We'll abuse that to connect to a reverse proxy process called "Lifeboat".
+
+```mermaid
+graph LR;
+    subgraph Attacker["Attacker Process"]
+        AInner["RemoteNET"]
+    end
+    
+    subgraph Sanbox["UWP Sandbox"]
+        subgraph Target["UWP Target Process"]
+            TInner["ScubaDiver"]
+        end
+    end
+
+    subgraph Lifeboat["Lifeboat"]
+        LBInner["Reverse Proxy"]
+    end
+    
+    AInner -->|HTTP Req| LBInner
+    LBInner -->|HTTP Resp| AInner
+    LBInner -->|HTTP Req| TInner
+    TInner -->|HTTP Resp| LBInner
+
+    %% Custom Styling
+    classDef redBackground fill:#8B0000,stroke:#000,color:#FFF;
+    class Sanbox redBackground;
+```
+
 
 ### Diver communication
 The `ScubaDiver.Diver` class does all the heavy lifting within the target process.  
@@ -41,7 +90,7 @@ Luckily, [KeeFarce](https://github.com/denandz/KeeFarce) had this figured out. I
 It uses a trick of compiling a function directly from IL to return the `IntPtr` it recieves as the "result's address".  
  Luckily the runtime auto-magiclly converts this to an `object` when returned.  
 Getting that `object` gives us a lot of power - We can now use `.GetType()` on it, explore it's `MethodInfo`s and `PropertyInfos` and invoke them :)  
-Unfortunatly this power comes with a cost. Converting `IntPtr`s back to objects without the runtime to hold our hands is a very risky task.  
+Unfortunatly this power comes with a cost. Converting `IntPtr`s back to objects without the runtime to hold our hands is a risky task.  
 .NET's GC just turned from our best friend into our enemy.  
 If GC happens between retrival of the `IntPtr` address to actually making it into a reference the object might move around the program memory.  
 That means the address we are now going to "dereference" might be just about anything!