Source code review
5 min read

BDO Companion: pipe authorization, UIAccess, and signing

A security review of the downloaded BDO Companion 0.7.3 and bundled IQON Overlay 0.8.0, focused on Windows IPC, privileges, and package trust.

Date
30 September 2026
Outcome
Source review
Focus
BDO Companion 0.7.3 + IQON Overlay 0.8.0 · offline binary metadata and IPC review

Review date: 30 September 2026. Method: offline package and existing static-evidence review. Target: supplied BDO Companion 0.7.3 package and its bundled IQON Overlay 0.8.0, which has a separate version. This is a desktop-application security review; game internals are outside its scope.

The strongest findings concern two boundaries that deserve separate treatment: Windows authorization on the local overlay pipe, and the overlay's requested UIAccess privilege. Neither the presence of encryption nor an embedded signing certificate establishes that these boundaries are secure. This review identifies what the artifact actually shows and what would need validation before claiming an exploit.

Artifact identity and method

ArtifactSHA-256Verification on review date
Companion MSIfee1318f1579361d0458945e6371d9e3bf75096090e7619f76c109a26d49978eHistorical extraction record; original installer unavailable locally.
Main executable payloada5c1e4e3a0da5aa8a71af0b090e40af7f6d6db13dbb213c93cd1d26495c9c635Recomputed from the available extracted file.
IQON Overlay executable52bbdb52ea9e6d884ff526fa023c3630aee6c172f15c8545933c1027996aa375Recomputed from the available extracted file.

Earlier offline interoperability analysis was recorded in August 2026. This security review adds executable metadata, import and compiled-marker inspection, reads the existing targeted pipe evidence, and interprets those observations using primary platform documentation. No downloaded executable was launched, no installer was run, and no vendor API was contacted. The report distributes original prose rather than application source, assets or decompiler output.

The overlay pipe uses default Windows authorization

The existing focused pipe-creation evidence shows a CreateNamedPipeW call whose security-attributes argument is null. Its implication is precise: this call does not supply an application-specific security descriptor. It does not imply a null DACL or unrestricted access.

Microsoft documents a default descriptor that gives full control to LocalSystem, administrators and the creator owner, with read access for Everyone and the anonymous account. Connection access still depends on requested rights, the descriptor and Windows policy. A session-specific logon SID is the documented approach for excluding other sessions. Microsoft: named-pipe security.

The packaged parent creates a fixed endpoint and launches the overlay with that endpoint as an argument. The overlay also accepts an endpoint override. These observations identify where to examine peer identity; a predictable name alone is not proof that another process can impersonate either peer. The recovered wrapper's open and pipe modes are derived from caller parameters, so first-instance exclusivity and rejection of remote clients were not established by this review.

The overlay has an outer length-delimited frame limit of 8 MiB and initializes separate directional encryption states. That is useful evidence of framing and confidentiality machinery. It leaves authentication unanswered: the exact key derivation and encrypted message representation remain unresolved. The cap also bounds an individual frame, not connection count, message rate or total memory use.

Disposition: confirmed default-security-descriptor use; peer authentication and effective cross-user access remain unverified. A focused validation would inspect the live pipe DACL under a disposable installation, check session restrictions and determine whether the application rejects an unexpected peer before interpreting messages. A recommendation to use an explicit session-scoped descriptor is hardening advice, not a proven unauthorized-write vulnerability.

UIAccess changes the overlay's trust requirements

The overlay's embedded manifest explicitly requests asInvoker with uiAccess=true. These are different controls. asInvoker does not itself request administrator elevation. UIAccess is a request for interaction across user-interface privilege boundaries, subject to Windows acceptance rules.

Microsoft documents that UIAccess requires an appropriately trusted digital signature, and that secure-location policy ordinarily constrains where such applications may reside. Its benefit to an overlay does not eliminate the need to protect the executable and the inputs controlling its window behavior. Microsoft: UIAccess policy.

The available main and overlay files both contain Authenticode certificate-table data. Certificate parsing found an IQON Digital LLC certificate in those structures. This is evidence of embedded signing material, not a successful signature check: file-digest validation, trusted-chain evaluation, timestamp policy and revocation were not performed. A certificate can remain present in a modified file.

The original MSI was unavailable, so this review could not inspect its installation tables, custom actions or final directory permissions. It cannot establish whether Windows grants UIAccess, whether the installed location meets policy or whether a different local user can replace the overlay. The existing bootstrap evidence confirms a shell launch with an endpoint argument; it does not establish an elevation bypass.

Disposition: confirmed manifest request with unverified runtime acceptance. The security question is whether a potentially more capable UI process trusts only its intended parent and executes from a protected location.

The webview and updater need application-specific proof

The main payload is Rust/Tauri, not Electron. Applying Electron settings such as nodeIntegration or contextIsolation to this binary would answer the wrong question. Compiled markers identify Tauri 2.11.3, updater plugin 2.10.1 and opener plugin 2.5.4. Markers establish included dependency provenance; they do not reconstruct enabled capabilities or command reachability.

Tauri capabilities govern which windows and webviews can invoke native commands, with permissions from overlapping capabilities combining. This review did not recover the deployed capability configuration, effective CSP, navigation policy or custom command validation. It therefore cannot claim either an unrestricted bridge or a correctly restricted one. Tauri: capabilities.

Updater-plugin presence likewise does not prove an active, correctly configured update path. Tauri's documented updater verifies signed artifacts using its configured public key and normally enforces HTTPS; transport configuration and artifact-signature trust are distinct checks. The app's actual endpoint selection, trusted key, enabled commands and handling of failure were not reconstructed. No update metadata was requested. Tauri: updater.

Storage, conclusions and remaining evidence

Registry and certificate APIs appear in the imports, but API presence cannot show what account data is persisted or whether diagnostic output exposes secrets. No real user profile, credential store or application log was inspected. Encryption at rest, redaction and retention therefore remain unassessed rather than presumed absent.

The review establishes a default-descriptor pipe creation path, a separate UIAccess-requesting overlay and embedded signing material whose validity has not been checked. Their combination supplies a concrete follow-up: verify installation ACLs, effective UIAccess, pipe peer authorization and the encrypted handshake together.

← All researchNext article