A CAS Institute of Information Engineering (MESA Lab, advisor and PhD student names redacted) mid-term report describes three original, experimentally-validated Tor hidden-service deanonymization techniques under the name 'AlterCell': a watermarking attack exploiting a newly-discovered Tor cell-integrity-validation logic flaw that is 18.8x faster than the prior published signal-cookie attack and evades the Vanguard defense (100% TPR / 0% FPR across 341,721 monitored real Tor links over 5 days); a remote / rendezvous-point-side website-fingerprinting method for server-side hidden-service correlation (up to ~90% accuracy using a quadruple-loss metric-learning model); and an attack on Tor's SBWS bandwidth-measurement tool that inflates the researchers' controlled nodes' consensus bandwidth to raise their odds of being selected as a target's guard node. The framework was run against the live Tor network and deanonymized 113,670 hidden services between 2024-01-11 and 2024-03-11.

A MESA Lab task tracker records the assignment "TSG: determine how many clients are behind an IP address," and a companion technical design document details the method: identify distinct TLS clients sharing one public IP using a <JA3 fingerprint, server domain, server IP> 3-tuple (JA3 alone collides across different apps), then use TLS Session Ticket reuse/lifetime sequences per identified client to detect multiple concurrent devices (i.e. NAT) behind that IP.

The same MESA-affiliated researcher (name redacted) gave a "cyberspace mapping" presentation that describes an operational dark-web ("暗网") mapping capability built on controlled/malicious Tor relay, HSDir, and guard nodes: 4,254 discovered node-to-hidden-node bindings and 63 identified hidden router families via guard-node correlation; a "parallel undetectable" hidden-service traceback method that embeds a watermark in the client's packet-direction sequence to recover a hidden service's real IP and guard-node IP; and a hidden-service "isolation" attack that floods a target's HSDir nodes with malicious descriptors, claimed effective against "a well-known foreign dark-web site."

Internal engineering doc describes "整形平台" (internally versioned as "Nirvana" — GitLab repos reshape/nirvana_client and reshape/nirvana_platform), a Kafka/Redis-backed, fully-async C/S platform sitting downstream of sapp that performs cross-session, cross-link correlation to reconstruct complete file content, VoIP audio, and session metadata. Its explicit "单向流对准" (single-direction flow alignment) feature reunites the client-to-server and server-to-client halves of one session when they were captured separately (e.g. asymmetric routing, or a passive mirror tap seeing only one direction).

relationship-gtpc-user derives a single per-subscriber correlation key as Hashkey = md5(IMEI + IMSI + phone_number + vsys_id) from mobile-core GTP-C signaling, and a separate per-tunnel key gtp_uuid = md5(uplink_teid + "|" + downlink_teid). On every update it writes not just the primary user<->TEID row (tsg_galaxy:relation_user_teid) but up to four additional secondary-index rows into tsg_galaxy:gtpc_knowledge_base, one per identifier (IMEI, IMSI, phone number, APN) with a type-digit prefix ("0"/"1"/"2"/"3") and — for phone number and APN — the value's characters reversed before use as the row key, a range-scan-friendly key design that lets any of the four identifiers be used to look up the associated tunnel/session independently.

radius-relationship-hbase (galaxy/tsg_olap) builds a bidirectional, MD5-keyed RADIUS accounting index in HBase — a framed-IP-to-account table and its account-to-IP mirror — so any subscriber account or assigned IP can be looked up in O(1) from either direction, per multi-tenant vsys_id. Each direction is fronted by a Guava write-through cache (10M-entry cap, 24h TTL) so lookups do not hit HBase on the hot path.

radius-account-knowledge's MapCompletedFunction explicitly prefers the RADIUS acct_multi_session_id field over acct_session_id when both are present in an accounting record, specifically to keep a single logical session identifier stable across events that would otherwise fragment it (e.g. re-authentication, mobility/roaming, NAS handoff) — a deliberate design choice for session-identity continuity rather than a default library behavior.