[artyom08-dev]

in november chairman xi and the deepseek infra crew woke up and chose absolute violence, mass-nuking reverse proxies left and right. literally everyone running a proxy ran into this exact same wall: upstream returns a slick http 200, but the payload is a fat middle finger - code=40003 INVALID_TOKEN. fresh burner accounts get clapped after literally 3-4 prompts, making the proxy 100% cooked and unusable in its current state

yeah, this pr is huge, but here’s the deal: deepseek isn't catching people on just one red flag. they're running a legit social credit score heuristic. every tiny slip-up is an additive term: janky user-agent, missing cloudflare/waf cookie, token minted on desktop but talking to an android route - each discrepancy dings your trust score until your social credit hits rock bottom and the banhammer drops. if we leave even a single mismatch behind, their heuristics sniff us out immediately. we had to patch every damn leak in one go

the core culprit was... our setup (idk how else to put it, literally everything in the current code gives us away, it’s a tracking paradise): an ungodly hybrid where we hit android routes from pr #16 (cooked up back in early september and wildly obsolete), while spraying desktop headers. and the cherry on top (shoutout @1515asd for the catch): the user literally generates their session token in a desktop browser, and then we turned around and threw it at mobile endpoints. @1515asd tried patching this in his fork by shifting registration to android and duct-taping mobile headers, but let's be real - that's a cursed crutch. you can't fake a pristine android client without a physical device and hardware attestation. so i nuked the mobile nonsense completely and rolled us back to clean desktop browser emulation, powered by mandatory playwright startup warmup for authentic cookies.

stealth & anti-ban:

ditching android -> full desktop browser: purged all the stale pr #16 mobile junk; we now impersonate a clean modern desktop chrome instance across the board.
playwright cookie warmup: boots a headless browser on startup to harvest genuine cf_clearance, hwwafsestime, intercom, va* cookies, and a legit shumei device fingerprint (smid).
strict account isolation: each token gets its own isolated cookie jar, unique device_id, and shumei_id — no more cross-pollinating account sessions like a bunch of amateurs.
waf 202 auto-healing: whenever cloudflare / aws waf serves an html challenge (the infamous 202 json decode error), we don't crash and burn. we invalidate the cookie and silently re-warm via playwright on the fly
graceful 40303 handling: when deepseek throws a captcha/shumei challenge, we don't kamikaze the token. we dock its social credit, put it on an ice pack (30-min cooldown), and keep the pool rolling
dashboard captcha solver: yeah, it’s a dirty hack - it pops a local browser on the host, so if youre headless on a remote vps it won't do shit. but if you're running locally on desktop, it beats the hell out of yeeting your account into a 30-minute ban coffin with zero recourse
parking system: bans (40012 -> 24h parking), dead credentials (40002/40003 -> quarantine until manually fixed), and short-term rate limits. token doesn't hit quarantine, it just gets parked for a bit

other goodies & features:
claude / anthropic mock: intercepting messages from Claude Code’s auto mode and returning an authorizing response; it’s an optional feature. this way, we don’t waste dseek requests for these interactions. another quirk is that it sends this kind of stuff even when "bypass permissions" is enabled
json mode & structured outputs: native response_format / json schema support, schema minification, and hash-caching tuned for deepseek's prompt cache
bulletproof tool call repair: resilient parser that heals janky json (single quotes, trailing commas) and extracts tool calls leaked into raw xml tags
pool rotation fix: failed tokens are passed to exclude, seamlessly retrying user turns on the next available key without breaking client streams

unfortunately, playwright is mandatory for this version now, we won't bypass the new deepseek protection otherwise. my friend and i tested this version for over three hours with zero token bans. when i switched back to the main branch version... the token got banned after 4 requests

[artyom08-dev]

fixes #105 #106

[artyom08-dev]

thanks to @1515asd for the heads-up on the upstream reasoning change. the issue manifested differently on our end and required a different fix, but had the exact same root cause

[1515asd]

Honestly this is good work and I agree with the direction. You were right about the core thing: a session born in a browser being driven through android routes is exactly the mismatch that burned people, and I said as much in #106 while I was still chasing a wrong theory of my own. Rewriting the client to look like a real desktop Chrome, one cookie jar per account, not throwing a token away on 40303, parking instead of instant quarantine — all of that is better engineering than what most of us had. So yes, count me in on the diagnosis.

But I read through the code and both READMEs, and what worries me is what it asks of the person actually running it. Playwright is mandatory now, you say so yourself at the end, yet the documented install paths don't ship it. The Dockerfile only installs curl, there's no playwright install chromium in it, the plain requirements.txt has no playwright at all, and in pyproject it sits under optional extras. So someone doing the recommended docker run ghcr.io/... or uv sync ends up with async_playwright is None, the startup cookie warmup dies with "playwright is not installed", and they have to work out the browser binaries and system libs on their own. The Chinese README says the exact opposite — that Playwright and Chromium are deprecated and you no longer need playwright install chromium or xvfb — which will send half the readers down the wrong road. That one's worth fixing before the issues start coming in.

And once it's installed, the operator's day hasn't got shorter. Accounts still registered by hand, incognito window, log in, F12, JSON.parse(localStorage.getItem("userToken")).value, paste into the dashboard, close the window — the same three steps we all had before, none of it got simpler. On top of that, startup launches a headless Chromium per token with a 120s timeout and two retries, so ten accounts means ten browser launches before the service is ready, plus a resident browser on a VPS that rarely has memory to spare. The captcha button is the one I'd flag hardest: it opens a visible browser and waits up to ten minutes for a human to click through a challenge. You already said it, on a headless box it does nothing — so for most self-hosters a 40303 still just means a 30-minute cooldown or a 24-hour park with no way out. That's a lot of new machinery for a user to carry if the real trigger turns out to be much smaller.

Here's why I wanted to write, though. We've been running the plain old way — and I mean the old way, nothing changed about extraction or client shape — and haven't lost an account. The token came out of Safari's localStorage right after a normal web login with the email OTP and went into the pool at 7:02 AM on Nov 7 US Eastern (12:02 UTC); the first "hi" went out at 7:07 AM with no kick. It's now late morning on Nov 7, a bit over four hours later, and I checked the live pool a minute ago: still ACTIVE, a real upstream probe says valid and not muted, and the last actual request was about half an hour ago. In between there were three deploys, a pile of recorded-stream replays and A/B tests against the real upstream. Nothing died. And by your checklist this setup should be the first to go: web-born token, android-shaped bridge, a short web-format shumei id on record (the one android login rejects), one account, no warmup, no isolated browser profile, no parking. Three or four prompts shouldn't have kept it alive for four hours.

So my own guess, and I'll happily be wrong, is that the wave was a short-lived clamp plus a concrete protocol change, not a permanent rule quietly scoring our client shapes all along. Two things push me there. First, that same setup — web-born token into an android-shaped bridge — was getting accounts muted and tokens revoked on Nov 5 and all through Nov 6, and now it just sits there on a fresh account; our four versions in between didn't change the client shape or add any anti-ban logic at all. Second, and this might be the more useful bit for you: we did hit something today that looks exactly like "dies after a few requests". Upstream started requiring shumei_device_id in the completion body on follow-up turns, and without it the answer comes back as biz_code 26 "invalid message id", instantly empty. Add the key — null passes too — and it's fine. That's one field, not an identity overhaul; we added it to fix empty replies, not bans. When you said switching back to main got the token banned after 4 requests, I'd really want to check whether main is simply missing that field. That would explain it without needing the whole social-credit story. I'm not saying your rewrite doesn't help — I'd keep most of it — I'm saying the cause might be smaller and far cheaper to fix than "we had to patch every leak in one go", and if so, making every user install a browser and keep a desktop around for captchas is a steep price for it.

Either way, both our samples are tiny. You said two hours wasn't enough, and four hours on one account isn't either. I'm leaving this one running and will log the moment it drops, and I'd love to hear what you see if you take an old-style token and just run it on current upstream for a few hours without changing the shape. If it survives too, we'll know the wave was the thing. If it dies, I'll eat my words and come help write the browser setup docs.

[artyom08-dev]

i already mentioned in the pr text that i took one of the tokens and ran it on the main version, and it died almost instantly. right now i have claude code running, and it's doing work pretty actively, so let's see how it goes. my friend just texted me that deepseek ended up banning his account after the captcha anyway, but he managed to make over two hundred requests, whereas our record on main version today was only 10 requests. personally, i haven't run into any bans

as for the wave... it's not a change in protocols at all, it's targeted bans on reverse proxies. the ban wave hit absolutely every project, just check out other repos. even harmless browser extensions were getting banned. and they're fine-tuning this right now. shumei_device_id was definitely not added by accident

[artyom08-dev]

And once it's installed, the operator's day hasn't got shorter. Accounts still registered by hand

did I set out to automate the login process in this PR? no. so, smth is off here. you’re free to do whatever you like in your own fork, but since i’m contributing to the project itself, i can’t just go adding random features

[1515asd]

Fully with you on this one 👍 — it's not a protocol change at all, it's targeted bans on reverse proxies, they hit every project out there, and they're clearly still fine-tuning it. shumei_device_id definitely wasn't added by accident.

Honestly, this whole "grab a web token and drive it through a bridge" route may have genuinely reached the end of the road for us: one of our alt accounts was just disabled, literally just now 💀

That's also why I don't think piling more machinery onto this route is worth it. Nothing here automates the account side — and to be clear, I'm not asking you to add login automation to this PR, you never set out to do that — accounts are still registered and logged in by hand, the token still gets pasted in manually, and playwright spinning up a headless Chromium per token is heavy and eats a lot of RAM on a small box. On a headless VPS the captcha step doesn't do anything either. That's a lot of weight to carry for a route that's already this fragile.

So we're going to step back and look into a different approach, a different route after this. No ETA, not sure when — could be a while, we'll see.

If you need a hand with anything — another pair of eyes, real SSE stream captures, or someone to A/B a fix against a live token — just ping me anytime, happy to help.

[artyom08-dev]

it's pretty raw, still way too raw and not ready to merge, so i'll keep working on it for now. i'm not even that worried about bans anymore, it's more about captchas. i keep hitting an endless captcha that's just impossible to pass

[AmanCode22]

@artyom08-dev @1515asd thnx for the updates and effort but few things to considerbefore its ready to merge.

[AmanCode22]

@artyom08-dev that captcha is old issue but waf cookie is harvested before captcha appears so safe

[artyom08-dev]

i’ve set it to draft for now. it’s not ready to merge yet
what few things did you have in mind?

[AmanCode22]

1. The playwright is not documented to install. . The PR touches neither requirements.txt nor pyproject.toml nor any Dockerfile. I checked main: no playwright anywhere. .env.example declares it mandatory; the code hard-fails with CookieGenerationError("playwright is not installed"). So docker run / uv sync / pip install users get a broken startup.

2)Docs contradicts: English README gets a 1-line flip ("Playwright must be installed"), but the Chinese README still says the opposite (Playwright deprecated, no playwright install chromium needed) — and isn't touched at all.

3)Slow Startup mostly in small VPS : warmup launches a headless Chromium per token (120s timeout ×2 retries) before the service is ready — 10 accounts = 10 browser launches, plus resident RAM on a small VPS.

4)Keep it non headless if u want , i have not checked that part but still recommending from past experience with deepseek web and playwright that headless is real mess.

5. DEEPSEEKER_AUTO_MODE_MOCK defaults to true — Claude Code auto-mode prompts get silently mocked by default. Should probably be opt-in.

6. One thing i need to address not much imp but still the PR body and a function name (chairman_xi_penalize_social_credit) are… colorful for a public repo like deeperseeker so kinda worth taking note of.

[AmanCode22]

If u need any help on playwright thing ask me I have played with it a lot when making deeperseeker at start it took my much time and the last option was highly tuned

Edit: Btw its there only in main branch I have just commented it for any future issue like this

[artyom08-dev]

thanks, i'll still take a look, maybe i'll just throw it away completely if possible, cuz it's really heavy

[artyom08-dev]

that captcha is old issue but waf cookie is harvested before captcha appears so safe

@AmanCode22 it looks like you are talking about the cloudflare captcha, but i mean deepseek's own captcha that appeared recently

[AmanCode22]

thanks, i'll still take a look, maybe i'll just throw it away completely if possible, cuz it's really heavy

that captcha is old issue but waf cookie is harvested before captcha appears so safe

@AmanCode22 it looks like you are talking about the cloudflare captcha, but i mean deepseek's own captcha that appeared recently

So the newer captcha I also noticed few days back when doing login ya then that one needs a solution entirely

[AmanCode22]

Still if u need any advice I am here but looks like deepseek has evolved past much from where I left it few weeks back in deeperseeker

[1515asd]

We said earlier we would step back and look for a different way. No date for it. Here is where we are now. This is us thinking out loud, not a result.

We looked at almost every project out there. At first it was all ideas and big words, and it stayed foggy. Then we drew it as one very simple picture, and it became clear. That helped more than anything. So let us just show the picture.

Two doors.

Door A is the web page. Door B is the phone app. Behind each door is the same food: an answer to your question. Each door has its own guard and its own rules. They were built separately. They were never meant to know about each other.

Who gets into door A easily?

Someone who is already inside. He did not come in from the street. He walked out of that door. The door gave him his name, his badge and his keys when he was born there. So when he comes back, the guard just knows him. He does not have to pretend to be anyone.

Now the people outside.

They have no name, no badge, no keys. They still want the food. Two things got tried:

1. Most projects: build a fake "web person". They take nothing and dress it up to look like someone from door A. To do that they carry a whole real browser with them. They hand a made-up ID to a guard at the door whose only job is asking "are you a robot or a human?". The door keeps changing its locks, so they keep changing the costume too. The hard part: they have never been inside. They do not know what the room looks like or how the locks work. They are guessing from the street. So the costume is always a little wrong, always heavy, and never finished.

2. Our old way: dress up as B and walk into door A. We did not build a fake web person. We put on the phone app's shape and went to door A. For a while that worked, because back then door A's guard only looked for "fake web people". It had no rule about someone shaped like the phone app. It thought "this looks odd, I do not know this one", but it could not be sure, so it let us in. It did not forget, though. It wrote things down every time. After enough visits it had enough notes, and it put up a sign: "anyone shaped like the phone app is not welcome here". Not one account — the whole shape. And only after many visits, not at the first one.

There is a third door too, door B. It looks easier: a weak door, no guard asking about robots. But it wants a fingerprint, and that fingerprint is not in a browser and not on either door. It lives down inside the device's system, which is a separate thing with its own defences. To reach it you need root — a level of access most people running a small server simply cannot get. So that road is blocked for most people as well.

Why say all this?

Because once it is a picture instead of big words, one thing is very clear: every project out there is doing the same single thing — dressing up. Dress as a web person. Dress as the phone app. Act like a real browser. Look more like a real device. Add one more header. Different names, one action: pretend to be someone else. Even our old way was just another costume.

The only one who never does this is the person who came out of the door. He does not need a costume. He already belongs there.

So we are not trying to make a better costume. We are trying to stop dressing up at all.

What we are looking at now. These are questions, not answers. We have not tested any of them.

1. Walk into door A carrying nothing. No real browser to drag along. No window that has to stay open. No waiting around to "warm up" before it works. Just the question, and the answer comes back. (This is the same heavy load people in this thread are already tired of.)

2. Get what door B asks for without opening the phone's system. Is there any other way to get that fingerprint, without going into the system at all, without root?

3. Do not go in. Watch what comes out. Instead of pushing past a guard, look at what leaves each door — the traffic, the little pieces of data, the answers. Read those and work backwards. Someone who just walked out may tell you more than a guard you never got past.

4. Get one honest look inside. Right now everyone is guessing about rooms they have never seen. One real look from the inside would replace a lot of guessing. Not sneaking in — just being able to see what the checks actually are.

5. Or ask why there is a door at all. Maybe "get through the door" is the wrong question. Maybe the whole shape of the problem changes if you stop treating the door as something you must pass.

None of this is a result. None of it is a plan with a date. Still no date, like we said. We are sharing it because the picture got simple once we drew it, and we would rather be wrong in company than go in circles alone. If any of this sounds right, or sounds wrong, we would like to hear it.

[AmanCode22]

@artyom08-dev @1515asd I am currently working on binary level analysis of deepseek android app + deep analysis of its networking and everything using a rooted android device would report as soon as i find something.

As binary level analysis can reveal information like how device fingerprint idd possible can be generated.

[artyom08-dev]

shumei is detecting playwright and blocking the account chain and triggering captchas because of it. worked on stealth and now testing a new commit before pushing. also, turns out deepseek learned to track users by ip, which makes things even harder, triggering captchas and ban chains. we successfully bypassed basic defense in this pr, but after 50-100 requests its system flags us as suspicious. it mostly gives captchas on requests now, rarely a ban

[artyom08-dev]

found a pretty weird piece of code in deepseek's main.js, which i initially misunderstood in this pr as adding B to the shumei device id, here it is:
n.startsWith("B") ? { shumei_device_id: n } : {}
meaning if shumei device id DOESN'T START WITH B, we don't send it at all! and no, this isnt a safeguard against an incorrect format. my real browser returned it without the 'b' and didn't send it!

also deepseek started blocking accounts even from the real browser (not going through our proxy at all, these are just my personal accounts) if i use a vpn, they really are tracking ips

[artyom08-dev]

i’m gonna push a commit with a stealth mode right now... and that’s pretty much all we can do, cuz they track ips aggressively too. if one ip uses multiple tokens, they throw a captcha at every token. how to bypass this? i have absolutely no clue, it’s not like we're gonna add a proxy pool here

android simulation won’t work here either, my current setup already does everything possible on the client side, but they track ips. it's the exact same thing on android: if there are multiple tokens, they throw a captcha at you. if it's just one token, you’ll be sending requests too frequently and they'll damn well throw a captcha at you anyway

[AmanCode22]

@artyom08-dev I have run binary level analysis of apk of deepseek and have found almost process of device fingerprint can I pls get an sample so that I can confirm I am going in right way

[AmanCode22]

ID	What it is	Where it comes from
Local deviceId	Device fingerprint ID computed on-device	SmAntiFraud.getDeviceId() — read from SDK cache, generated by native lib libsmsdk.so
Server SmID	Risk-engine ID assigned by Shumei's server	Server response pushed to the app through SmAntiFraud.IServerSmidCallback (registered via registerServerIdCallback)

I have found these two in deepseek app analysis

[artyom08-dev]

@AmanCode22 i don't have a rooted android on hand rn, and if i remember correctly, 1515asd wrote that they only have an iphone, so highly unlikely. plus you don't just need one sample, you actually need a few of 'em to figure out their synthesis logic... maybe try an emulator?

plus i don't even think the android route would help anyway, since i haven't really messed with android, i've been working on the web side. right now i'm facing a huge issue where they're literally ip-banning everything, as you can see in my last message... no clue how to bypass it

found one project where they just added proxies, but... are people actually gonna do that? prob not

[artyom08-dev]

the current version was stress-tested on a pool of 3 tokens, and none of them got flagged as parked due to a captcha. it’s already got built-in protection against any future deepseek verification methods and perfect masking for shumei, your feedback has been taken into account

there are 2 hitches i’m not sure how to handle yet:

ip blocking, and whether to add proxy support here (i spelled out the issue earlier), though with this kind of masking i haven't even run into it anymore. maybe it looks at the shumei scores...

and the captcha solver button. that kind of workaround won't open anything on vps instances. then again, we barely run into captchas anymore, so pretty much no one should even see it

[1515asd]

@artyom08-dev glad the feedback helped — solid progress, nice work. on the two open hitches: for ip blocking, making proxy support optional / opt-in sounds like the sane path — most self-hosters won't buy proxies, but the ones who genuinely need it can just plug theirs in. and the captcha solver button is a no-go on headless vps boxes anyway; if captchas have mostly stopped showing up with the masking in place, it's probably not worth the effort at all.

one heads-up for anyone reading our repo: there's a comparison graphic in our readme right now laying out the pros and cons of the token / browser / community-project approaches — parts of it are just wrong. don't trust it for now, we mixed things up and it's being redone.

[artyom08-dev]

@AmanCode22

3)Slow Startup mostly in small VPS : warmup launches a headless Chromium per token (120s timeout ×2 retries) before the service is ready — 10 accounts = 10 browser launches, plus resident RAM on a small VPS.

4)Keep it non headless if u want , i have not checked that part but still recommending from past experience with deepseek web and playwright that headless is real mess.

to this end, two settings were added to the .env file. they reduce the level of masking but improve speed/convenience.

[1515asd]

@artyom08-dev exposing those as .env switches makes sense — trading a bit of masking for speed/convenience is the right call to leave to the operator, especially for small VPS boxes and the headless mess.

as for our side, all I'll say is: there's more to it than what's visible here, and the key point isn't in this thread. take your time exploring 🙂

I guarantee you: no method like ours exists anywhere on the market right now.

[artyom08-dev]

@1515asd dear ai agent, please tell whoever is managing you not to think that sending via a real browser is something unique, god forbid try to sell it, and not to try to hide it even without a force push. controlling a browser via chrome debugging was never really a big deal. it's just dumb and clunky, plus u can't run a huge pool of accounts with it... thanks ;)

[AmanCode22]

@artyom08-dev i dont think if @1515asd is an ai agent

[artyom08-dev]

@AmanCode22 take a look at his responses in the issue. he forgets things he knew just minutes earlier; this quote alone, i think, is enough:

If you need a hand with anything — another pair of eyes, real SSE stream captures, or someone to A/B a fix against a live token — just ping me anytime, happy to help.

[AmanCode22]

@AmanCode22 take a look at his responses in the issue. he forgets things he knew just minutes earlier; this quote alone, i think, is enough:

If you need a hand with anything — another pair of eyes, real SSE stream captures, or someone to A/B a fix against a live token — just ping me anytime, happy to help.

Ya that I feel is true so we cant kinda trust him much

[1515asd]

@artyom08-dev nothing is being sold here, and it never will be. this is something we built ourselves, from the ground up, for our own project — fully self-developed, and right now nobody out there knows this method. it's just not finished yet, the english side hasn't even been pushed.

so a genuine word of advice for anyone reading: don't download anything, don't put your trust in what's sitting up there right now, and don't burn your time trying to dig into it at this stage. when it's properly done, you'll see it the normal way — free and open, same as always. that's all for now 🙂

[AmanCode22]

purely AI confirmed now

[1515asd]

@AmanCode22 man, sorry to see that. the reason my messages read so much like AI is that basically all my time goes straight into the project. I'll own it — most of those messages were AI-written. I'm usually testing the project and replying at the same time, so only a handful of lines here were actually typed by me. most of the time I'd just have GPT generate something reasonable and fire it off without really thinking it through — those long, detailed write-ups earlier? that's exactly how they came about. when I actually get a spare minute, that's when it's really me replying.

[1515asd]

and to add to that — since I never paid for a subscription plan, the model I use isn't actually that smart, and on top of that I never bothered optimizing my prompts. that's exactly where the "AI flavor" you're all seeing comes from.

[artyom08-dev]

btw real people dont really throw around those dashes and fancy symbols like that, and they barely type periods either

sounds like you just fed that to an ai and told it to sound human... wait, i was literally writing a reply to this message and he deleted it. he seriously put that quote into ai and told it to sound more human, and it just duplicated the exact same thing??

[artyom08-dev]

exactly a minute ago, there was a post from him here containing this quote, along with a note that he would add more details in posts

[1515asd]

here's what happened with that deleted message: I was trying to add some details since I'm testing the project right now. what I meant to say was that real people never use punctuation and slashes like that, and you could take that as a tell for your judgment. but the AI got it twisted, and it went out before I caught it. I went to take it down, which ate up some time. and yeah, this very sentence is AI too. once I'm done with everything on my plate I won't be this half-assed about it.

[1515asd]

@AmanCode22 @artyom08-dev ok, all my work's done now, the new files are up on my repo, those ai sentences were dogshit, even i could barely stand to read them, only because i was testing and replying at the same time, so the second the ai answered i'd just copy paste and hit send, this idea of mine really is different, and i wasn't saying i was gonna sell anything, that was the ai's own wording that misled you guys, i brought up that door a and door b thing before, i chewed on that one for a long time and came up with a new way, then spent half a day digging into the official window, and i really did find something, found a real way in, nobody knows about it yet, it's not like those popular projects out there, well can't say totally different either, the base is still AmanCode22's, i just used one clever idea, artyom08-dev's one needs a browser, rough if you're on a free server, and you gotta click through verification, that's the annoying part, and the official side keeps switching up the protocol, so we're all stuck updating all the time, and the reason AmanCode22's one is better, no heavy browser, no sitting there clicking captchas, one should last you a good while, that's the lightweight part right there, it still has to deal with the protocol changes though, and mine? no browser, no sitting there clicking captchas, just as light as AmanCode22's, and what's better? it goes right around their detection, and no chasing their protocol changes either, because i already went around it, what i'm worried about right now is whether the official side will see this new method, i'm kinda scared to let it out, if you guys need the actual method i'll definitely share it for free, let me say it again, i'm not selling anything, i'm really into this project, the reason i don't plan to is exactly what i just said, and right now i still can't guarantee it won't get banned at all, because it hasn't had a long run yet, but a few days should do it