Security & privacy

Understand security warnings and privacy limits

Check the file and its warning before allowing it to run. A working Oblivion connection does not guarantee anonymity or prevent traffic from escaping when the tunnel stops.

Desktop v3.11.0 · Installer and code checks do not replace live leak tests; those have not been performed.

Check the exact file before you run it

Start from Oblivion Desktop releases, under bepass-org/oblivion-desktop. Match the release, operating system, architecture and filename. The separate bepass-org/oblivion project and third-party repackages are not the same Desktop build. Use the download guide if you are unsure which package fits.

We checked the v3.11.0 Windows x64 installer on 5 November 2026, without running it:

Check Result
File oblivion-desktop-win-x64.exe from release v3.11.0
Size 119,802,453 bytes
SHA256 0f6ff465934848c843c2d93a20aea0b9767dd4117677431033174c8e869378bb
File identity Our calculated SHA256 matches the GitHub release asset digest.
Embedded signature No Authenticode certificate table in this installer. Windows catalog signing and certificate trust were not tested.

These results apply to that file only, not the portable ZIP, another architecture or a later upload. A matching hash confirms the downloaded bytes match the published reference; it does not establish that the software is harmless. Exact release

In PowerShell, opened in the folder containing your download, these read-only commands show its hash and Windows signature information:

Get-FileHash -LiteralPath '.\oblivion-desktop-win-x64.exe' -Algorithm SHA256
Get-AuthenticodeSignature -LiteralPath '.\oblivion-desktop-win-x64.exe' | Format-List Status,StatusMessage,SignerCertificate

Replace the filename if needed, then compare with the reference for the same release and package. If the hash differs, do not run the file: recheck your selection and download again from the release page. A signature identifies a signer and integrity status; it is not a malware verdict. These commands do not change a setting, so there is nothing to undo. Microsoft: file hashes · Signature information

Read the warning, not just the app name

Before allowing a blocked file, record the detection name, affected file path, release, SHA256 and antivirus definition date. An alert for warp-plus.exe is not an alert for the installer; checking the installer’s hash does not identify a quarantined component.

  • SmartScreen / “unrecognized app”: this can be a file or publisher reputation warning, even for signed software. Unknown publisher means the publisher identity is not verified; neither message alone is a malware finding. Check the source, hash and signature before deciding, and leave the app blocked if you cannot establish trust. A NotSigned signature status is not a malware diagnosis, and Valid is not a clean scan. Microsoft: SmartScreen reputation
  • Malware detection: keep the file blocked while you investigate. Update the antivirus definitions and request the vendor’s assessment of the exact file.
  • Potentially unwanted application (PUA): Microsoft distinguishes this from malware, but the warning still deserves review. It is not an automatic approval to run the app. Microsoft’s explanation
  • not-a-virus / Server-Proxy: an older Kaspersky report classified warp-plus.exe as legitimate proxy software that could be misused. That category is different from a malware finding, and is not a certificate of safety. Historical report #264

The project’s antivirus guide describes past detections as false positives. That is the project’s explanation of those cases, not proof that every current alert is false. Leave an uncertain file in quarantine; for Defender, use Microsoft’s file-submission service to request analysis.

What about VirusTotal or ANY.RUN?

The project’s VirusTotal image is historical, not a scan of every release. An ANY.RUN report records a Malicious activity verdict for a v3.0.0-associated sample, analysed on Windows 10 on 1 September 2025. Its SHA256 is b3c58674968ef9a19b9049c6d57578b79af1fe786b8fe9dd27a91770da8d3042. We read the static report, but have not independently matched that sample to the original release. We have neither disproved that verdict nor established it for v3.11.0. Compare reports by file hash, date and test environment, not by filename alone.

Understand permissions and antivirus exceptions

An administrator prompt asks permission; it does not certify the file. Desktop’s helper and network configuration can require elevated access. Approve only an action you intended, after checking the file and the prompt. Installation steps are in the Windows guide and macOS guide.

On macOS, an unidentified-developer or notarization warning differs from a warning that an app is damaged or will harm the computer. Do not assume every “damaged” message only means a missing signature. Recheck the package and follow the warning-specific Apple guidance; disabling Gatekeeper globally is not a file verification step.

On Windows, v3.11.0 can show Add to Exceptions when recovering a missing core file. Choosing Yes runs an elevated script that attempts exclusions for the packaged and working copies of warp-plus.exe, masque-plus.exe and usque.exe in Defender, and also attempts Bitdefender exclusions. This changes antivirus coverage; it is not a routine connection setting. We inspected the code, but did not execute it on Windows. Exception code

Do not add an exclusion merely because the connection failed. If you previously added one, review Windows Security → Virus & threat protection → Manage settings → Add or remove exclusions. Remove entries you no longer intend to allow; a folder exclusion covers the files inside it too. The app’s script contains no timed expiry, so do not assume disconnecting restores this protection. Review Bitdefender separately if it is installed. Microsoft: exclusions and removal

If you chose Allow on device for a detection, also open Virus & threat protection → Allowed threats, select the item and choose Don’t allow. That allowance is separate from the exclusions list. Check that the item is no longer allowed, then run a scan; removing an allowance does not undo anything a file already did. Microsoft: protection history

Does the Windows updater verify its download?

In the v3.11.0 update path we reviewed, the app downloads the installer over HTTPS, follows redirects, saves it and requests elevated execution. We did not find a checksum or signature verification step before launch. The cached-installer path uses the saved version value before launching the existing file. A UAC prompt is not an additional integrity check. Tagged updater code

Issue #1214 raises an interception scenario. We checked the code paths, not a live attack, and do not claim that any network observer can defeat HTTPS. To inspect an update yourself, decline the automatic update, obtain the installer from its release page and perform the file checks above before deciding to run it. A manually downloaded file still needs the same assessment.

Do not rely on a kill switch

The v3.11.0 README leaves Kill Switch unchecked, and the related feature request describes it as a roadmap item. Do not rely on Desktop to block every connection when its tunnel stops. System Proxy and TUN are traffic-handling modes, not evidence of a tested kill switch. Feature list · Kill-switch request

  • Proxy (labelled None in the English Configuration menu) needs the app to be configured for the local proxy.
  • System Proxy only affects software that follows the system’s proxy configuration. A browser refusing connections after disconnect does not prove other apps are blocked.
  • TUN handles traffic at the network level, but direct-routing rules still matter. For example, the Discord switch can send named-process UDP traffic directly. Check routing rules and app-specific settings.

Stopping Desktop, a core crash, sleep/wake and changing networks are different cases. No all-platform failure test is established here. If your activity requires all traffic to stop whenever the tunnel is unavailable, Desktop’s current evidence does not meet that requirement.

Check DNS and WebRTC separately

A changed browser IP is only one observation. DNS concerns where names are resolved; WebRTC can use separate connections for calls. A private LAN address in a test is not the same observation as your original public ISP address. WebRTC connection basics

The project’s macOS DNS guide has an important update: it says DNS changes are automatic from 2.40. Its older manual-DNS instructions are not a general recipe for v3.11.0. The presence of strict_route in a configuration is not proof that every OS/browser combination passed a leak test. macOS DNS guide

A historical WebRTC report #283 concerns v0.10.8-beta, with System Proxy/None mentioned in the discussion. It neither proves nor rules out a leak in today’s TUN setup. We have not run live DNS, IPv6, WebRTC or disconnect-leak tests for this page.

For browser checks, you can use the separate BrowserLeaks tools for public IP/IPv6, DNS resolvers and WebRTC addresses. These are third-party test sites, which receive your test connections. Run the same tools before and after connecting, with the same browser permissions. An empty, blocked or unsupported test is not a pass; DNS and WebRTC tests require browser scripting.

For a useful comparison, use a test session without sensitive activity:

  1. Record the OS, Desktop and browser versions, method, mode, routing rules and browser DNS settings. Note the public IPv4/IPv6 addresses and resolver results before connecting.
  2. Repeat the same IP, DNS and WebRTC checks while connected. Record public addresses separately from private/local candidates; note any browser permissions you changed.
  3. Check normal disconnect separately. An intentional disconnect does not reproduce a crash or prove protection during reconnect. Restore any browser permissions or DNS settings you changed.

If your original public address appears where you expected a tunneled connection, stop treating that path as covered and review its routing. A clean browser test is useful evidence for that setup, not a guarantee for all applications.

Encryption is not anonymity or a no-logs promise

Only traffic sent through the selected route receives that route’s protection. Direct exclusions, signed-in accounts and site tracking still matter. Changing an IP address does not remove an account’s identity or choose a guaranteed country; see methods and IP location.

Cloudflare’s WARP privacy documentation describes limited DNS and traffic data, excluding payload, and lists operational data it may collect. It does not justify describing Desktop and every bundled method as “no logs.” Desktop, its cores and their service providers must be assessed separately. Cloudflare’s official-client documentation is not an audit of this unofficial client. Cloudflare privacy

Desktop also has local diagnostic logs. Before sharing one, check for addresses, usernames, paths and other identifying values; send only what is needed. See finding and preparing App Log. This page does not promise complete anonymity or protection from a compromised computer.

Source code, license and reporting a concern

The code and a GitHub Actions build workflow are public. That makes inspection possible; it does not by itself prove reproducible builds, an independent security audit or that every binary matches reviewed source. We have not established an independent audit covering v3.11.0. Security statement · Build workflow

Desktop’s license is Restrictive License - No Sale and Modification Limitation. It restricts sale/distribution of modified versions and changes to core identity details; it allows binary distribution subject to retaining the original license and copyright. Read the actual license before redistributing. Do not assume it has the license or permissions of a related project.

The Desktop repository was archived when checked on 5 November 2026; v3.11.0 was its latest release. Existing reports can be read, but new issues cannot be opened there. The security statement does not provide a dedicated private reporting address, and we have not verified an active security-response channel. For a file detection, contact the antivirus vendor with the hash and detection details. Keep credentials and sensitive logs out of public posts; do not treat an unverified social account as project support.