Added a few bugs/expoits of my own

README.md

@@ -1,3 +1,14 @@
+https://discord.gg/WytKH65ZR join up for research, help, documentation, and more useful information for those interested.
+
+# News/Contact
+
+Credit for the objdump finding goes to someone who beat me to it (and has a better PoC): https://github.com/4D4J/objdump-Out-Of-Bounds-write
+
+New drops today ;) Biggest thing yet (DELAYED, I PROMISE THE WAIT WILL BE WORTH IT! After this, you guys will *usually* get one new PoC a day)
+
+I've also noticed a surprising amount of "security researchers" aren't able to adjust the PoC to work in their environment. I will broaden the PoCs for those select few...
+
+If you wish to collaborate/discuss with me, contact me on discord @ashdfrkl
 # Statement
 
 This repo was incomplete when published. 
@@ -22,6 +33,37 @@ A consolidated archive of my public proof-of-concept and vulnerability research
 
 Most folders contain one of my former standalone PoC repos, preserved with its original README and tracked files. New research entries are added directly here as self-contained folders.
 
+## Contributed Research (by [Unrealisedd](https://github.com/Unrealisedd))
+
+The following entries were contributed via PR:
+
+| Folder | Description |
+| --- | --- |
+| `openvpn-UAF-BYOVD` | ovpn-dco-win kernel driver CNG key UAF + crash PoC |
+| `storsvc-dll-hijack-lpe` | StorSvc `LoadLibraryW("SprintCSP.dll")` without `LOAD_LIBRARY_SEARCH_SYSTEM32` |
+| `dam-sys-kernel-bugs` | dam.sys: 3 kernel bugs from standard user (BSOD + confused deputy + Defender freeze) |
+| `seb-service-auth-bypass-lpe` | Safe Exam Browser SYSTEM service auth bypass → RCE as SYSTEM via log injection |
+| `defender-signature-lock-bypass` | CVE-2026-45498 patch bypass: `FILE_SHARE_READ` locks Defender signatures |
+| `discord` | Discord Desktop RCE attack paths |
+| `wazuh` | Wazuh stack BOF + SCA DoS |
+| `nextcloud` | XXE file read/SSRF + SSRF protection bypass |
+| `n8n-ssrf-via-oauth2` | SSRF via OAuth2 callback in n8n |
+| `fluentbit-infinite-dos` | Fluent Bit collectd parser unauth DoS loop |
+| `librenms-RCE-chain` | LibreNMS SSTI to RCE chain |
+| `overwolf-updater-lpe-poc` | Overwolf Updater forged Authenticode cert + insecure service DACL → SYSTEM LPE |
+| `spacedesk-service-lpe-poc` | spacedesk service Everyone full-control DACL → SYSTEM in 3 commands |
+| `woodpecker-yaml-cr-injection` | Woodpecker CI pipeline RCE via `\r` YAML injection bypass |
+| `retroarch-chd-map-heap-overflow` | RetroArch libchdr integer overflow → heap OOB write on 32-bit |
+| `defender-ntlm-coercion-poc` | Windows Defender NTLM coercion: standard user forces SYSTEM credential leak via UNC scan |
+| `‎keep-provider-invoke-unauth-rce-poc` | Unauthenticated RCE chain in the keep monitoring system |
+| `mysql-router-mrs-oauth-cached-name-ato-poc` | MySQL Router MRS OAuth display-name cache collision → account takeover (CVSS 9.1) |
+| `firefox-cert-override-sandbox-escape-poc` | Firefox IPC sandbox escape: unvalidated `AddCertException` → silent MITM on arbitrary hostnames |
+| `mosquitto-builtin-websocket-preauth-rce-poc` | Eclipse Mosquitto built-in WebSocket pre-auth RCE via empty-frame heap overwrite (v2.1.0-v2.1.2) |
+| `paho-mqtt-websocket-queued-frame-uaf-poc` | Paho MQTT C WebSocket queued-frame UAF: ASan UAF + allocator overlap + marker PC transfer |
+| `nanomq-rule-republish-cjson-uaf-poc` | NanoMQ rule republish cJSON UAF/double-free: 5/5 ASan + 5/5 release crash |
+| `samba-dns-mx-forwarder-talloc-uaf-poc` | Samba internal DNS forwarded MX talloc parent UAF: one-record ASan + two-record deterministic abort |
+| `bitlocker-bootmgfw-type15-oob-dos` | bootmgfw.efi type-0x15 collector/selector count mismatch: persistent boot DoS + escalation to irrecoverable data loss |
+
 ## Contents
 
 | Folder | Source | Tracked entries |
@@ -30,6 +72,7 @@ Most folders contain one of my former standalone PoC repos, preserved with its o
 | `anydesk-printer-com-impersonation-poc` | `7491303301093b2d40bee9dadf6b38f757ce78e0` | 4 |
 | `c-ares-tcp-uaf-calc-poc` | direct entry, June 24, 2026 | 7 |
 | `curl-smtp-expn-recipient-crlf-injection` | direct entry, July 1, 2026 | 3 |
+| `defender-ntlm-coercion-poc` | direct entry, July 6, 2026 | 3 |
 | `discord-activity-stock-client-rce-poc` | direct entry, July 14, 2026 | 8 |
 | `discourse-scoped-api-key-preauth-bypass` | direct entry, July 3, 2026 | 3 |
 | `docker-cp-copyout-destination-escape` | `d1367b1381736d7f961ac808ce88d4e24a633adc` | 5 |
@@ -64,6 +107,13 @@ Most folders contain one of my former standalone PoC repos, preserved with its o
 | `redis-vset-duplicate-hnsw-id-rce-poc` | direct entry, July 3, 2026 | 3 |
 | `rustdesk-session-permission-pocs` | direct entry, June 25, 2026 | 17 |
 | `systeminformer-phsvc-trusted-host-lpe-poc` | direct entry, June 24, 2026 | 3 |
+| `firefox-cert-override-sandbox-escape-poc` | direct entry, August 10, 2026 | 1 |
+| `mysql-router-mrs-oauth-cached-name-ato-poc` | direct entry, August 10, 2026 | 7 |
+| `mosquitto-builtin-websocket-preauth-rce-poc` | direct entry, August 13, 2026 | 6 |
+| `nanomq-rule-republish-cjson-uaf-poc` | direct entry, August 20, 2026 | 4 |
+| `paho-mqtt-websocket-queued-frame-uaf-poc` | direct entry, August 21, 2026 | 7 |
+| `samba-dns-mx-forwarder-talloc-uaf-poc` | direct entry, August 21, 2026 | 4 |
+| `bitlocker-bootmgfw-type15-oob-dos` | direct entry, August 21, 2026 | 4 |
 | `vlc-vp9-reschange-crash-poc` | `fae72b82f24d03cf2fb9cb55fbb2e7774f684ff3` | 3 |
 
 ## Consolidation Check

bitlocker-bootmgfw-type15-oob-dos/README.md

@@ -0,0 +1,155 @@
+# Persistent Boot DoS in bootmgfw.efi via FVE Metadata Count Mismatch
+
+## Summary
+
+The Windows Boot Manager (`bootmgfw.efi`) contains a count/capacity mismatch in the function that collects type-0x15 child datums from a BitLocker recovery-password VMK. The collector iterates all matching children and reports the total count, but only stores up to five pointers in a fixed-size stack array. Its caller trusts the reported count without bounds-checking and reads one slot past the end of the array when six children are present, landing on the stack cookie. The cookie is dereferenced as a datum pointer, causing a fault on unmapped memory.
+
+Because the malformed metadata lives on disk, the crash happens on every boot attempt. The machine becomes unbootable until the FVE metadata is manually repaired from external recovery media.
+
+## Affected Component
+
+| Field | Value |
+|-------|-------|
+| Binary | `bootmgfw.efi` |
+| Tested build | SHA256 `490d08f9...3d857274` |
+| Collector function | RVA `0x1ff6b4` |
+| Selector function | RVA `0x1ffaa8` |
+| Vulnerable instruction | RVA `0x1ffbda` (read of `[RCX+0x18]` where RCX = cookie) |
+
+## Root Cause
+
+Two functions work together to find type-0x15 children inside the recovery-password VMK datum. I'm calling them the **collector** and the **selector** based on their roles.
+
+### The collector (RVA 0x1ff6b4)
+
+This function walks the VMK's child datums looking for type-0x15 entries. It has a local array of 5 `qword` pointers on the stack and a counter (`BP`) that starts at zero. For each matching child:
+
+```asm
+; At 0x1ff7b3 inside the collector
+CMP   BP, 0x5                    ; is the counter below the array size?
+JNC   skip_store                 ; if >= 5, don't store the pointer
+MOVZX EAX, BP
+MOV   [R12 + RAX*8], RDI        ; store pointer at array[counter]
+skip_store:
+INC   BP                         ; always increment -- even when we skipped the store
+```
+
+When it returns, the counter holds the *actual* number of type-0x15 children found (e.g. 6), but the array only holds the first five pointers. The function writes the counter to an output parameter and returns success.
+
+### The selector (RVA 0x1ffaa8)
+
+The selector calls the collector, then loops over the returned count to process each pointer:
+
+```asm
+; The selector's loop starting around 0x1ffb78
+INC   R13D                       ; increment loop counter
+...
+MOV   RCX, [RBX]                 ; load pointer from array[i]
+...
+MOVZX EAX, word ptr [RCX+0x18]  ; dereference it as a datum -- reads type field  ← CRASH
+ADD   RBX, 8                     ; advance to next slot
+```
+
+On the sixth iteration, `RBX` points past the array into the stack cookie slot. The cookie value gets loaded into `RCX` and dereferenced as a datum pointer, faulting on unmapped memory.
+
+> **The gap:** The collector bounds-checks the *store* but not the *count*. The selector trusts the count without checking it against the array capacity. Neither function is wrong in isolation -- the bug is in the contract between them.
+
+## Trigger
+
+An attacker modifies the on-disk FVE metadata to add a sixth type-0x15 child datum to the recovery-password VMK. BitLocker stores three redundant copies of its metadata, so all three need to be patched for the change to survive validation.
+
+The type-0x15 datum is a 28-byte (0x1C) structure. Inserting one requires:
+
+- Appending the datum to the VMK's child list
+- Updating the VMK datum size field
+- Updating the dataset size and end fields
+- Updating the information block size field
+- Recalculating the validation area CRC32
+
+This is a structurally valid mutation -- the metadata passes all format validation checks. The only thing wrong with it is that there are six children instead of the expected five-or-fewer.
+
+## Attack Scenario
+
+1. Attacker gains raw disk write access to a BitLocker-encrypted volume (physical access via USB boot, or local admin / raw volume access on a running system)
+2. Attacker locates the three FVE metadata copies (they start with the signature `-FVE-FS-` and are at fixed offsets)
+3. Attacker inserts a sixth type-0x15 child into the recovery-password VMK in each copy and fixes up the size/CRC fields
+4. On next boot, `bootmgfw.efi` parses the metadata, the collector reports count=6, the selector reads past the array, and the boot manager crashes
+5. Every subsequent boot attempt hits the same crash -- the machine is bricked until the metadata is repaired from external recovery media
+
+## Impact
+
+**Primary: persistent denial of service.** The system is unbootable. The crash happens before the BitLocker recovery prompt, so even entering a valid recovery key is impossible. The user cannot self-recover without external tools and knowledge of the FVE metadata format.
+
+**Secondary: data loss through metadata destruction.** The encrypted volume data itself is intact after the basic trigger, but a typical user encountering a persistent boot loop on an encrypted machine is likely to conclude the data is unrecoverable and reformat -- that alone makes this a practical data-loss vector.
+
+With some additional work, this can be escalated to complete, irrecoverable data loss:
+
+- **Corrupt all three FVE metadata headers.** BitLocker stores three redundant copies of its metadata. The basic PoC already patches all three to trigger the crash. If the attacker goes further and zeroes or corrupts the metadata header signatures (`-FVE-FS-`) across all three copies, the volume becomes unrecognizable as a BitLocker volume entirely. Recovery tools like `manage-bde` or `repair-bde` rely on at least one intact metadata copy to locate the VMK and decrypt the volume. With all three gone, the volume is just raw encrypted bytes with no key material on disk.
+
+- **Destroy the recovery-password VMK itself.** Even if the victim saved an external recovery key (the 48-digit numerical password), that key is useless without the corresponding VMK datum to unwrap. The recovery key doesn't decrypt the volume directly -- it unwraps the VMK, which in turn holds the FVEK (Full Volume Encryption Key) that actually decrypts the data. If the attacker overwrites or zeroes the VMK datum contents inside the FVE metadata (not just the type-0x15 children but the VMK's key material itself), the chain breaks: recovery key -> VMK -> FVEK -> data. No VMK means the recovery key has nothing to unwrap, and the FVEK is never recoverable.
+
+- **Wipe the TPM protector.** If the machine uses TPM-based unlock (which most BitLocker deployments do), the TPM-sealed VMK protector is another path to the FVEK. Corrupting or zeroing the TPM protector datum in addition to the recovery VMK eliminates this fallback too.
+
+The result: even a victim who diligently saved their recovery key to a USB drive or printed it out cannot recover the volume. Every path from key material to FVEK is severed. The data is cryptographically intact on disk but permanently inaccessible -- effectively destroyed.
+
+All of this requires the same level of access as the basic DoS (raw disk writes to a powered-off volume), and the same patching approach (locate FVE metadata, modify datums, fix up sizes and CRCs). The PoC's existing `build_type15_overcount.py` library already knows how to parse and modify the FVE structure at this level.
+
+## Emulation Evidence
+
+I emulated the exact `bootmgfw.efi` collector and selector code using Unicorn Engine with six type-0x15 children. The surrounding functions (iterator, extractor, validator, allocator, free) are stubbed at their call boundaries.
+
+| Iteration | Slot address | Value loaded | Source |
+|-----------|-------------|-------------|--------|
+| 0 | `0x701fdf58` | `0x60002000` | array[0] -- valid |
+| 1 | `0x701fdf60` | `0x60002100` | array[1] -- valid |
+| 2 | `0x701fdf68` | `0x60002200` | array[2] -- valid |
+| 3 | `0x701fdf70` | `0x60002300` | array[3] -- valid |
+| 4 | `0x701fdf78` | `0x60002400` | array[4] -- valid |
+| 5 | `0x701fdf80` | `0x2b995dc07d32` | **stack cookie** |
+
+On iteration 5, the slot address (`0x701fdf80`) matches `RBP - 0x19`, which is where the `/GS` stack cookie is stored. The cookie value `0x2b995dc07d32` is loaded and dereferenced as a datum pointer. The read at `cookie + 0x18` = `0x2b995dc07d4a` faults with `UC_ERR_READ_UNMAPPED`.
+
+## Reproduction
+
+### Prerequisites
+
+- A VirtualBox VM with a BitLocker-encrypted Windows installation (powered off)
+- Python 3.10+ with `pefile` installed
+
+### Quick path -- patch only
+
+```bash
+# Clone the VM disk to a standalone VDI first
+VBoxManage clonemedium disk <source.vdi> target.vdi --format VDI
+
+# Dry run -- shows what would change
+python poc_patch_fve.py target.vdi
+
+# Apply the patch
+python poc_patch_fve.py target.vdi --apply --output evidence.json
+
+# Boot the VM -- observe crash
+```
+
+## Suggested Fix
+
+Either cap the reported count to the array capacity in the collector, or have the selector bounds-check the count before iterating. The simplest fix in the collector:
+
+```asm
+; After the iteration loop, before writing the count to the output parameter:
+CMP   BP, 0x5
+JBE   count_ok
+MOV   BP, 0x5          ; clamp to array capacity
+count_ok:
+MOV   [R15], BP
+```
+
+---
+
+## Files Included
+
+| File | Description |
+|------|-------------|
+| `poc_patch_fve.py` | Standalone PoC -- patches a VDI with 6 type-0x15 children |
+| `build_type15_overcount.py` | Low-level FVE metadata mutation library |
+| `vdi_type15_overcount.py` | VDI image I/O and patch orchestration |