2026 GachaDex containment thread

Dex-chan lover
Joined
Sep 29, 2019
Messages
984
This means that not only is reading as normal not a viable strategy
Specially for those who read 3rd party apps (Neko in my case), since it's the mangadex frontend that's sending the event requests and all the coins I would get from the chapters I read on april 1st got lost in the void :haa:
I didn't reverse engineer the api and write a script to automatically send requests or anything
I did reverse engineer the API by looking at the devtools network tab lmao.
My plan was to add it to my own build of Neko (I'm one of the main contributors there so I know the codebase :dogkek:) and use it during this month, but I got lazy after implementing my testing script, and the gacha addiction got the better of me.

I will say, I ran some linear regressions on the dexcoin amounts, and I don't know what JinxedMyself was doing, but he got coins nearly twice as fast as me. probably chaining multiple different operations together at the same time or something.
But unless this game runs through at least half a year, I'm not sure it would be possible
I also did some statistical analysis on about 25 10x pulls in the first couple of days and arrived at a similar conclusion

My first script was not that greedy, since it didn't use the ads, just chapter reads. And then around 2 days ago I added a second script I made in 2 minutes to run on the ads, since my prediction was that even with the first script it still would take over a month to get all cards.
I had plans to do a general rebalance of the economy but I've been postponing it for a bit so that one's on me... :shamihuh:
So ye, I think it balancing :headpat:

Maybe verification of the payload is a good start. :)
Now onto my constructive criticism :wooow:

Apart from payload verification, my first idea would be obfuscating the code related to the gacha using WASM, since it would make it way harder to reverse engineer, specially if you encrypt the payload.

Another idea would be using the browser's DRM to generate an integrity token based on a challenge that can be verified server-side. Along that, there is other challenge PoW methods (but I'm not sure how effective that would be tho, since the request frequency is not that big).

Tho these ideas wouldn't deter auto-clickers, but it would make scripting harder

Which is why you got blacklisted, since cheating is not okay...
Anyway, completely fair, in the beginning I was mostly using the script to get title recs, but gacha addiction is gacha addiction.

I can remove you from the blacklist if you promise you won't try to automate
I would also accept similar terms, even if it meant losing the 80-100 something cards I got legitimately in the first couple of days :nyoron:
I'm curious about what will happen on the weekend

(also, long live the Resistance):bocchiwave:
 
Last edited:
Fed-Kun's army
Joined
Aug 1, 2019
Messages
20
Specially for those who read 3rd party apps (Neko in my case), since it's the mangadex frontend that's sending the event requests and all the coins I would get from the chapters I read on april 1st got lost in the void :haa:

I did reverse engineer the API by looking at the devtools network tab lmao.
My plan was to add it to my own build of Neko (I'm one of the main contributors there so I know the codebase :dogkek:) and use it during this month, but I got lazy after implementing my testing script, and the gacha addiction got the better of me.



I also did some statistical analysis on about 25 10x pulls in the first couple of days and arrived at a similar conclusion

My first script was not that greedy, since it didn't use the ads, just chapter reads. And then around 2 days ago I added a second script I made in 2 minutes to run on the ads, since my prediction was that even with the first script it still would take over a month to get all cards.

So ye, I think it balancing :headpat:


Now onto my constructive criticism :wooow:

Apart from payload verification, my first idea would be obfuscating the code related to the gacha using WASM would make it way harder to reverse engineer, specially if you encrypt the payload.

Another idea would be using the browser's DRM to generate an integrity token that can be verified server-side. Along that, there is other PoW methods (but I'm not sure how effective that would be tho, since the request frequency is not that big).


Anyway, completely fair, in the beginning I was mostly using the script it to get title recs, but gacha addiction is gacha addiction.

I would also accept similar terms, even if it meant losing the 80-100 something cards I got legitimately in the first couple of days :nyoron:
WASM obfuscation would raise the bar meaningfully, but the fundamental issue isn't obfuscation, it's that the signing key is client-side at all. WASM just makes extraction harder, not impossible. The key still has to exist in memory at runtime and can be pulled from a heap dump or by hooking the crypto calls before they're made.

The DRM integrity token approach is certainly a robust one. Tie token validity to a verified browser environment. It's genuinely hard to spoof outside of that environment. The tradeoff is it locks out non-Chromium users and adds infrastructure complexity on the verification side.

Personally, I feel like the cleaner architectural fix that doesn't require either. Just move token issuance server-side entirely.
The frontend authenticates with Keycloak, the backend performs the exchange and issues a short-lived Ministry token directly, the private key never touches the client at all. That alone closes the specific attack vector here, since there's nothing in the bundle to extract.

PoW is probably overkill for this use case as you noted, the cooldowns are generous enough that even "legitimate" automation stays under any reasonable rate threshold. The real gap is payload validation, particularly on CHAPTER_UPLOAD.
 
Yuri lover in denial
Contributor
Joined
Nov 18, 2018
Messages
20,897
new leaderboard status:
BR65QVr.png


and the teams are 50-50 again.

i'm gonna spend it all once i hit 1 million. hopefully i can fill out my collection.
So many no names are gone now, rip. Rolands win again.
eWdoboh.png
 
Dex-chan lover
Joined
Sep 29, 2019
Messages
984
The DRM integrity token approach is certainly a robust one. Tie token validity to a verified browser environment. It's genuinely hard to spoof outside of that environment. The tradeoff is it locks out non-Chromium users and adds infrastructure complexity on the verification side.
Firefox and Chromium both use Widevine, and Safari has FairPlay Streaming, so I think the only ones affected would be some Firefox-based fork users (the ones not on Linux) and the people that use some of the more peculiar browsers.
 
Fed-Kun's army
Joined
Aug 1, 2019
Messages
20
Firefox and Chromium both use Widevine, and Safari has FairPlay Streaming, so I think the only ones affected would be some Firefox-based fork users (the ones not on Linux) and the people that use some of the more peculiar browsers.
Sounds like I could fit inside those peculiar browsers somewhat. Not right now, but I have at least 8 different browsers.
 
Fed-Kun's army
Joined
Aug 1, 2019
Messages
20
Okok, I'm curious now :wooow: is it something other than gecko, chromium and webkit then?
Ladybird is certainly a relative big name that's worth mentioning. Fully independent engine from scratch in C++.
There's also Goanna-based browsers (Pale Moon, Basilisk), which is technically a fork of an older version of Gecko and diverged into its own thing.
 
Fed-Kun's army
Joined
Aug 1, 2019
Messages
20
Firefox and Chromium both use Widevine, and Safari has FairPlay Streaming, so I think the only ones affected would be some Firefox-based fork users (the ones not on Linux) and the people that use some of the more peculiar browsers.
Meat and potatoes time. :02:
Widevine and FairPlay are media DRM systems, not browser integrity attestation APIs. They verify content licenses, not that the browser environment itself is unmodified. tools like widevine-l3-decryptor and later devine demonstrate that even a "verified" Widevine environment can have its decryption keys extracted at runtime.

What the integrity token approach actually requires is something like Chrome's Device Bound Session Credentials. DBSC is still experimental and Chromium-only, and Mozilla has explicitly pushed back on implementing anything in that space on privacy grounds.

So the coverage problem is actually worse than Widevine suggests. You'd effectively be attestation-gating the feature to Chrome stable, which is a meaningful portion of users but still a significant exclusion, and it would likely draw more community pushback than the automation problem it's solving warrants, especially for an April Fools event. Server-side key issuance stays the pragmatic fix for the actual attack surface here.
 
Dex-chan HATER
Joined
Mar 17, 2019
Messages
13,000
new leaderboard status:
BR65QVr.png


and the teams are 50-50 again.

i'm gonna spend it all once i hit 1 million. hopefully i can fill out my collection.
breaking news: the teams of @bigtiddyoneesan and @Data_Gold have been swapped?! there does exist a one-time option to switch your team for 100k, but i don't recall using it (seriously, i don't). perhaps this is the work of a mischievous mod?
FfSKhkG.png
 
Womp Womp
Staff
Super Moderator
Joined
Aug 23, 2023
Messages
916
breaking news: the teams of @bigtiddyoneesan and @Data_Gold have been swapped?! there does exist a one-time option to switch your team for 100k, but i don't recall using it (seriously, i don't). perhaps this is the work of a mischievous mod?
FfSKhkG.png
Just a stupid person impersonating others... already dealt with
 
Yuri lover in denial
Contributor
Joined
Nov 18, 2018
Messages
20,897

Users who are viewing this thread

  • Top