How Pandora works

Pandora is a stack. Each layer talks only to the one below it, and only the bottom layer reads or writes the client's memory.

So everything above the bottom can run with no Roblox open: swap L0 for a fake and nothing else changes. Attaching, building the index, the re-apply loop and the diagnostics sit on top of the stack.

How does it know a block of memory is the flag registry? It collects evidence. Structure alone says little: any object that holds a pointer and a small number looks the same. Content is what settles it.

Every write goes through one function, apply_typed. It runs the gates below in order and stops at the first one that says no. A slot is the memory where a flag's value lives.

Three crashes came from writing without looking at the target first. In all three, one read right before the write would have blocked it. That is the premise of the design.

What the read checks, by type:

The int contract needs more than a look at the bytes. An int slot sits 4 bytes from the next one, so an 8-byte read returns our value and the neighbour's. Those 8 bytes could also be one pointer. Three checks tell them apart.

Moving to another server rebuilds the DataModel. Addresses Pandora held now belong to other objects. Four crash logs all ended in HardAssert (Could not find class descriptor) right after submitStartGameTask.

Guessing a hop from a memory sample only works after a cycle has already written, maybe into freed memory. So Pandora reads Roblox's own log instead, only the part added since the last look. On submitStartGameTask it skips that cycle's write, drops its caches and rebuilds the index on the spot. When the log can't be read, it falls back to the memory guess.

Tested with a synthetic log: one 2 s cycle skipped, then the earlier numbers came back. The index rebuild took 359 ms. A real hop can't be triggered from the command line, so this has not been reproduced in a live game.

Time from launching Pandora to the first flag written. The old build waited 2 s before its first look, then took 3 s to build the index and 3 s more to apply. The new one doesn't wait, and the other two steps got shorter.

Each row is the same work, before and after. The faint bar is before, the strong bar is after. Each row has its own scale.

The page cache used to copy a whole 4 KB page on every hit. Building the index copied 4.26 GB that way. It now copies only the bytes it was asked for.

The missing-flag report was 80% of one apply. It made 11.5 million comparisons on a list that had not changed: 195 to 299 ms, next to 25 to 45 ms for the writes. The names are now sorted and found by binary search, and nothing is computed while the list stays the same.

Every missing flag used to start an index rebuild in the middle of the apply. One took 1,390 ms and found 3 names. The index is now built in the background and swapped in whole when it is finished. At first it was only moved to a background thread, and the apply time stayed the same: the rebuild emptied the live index before filling it, so every lookup in the meantime missed. Building and installing had to be separate steps.

A “not found” is remembered, but not for long. The memory is dropped whenever the index changes, and every 5 minutes anyway. One read that missed in a busy game must not keep a flag out for good.

Nothing is written to disk when the content hash is the same, and flags.json is not parsed again when its modified time and size are the same. At a 2 s cycle that is about 40,000 calls a day that now do nothing.

Building the index means sweeping the game's heap. The sweep is cut into 1 MB chunks, 128 to a batch (32, 64 and 128 all took about 420 ms, 256 took 585), and spread over threads. The results are merged in chunk order, so the candidates come out in the same order as with one thread.

File-backed memory (MEM_MAPPED) is 25% of the bytes, 503 MB, but only 1.4% of the candidates, and none of those became a list. The fast sweep skips it. That is something seen on this client, not a rule, so it is checked: when a fast run finds more than 0.5% fewer names than the run before, everything is read once more. --fflag-scan-diff compares the two sweeps name by name.

FlagML is a small neural network that ranks flag names by how much they look like the ones you apply. It only orders names. Nothing in the write path reads its output.

The network takes 256 numbers, so a name is counted first. Lowercase it. Slide a window over its bytes: 2 wide, then 3, then 4. Hash each window with 64-bit FNV-1a, take the result mod 248 and add 1 to that cell. Cells 248 to 255 are for the prefix. At the end every cell is divided by the sum of all the cells, so a long name does not outweigh a short one.

Two different windows can land in the same cell. The 72 built-in presets hold 3,186 different names. The median name has 93 windows, and 13 of its cells are shared this way. The network only sees the count, never which window it was.

Cells 248 to 255 stand for eight prefixes: fflag, dflag, sflag, ffint, dfint, fint, flog, dflog. A name lights the one it starts with. A DFFlag or FString name matches none of them, so no prefix cell lights.

The network is 256 numbers in, 64 hidden units with ReLU, 1 number out through a sigmoid. It starts from fixed weights (seed 42). Each name you apply is one gradient step toward 1, at a rate of 0.02.

It only ever sees names that were applied, never one that was left out. A score therefore says how much a name looks like what you apply. It does not say the flag helps.

After an apply that wrote at least one flag, a background thread scores every name in the index that you are not already applying. The score is half the network's output plus half the average overlap with the names you applied, the dot product of the two encodings. The list is sorted and the top 5 are printed to stderr. The window does not show them.

The weights and the last 5,000 training records are saved every 100 records, after each scoring pass, and when Pandora closes.

A crash log once ended inside FlagML, on an index out of bounds. Training had gone to NaN, the saver wrote that as JSON null, and the loader dropped the nulls, so a row of 64 weights came back with 62. Now a weight that is not finite becomes 0 on every training step, every save and every load. Training and scoring check the shape first: a wrong shape scores 0.5 and trains nothing. A file with any row or vector of the wrong length is thrown away whole, and the network starts again from the seed.

Undo writes back what was in the slot before Pandora's first write. It never writes a default: Pandora does not know the defaults of a build, and the value that was there may have come from the server.

Every write Pandora confirms adds one entry to a ledger in memory: the flag name, the address of its value, the type, the value Pandora found there and the value it wrote. Before the ledger is saved, and again before Undo, each entry also gets the flag's name tag: 16 bytes read from its descriptor, a pointer to the name and the name's length. A second write to the same slot adds nothing, because the first value is the original. The number on the Undo flags button is the number of entries.

The ledger is saved to fflags\original.json after each apply that adds an entry, with a header: the Roblox process ID, its start time, the module base (where Roblox's code is loaded) and the build. When Pandora attaches to Roblox it loads the file only if all four match. A process ID alone proves nothing, because Windows reuses them. The build is compared only when both sides have one. On a mismatch the file is deleted and Pandora says the saved ledger belongs to a different Roblox process. A file that does not parse is deleted too. Restart Pandora alone and the ledger survives. Restart Roblox and it does not.

Undo looks at each slot three times, in this order. The first check that fails ends it for that slot.

Restored, already original, changed by Roblox and moved slots all leave the ledger. Only a failed slot stays. The message counts what happened and leaves out anything that is zero.

Before it touches the first slot, Undo switches off Auto apply (it applies your list every 5 seconds) and Re-apply guard (it puts your values back every 2 seconds). Left on, they would write the list again a moment later: the window would say undone and the game would still have the values.

Undo does not touch flags.json. That file is your list, not the game's state, and you may want to apply it again. If a startup file was deployed with --fflag-file-deploy, Undo puts that back too: the backup returns, or the file is deleted if there was none. A file that changed after Pandora wrote it is left alone.

A flag Roblox reads once, when it builds something, keeps its effect until Roblox builds that thing again. Undo puts the slot back. It cannot take back what the game already did with the value. A flag applied before Pandora started has no entry and nobody knows what it held, so Pandora does not guess. It says nothing is recorded, and only a Roblox restart clears such a flag.

Some flags have nothing to do with frames and break something real when they are wrong: a login rollout, a token, a payment switch, a server address. Community lists mix them in, and some overwrite a telemetry address with "null". The list Pandora builds for your PC does not.

The check runs first, over every name Pandora knows: the flag index, Roblox's settings table and the presets. It cuts the name into words and refuses it if any word is on a list of 61. It also refuses a name that contains _place or ends in placeid: those flags carry a list of places, and the server gives each place its own value. On the flags I measured, 2,296 names are refused.

This is part of building the list. It is not a gate on writes: a name you put in your own flags.json is not checked, and FlagML's scan does not use it either.

The first version looked for the listed words as letters inside the name. age is inside Percentage, Storage, Manager and Package. ban is inside Bandwidth. On the flags I measured, that refused 6,387 names. Cutting the name into words at its capital letters and refusing only a whole word refused 1,711 at the same point. That was one snapshot; the 2,296 above is the current count.

Every command here runs without the window: it prints to the console and exits. Run them from a terminal in the folder Pandora.exe is in. Click a line to copy it. The ones that read Roblox's memory stop with a message when Roblox is not running.

A faster sweep can drop one name and gain another and still report the same count, so counts prove nothing. scan-diff compares the two lists name by name.

Pandora keeps its own files in one folder. The startup file from --fflag-file-deploy is the exception: it goes into Roblox's own folder.