Jurojin Poker

How an update works, and how this one was changed

ShareWhatsAppX

This is a slightly more technical account of how the security breach worked. It is here so anyone can follow it: what a normal update does, what was changed, and how we know the update people get now is not a compromised one.

We can confirm that because Amazon S3 kept every previous upload. We compared all of them. The file that address serves today is a normal build. The compromised uploads are only in the history behind it, and that history is what dates them.

Two separate tricks. One changed which zip a group downloaded. The other changed what was inside that zip. The signed launcher did not have to change.

The group name below is an example. It is not the real name.

A normal update, and the altered one

Both columns are the same sequence. The group name below is an example. A group is a label on the account, and people in it share one download address. That name, and the address the installer uses, are stored separately. Official updates write the legitimate address.

The altered column changes one letter in that address, from a capital N to a small n. Amazon S3 keeps those as two different paths, and serves the one that matches the URI saved on the group. launcher.exe still starts the file named JurojinUI.exe, so it never needed a new build. Inside the tampered zip that file is a stand-in: it installs Mesh at that moment from ProcessCommunicator.exe, a name that belongs to a legitimate signed helper in a normal zip.

Normal update
Jurojin client
Logs inaccount in group Northstar
The client on the PC asks the server which account this machine is.
Server
Looks up that groupNorthstar → URI in S3
One specific URI for each group.
Amazon S3
Serves the path that matches that URIversions/Northstar/Jurojin.zip
S3 does not pick a group. It returns the object whose path equals the saved URI.
Installer
Downloads that objectGET versions/Northstar/Jurojin.zip
Signed. It fetches only the URI it was given.
launcher.exe
Runsstart JurojinUI.exe
Signed. It always starts the file named JurojinUI.exe. It does not inspect what that file actually is.
Inside the zip
The real app opensJurojinUI.exe · signed · megabytes
A normal zip has no file named Jurojin.exe.
JurojinUI.exeLarge and signed. This is the app that opens.
ProcessCommunicator.exeA legitimate helper. Signed.
Jurojin.exeNot in this zip.
Tampered update
Jurojin client
Logs ingroup name still Northstar
Same request. The group name and the group id do not change.
Server
Looks up that groupNorthstar → URI in S3
One specific URI for each group. The group is still Northstar.
Amazon S3
Serves the path that matches that URIversions/northstar/Jurojin.zip
versions/Northstar/Jurojin.zip is still there. The small n is a different object.
Installer
Downloads that objectGET versions/northstar/Jurojin.zip
Still signed. It does not choose the file. Other groups kept their own URIs.
launcher.exe
Runsstart JurojinUI.exe
The same signed launcher. It did not need a new build. Every PC in that group gets this start.
Inside the zip
The fake program runs, and installs Mesh at that momentJurojinUI.exe · under 1 MB · unsigned
Not every tampered zip included the Mesh file. When it did, the app still opened, so the PC looked normal.
JurojinUI.exeThe stand-in. It runs now, installs Mesh, and starts the real app.
ProcessCommunicator.exeIn a clean zip this name is the legitimate signed helper. Here the unsigned Mesh installer was hidden under that same name.
Jurojin.exeThe real app, still signed, opened under this other name.

On and off, so the group looked normal

They did not leave the tampered zip in place. Accounts were moved into the group and moved back out, and the group's URI was set back to the original path. A look at the group after that showed the normal address, and a different set of people. That is why it did not stand out.

S3 kept every upload on the altered path. From 11 June 2025 through 28 January 2026 a tampered zip would go up, then a clean zip would replace it, then another tampered zip would go up. Those are 92 windows, not one block. Added together, the tampered file was what a client would download for 72.7 days. For 158 days in that same span the current file was a normal build.

Accounts
Moved into the group, then back outgroup Northstar
They put accounts in and took them out again. Only the accounts in the group at that moment shared its URI.
Altered URI
The group points at the other path while they are in itversions/northstar/Jurojin.zip
An update on those PCs then gets the tampered zip. This was not one stretch. It happened in 92 windows. Added together, the tampered file was current for 72.7 days.
Original URI
The group URI is set back to the original pathversions/Northstar/Jurojin.zip
After that, the group name, the people in it, and the address all look ordinary. A later check does not show who was only there for the window.
Version history
S3 still has every earlier upload
Between windows a clean zip was current for 158 days. The longest tampered window was about five days. Many lasted hours. The last tampered file was replaced on 28 January 2026 at 14:25 UTC. That clean file is still current.

The last file was left clean

The version that is current on the altered address is a legitimate build: a large signed JurojinUI.exe, and no renamed Jurojin.exe. Looking only at the file that is there now, the address looks ordinary. The tampered uploads are still in the version history behind it. That history is what shows the dates, which uploads were tampered, and which kind each one was.

How the remote-access tool was installed

It went to whoever was in the group and updated while a package containing it was the current file. It did not check poker screen names. The IntuitiveTables variant of this operation did that, as far as we know. This one did not.

Being served a tampered package is not the same as a device ending up with the tool. Not every tampered zip contained it, and not everyone in the group updated during one of those windows.

Back to the security notice