This document collects background information, hypothesis testing, undocumented behaviors, and experimental notes relevant during analysis of the FVE COM interface exposed by Windows.
BitLocker predates modern PowerShell cmdlets.
Internally, Windows used COM to provide:
- Volume encryption/decryption management
- Policy/APIs for OEMs and enterprises
- UI hooks for early Control Panel integrations
Much of this legacy interface remains compiled but undocumented.
The CLSID:
{A7A63E5C-3877-4840-8727-C1EA9D7A4D50}
was originally registered for elevated usage by OEM tools.
Key observations:
Windows elevates only the COM server, not the process.
Event logs rarely track COM elevation use.
Otherwise Windows returns:
0x80080005 (CO_E_SERVER_EXEC_FAILURE)
- Process is medium IL
- UAC is enabled
- ConsentPromptBehaviorAdmin ≠ 0
Since no IDL exists, DISPIDs were discovered by:
- Memory scanning of COM vtables
- Observing method invocation side-effects
- Reverse engineering
fvecpl.dlland related modules - Noting consistent ID ranges (700–800 region)
Example relevant DISPIDs:
| DISPID | Method Name | Notes |
|---|---|---|
| 519 | DoCheckForAdminRights | Returns BOOL-like value |
| 769 | DoUnlockWithPassword | Requires BSTR/password |
| 775 | DoDecrypt | Immediate volume decryption |
| 790 | DoTurnOnDeviceEncryption | No params |
| 791 | DoTurnOffDeviceEncryption | No params |
Side effects are immediate and extremely sensitive, test in a disposable VM only.
- COM server stays alive ~60 seconds after last call
- Lifetime extensions possible via
IMarshal
Some methods block until BitLocker background tasks finish.
FVE HRESULTs behave differently from classic Win32:
- Some return
S_OKbut set values in out parameters that indicate failure - Others throw COM exceptions when given empty params
These behaviors show a meaningful attack surface:
Many EDRs do not inspect COM elevation behavior.
Medium-integrity → High-integrity transitions via Windows brokered elevation.
- Disabling device encryption
- Changing protection state silently
- Forensic evasion (unlock/decrypt volumes)
This research helps defenders close these blind spots.
To extend research:
- Ghidra + COM helper scripts
oleview.exeoroleviewdotnet- API Monitor (32/64-bit)
- Procmon with COM filters
- Sysmon Event ID 1/10
- ETW:
Microsoft-Windows-COMRuntime
Always use:
- Windows 10/11 VM snapshots
- Secure boot variants
- Different UAC settings
Likely 25–30 additional methods exist.
Windows 8 → 10 → 11 may reveal deprecated functionality.
See REVERSE_ENGINEERING.md for a VM runbook to map {A7A63E5C-3877-4840-8727-C1EA9D7A4D50} to its AppID, identify the hosting dllhost.exe, and walk stack traces from IDispatch::Invoke into the server module(s).
Notably in:
- Windows Update Agent
- Disk Management
- Task Scheduler Elevation Broker
- Device Management COM layers
Most tools ignore CoGetObject + Elevation:.
This research:
- May modify system encryption state
- Is destructive when misused
- Must only be executed with explicit authorization
You are fully responsible for safe handling and compliance.
The FVE COM interface represents a rare window into legacy Windows internals.
By understanding it, researchers can:
- Improve Windows hardening
- Detect stealthy misuse
- Reveal undocumented attack surfaces
This project and its accompanying code are based on a public proof-of-concept originally shared via social media by vx-underground, demonstrating how Windows Elevation Monikers can be used to instantiate undocumented Full Volume Encryption (FVE/BitLocker) COM interfaces. Original Post
This material is provided for educational and research purposes only. It is not intended for unauthorized system access, data destruction, bypassing security controls, or production deployment.
Always obtain explicit authorization before experimenting with system internals, encryption subsystems, or privileged operations. Use only in controlled test environments or dedicated research VMs.