A MESA Lab researcher (name redacted) maintains a personal repo that archives a named toolset for Tor/dark-web deanonymization: an "IP protection software" folder (TorIM2, create_IM_ID_info), a "Tor clearnet domain collection" archive recording exit-node destination traffic, an "accelerated anonymous channel" tool, a "dark web service traceback" archive labeled as an old deanonymization attack, and a "dark web hidden node detection" collection of harvested hidden relays.
folder/file names (translated): IP-protection-software/TorIM2.rar; Tor-clearnet-domain-collection/exit-node-records-of-accessed-targets.tar.gz; darkweb-service-traceback/old-deanonymization-attack.rar; darkweb-hidden-node-detection/hidden-node-collection.tar.gz
Defense implications
- MESA Lab has archived exit-node traffic monitoring and hidden-relay/bridge discovery tooling; Tor bridge distribution to CN-adjacent users should assume some bridges are already discoverable by this kind of probing and should rotate accordingly.
Related findings
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."
A published MESA Lab / IIE-CAS paper ("ExitSniffer", CCIS-2021) and two filed patents describe a tool that actively builds 2-hop Tor circuits through every exit relay to decoy websites and diffs the decoy's observed source IP against the relay's public consensus IP to expose non-public "hidden node" infrastructure behind Tor exits (96% coverage of all exits in about 50 seconds), plus a complementary passive method -- a government-funded ("国家信息安全项目") controlled Tor relay that logs real predecessor-hop IPs -- that found hidden nodes behind 71 of 6,850 tracked routing nodes; the same research program's dataset separately logs 10,412,582 real anonymous-user access records against 1,627,920 distinct clearnet domains visited through Tor.
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.
The VoIP-fusion correlation key linking a SIP signaling record to its RTP media record is not timing/heuristic-based -- it is an exact match between the negotiated media endpoint fields parsed out of the SIP record (from_rtp_ip/from_rtp_port/to_rtp_ip/to_rtp_port, i.e. the SDP-negotiated RTP endpoints carried in the SIP signaling) and the actual observed RTP flow's four-tuple (common_client_ip/port, common_server_ip/port). A separate normalization rule sorts every four-tuple by port then IP (smaller first) before use as a join key, and common_vsys_id is the default grouping/partition key.