Vex doesn't touch your files, passwords, browser data or anything personal. Everything it does comes down to three jobs: lock your license to your PC, sign you in, and protect its own code from cracking. A bytecode scanner rates some of those low-level techniques "critical" or "high" because malware is built from the same building blocks — so below is every flag it raises and the exact, boring reason behind it.
The severity labels are the scanner's, not a sign anything was caught running. Each flag means "this capability exists in the code," never "this bad thing happened."
The one "critical" flag. Once at startup, Vex runs Windows' own built-in command reg query (via ProcessBuilder) to read your machine's anonymous MachineGuid — the most stable hardware id to tie your license to, so a shared or leaked key can't be used on another PC. It launches only reg, spawns no other program, and runs nothing downloaded. This is com.vex.loader.Hwid.regQuery — and it's why ProcessBuilder.start shows up.
Pairs directly with the flag above: after running reg query, Vex reads that command's text output (an InputStreamReader over the process's standard output) to pull the MachineGuid back out. It's reading one command's own output — not your files, not network data. Same method, Hwid.regQuery.
If the machine id above can't be read, Vex falls back to a network adapter's hardware id (NetworkInterface.getHardwareAddress) to fingerprint your machine for the same license lock. It's read once, hashed before it ever leaves your PC, and never used to identify you personally. This is Hwid.primaryMac.
When you launch, Vex opens your default browser to the sign-in page using Desktop.getDesktop() — the standard way any app opens a link. Scanners note that droppers can misuse it to open a downloaded file; here (PreLaunch.openBrowser) it opens a tab and nothing else. It does not run files or programs.
Java's URL classes are used for two harmless things: talking to getvex.lol over HTTPS to verify your license (URLEncoder.encode just formats your device id for the request), and the in-memory loader that hands the client's classes to the game (URL / URLStreamHandler / URLConnection, in MemoryUrlHandler / MemoryUrlConnection / PayloadInjector). Both are ordinary web/loader plumbing — no hidden external code is fetched.
To load Vex into memory (never written to your disk or mods folder), the loader calls one of Minecraft's own class-loader methods by name — that's the reflection (Class.getMethod, in PayloadInjector.fetchAndInject) the scanner flags. Malware uses reflection to hide API calls; here it does exactly one thing: hand the client's classes to the game's loader. There is no second hidden program.
This points at FileNotFoundException inside MemoryUrlConnection.connect, which the in-memory loader throws when a requested class isn't in its memory map — the standard Java way to say "resource not here." Despite the java.io name, Vex writes nothing to your disk; the client lives entirely in memory.
Vex's code is obfuscated so it can't be trivially copied, cracked or redistributed. Encrypting the text inside it uses XOR (IXOR) byte operations — a completely normal technique. It's flagged only because some malware also encrypts its strings; here it exists purely to keep Vex paid-only. The flagged methods are renamed obfuscator output (e.g. a, d, v).
The other half of the protection above: the obfuscator stores text encrypted and decodes it at runtime in a static initializer (a tableswitch picking XOR keys, then ixor / i2c / intern). Scanners recognise that decode shape and guess a brand ("ZKM") — it's actually our obfuscator, doing the same anti-piracy job. No payload, no hidden behaviour.
Some scanners also note that Vex's encrypted strings are stored using a block of Unicode "braille" characters — a fingerprint the obfuscator leaves behind. It's just how the encrypted text is stored (same anti-piracy layer as the two flags above); it carries no behaviour and runs nothing.
None of these are detections of actual malware — they're heuristics: "this technique can be used by bad software." A scanner can't tell licensing, sign-in & obfuscation apart from the same techniques in malware, so it flags them generically and assigns a severity. Every one above is a false positive in this context.