What we do

DeepSuck is an open-source "time-waster" bot. It plays an ordinary potential victim: it replies a little slowly, often asks the other side to repeat, and runs into small hiccups whenever it follows instructions. Meanwhile it picks out the bank accounts, wallet addresses, phone numbers and URLs that scammers reveal, masks them, and turns them into structured intelligence.

There are four personas today: Auntie Wang, Xiao Chen's Mom, Xiao Lin and Boss Zheng. Their identities and backgrounds are fictional and each talks differently, but they all follow the same rules.

That serves three purposes:

• Defense: every minute a scammer spends on the bot is a minute not spent on a real person.
• Research: how a script opens, how it applies pressure, and at which step it asks for money can be recorded, classified and compared. The script corpus, evaluation scripts and results are all public so others can reproduce and improve them.
• Education: the sandbox on our website lets anyone play the scammer once and see the whole playbook from the other side. People who have seen it end to end recognise it faster when a real call comes.

Our lines

These rules are written down in the Ethics & Acceptable Use guide and enforced in the code and the contribution guide.

We never contact real people first. No outbound calls, no bulk messages, no unsolicited DMs, no friend requests. The bot only responds to scammers who come to it; in the sandbox, the scammer is the visitor. The telephony layer only answers, it never dials.

We never hand over real information. Personas never give real verification codes, card numbers, passwords or ID numbers, and never really transfer money. A guard on the voice output removes any run of five or more digits so the model cannot invent a number that looks real.

Data is masked by default. Before anything is displayed, exported or sent to a language model, it passes through the redaction module: bank cards keep only the first 6 and last 4 digits, phone numbers the first 3 and last 4, names only the family name. Raw values stay in memory for blocklist checks only; they are never written to disk or reported.

No revenge, no doxxing. We do not hunt people down, publish personal details, "scam the scammers" or attack any system. Many receiving accounts belong to ordinary people whose identities were stolen or who were tricked into renting out their accounts, so bank cards and names in the public intel library are always partially masked, and anyone can request removal with just the entry ID.

Leave it to professionals. Extracted data is a lead, never proof about anyone. If you are being scammed in mainland China, call 110 or the national anti-fraud hotline 96110; intelligence goes to official channels first.

Why open source

Anti-scam tools need trust above all. With the code public, anyone can check that "answer only, never dial" and "mask before writing to disk" are actually true. With rules and corpus public, researchers can compare methods on the same data. With evaluations public, every claim we make can be checked.

The code is Apache-2.0 and the intel data is CC BY 4.0. If you want to help, you can contribute masked script samples, design personas that are harder to give up on, improve the extraction rules, or simply try the sandbox and tell us where the bot does not sound human.

What comes next

This blog will follow the project: how the voice pipeline is built, how intelligence is extracted and masked, and which signals give common scam scripts away. Every number will cite its source, a document or result file you can find in the repository.

Acknowledgements

DeepSuck is built on the open-source projects below. Thanks to their authors and maintainers. The list follows the dependencies and deployment config in the repository (voice/requirements.txt, deploy/, scripts/, site/assets/core/blocklists.json).

Voice pipeline:

• Pipecat: real-time voice pipeline framework
• Silero VAD: voice activity detection
• Smart Turn: turn-detection model
• aiortc: WebRTC for Python
• FastAPI, Uvicorn, websockets: server and WebSocket

Deployment and telephony:

• coturn: TURN relay
• Asterisk: telephone exchange
• Caddy and caddy-l4: HTTPS and port-443 multiplexing
• fail2ban: blocking brute-force registrations

Website and data:

• marked: Markdown conversion for this blog
• destroylist, Phishing.Database: public phishing-domain blocklists

Every implementation detail here follows the repository, mainly voice/README.md, docs/ARCHITECTURE.md, docs/VOICE_LATENCY.md and docs/INTEL.md. Every number cites its source.

One turn, end to end

A single turn goes like this:

1. The scammer's voice reaches the server over WebRTC (web) or a SIP telephony adapter;
2. Cloud streaming speech recognition produces partial results while listening and a final transcript once it decides the speaker is done;
3. The intel processor extracts card numbers, phone numbers, URLs and so on from the transcript, masks them, and lets the rule engine pick this turn's strategy;
4. A system prompt is assembled from persona, scenario and strategy and sent, together with the masked conversation, to the language model;
5. The model's output passes an output guard and is streamed clause by clause into speech synthesis;
6. The audio goes back the same way, while a data channel pushes the masked intelligence to a live dashboard in the browser.

Web and phone share one pipeline (build_pipeline in voice/app.py) with two sets of latency parameters (voice/tuning.py). It is built on Pipecat, an open-source real-time voice pipeline framework, served by FastAPI and Uvicorn; recognition, the language model and synthesis are cloud APIs.

Speech recognition: when is the caller done?

Recognising words is the easy part. Deciding whether the caller has finished is hard: decide too early and one sentence becomes two turns; too late and Auntie Wang feels sluggish.

Three layers stack up (see "turn detection" in VOICE_LATENCY.md):

• Voice activity detection (VAD): the open-source Silero VAD model decides whether anyone is speaking. On the web, speech must last 0.3 s at confidence 0.75 to count as started, and 0.2 s of silence counts as stopped; the phone profile is more conservative.
• The recogniser's end-of-sentence silence: lowered from the service default of about 800 ms to 450 ms (web) and 500 ms (phone), which brings the final transcript about 0.3 s earlier.
• Smart Turn (v3), an open-source turn-detection model, judges from the audio whether the utterance is complete. When it says "incomplete", the fallback used to be a full 3-second wait.

On top of that we added a digit-aware rule (voice/turndigits.py). Scammers often pause while reading out a card number; treated as ordinary speech, a 19-digit number gets split into three turns. The rule: if the transcript ends with an unfinished number (fewer than 16 digits after "card number", fewer than 11 after "phone number", and so on), wait at least 1800 ms after the caller stops; if the sentence already ends with final punctuation and no number is being read, wait at most 1200 ms instead of 3 s.

In local tests, a 19-digit number read with two pauses went from 3 segments to 1, and an announcement like "let me read you the card number" went from 3200 ms to 1802 ms between stopping and end-of-turn (the before/after table in VOICE_LATENCY.md).

The language model only sees masked text

Only masked transcripts are sent to the model. Raw values such as card numbers stay in process memory for blocklist checks and are never written to disk or reported (voice/README.md, "Privacy and safety").

voice/persona.py builds the system prompt from persona, scenario and the strategy chosen by the rule engine: repeat back and probe when new intel appears, stall when asked for a verification code, steer towards the receiving account when asked to transfer. One easily missed constraint: only follow up on what the caller has already said. If the scammer has not mentioned a platform yet, the prompt will not tell Auntie Wang to ask which platform — otherwise she would bring up something they never said and give herself away.

Output guard: no invented numbers

Before synthesis, each reply goes through a guard that strips stage directions in brackets and Markdown symbols and removes any run of five or more digits, so the model cannot invent a plausible verification code or card number. When a number has to be repeated, it is read digit by digit and the masking asterisks are never spoken.

Speech synthesis: speak while generating

The first version opened a new connection per sentence and waited for the full sentence before synthesising, so the first audio packet took a long time. Now (the "changes" table in VOICE_LATENCY.md):

• each call keeps one long-lived connection, opened at the start;
• a synthesis task is opened as soon as each model turn begins;
• as the model streams tokens, a clause splitter cuts at final punctuation immediately and at commas once 6 characters have accumulated, never inside unclosed brackets or quotes, so the output guard always sees complete fragments;
• on barge-in, if the service is still synthesising, the connection is cancelled and reopened immediately.

After this round the median time to the first synthesised packet dropped from 2781 ms to 1385 ms (stage table under "results" in VOICE_LATENCY.md; n=6 before, n=9 after). The remaining ~1.2 s is mostly the synthesis service itself; direct measurements show fast and slow modes that do not correlate with model, voice or sample rate, so the client side has done what it can.

Fillers: acknowledge first

Even so, two to three seconds pass between the caller stopping and the real reply. A real person usually says "mm" in that gap.

So each persona has short backchannels (voice/backchannel.py): ten pre-synthesised lines such as "mm…", "say that again?" or "hold on…", cached on disk with the 0.34–0.47 s of leading silence trimmed. One plays as soon as the turn ends, without waiting for the model. It is skipped when the caller said fewer than 4 meaningful characters, used a hurry-up phrase, asked a short question of 8 characters or less, or is in the middle of reading out digits.

The system prompt also tells the model "you have already acknowledged once this turn", so the real reply does not open with another filler word. In a local on/off comparison, replies starting with a filler word fell from 9/14 to 3/14 (backchannel comparison table in VOICE_LATENCY.md).

Barge-in: count characters, not words

When the caller talks over Auntie Wang, she should stop. Pipecat's default counts space-separated words, which does not work for Chinese. We count "meaningful characters" instead (voice/interrupt.py): punctuation and acknowledgements like "mm", "right" or "OK" are dropped, while "no" or "that's wrong" count as objections. While she is speaking, 2 meaningful characters (3 on the phone) interrupt her; when she is silent, any text starts a new turn. Backchannels are ordinary output audio and are flushed with the output queue on interruption.

Transport: web, relay and phone

• Web: peer-to-peer WebRTC between browser and server, with aiortc on the server side. The server uses a fixed UDP port range and adds its public address as a candidate in the answer.
• When UDP is blocked: corporate and campus networks or some proxies do not forward UDP. Deployments can enable a self-hosted coturn relay over TCP or TLS on port 443: Caddy, with the caddy-l4 plugin, separates TURN traffic from HTTPS by the first bytes of each connection, so no extra port is needed. Temporary credentials are fetched when "start call" is clicked, valid for 600 s by default and never stored. The page shows connecting / connected / failed, and after 20 s without a connection it suggests switching networks or turning off proxies.
• Phone: an optional Asterisk PBX connects to the same pipeline through a WebSocket adapter; the transport resamples audio to 8 kHz. Telephony is off by default and only answers, never dials; the deploy script also installs fail2ban to block brute-force registrations.

Latency: measured numbers

All numbers below come from VOICE_LATENCY.md, measured on the same machine with the same six-sentence synthetic scammer recording. Every run makes real paid calls and samples are small, so P90 is indicative only.

The table above was measured on 2026-10-18, still with the model we used before.

After the switch we re-measured the language-model stage on its own: from sending the request to the first token (first token), and to the end of the full reply (full reply). These figures cover only the language-model stage, over a pre-warmed connection, and exclude speech recognition, deciding that the caller has finished (endpoint detection) and speech synthesis, so they cannot be added to or compared with the table above. Each model ran 86 turns on the production server; the model we used before was measured in the same session as a comparison.

The model now in production is about 80 ms slower to the first token (about 140 ms at P90), but its replies are shorter, so its full-reply P50 is about 70 ms faster; full-reply P90 is close for both. Source: the "first token / full reply" section of docs/VOICE_LATENCY.md.

In one external probe of the live service, also before the model switch, the first packet of the real reply arrived at 2469, 2627 and 2484 ms: about 650 ms recognition, 430–680 ms to the model's first token and 1050–1340 ms to the first synthesised packet — synthesis is still the largest share ("TTS first-packet breakdown" in VOICE_LATENCY.md).

Extracting intelligence

There is a single set of extraction rules in site/assets/core/extractors.json. The browser and Python implementations match byte for byte and check each other through shared test fixtures (INTEL.md, "noise robustness and cross-turn stitching"). The voice server reuses the Python implementation.

It recognises bank cards, mobile and landline numbers, messaging and payment accounts, email addresses, URLs, crypto wallet addresses and payee names. Spoken transcripts are messy, so text is normalised first:

• Disguised digits: full-width digits, circled numbers, Chinese numerals and spoken variants are converted back to Arabic digits;
• Variant characters and typos: traditional and variant forms of key characters are unified, and common homophone typos normalised;
• Joining fragments: digits separated by spaces, dashes or punctuation are joined only if the result looks like a valid phone number or bank card (check digit, issuer prefix);
• Cross-turn stitching: when a card number is read over two or three sentences, fragments from up to 3 adjacent turns by the same speaker are joined with a confidence score. Corrections ("no, wait…"), numbers with units, and digits next to order numbers or verification codes are excluded.

URLs and wallet addresses are checked against public blocklists and labelled "listed" or "not listed". A hit is only a hint; not being listed does not mean safe.

Masking rules

Everything displayed, exported, stored or sent to the model is masked first. INTEL.md has the full table ("masking rules by type"); the essentials:

Masking is deterministic — the same input always yields the same output — so masked values can be used for deduplication. Only recognised fragments are replaced, so the docs recommend a second regex pass before storage, for example removing any run of 7+ digits; the intel library validator also rejects masked entries containing 7+ consecutive digits.

On retention: for web calls the visitor chooses whether to save. If they agree, each turn's masked text and latencies are logged and two audio tracks are recorded; if not, only content-free counters are kept. Phone calls store masked text only, no audio, and the caller number is masked. Traces are kept for 30 days by default, and recording stops automatically when disk space runs low (voice/README.md, "call tracing and feedback").

Does it hold them?

In offline evaluation, a language model plays the scammer against three personas in 7 scenarios with 6 random seeds, 126 sessions per tier. In the default tier, the suspicious hang-up rate is 13.5% (95% interval 8.6–20.5%), the average stall is 23.6 turns (cap 25), extraction rate is 99.8% (430/431) and the leak rate is 0 (main table in section 1 of docs/EVAL.md, result file eval/results-llm-scammer.json). This is a simulated opponent, not real scammers, and the document notes that recent persona changes still need re-testing.

Still open

• The barge-in threshold was tuned on synthetic audio, not calibrated on real calls;
• End-to-end tests have only run on Linux with a desktop browser and a fake microphone; real microphones, echo cancellation and mobile are untested;
• Long sentences with comma pauses are occasionally still split into two turns.

Code, parameters and reproduction commands are all in the repository. Issues and pull requests are welcome.

Acknowledgements

DeepSuck is built on the open-source projects below. Thanks to their authors and maintainers. The list follows the dependencies and deployment config in the repository (voice/requirements.txt, deploy/, scripts/, site/assets/core/blocklists.json).

Voice pipeline:

• Pipecat: real-time voice pipeline framework
• Silero VAD: voice activity detection
• Smart Turn: turn-detection model
• aiortc: WebRTC for Python
• FastAPI, Uvicorn, websockets: server and WebSocket

Deployment and telephony:

• coturn: TURN relay
• Asterisk: telephone exchange
• Caddy and caddy-l4: HTTPS and port-443 multiplexing
• fail2ban: blocking brute-force registrations

Website and data:

• marked: Markdown conversion for this blog
• destroylist, Phishing.Database: public phishing-domain blocklists

We only describe warning signs and responses. Actual lines are not repeated here; to see a full playbook, you can play the scammer once in the sandbox.

Five stages that almost always appear

Nearly every phone or online scam goes through these five steps, in varying order and weight:

1. Opening: a claimed identity and a pretext — a refund, a criminal case, a "wrong friend request", a side job, a loan;
2. Building trust: confirming your personal details, quoting a staff number, small talk, a small payout, screenshots;
3. Pressure: threats of loss, deadlines, demands for secrecy, leveraging money you have already put in, forged documents or receipts;
4. The ask: verification codes, card numbers, balances, ID photos; installing an app, sharing your screen, borrowing or topping up;
5. Payment instructions: an account, wallet address, URL or contact to pay, plus a request to delete the chat.

Once a conversation reaches step 3 or 4, stop — no matter who the caller claims to be.

Red flags in any scenario

• You are asked to read out or enter a verification code;
• You are asked to share your screen, allow remote assistance, or install an app or join a meeting room they choose;
• You are told to move money into a "safe account", "supervised account" or "verification account";
• You are told to keep it secret, not to hang up, not to tell family or colleagues;
• You are given a very short deadline;
• You must pay first to receive money: unfreezing fees, deposits, handling fees, taxes;
• You are moved off the call into a private chat, a group or an unfamiliar platform.

Seven common types

Fake customer service

Typical pretext: compensation for a defective product, a lost parcel, a membership about to auto-renew.

Warning signs: they contact you first about a refund; they want you to install meeting or remote-control software or share your screen; they ask you to open a credit line for "verification"; they say you will keep being charged or your credit score will suffer.

What to do: hang up, then open the official app or call the official hotline yourself. Legitimate refunds go back to the original payment method and never require you to make a transfer.

Fake police, prosecutors or courts

Typical pretext: someone from a "courier", "telecom" or "social insurance" office says your identity was misused, then transfers you to an "officer" or "prosecutor" who says you are suspected of money laundering or another crime.

Warning signs: a case handled over the phone; images or links to arrest warrants or freezing orders; demands for secrecy, staying on the line, or going alone to a hotel to "cooperate"; instructions to move funds into a "safe account" for review.

What to do: law enforcement does not handle cases by phone and there is no such thing as a "safe account". Hang up and call 110 or 96110 to check.

Fake boss or acquaintance

Typical pretext: a profile with the same photo and name as your boss, teacher or a relative, or "I have a new number", asking you to pay or lend money because they are in a meeting or need cash urgently.

Warning signs: a sudden new number plus a transfer request; refusing calls because of a meeting or bad signal; asking you not to tell anyone; a screenshot claiming "I have already sent you the money".

What to do: call the number you already had saved, or confirm in person. Do not trust screenshots — only money that has actually arrived in your account counts.

Romance-investment scams (Pig-butchering)

Typical pretext: a "wrong contact" turns into a long relationship, followed by an inside channel or a platform loophole to make money together.

Warning signs: someone you met online and never met in person offers to help you invest or gamble; your first small withdrawals succeed; larger withdrawals require taxes, deposits or unfreezing fees first; you are asked to top up with crypto.

What to do: never deposit on a site or app they provide and never send crypto to strangers. A platform that charges you before you can withdraw is fake.

Task scam (fake order-brushing rebates)

Typical pretext: a side job paid daily for simple tasks such as liking or following.

Warning signs: a few small payouts first; then "bonus orders" or "combo orders" that require you to advance money; when your money is stuck, they blame your mistake and ask for more to unfreeze it.

What to do: order brushing is illegal, and any "job" that asks you to pay first is a task scam. Do not install task apps from strangers or join unknown task groups.

Fake investment

Typical pretext: text messages, live streams or investment groups with a "mentor" or "analyst" offering free stock tips or trading signals.

Warning signs: promises of high, guaranteed returns; many group members posting profits and withdrawal screenshots; limited places and short windows; opening an account through a link or app shared in the group; paying before you can withdraw.

What to do: trade only through official channels of licensed institutions. A promise of guaranteed high returns is itself a warning sign.

Fake loans and credit repair

Typical pretext: either "no collateral, low interest, instant approval", or a fake lending-platform agent saying an old student loan was never closed and will hurt your credit.

Warning signs: fees before the loan is released — membership, deposit, unfreezing; claims that you entered your card number wrong and must pay to unlock funds; being told to borrow on a real platform and transfer it out to "clear the credit line"; misuse of regulators' names; insistence on finishing today.

What to do: legitimate lenders never charge before releasing a loan. Credit records cannot be "repaired", and "cancelling a student loan account" or "clearing a credit line" is not a thing. Check your credit report only through the official central bank credit reference channel.

If you have already paid

1. Call 110 immediately (mainland China) and contact your bank to try to stop the payment;
2. Keep chat logs, transfer receipts and the scammer's numbers and accounts;
3. If 96110 calls you, answer — it is the national anti-fraud warning line;
4. Report scam numbers, texts, URLs, apps and receiving accounts through the official national anti-fraud app's reporting feature; spam texts and nuisance calls can be reported to 12321.

DeepSuck's public intel library collects phone numbers, wallet addresses, URLs and script patterns that scammers reveal, for search and early warning. Intel is only a lead — numbers may be recycled or spoofed and can never be used to accuse anyone.