DEV Community: Luan Silveira

What feature would you want in a Roblox account manager?

Luan Silveira — Fri, 09 Oct 2026 04:45:16 +0000

I maintain MultiAlt (source on GitHub), a free, open-source (GPL-3.0) Windows app that keeps several Roblox accounts signed in and opens them side by side. It started as a rewrite of the Roblox Account Manager by ic3w0lf22, which was archived in October 2024 after about 2.2 million downloads. MultiAlt is built with Tauri 2 (Rust and React/TypeScript).

I'm deciding what to build next, and I'd like that list to come from the people who use these tools, not from me guessing.

If you run more than one Roblox account (to farm, trade, test your own game, or play with friends on a second account):

What feature would you want in an account manager that no tool gives you today?
What did the old Roblox Account Manager do that you still miss?
What's the most annoying part of juggling accounts right now?
What do you use your extra accounts for?

One line is enough. I read every answer, here or in the GitHub discussion, where 👍 votes decide what goes on the roadmap.

What's already planned: putting many accounts into a Roblox group at once, and a FAQ inside the app. One rule stays fixed: no cheats, no exploits, nothing that breaks Roblox's rules.

You can also drop ideas in the MultiAlt Discord.

Download and docs: multialt.pages.dev. Not affiliated with or endorsed by Roblox Corporation.

Keeping an archived 800-star Roblox tool alive: MultiAlt, in Rust and Tauri

Luan Silveira — Mon, 05 Oct 2026 09:30:48 +0000

The original Roblox Account Manager by ic3w0lf22 helped millions of players run several Roblox accounts on one PC: its last release has over 2 million downloads. In October 2024 the repository was archived.

MultiAlt (source on GitHub) continues that work, now in Rust + TypeScript with Tauri, and it's actively maintained.

What it does

Keep every Roblox account signed in, in one list
Multi Roblox: open several Roblox clients at once
Send a group of accounts into the same server, or follow a friend into theirs
Keep alts in game with AFK mode and Auto Rejoin
Import the old Roblox Account Manager account file
English, Portuguese and Spanish UI

What changed under the hood

Encrypted storage by default. Accounts are encrypted with your password, or with a device key kept next to the data file, so copying the file alone exposes nothing.
No admin, auto-update. A per-user MSI installer that updates itself; it scans 0/75 on VirusTotal.
Multi Roblox that doesn't kill other clients. Holding Roblox's singleton mutex is opt-in, and nothing in the launch flow closes other accounts' windows.
A server finder that respects groups. "Best fit" picks the fullest server where the whole group still fits, with one spare seat, and asks the API for the right sort order instead of re-sorting a single page.
Three languages, because Roblox has a huge audience in Brazil and Latin America.

Things I learned

Antivirus models are picky. At one point a single crypto dependency was enough for Windows Defender's machine-learning engine to flag the build. I found it by bisecting builds against VirusTotal, and now every release is scanned with VirusTotal and Defender before it ships.
Roblox picks its build from the launch URL, not only the registry. Opening a client build that doesn't match the channel in the launch URL makes Roblox's own installer pop up, and that installer closes every open client. Getting this right took a lot of reading the client's logs.
Never close what you didn't open. Closing the manager used to close every Roblox window when more than one was open, including accounts opened from the website. Now closing the app leaves every client running.

Try it

It's free and GPL-3.0.

Download and guides: https://multialt.pages.dev/
Code: https://github.com/luanmacea/MultiAlt
Video walkthroughs: https://www.youtube.com/@MultiAltApp
Community and help: https://discord.gg/NPvyWgKbfH

Feedback and issues are very welcome.

Not affiliated with or endorsed by Roblox Corporation.

How a crypto library got my Tauri app flagged as a trojan (and how I found it by bisection)

Luan Silveira — Wed, 30 Sep 2026 16:57:50 +0000

My desktop app started getting flagged by Microsoft as Trojan:Win32/Wacatac.B!ml. The code hadn't learned any new tricks. The culprit turned out to be the encryption library I had just added, and I found it by bisecting builds against the VirusTotal API.

This post covers how I tracked it down, how I replaced the library without breaking the files users already had on disk, and what I'd do differently.

The app

RAM — Roblox Account Manager is an open-source (GPL-3.0) Windows app built with Rust + Tauri 2 and React. It manages many Roblox accounts, launches several game clients at once and automates things like rejoining servers.

That last part matters. An app that stores session cookies, spawns processes, brings windows to the front and sends synthetic input already looks suspicious to a heuristic engine. There is no margin for anything else to look off.

The symptom

After one release, Windows started warning users about the .exe, and VirusTotal showed 1/75: Microsoft, Trojan:Win32/Wacatac.B!ml.

The !ml suffix is the important part: it's a machine-learning verdict, not a signature match. No known malware pattern was found. A model just decided the binary resembles malware.

First guess: wrong

My first instinct was to compare the last clean build with the flagged one. I dumped both with pefile:

same 16 "heuristically heavy" imports (SendInput, SetForegroundWindow, TerminateProcess, DuplicateHandle, RegSetValueExW…)
same section entropy, same linker
only four new imports, all boring (FlushFileBuffers, OpenEventW, RemoveDirectoryW, MessageBoxW)

Conclusion at the time: "the behavior profile is identical, the model just changed its mind, nothing to fix." It sounded reasonable, and it was wrong. The import table isn't everything the model looks at.

Bisecting against VirusTotal

So I stopped guessing and bisected. The VirusTotal API is free (4 requests/minute, 500/day). A small script hashes the file, looks up an existing report and uploads it only if the hash is new:

const digest = new Bun.CryptoHasher("sha256").update(bytes).digest("hex");
const existing = await fetch(`${API}/files/${digest}`, { headers });
if (existing.ok) {
  // already analyzed: read last_analysis_stats
} else {
  // upload, then poll /analyses/{id} until "completed"
}

Then plain git bisect: build the release .exe at each step, scan it, mark it good (0/75) or bad (1/75). Each step takes a few minutes, mostly the Rust release build.

(A tip: my first attempt bisected by date and broke on merge commits. Use real git bisect.)

The first bad commit was the one that integrated encryption for the account file, using sodiumoxide, the Rust bindings to libsodium.

Why libsodium?

sodiumoxide statically links the libsodium C library into your binary. A blob of optimized native crypto primitives, sitting inside an app that also stores credentials and injects input, is apparently close enough to what ransomware and stealers ship for the model to fire.

Nothing is wrong with libsodium itself. It's the combination the classifier learned to dislike.

Replacing it without locking anyone out

Users already had encrypted files on disk, and some had a password on them. The replacement had to read those files byte for byte. I went with pure-Rust RustCrypto crates and matched every libsodium parameter:

argon2 = "0.6"
crypto_secretbox = "0.1"  # XSalsa20-Poly1305
sha2 = "0.10"             # SHA-512 of the password, as before

/// Same as libsodium's crypto_pwhash (argon2i13, OPSLIMIT/MEMLIMIT_MODERATE):
/// Argon2i v0x13, t_cost = 6, m_cost = 128 MiB, parallelism 1, 32-byte output.
pub fn derive_key(password_hash: &[u8], salt: &[u8]) -> Result<Key, CryptoError> {
    let params = Params::new(131072, 6, 1, Some(32)).map_err(|_| CryptoError::InvalidData)?;
    let argon = Argon2::new(Algorithm::Argon2i, Version::V0x13, params);
    let mut key: Key = [0u8; 32];
    argon.hash_password_into(password_hash, salt, &mut key)
        .map_err(|_| CryptoError::InvalidPassword)?;
    Ok(key)
}

crypto_secretbox from RustCrypto already produces libsodium's layout: the 16-byte Poly1305 MAC in front of the ciphertext.

What made me trust the swap was a test. Before removing libsodium, I encrypted a tiny payload with the old implementation, pasted the bytes into the test as hex, and the new code must decrypt them exactly:

#[test]
fn decrypts_a_libsodium_fixture() {
    // Bytes produced by the OLD libsodium/sodiumoxide implementation.
    // If this fails, existing users' files would be locked. Never relax it.
    let fixture = hex_decode(concat!(
        "526f626c6f78204163636f756e74204d616e6167657220637265617465",
        // …the rest of the header, salt, nonce, MAC and ciphertext
    ));
    let hash = hash_password("test-password");
    let plain = decrypt(&fixture, &hash).expect("fixture must decrypt");
    assert_eq!(plain, b"{\"account\":\"example\"}");
}

If any parameter is off by one — Argon2 version, memory cost, MAC position — this test fails. That's exactly the kind of bug that locks users out of their data.

Side effect: tests got 17x slower

Pure-Rust Argon2 in a debug build is painfully slow: 5.4 s per derivation, against 0.3 s optimized. libsodium never had this problem, because it's precompiled C.

Since cargo test runs in debug, the suite went from minutes to most of the CI time. The fix is one block in Cargo.toml: optimize dependencies even in dev builds, keep your own crate unoptimized so it still compiles fast.

[profile.dev.package."*"]
opt-level = 3

The Rust suite went from 230 s to 41 s, faster than it was with libsodium.

Results

File	Before	After
App `.exe`	1/75 (`Wacatac.B!ml`)	0/75, Defender clean
MSI installer	0/61, but required admin	0/75, per-user, no admin
NSIS setup	3/71	1/75 (one generic ML engine, on the packager)

No code signing, and no removing the encryption.

What I'd tell anyone shipping an unsigned desktop app

!ml verdicts are a moving target. The same source built with different feature flags got different verdicts from the same model. You can't "win" once; you measure every release.
VirusTotal's Microsoft engine and local Defender disagree. A build passed local MpCmdRun and still got flagged on VirusTotal. Check both, because users see both.
Bisect, don't theorize. My careful import-table analysis pointed at the wrong conclusion. A few rounds of git bisect pointed at the right commit.
Make your scanner fail loudly. My own scan script once reported "all clean" while the Defender step had crashed (a UTF-8 em dash in a BOM-less .ps1 breaks Windows PowerShell 5.1) and the VirusTotal step exited 0 on any verdict. A scanner that didn't run must never count as clean. That rule now has a test.
Native C dependencies are a heuristic risk. If a pure-Rust equivalent exists and you can prove format compatibility with a fixture, it's worth considering.

The durable fix is still code signing (there are free options for open-source projects, like SignPath Foundation). Until then, measuring every release and keeping the recommended download clean is what I can do.

Download and guides: multialt.pages.dev. Community: Discord. The project (now called MultiAlt) is open source, and I'd love feedback on the Rust/Tauri side: github.com/luanmacea/MultiAlt

I wrote this post with the help of an AI assistant; the investigation, numbers and code are from the project's history.