356PK Left an Internal Label in Its Page. HZ333 Has the Same One.
Over the past week this catalogue has connected six casino brands to one download operation, and every link in that chain has been made of infrastructure. Shared hostnames. Identical package naming. Boilerplate matching character for character. That evidence is solid and it is also completely impersonal: it tells you that two websites run the same software, which is true of a great many websites, and it never tells you that anybody is on the other end managing them as a set. 356PK is where that changes, and it changes because of a field nobody was supposed to read. Shipped in its public page is a configuration value called siteName, the label a back office uses internally to tell one deployment from another. On most sites it holds the brand name. Here it holds the brand name followed by a Chinese phrase, and the phrase is a person's nickname with a number attached to it. We then went back to a brand this catalogue listed days ago and found the same nickname in the same field, under a different number, on a site whose storage bucket was provisioned one place along in the same sequence. This guide covers what that field says, what we can and cannot conclude from it, and what else we measured on 356PK along the way.
The Field, and Exactly What It Says
The front page of 356pkapp.cool is a small shell, 11.7 KB, that loads its content at runtime. Inside it sits a block of configuration, and in that block is a key called siteName. Its value on this site is the string 356pk followed by a hyphen and a short Chinese phrase. Read literally, the phrase is a personal nickname, Xiao Jiang, then the number six, then a term that translates as big brother and is used in this kind of context the way an English-speaking operation might say boss or lead. So the whole value reads, roughly, as 356pk, Xiao Jiang, number six, boss. That is not a brand name and it was not written for customers. It is the sort of label somebody types into an admin panel so that the sixth deployment can be told apart from the fifth. We want to be careful about the conclusion, because this is exactly the kind of finding that gets overstated. A nickname in a configuration field does not identify a person, does not establish who owns anything, and is not evidence of wrongdoing. What it does establish, and this is worth having, is that these sites are numbered deployments administered by a back office that thinks of them as a series rather than as competitors, and that the people running them are working in Chinese.
- The public page ships a siteName configuration field
- Its value is the brand plus a Chinese nickname and the number six
- Not a brand name and not written for visitors
- It shows numbered deployments managed as a series, not separate businesses
HZ333 Has the Same Nickname
A stray label on one site would be a curiosity. What makes it worth a section is that we checked the others. HZ333 has been in this catalogue for some time, listed on its own merits well before any of this mapping began, and it runs the same front-end template as 356PK. Its siteName field carries the identical Chinese nickname, with a different number attached, plus a trailing digit. Same person or team name, different deployment number, same field, same template. Then there is the second thing, which we noticed only because we had been recording bucket names all week. Every one of these brands stores its Android packages on an Amazon bucket whose subdomain carries a number. 356PK is on 3929. HZ333 is on 3930. They are consecutive. Provisioned one after the other, presumably minutes apart, by whatever process creates these deployments. Put beside the shared nickname, that is a considerably tighter connection than anything we established between the four brands in the 88DD group, where the evidence was all shared boilerplate and could in principle have described two unrelated customers of one software vendor. Here two brands share a human label and adjacent slots in a provisioning queue. TR2026, also on this template and also catalogued here, carries a different label in the same field, which is a useful control: the field is not simply always the same, it varies by deployment as you would expect a real internal label to.
- HZ333 carries the same Chinese nickname under a different number
- 356PK is on storage bucket 3929, HZ333 on 3930 — consecutive
- Tighter evidence than shared boilerplate alone provides
- TR2026 carries a different label, showing the field genuinely varies
Two Templates, One Download System
Something else falls into place with this listing. The seven brands we have now traced do not all look alike, and until 356PK it was not obvious why. Four of them, 88DD, Y222, 999HA and 77MVP, ship a heavy front page of 126 to 146 KB with their whole configuration inline, which is precisely why we were able to measure so much of them: the download manifests, the promotional banners, the currency lists, all sat in the page for anyone to read. The other three, TR2026, HZ333 and now 356PK, run a different template that identifies itself in the markup as dw-site version 7.5.5 and ships an 11.7 KB shell that fetches everything at runtime. Two different front ends. But underneath, the download infrastructure is one system. Every brand stores its packages on an Amazon acceleration bucket following the same subdomain pattern, under an identical path, with the same three-file naming scheme of a six-character hexadecimal prefix followed by sn, nn_v3 and nn64_v3. And the bucket numbers cluster tightly: 3809, 3856, 3912, 3922, 3929, 3930, 3938. Seven brands, two storefront designs, one provisioning sequence. The practical reading is that the choice of template is cosmetic and the operation behind it is not.
- Four brands ship a heavy inline page; three run the dw-site v7.5.5 shell
- All seven use one package naming scheme under an identical path
- Bucket numbers cluster: 3809, 3856, 3912, 3922, 3929, 3930, 3938
- Different storefronts, one provisioning system underneath
The Downloads Check Out, and All Three Are Offered
As with every brand in this group, 356PK publishes its Android manifest with a stated size against each package, so we ran the same test: request each file and read back the bytes the server actually sends. The stub is declared at 6.74 MB and arrives as 7,068,880 bytes, which is 6.74. The 64-bit build is declared, oddly, as the text string 68.73999999999999 and arrives as 72,078,160 bytes, or 68.73. The universal build is declared as 89.84999999999999 and arrives as 94,211,389 bytes, which is 89.84. All three hold. Those trailing digits are the same floating-point artifact we noted on Y222, the residue of a computer adding decimal fractions rather than a person typing a figure, and it is mild evidence the numbers are generated rather than claimed. More importantly, all three builds are actually offered here. That is worth stating because 77MVP, covered in this catalogue two entries ago, publishes only the 6.69 MB stub and lists no complete package at all, routing every Android visitor through a shell that downloads an unstated 76 MB after installation. 356PK does not do that. If you want the complete 89.84 MB package up front, on a connection where that is the sensible choice, it is there and the site tells you its size.
- Declared 6.74 / 68.73 / 89.84 MB, every one confirmed on measurement
- Sizes carry floating-point artifacts, so they are computed not typed
- All three builds genuinely offered, unlike sibling brand 77MVP
- The full package and its real size are available up front
Where the Polish Runs Out
Two things on this site are broken in the small, careless way that seems to characterise these deployments once you look past the front page. The page ships with an empty title element. Not a missing one, as we found on 999HA, but a pair of tags with nothing between them, which is the same state we recorded on 222RS some time ago. A browser has no name to show, so the tab, the history entry and any bookmark all fall back to the raw web address. And the support channel is served in a way that will frequently fail. The interface routes live chat to an external address, and that address returns an HTTP 404 status with a content type of plain text, even though the body it sends is a genuine support page titled Online Consultant. The content exists. It is simply being delivered with a status code that says it does not and a content type that says it is not HTML, which is precisely the combination an embedded panel will refuse to render. If you open support inside this app and see nothing, that is the likely reason, and it is worth establishing an alternative contact route before you deposit rather than after.
- Empty title element, so tabs and bookmarks show only the address
- Support address returns a 404 status with a plain-text content type
- The support page itself exists and is titled Online Consultant
- An in-app panel showing nothing is the expected result of that combination
What It Gets Right, Including One Notable Omission
Two things here are better than the group average and both deserve saying. The first is transport security. All of these brands correctly refuse to serve a page over plain unencrypted http, answering instead with a permanent redirect to the secure address, but they split on what comes next. Y222 and 77MVP send a strict-transport header lasting only 180 days with no subdomain coverage and no preload flag. 356PK sends the strong form: a full year, extended to subdomains, with preloading requested so that even a first-ever visit never touches http. On the same operation, that is the more careful setting and this brand got it. The second is an omission rather than an addition, and it is the more interesting of the two. Four brands in this group, 88DD, Y222, 999HA and 77MVP, all carry an identical sentence citing PAGCOR, the Philippine regulator, inside the copy that gates identity checks and withdrawals. We have criticised that repeatedly, because naming a regulator to justify holding somebody's money while publishing no licence number is the shape of a claim without the substance of one. 356PK contains no reference to PAGCOR anywhere. It makes no regulatory claim at all. That is not a licence, and it does not make the platform safer, but making no claim is more honest than making an unverifiable one, and on this narrow point 356PK compares well with its siblings.
- Strict-transport set for a year, with subdomain cover and preload
- The stronger of the two configurations used across these brands
- No PAGCOR reference anywhere, unlike four related brands
- Making no regulatory claim beats making an unverifiable one
And What Is Still Not Published
Less is visible on 356PK than on the heavier front ends, because the shell loads its content at runtime rather than shipping it inline. That cuts both ways, and it is worth being honest that it limits what we can report as much as it limits what anyone else can see. No return-to-player figure is published for any game. No game supplier is named. No stake ranges, no maximum win, no bonus terms, no wagering requirements and no withdrawal minimums appear anywhere you can reach before creating an account, and unlike the 88DD group we cannot even read a vertical list from the page, since it is not there to read. Slots are referenced in the interface code and that is genuinely the extent of what the site reveals in advance. No company is named, no registered address is given, no licence number exists to check. The pattern holds across all seven brands now and it is worth stating plainly one more time: this operation is accurate about the things a visitor can verify without permission, such as file sizes, and silent about every single thing that would require it to make a commitment somebody could later hold it to.
- No RTP, no supplier, no stake ranges, no bonus terms
- No company, registered address or licence number
- The runtime-loaded shell exposes even less than its siblings do
- Slots referenced in code is the extent of what is visible in advance
Key Takeaway
356PK would be an unremarkable entry judged on its own. Its downloads are honestly described and all three are offered, which is more than one sibling manages. Its encryption is the strong configuration. It makes no regulatory claim it cannot support, which after four brands citing PAGCOR to justify withholding withdrawals is genuinely refreshing. Balanced against that, the page has no usable title, the support channel is served in a way that will often show nothing, and nothing that matters about the games or the money is published anywhere. What makes this listing worth reading is the field somebody forgot to clear. For a week the case that these brands are one operation has rested on shared hostnames and matching boilerplate, which is good evidence and impersonal evidence. A back-office label naming a deployment as number six under somebody's nickname, matching the label on a brand provisioned one bucket earlier, is a different kind of thing. It is the operation describing itself, briefly and by accident. The practical conclusion has not changed and is only firmer: seven brands, two storefront templates, one provisioning queue, and a set of choices about how much care each deployment received. If you are spreading a balance across several of these names to limit your exposure, you are not spreading anything. And on whether the money comes back out, not one of the seven has published a single thing you could hold it to.
356PK
Shares a download system with the 88DD group but a different front end, and leaks an internal Chinese operator label it shares with HZ333.