net4people
Leak of Geedge Networks internal documents (100,000+ from Jira, Confluence, GitLab)
We have discussed the Chinese company Geedge Networks (积至). Last year, there was the news that Geedge had provided equipment for VPN blocking in Myanmar. One of the founders of the company is 方滨兴 (Fang Binxing), the famous "father of the Great Firewall". Another Geedge principal, 郑超 (Zheng Chao), is a coauthor of censorship-related research papers we have discussed: #275, #282, #444.
Today, there are many news articles and reports about a leak of Geedge Networks internal documents, including from Jira (bug tracker), Confluence (wiki), and GitLab (source code). They say that several news organizations and technologists have worked together for a year to analyze the documents. This is the primary reporting from the people who worked directly with the documents, as best as I have been able to determine:
- The Globe and Mail: Leaked files show a Chinese company is exporting the Great Firewall's censorship technology (archive)
- Der Standard: Wie China seine Totalüberwachung des Internets ins Ausland exportiert (archive)
- Follow the Money: China exports censorship tech to authoritarian regimes – aided by EU firms (archive)
- InterSecLab: The Internet Coup (archive) PDF 76 pages (archive)
- Amnesty International: Shadows of Control: Censorship and mass surveillance in Pakistan (archive) PDF 102 pages (archive)
- Justice for Myanmar: Silk Road of Surveillance (archive) PDF 47 pages (archive)
As far as I can tell, the actual contents of the leak have not been made public. Even so, there is a lot of information across these public articles and reports. They include, at least, evidence of exports to other contries including Myanmar, Pakistan, Ethiopia, Kazakhstan, and at least one other unidentified country; operation in the Chinese provinces of Xinjiang, Jiangsu and Fujian; technical information about Geedge's products; and collaboration with MESA, a research lab at the Chinese Academy of Sciences.
Here are notes and highlights from the three news articles.
The Globe and Mail: Leaked files show a Chinese company is exporting the Great Firewall's censorship technology
The leak of internal documents shows that Geedge works directly with governments and ISPs to install products for censorship and surveillance. They offer capabilities including tracking users' locations and network access history, and blocking services and circumvention systems.
…a leak of more than 100,000 internal documents linked to Geedge Networks, a little-known Chinese company that has quietly assumed a key role in developing the Great Firewall and providing similar censorship capabilities to governments around the world…
The files offer a key insight not only into how Geedge exports cutting-edge censorship technology to its authoritarian clients, giving them capabilities they might not otherwise have, but also into the evolution of the Great Firewall itself.
This includes solutions for filtering websites and apps, real-time online surveillance, throttling internet data to certain regions or enacting internet blackouts, identifying anonymous users by their online footprint, and blocking tools used to bypass censorship, including virtual private networks (VPNs).
Geedge is involved in at least five other countries: Kazakhstan, Ethiopia, Myanmar (#369), Pakistan, and an unidentified one known only by the codename A24. Kazakhstan was an early customer after being founded in 2018.
After its founding in 2018, one of Geedge's first clients was the government of Kazakhstan, to whom the company sold its flagship Tiangou Secure Gateway (TSG), which provides functions similar to China's own Great Firewall, monitoring and filtering all web traffic that passes through it, as well as attempts to bypass such censorship.
The same tool has been rolled out in Ethiopia and Myanmar, where it has been instrumental in enabling that country's military junta to enforce a ban on VPNs. In many cases, Geedge works with other private companies, including internet service providers (ISPs) such as Safaricom in Ethiopia, or Frontiir and Ooredoo in Myanmar, to enact government censorship, the documents show. No ISPs that have partnered with Geedge responded to a request for comment.
Myanmar is treated specially in the Justice for Myanmar Silk Road of Surveillance report. Pakistan is treated specially in the Amnesty International Shadows of Control report.
About Pakistan, this Globe and Mail article says that Geedge installed their new systems, including the Tiangou Secure Gateway (TSG), on existing equipment left behind by Sandvine. (Sandvine is now called AppLogic.)
Sandvine quit Pakistan in 2023 amid growing scrutiny of its work there, and was quickly replaced by Geedge, which the documents show apparently utilizing existing Sandvine installations as well as providing new technology to power Islamabad's Web Monitoring System, as the country's national firewall is called.
In a statement, AppLogic said it was not aware of Geedge and any hardware repurposed by the company was off-the-shelf equipment "that does not contain any special capability that is unique to Sandvine's solution."
The article cites the same hiring advertisement that was posted in https://github.com/net4people/bbs/issues/369#issuecomment-3254638017 that mentions a further four countries: Malaysia, Bahrain, Algeria, and India:
A recent job ad posted by Geedge also mentioned the BRI [Belt and Road Initiative]. That ad sought candidates "able to speak English or another foreign language," and willing to go on three- to six-month business trips to "Pakistan, Malaysia, Bahrain, Algeria, and India."
Besides foreign contries, the documents show Geedge involvement in the Chinese provinces of Xinjiang, Jiangsu, and Fujian. This could be a sign of a more distributed, regional, firewall system, as has been discussed in relation to Henan in threads such as #416 and "A Wall Behind a Wall".
Geedge is closely aligned with MESA, a research lab at the University of the Chinese Academy of Sciences. We have previously mentioned MESA at https://github.com/net4people/bbs/issues/471#issuecomment-2803829013, in a reading group post about MESA's "SAPP" network analysis platform. Geedge's chief technology officer 郑超 (Zheng Chao) was a co-founder of MESA in January 2012.
Mr. Fang is described proudly in the Geedge documents as "father of the firewall." Other top company personnel, such as chief executive Wang Yuandi and chief technology officer Zheng Chao, are listed as co-authors of papers on internet censorship and creator of patents applied for by Geedge. The company also has a close relationship with the Massive and Effective Stream Analysis Laboratory (MESA Lab) at the Chinese Academy of Sciences, with the documents showing regular collaboration between personnel at both entities.
It was a MESA Lab researcher who took notes at the July, 2024, meeting in Xinjiang, where attendees spoke of using technology to "strike at the use of tools" to bypass the Great Firewall and establish the "Xinjiang Branch Centre" as an "anti-terrorism vanguard" and "demonstration of provincial capabilities."
The company does individualized research on circumvention systems and VPNs in order to block them.
The leaks show employees at the company working to reverse-engineer many popular tools and find means of blocking them. One set of documents lists nine commercial VPNs as "resolved," and provides various means of identifying and filtering traffic to them. Similar capabilities have long been demonstrated by the Great Firewall, with most commercial VPNs inaccessible from within China and many dedicated anti-censorship tools also hard to access.
Der Standard: Wie China seine Totalüberwachung des Internets ins Ausland exportiert
Machine translation into English: How China is exporting its total surveillance of the internet abroad
A Chinese company is supplying the technology behind this to authoritarian countries. The consequences for opposition figures and journalists could be dramatic.
Sophia Baumann 9. September 2025, 05:00
His name stands for a monstrous system: Fang Binxing, professor, party member, architect of digital control. Anyone who wants to know what he does and what he stands for has to read between the lines – or search outside the Chinese firewall. Because Fang is one of the fathers of the system that selects, controls, and makes information disappear in China: the so-called "Great Firewall."
In 2011, during a lecture in Wuhan, an unknown person allegedly threw an egg and a shoe at Fang Binxing. It was a symbolic protest against a man who had turned the Chinese internet into a bulwark against freedom. Fang's office denied the incident at the time.
Total surveillance as an export hit
In 2018, Fang founded Geedge Networks, a company through which he intended to turn his invention, the Chinese firewall, into an export hit. Exclusive research now shows that Geedge Networks supplied censorship and surveillance technology to several, mostly autocratic states and may still be doing so. Its problematic customers included Myanmar, Pakistan, Kazakhstan, Ethiopia, and regional Chinese authorities.
DER STANDARD researched this for several months in collaboration with the Dutch platform Follow the Money and the Canadian newspaper The Globe and Mail, as well as with the help of the NGO Amnesty International, the activist group "Justice for Myanmar", which focuses primarily on the junta in Myanmar, the Tor Project, and Intersec Lab, which also provided technical support to the group.
The technologies offered by Geedge Networks are extremely powerful, as shown by an analysis by the IT security experts at Intersec Lab. They enable authorities to monitor the data traffic of individuals in certain regions, for example during protests. They can specifically detect and block individual virtual private networks (VPNs), which users have previously used to circumvent digital censorship by authorities. And they can even insert malicious code into websites or launch DDoS attacks, thereby crippling individual sites.
"Serious humanitarian consequences"
Ironically, the countries to which Geedge Networks supplied these tools have long been the subject of massive criticism. The American non-governmental organization Freedom House classifies China, Myanmar, Ethiopia, Pakistan, and Kazakhstan as "not free" in terms of internet freedom.
What this means in concrete terms can be seen in Ethiopia, for example. There, the government shut down the internet in the Tigray region for a good two years starting in 2020 – in the midst of an armed conflict involving serious human rights violations. This hampered the coordination of food deliveries and medical aid. Kian Vesteinsson of Freedom House says the blockade had "serious humanitarian consequences."
Myanmar also tightened its digital grip significantly after the military coup in 2021. Only websites pre-approved by the military are still accessible. In the meantime, cell phones were checked at roadblocks in search of installed VPN apps. Now, technology is doing what soldiers used to do.
Research suggests that Geedge Networks' censorship and surveillance technologies are now also being used in the countries mentioned.
Neither Ethiopia, Kazakhstan, Pakistan, nor China responded to requests for comment from STANDARD. The authorities in Myanmar could not be reached for comment. Geedge Networks and Fang Binxing also left all inquiries unanswered.
Surveillance technology from the West
At the same time, Geedge Networks is not the first company to supply such technologies to autocrats and censorship-happy authorities. Western companies have also been active in this market and have been criticized for years.
In 2015, for example, the NGO Privacy International revealed that Pakistan was using surveillance technologies from German companies. Even then, the country's massive surveillance frenzy was well known. According to media reports, one of the German companies, Utimaco, was also active in Myanmar. When asked, Utimaco stated that the company had always complied with all laws and regulations. Furthermore, it had never done business directly with any of the mobile network operators in Myanmar.
Later, the Canadian company Sandvine is said to have supplied Pakistan with a system that enables the authorities to block unwanted websites. In 2023, Sandvine, now renamed Applogic Networks, withdrew from the country. But it apparently left at least some of the Sandvine hardware in Pakistan.
Research suggests that this was then reused by Geedge Networks, at least initially. Applogic Networks told the STANDARD that it had no knowledge of this. Furthermore, the company emphasized that its technology cannot be used to decrypt user data or deploy spyware.
European traces
A French company also became an unwitting accomplice of Geedge Networks. The French Thales Group sells software that can be used to manage licenses. Geedge Networks apparently used this to maintain control over the products it sold. This allowed it to limit the functionality of the software for a limited period of time.
Upon request, the Thales Group confirmed to the STANDARD that the Chinese company is one of its customers. However, Geedge Networks' software does not rely on the French product to function. The company claims to have nothing to do with surveillance.
In addition, Geedge Networks apparently used a German server to distribute its software to customers via download links. The motives for this remain unclear. However, it is known that the Chinese firewall is making it increasingly difficult to access Chinese websites from abroad. The responsible ministry in Germany did not respond to inquiries from the STANDARD on the subject.
The model of digital authoritarianism
Unlike Western providers, a company like Geedge Networks is unlikely to be subject to ethical standards. On the contrary, the dissemination of its own technologies seems to be an overriding political goal here.
China wants to "export its model of digital authoritarianism," says Kian Vesteinsson of Freedom House. This is particularly true for autocratic neighbors such as Myanmar.
But while censorship has long been the norm for China's population, resistance is stirring in Myanmar. The organization "Justice for Myanmar," which was also involved in this investigation, warned last year against cooperating with Geedge Networks. In Pakistan, Usama Khilji of the organization Bolo Bhi sounded the alarm. "Pakistan is a democracy, we have fundamental rights – we cannot be treated the way the Chinese government treats its citizens," he said even before the research was made public.
A new position at Geedge Networks is currently advertised on a Chinese online job board. One of the criteria for applicants is a willingness to travel on business – to Pakistan, but also to Malaysia, India, Bahrain, and Algeria. So business seems to be booming for Geedge Networks, and Algeria, Malaysia, India, and Bahrain may also already be using its services or showing interest. The relevant authorities in the respective countries did not respond to questions from the STANDARD.
The spirit of the "Great Firewall" has long since taken hold. It creeps through networks, blocks data, and filters information. And sometimes it even affects its creators themselves: When Fang Binxing wanted to show a South Korean website during a lecture in 2016, he was blocked – by his own firewall. (Sophia Baumann, September 9, 2025)
This article lists additional capabilities of Geedge's technology, beyond tracking users and blocking access: injection of malware into HTTP sessions, and directly launching DDoS traffic volume attacks.
Die Technologien, die Geedge Networks anbietet, sind überaus mächtig, zeigt eine Analyse der IT-Sicherheitsexperten von Intersec Lab. Sie ermöglichen Behörden, den Datenverkehr von Einzelpersonen in bestimmten Regionen zu überwachen, beispielsweise während Protesten. Sie können gezielt einzelne Virtual Private Networks (VPNs) erkennen und blockieren, mit deren Hilfe Nutzer bislang die digitale Zensur von Behörden umgehen konnten. Und sie können sogar bösartigen Code in Websites einfügen oder DDoS-Angriffe starten und damit einzelne Seiten lahmlegen.
The technologies offered by Geedge Networks are extremely powerful, as shown by an analysis by the IT security experts at Intersec Lab. They enable authorities to monitor the data traffic of individuals in certain regions, for example during protests. They can specifically detect and block individual virtual private networks (VPNs), which users have previously used to circumvent digital censorship by authorities. And they can even insert malicious code into websites or launch DDoS attacks, thereby crippling individual sites.
It has the same information about Geedge software being deployed on repurposed Sandvine hardware in Pakistan. Evidently, Geedge places a priority on decoupling software from hardware.
Später soll die kanadische Firma Sandvine Pakistan ein System geliefert haben, das den Behörden das Blockieren von unerwünschten Internetseiten ermöglichen kann. 2023 zog sich Sandvine, inzwischen umbenannt in Applogic Networks, zwar aus dem Land zurück. Aber offenbar hinterließ es zumindest Teile der Sandvine-Hardware in Pakistan.
Die Recherchen legen nahe, dass diese nun von Geedge Networks zumindest zu Beginn wiederverwendet wurden. Applogic Networks teilte dem STANDARD mit, davon keine Kenntnis gehabt zu haben. Darüber hinaus betonte das Unternehmen, dass man mit seiner Technologie keine Benutzerdaten entschlüsseln oder Spyware einsetzen könne.
Later, the Canadian company Sandvine is said to have supplied Pakistan with a system that enables the authorities to block unwanted websites. In 2023, Sandvine, now renamed Applogic Networks, withdrew from the country. But it apparently left at least some of the Sandvine hardware in Pakistan.
Research suggests that this was then reused by Geedge Networks, at least initially. Applogic Networks told the STANDARD that it had no knowledge of this. Furthermore, the company emphasized that its technology cannot be used to decrypt user data or deploy spyware.
A French company, Thales Group, provides license enforcement to Geedge. Geedge used at least one server in Germany for the purpose of software downloads. (Perhaps to avoid interference by the GFW, if the download server had been hosted in China.)
Auch ein französisches Unternehmen wurde – wohl unfreiwillig – zum Helfer von Geedge Networks. Die französische Thales Group vertreibt eine Software, mit der man Lizenzen managen kann. Geedge Networks nutzte diese offenbar, um Kontrolle über die von ihr verkauften Produkte zu behalten. Sie könnte damit etwa die Funktionsfähigkeit der Software zeitlich beschränken.
Auf Anfrage bestätigte die Thales Group dem STANDARD, dass das chinesische Unternehmen zu ihren Kunden gehört. Die Software von Geedge Networks sei jedoch nicht auf das französische Produkt angewiesen, um zu funktionieren. Mit der Überwachung habe man nichts zu tun.
Darüber hinaus nutzte Geedge Networks offenbar einen deutschen Server, um seine Software über Downloadlinks an die Kunden zu verteilen. Die Motive dafür bleiben unklar. Bekannt ist aber, dass die chinesische Firewall den Zugriff auf chinesische Websites aus dem Ausland zunehmend erschwert. Das zuständige Ministerium in Deutschland ließ Anfragen des STANDARD zu dem Thema unbeantwortet.
A French company also became an unwitting accomplice of Geedge Networks. The French Thales Group sells software that can be used to manage licenses. Geedge Networks apparently used this to maintain control over the products it sold. This allowed it to limit the functionality of the software for a limited period of time.
Upon request, the Thales Group confirmed to the STANDARD that the Chinese company is one of its customers. However, Geedge Networks' software does not rely on the French product to function. The company claims to have nothing to do with surveillance.
In addition, Geedge Networks apparently used a German server to distribute its software to customers via download links. The motives for this remain unclear. However, it is known that the Chinese firewall is making it increasingly difficult to access Chinese websites from abroad. The responsible ministry in Germany did not respond to inquiries from the STANDARD on the subject.
Follow the Money: China exports censorship tech to authoritarian regimes – aided by EU firms
This article gives an outline of various Geedge products, which may be sold to customers in a bundle or selectively. Cyber Narrator is a kind of high-level dashboard that nontechnical users can interact with directly. Tiangou Secure Gateway (TSG) is the actual network surveillance and blocking device. TSG Galaxy is a data storage and analysis pipeline. Network Zodiac is a manager and monitor for the other systems.
Geedge Networks' portfolio includes several different technologies, InterSecLab's data analysis shows. "Cyber Narrator" is the main interface that clients interact with. It allows even non-technically-skilled individuals to monitor groups of internet users in specific areas, for example, during demonstrations.
Then, there is the "Tiangou Secure Gateway" – believed to be the flagship product. This tool can block VPNs, but also insert malicious code into websites or launch attacks on websites.
Another product is the "TSG Galaxy", where data collected on users is stored, while "Network Zodiac" monitors all other systems and reports any errors.
There may be may more installations of Geedge equipment such as TSG than even the countries mentioned in this leak, because Geedge's public marketing web site says "40+ global service providers":
In a 2024 speech covered by a Chinese media, Binxing announced that the company aims to expand into "international markets" and promote Chinese technologies globally. It seems he did just that as the documents show that Myanmar, as well as Pakistan, Ethiopia and Kazakhstan, held licenses for at least the flagship product, the Tiangou Secure Gateway. Furthermore, Geedge Networks' website boasts it serves "40+ global service providers", suggests a much further reach than the leaked documents suggest.
A Geedge support ticket from February 2023 has to do with blocking social media in Ethiopia. This correlates with known blocking (#210) in Ethiopia at the time.
Then, in February 2023, amidst a wave of national protests, a support ticket from Geedge Networks shows their experts were called in to fix a problem with regard to social media platforms like YouTube and Twitter. During the same time frame, the blocking of access to social media platforms was reported.
At least one Jira support ticket shows evidence of plaintext capture of email:
The internal documents show that Geedge Networks' tools, including the Tiangou Secure Gateway, were being used in [Pakistan]– and, in at least one case, e-mail traffic between a global shipping company and a Pakistani company has been intercepted.
The InterSecLab report (PDF 76 pages) is really good, with lots of specific technical detail. It explains more about Geedge's suite of products, its alignment with the MESA research lab, and the timeline of deployment in various countries.
Based on analysis of a leak of more than 100,000 Geedge Networks documents that was shared with InterSecLab, this research sheds light on the features and capabilities of Geedge Networks' systems, which include deep packet inspection, real-time monitoring of mobile subscribers, granular control over internet traffic, as well as censorship rules that can be tailored to each region. The leak also reveals information about Geedge Networks' relationship with the academic entity, Mesalab, as well as their interactions with client governments. The implications for data sovereignty are significant, and our findings raise concerns about the commoditization of surveillance and information control technologies.
This research examines the recent development of Geedge Networks' systems in various countries, including what is known about their deployment timelines. By analyzing the company's internal documentation, InterSecLab was able to chronicle the expansion of commercially available national firewalls and speculate about the implications for the future of the global internet considering the spread of such systems.
Geedge products
- Tiangou Secure Gateway
Tiangou Secure Gateway (TSG) is the name of the multi-purpose firewall and surveillance unit. TSG contains all the main DPI, filtering, tracking, throttling, and attack functions. Data extracted by TSG goes into TSG Galaxy for storage and analysis.
TSG's capabilities are extensive with surveillance and censorship capabilities through Deep Packet Inspection, the ability to identify and block VPNs and circumvention tools, throttle traffic, monitor, track, label and block individual internet users, and infect users with malware.
TSG may be installed on an integrated hardware platform called TSGX, or it may work with a customer's existing hardware. (The report says that in Pakistan, Geedge's TSG was installed on equipment that was left behind by Sandvine.) TSG runs an operating system called TSG-OS, which is based on Red Hat Enterprise Linux and Docker (cf. "A Flexible and Efficient Container-based NFV Platform for Middlebox Networking" by 郑超 (Zheng Chao) et al.)
As many TSG nodes can be installed as are needed, with a packet broker called Ether Fabric load-balancing traffic over all the nodes by 5-tuple hash. There is a system for managing a TSG cluster called Central Management or 毕方 (Bifang).
TSG relies on a userspace networking system called MARSIO. That is, it does its own routing and packet handling, bypassing the Linux kernel for efficiency. It uses DPDK. (Again cf. "A Flexible and Efficient Container-based NFV Platform for Middlebox Networking" from 2018.)
- TSG Galaxy
TSG Galaxy is a data storage and aggregation system (Extract, Transform, Load data warehouse) that holds such information as metadata about TCP and UDP sessions and protocols including TLS, SIP, DNS, and QUIC. Information in Galaxy can be queried by Cyber Narrator.
TSG Galaxy is Geedge Networks' ETL (Extract, Transform, Load) data warehouse solution designed for internet-scale mass surveillance, collecting and aggregating a significant amount of data about all internet users and data sent over the internet in a client country. It is built on the open source Apache Kafka stream-processing platform5, a common data processing software often used to provide customer analytics for online retailers and advertisers. The leaked data analyzed for this research included an SQL schema6 for TSG Galaxy that indicated that TSG Galaxy is utilized to store records of all TCP and UDP sessions, transport protocols that are largely used for broadband and mobile data, as well as all SIP sessions within the country. SIP is a protocol used for VoIP (Voice Over Internet Protocol), the basis for most modern telephone networks. This means that TSG Galaxy allows for not only the monitoring of network traffic and content over the internet, but also phone calls.
TSG Galaxy employs Internet Protocol Flow Information Export (IPFIX) to analyze traffic flows and deep packet inspection (DPI) to extract the metadata. Using DPI, they can extract detailed fingerprints, including TLS and QUIC server name indications, DNS queries and email headers. TSG Galaxy also implements connection fingerprinting techniques, such as JA3 hashes, allowing for Cyber Narrator to identify patterns to help determine what operating system a user is on and what applications they are using to connect. This technique can be used to help identify if a user is using a circumvention tool such as a VPN to obscure traffic or bypass censorship. Within TSG Galaxy, all of this information is combined with information from the internet service provider to link it to an individual internet user through various identifiers- including their IP address, their subscriber ID, IMEI, and IMSI7. Metadata extracted from TSG Galaxy is sent to a database able to be queried by a client through Cyber Narrator.
- Cyber Narrator
Cyber Narrator is a user interface, designed for nontechnical users, that allows for querying and displaying information collected by TSG and stored in TSG Galaxy. Blocking of services and protocols can be controlled in Cyber Narrator, and it offers the function of finding identifiers of users who have accessed specific content. Cyber Narrator uses a remote WebSketch service that annotates identifiers such as IP addresses with metadata from third-party data brokers or Geedge's own research.
Cyber Narrator is a powerful tool capable of tracking network traffic at the individual customer level and can identify the geographic location of mobile subscribers in real time by linking their activity to specific cell identifiers (cell IDs). The system also allows the government client to see aggregated network traffic.
…Cyber Narrator can make it easier for client governments and security forces to flag individual subscribers for using circumvention tools or accessing other applications or webpages that the client government considers as potentially malicious. The analytical capabilities of Cyber Narrator also enable the obstruction of access to specific websites or Virtual Private Network (VPN) services. Through Cyber Narrator, the client government can also identify individuals who accessed the content or service prior to its restriction.
- Network Zodiac
Network Zodiac or 哪吒 (Nezha) is a system for monitoring the other components, similar to Grafana. Apparently, the Network Zodiac dashboard has the capability to SSH into any other host (such as a TSG node), which is obviously a huge concentration of risk if a Network Zodiac host were to be compromised.
A notable feature that differentiates Network Zodiac from popular open-source solutions is its integrated web terminal, which enables network administrators to remotely connect to any monitored endpoint using SSH. This functionality provides the client with direct access to network devices for troubleshooting and management purposes. However, it opens up the client to significant security risk. In a worst case scenario, a hacker could have access to all of the client's security equipment deployed within a country.
TSG capabilities
TSG has the typical multi-protocol deep packet inspection and blocking capabilities, but also surprising throttling, injection, tracking, and offensive features.
Mirrored mode and in-line mode
TSG and Ether Fabric may be installed in either an on-path ("mirrored" or "passive") mode, or an in-path (flow-blocking or "active") mode.
The Geedge system can be deployed in two primary modes, mirrored and in-line, to help to control the internet. In mirrored mode, sometimes referred to as "passive" in the documents, the data is mirrored to the Geedge appliance using a network tap. Specifically, the network tap is an optical bypass switch. The packets do not have to wait to be processed before continuing to their destination. In this mode, if there was a failure of the Geedge system, the internet would continue to function. This mode can be advantageous as it does not add network latency due to processing delays or congestion. In mirrored mode, clients are unable to stop specific traffic from passing through and have to rely on packet injection to block connections.
In in-line mode, also referred to as "active" mode in the documents, the traffic must pass through the Geedge appliance before continuing to its destination. … The advantage of this mode is that one can fully stop specific traffic flows from ever making it through the network. This is often the solution chosen by customers who want absolute control, at the cost of reliability and network quality.
Compare this to a statement from an official in Pakistan in 2024:
But to monitor local traffic, the new firewall will use what is known as an "in-line network", which acts like a security checkpoint, where each data packet must be inspected and either allowed to pass or be blocked – as opposed to an alternative mechanism that simply observed and records traffic without interfering with its flow.
The use of an in-line network "will inevitably slow down internet speeds", the ISP official said.
Deep packet inspection
The report mentions the protocols HTTP, DNS, email, TLS, QUIC, and SIP.
Server name indication (SNI) can be extracted from TLS and QUIC. (For censorship based on QUIC SNI in China, see "Exposing and Circumventing SNI-based QUIC Censorship of the Great Firewall of China".)
Using DPI, they can extract detailed fingerprints, including TLS and QUIC server name indications, DNS queries and email headers.
TLS traffic can be decrypted if a MITM certificate is installed at the client; otherwise TSG has to rely on encrypted traffic classification heuristics:
TSG is capable of analyzing Transport involves Layer Security (TLS) traffic through two primary methods. The first method involves full decryption using the Man-in-the-Middle (MITM) technique, which requires the installation of a self-signed root Certificate Authority (CA) certificate by the subscriber. The second method employs deep packet inspection (DPI) and machine learning techniques to extract metadata from encrypted traffic. The latter approach is more commonly used, as it's invisible to the internet user, thereby eliminating the need for the internet user to install a CA certificate or configure any proxy settings. … The component responsible for implementing the TLS MITM attacks is referred to as the Tiangou Frontend Engine (TFE).
Traffic throttling
TSG incorporates traffic shaping capabilities that facilitate the prioritization or throttling of traffic from specific services, which can degrade the quality of service rather than blocking it outright. This is accomplished either through direct traffic shaping or by applying Differentiated Services Code Point (DSCP) marking, the industry standard for limiting or prioritizing traffic.
Injection and modification
TSG is capable of injecting traffic and modifying traffic. It can do this for the purpose of blocking, or even to infect users with malware or cause them to DDoS a target, Great Cannon style.
TSG is also capable of modifying HTTP sessions in realtime through techniques such as spoofing redirect responses, altering headers, injecting scripts, replacing text, and overriding response bodies.
TSG is equipped with an in-path injection capability that allows for the insertion of malicious code into files transmitted through the network. Geedge Networks is very explicit that this feature is intended for inserting malware into internet traffic as it passes through the TSG system.
TSG's in-path injection capability system allows for sophisticated targeting of this malicious code for the specific user, facilitating on-the-fly modifications across a variety of file formats, including HTML, CSS, and JavaScript, in addition to Android APK files, Windows EXE files, macOS DMG disk images and Linux RPM packages. Furthermore, TSG can alter several image formats such as JPG, GIF, PNG and SVG, and various archive formats such as ZIP and RAR, along with office documents, PDF, JSON, and XML files. This is also complemented by Cyber Narrator, which possesses analytical functionalities that can identify the most appropriate URLs to hijack in order to infect specific individuals. For instance, it can target a person's frequently visited websites that do not utilize Transport Layer Security (TLS).
One of the most bewildering offerings from Geedge Networks identified in the leaked dataset is DLL Active Defence, a product you might usually find in cybercrime black markets. At first glance, it appears to be a system designed to protect against Distributed Denial of Service (DDoS) attacks; however, a closer examination reveals that it is actually a platform for launching DDoS attacks against websites and other internet services deemed politically undesirable. This would appear to be Geedge's own implementation of China's Great Cannon, as described in a 2015 Citizen Lab report.13
DLL accomplishes this by utilizing internet scanning to identify traffic amplification points, such as recursive DNS servers, which can serve as launch pads for reflective denial of service attacks. It uses the in-path injection capability in TSG to effectively recruit unsuspecting users' computers to participate in the attack, thereby creating a botnet. This marks the first confirmed instance of a cybersecurity company offering what is essentially a "booter" DDoS-for-hire solution to its clients.
Attribution of network flows to real identities
Sanity Directory (SAN) or User Reputation Traffic Management System is a subscriber awareness system designed to integrate TSG seamlessly with Internet Service Providers' (ISPs) existing signaling and authentication, authorization, and accounting (AAA) protocols including RADIUS, 3GPP, and CGNAT. This integration facilitates the attribution of traffic flows to real identities.
A core feature of Geedge's Sanity Directory component is attributing traffic to a specific SIM card. This enables, not only mass surveillance, but highly targeted micro-surveillance on specific individuals in Pakistan and other countries Geedge operates.
Identifying and blocking circumvention tools
Geedge has paid VPN accounts and operates a network of mobile devices with VPN apps installed, in order to study their network behavior:
TSG also employs deep packet inspection to comprehensively identify protocols associated with Virtual Private Networks (VPNs) and circumvention tools, such as OpenVPN and WireGuard. It then allows clients to work with Geedge Networks to develop rulesets to block access to specific service providers, with Geedge managing a mobile device farm to install and operate VPN applications within a controlled environment.
To create the blocking rules, Geedge Networks uses reverse engineering, employing both static and dynamic analysis. Static analysis involves decompiling the app's source code to find APIs that return the list of servers, which can then be blocked. Dynamic analysis involves running the VPN app and analyzing its network traffic to identify patterns for blocking.
Evidence from the leak suggests that Geedge Networks maintains paid accounts with popular VPN providers for the purpose of analyzing and blocking their apps. TSG hardware can also identify popular VPN protocols like IPSec, OpenVPN and WireGuard.
There is a database of application network fingerprints called AppSketch, with fingerprints for lots of specific applications, such as individual VPN services. See the screenshot above.
Footnote 10, on the gathering of AppSketch fingerprints, mentions the technologies SAPP (#471) and Maat (#444), which we have discussed before.
To extract these [AppSketch] fingerprints, Geedge and the Mesalab students use a modified version of the open-source tool tcpdump, which they call tcpdump_mesa. The fingerprint is subsequently transformed into a ruleset utilizing one of four systems for deep packet inspection: SAPP (Stream Analyze Process Platform), a C packet parsing and injection library; Stellar, a stateful firewall plugin platform that operates on a higher level of abstraction compared to SAPP; or Maat, a declarative system. Unlike SAPP and Stellar, Maat does not require programming knowledge for the development of new rules. Maat is capable of matching common connection fingerprints, including IP addresses, domain names, TLS Server Name Indications (SNI), JA3/JA4 fingerprints, specified in a JSON file. Maat rules are synchronized across nodes within a TSG cluster through the use of a Redis database, thereby ensuring consistency in the application of these rules.
An interesting and surprising capability is discovering new VPN endpoints by watching the behavior of past known VPN users. (Reminiscent of "Identifying VPN Servers through Graph-Represented Behaviors", whose authors are affiliated with MESA.)
Additionally, Geedge Networks products are able to identify specific individuals as known VPN users. Once those known circumvention tool users move to a new provider that is not yet blocked, Geedge Networks can watch the users' traffic and use the trail they leave to identify the new VPNs to block in the future.
Furthermore, the system can identify individual subscribers as known VPN users and then later track their Internet usage and categorize any future unknown highbandwidth traffic flows as suspicious. This individualized classification can lead to the identification and blocking of previously unidentified services when an internet user switches to a new VPN provider, potentially exposing this new VPN and implicating not only the identified internet user but also all other users of this service.
Unidentifiable high-bandwidth flows may also inform blocking:
Even when TSG is unable to identify the specific application or service associated with a user's activity, identification, it can the flag any unusual large traffic flows as suspicious. Following this identification, the system can be configured to block the flagged traffic after a predetermined period, for example 24 hours. This approach corresponds to observations of the GFW, which has been observed similarly blocking any high-bandwidth encrypted traffic flow after a certain duration, even if it cannot identify the specific nature of the traffic9.
The report (p.63) talks about Tor bridges, Snowflake, and WebTunnel. The report suggests that Geedge has a way of enumerating Tor bridges, though whether it is in-house or outsourced is uncertain. An advertising screenshot of Cyber Narrator contains the string "Snowflake". The leak contains research by MESA students about WebTunnel, though they had not discovered a blocking technique at that time.
Geedge has a specialized tool for enumerating Psiphon endpoints called Psiphon3-SLOK. It correlates with observed changes in Psiphon connections in Myanmar in May 2024, when Geedge entered the country.
According to the leaked data, Geedge Networks appears to have attempted to circumvent this protective measure by developing an internal tool referred to as Psiphon3-SLOK.
In conversations with the Psiphon team, we learned that in late May of 2024 there was a sharp rise in users from Myanmar and a shift in how clients selected servers, consistent with server enumeration and targeted blocking. This period coincides with the deployment of the Geedge system in Myanmar.
Remote access to customer networks
Customer data stored in TSG Galaxy is accessible to students and researchers at MESA(!) and may be used for research.
A significant finding of this research is that all of this internet user data that is collected within TSG Galaxy at government client locations appears to be accessible to Geedge Networks employees. The data also suggests that snapshots of real customer data are sometimes shared with Mesalab, the academic laboratory at the Chinese Academy of Sciences that seems to be closely associated with Geedge Networks. The data suggests that engineering students at Mesalab have used real world customer information for research aimed at better understanding and obstructing internet censorship circumvention.
Additionally, employees of Geedge Networks appear to possess the capability to create a Wi-Fi network within their office that connects any device to a customer network remotely. This functionality allows them to verify that the blocking mechanisms are operating effectively in real-world scenarios.
Deployment to countries outside China
The report has detailed summaries of Geedge deployments in Kazakhstan, Ethiopia, Pakistan, and Myanmar. Even more detailed information about Pakistan and Myanmar are available in the Shadows of Control and Silk Road of Surveillance, respectively.
Deploying Geedge equipment involves Geedge staff traveling physically to the ISP where it is to be installed, and working directly with ISP personnel. (Incidentally, this fact exposes ISPs like Frontiir in Myanmar, who lied when asked about Geedge p.53.)
When setting up in a new country or province, Geedge staff will travel to the client location to install hardware on premises owned by the governments and the local ISPs. Local ISPs are integral to the set-up of a Geedge system. ISPs need to give Geedge staff access to their premises during the installation and to contribute a network plan for how the Geedge hardware can integrate into the ISP's existing systems. The Geedge hardware that collects and stores the bulk data is housed inside each individual ISP's data centers.
In the leak, countries are identified by codenames. All codenames but one (A24) are identified with a specific country. In most cases, the codename is the first letter of the name of the country, plus a two-digit year (which, apparently, does not always match the year of first deployment).
Kazakhstan (codename K18, K24)
Geedge was founded in 2018. The leak indicates that the government of Kazakhstan was its first customer, starting in 2019. The report relates the Geedge deployment to the government's aspirations for country-wide TLS MITM, such as we have seen in #6, #56, and #339.
Geedge's product Tiangou Secure Gateway (TSG) is capable of implementing an attack similar to the government-issued root certificate,26 which might have been a selling point for Geedge's initial approach to the Kazakhstan government.
An image dated October 16, 2020, lists IP addresses for a national center and 17 other cities running three separate Geedge products: Bifang (central management), Galaxy (the original name for TSG-Galaxy), and Nezha (an older name for Network Zodiac).27 An incomplete network planning document from Geedge begins to record events related to a Kazakh national center in September 2020. The log collects events until October 2022 and includes a table listing revisions to the project, including the date, version number, changes made, and the author responsible for each update.
Ethiopia (codename E21)
Geedge started working in Ethiopia in 2021.
This section mentions 郑超 (Zheng Chao) by name:
A December 2022 log entry notes that Geedge CTO Zheng Chao signed off on work at two Safaricom regional data centers in Addis Ababa.
We've mentioned that TSG can operate in either mirrored mode or in-line mode. The report makes the claim that switching the system from mirrored mode to in-line can precede a shutdown, and makes a connection to the February 2023 social media blocking.
Geedge's revision logs indicate that there is a correlation between switching from mirrored to in-line modes and governments preparing for internet shutdowns.42 For example, transitioning from mirrored to in-line configurations may indicate an internet shutdown is imminent as, broadly speaking, mirrored mode is more optimized for surveillance, and in-line mode is more suitable for internet shutdowns. In total, the logs show 18 changes to inline mode in Ethiopia, with two switches made at Safaricom data centers before the February 2023 internet shutdown.
Pakistan (codename P19)
Geedge started in Pakistan in 2023, the same year Sandvine exited the country. In the Shadows of Control report, Amnesty International calls the Geedge-operated firewall "WMS 2.0" (web management/monitoring system 2.0), to distinguish it from the earlier version of WMS that it replaced.
Geedge's presence in Pakistan matches what has been previously reported about Chinese involvement in the national firewall. Quotes from a Pakistan official match known capabilities of Geedge's TSG:
The language used by a senior Pakistan ISP executive in an interview with Al Jazeera, mirrors Geedge marketing materials closely.51 The unnamed executive said the new WMS was being deployed not only at the country's internet gateways but at local data centers of mobile service providers and ISPs.52 Because the previous system was only able to surveil content entering and exiting the country, Pakistan was not able to censor content hosted by local caching content delivery networks (CDNs) like those run by Netflix and Meta. Comparing WMS 1.0 and WMS 2.0, the executive said: "Unlike the Sandvine system, the new DPI-based system is now capable of monitoring local internet traffic," using an "in-line network" which also had a higher likelihood of slowing down internet speeds for users. The executive also noted that the Chinese (Geedge) technology provides the capability to manage applications and websites at a "granular level", providing better features than Sandvine.
Geedge's Sanity Directory has the ability to attribute network activity to a specific SIM card. In Pakistan, SIM cards are in turn linked to real-life identities:
…since 2015 every new SIM card issued to a mobile subscriber in the country must be registered to a particular user and linked to biometrics including fingerprints that are registered via the National Database and Registration Authority (NADRA). People need a NADRA profile to access basic services like healthcare, banking, and education. The NADRA profile also links to other databases, like voter registration and tax records, which combined create a comprehensive record on every citizen.[57](https://www.amnesty.org/en/documents/asa33/020 6/2025/en/) A core feature of Geedge's Sanity Directory component is attributing traffic to a specific SIM card.
Myanmar (codename M22)
Myanmar is significant because it was the first time the work of Geedge in a foreign country became publicly known, when Justice for Myanmar reported on it.
Besides the previously reported Frontiir, the leak notes data centers of every ISP in Myanmar. Frontiir had previously falsely denied doing any surveillance projects, when asked.
The planning document notes data centers for every ISP, state-owned or private, present in the country. The "big four" ISPs, MyTel, Ooredoo, MPT and ATOM, are listed as well as entries for smaller providers like Frontiir, Global Technology Group, Golden TMH Telecom, Stream Net, IM-Net, Myanmar Broadband Telecom, Myanmar Telecommunications Network Public Company Limited, Campana and China Unicom.
Documents also contains reports for link tests for all the ISPs. These reports provide information on website connectivity tests conducted in different dates throughout 2024. The objective of the tests seems to be to evaluate the effectiveness of the censorship on each ISP's network.
A Frontiir spokesperson denied that it had ever "built, planned, or designed anything related to surveillance" on its network. The leaked documents, however, indicate that Geedge hardware is installed inside the buildings of all the ISPs in Myanmar including Frontiir.
There's information about a list of apps and VPNs that the government of Myanmar wanted to block:
The leaked documents also contain detailed information on blocking VPNs, Tor (especially the Tor-powered mobile app Orbot), and Psiphon. Myanmar's wish-list of VPNs to block is longer than the lists of VPNs to block supplied by some of the other client states, like Ethiopia or Kazakhstan. The documents include a record of the development of rules to block "high-priority apps", which includes 55 apps for blocking, among them the messaging apps Signal and WhatsApp.
Codename A24
One Geedge customer is known only by the codename A24. The business relationship was apparently in an early state at the time of the leak.
While leaked documents include specific locations and/or internet service providers linked to the named client countries in this report, data related to A24 does not include any of these indicators that could identify the client. The only clues about the identity of the A24 client is the first letter A and the year 2024.
Aside from that, information indicates that, at the time of the leak, A24 and Geedge's relationship appeared to be in its early stages. It involved two proof-of-concept deployments of the Geedge equipment, one in mirrored mode and the other in in-line mode, in order to clarify the difference between these modes to the client.
Regional firewalls in China
The report shows Geedge's involvement in regional, province-level firewalls in China, particularly in Xinjiang.
In addition to working with international government clients, this research also provides evidence of the emergence of a provincial firewall model in China that is supplementing the National Great Firewall. Geedge Networks is working with several regional governments in China to build provincial firewalls, with censorship rules that may differ from region to region. InterSecLab has identified regional Chinese provincial firewall projects in Xinjiang, Fujian, and Jiangsu.
Xinjiang (codename J24)
Xinjiang is identified by the codename J24. The leaked document directly say that a regional firewall in Xinjiang is to be a model for national deployment in China.
The leak contains notes from a June 22, 2024 speech at the Xinjiang Branch of the Chinese Academy of Sciences (新疆分中心). The notes on the speech, likely taken by a Geedge employee, record that Geedge's project "aims to transform the regional center into a vanguard force of anti-terrorism, particularly in circumvention suppression."71 The notes mention that "the national (firewall) is evolving from a centralized to a distributed model" and that the Xinjiang regional center aims to "become a model for provincial (firewall) construction, which can be replicated or learned from elsewhere."
In common with most other Geedge deployments, the one in Xinjiang follows a structure with a central command center connected to "operator" data centers.
Compared to the earlier project, J24 is far more extensive and is no longer operated through ISPs as the end-users. Instead, it follows a structure similar to other areas of Geedge's operations with foreign clients, with a "national center" (in Xinjiang Geedge refers to this as a central command center) overseeing distributed regional centers (referred to by Geedge as operator centers). Under J24, these operator centers are located in data facilities belonging to China Telecom, China Mobile, China Broadnet, and China Unicom. Like the so-called national centers, the central command center allows for remote management of the surveillance equipment deployed at the operator sites. According to one document, there were 17 operator centers across these ISPs' facilities.
The requirements for the Xinjiang deployment show intense and invasive surveillance, consistent with what we know about the oppression in the province.
In the document titled CBNR-J24 Requirement Organization, Geedge outlines a list of features to incorporate into Cyber Narrator for their deployment in Xinjiang. Geedge Networks aim to support the summarization and analysis of user internet behavior, lifestyle patterns, and relationships as features in Cyber Narrator. They also want to add the ability to construct relationship graphs based on the people who a target communicates with and to group individuals according to the applications they use or the websites they visit.
The requirements for future development also mention adding the ability to check which users are connected to specific mobile base stations in order to support location triangulation through these stations and detect when a large number of people congregate in a particular area.
Additionally, the project plans to include the ability to create geofences, triggering alerts when specific individuals enter a designated area. There is also a focus on querying historical location data to trace past movements. Geedge aims to be able to flag individuals who frequently change SIM cards, call international numbers, or use censorship circumvention tools and foreign social media applications.
The J24 project also includes features designed to target specific groups. These features would allow for the display of the geographic distribution of a monitored group on a map and the detection of unusual gatherings of group members at specific locations. This enables operators to track and anticipate the formation of large protests and demonstrations.
Fujian, Jiangsu, and other provinces
There is some documentation about Geedge working in the provinces of Fujian and Jiangsu, but less compared to the other regions.
Documents indicate that Geedge Networks began conducting a similar pilot project for a provincial firewall in Fujian in 2022, a province off the coast of Taiwan. However, information about this project is limited compared to other deployments. In the leaked documents, this pilot lacks a code name and is simply referred to as the "Fujian Project" (福建项目).
Several documents also mention a project in Jiangsu, a coastal province in Eastern China. The stated motivation for Geedge's collaboration with the local authority, Jiangsu Provincial Public Security Bureau (JPSB), was combating internet scams. Communications show JPSB was hesitant to allow Geedge to create a big data cluster, preferring Geedge to deploy their tools on existing infrastructure. An initial test environment called Jiangsu Nanjing became operational in February 2023, and the Jiangsu Anti-Scam Project seems to have gone into production mode by March 15, 2024.
As far as I can tell, the actual contents of the leak have not been made public.
Enlace Hacktivista has what looks like the contents.
- https://enlacehacktivista.org/geedge.torrent (BitTorrent)
- https://files.enlacehacktivista.org/geedge/ (direct HTTPS download)
All together, the files are around 600 GB in size. 500 GB of that is in one file, mirror/repo.tar.
7206346 mirror/filelist.txt
497103482880 mirror/repo.tar
14811058515 geedge_docs.tar.zst
2724387262 geedge_jira.tar.zst
35024722703 mesalab_docs.tar.zst
63792097732 mesalab_git.tar.zst
71382 A HAMSON-EN.docx
16982 A Hamson.docx
161765 BRI.docx
14052 CPEC.docx
2068705 CTF-AWD.docx
19288 Schedule.docx
26536 TSG Solution Review Description-20230208.docx
704281 TSG-问题.docx
35040 chat.docx
27242 ty-Schedule.docx
111244 待学习整理-23年MOTC-SWG合同草本V.1-2020230320.docx
52049 打印.docx
418620 替票证明.docx
260551 领导修改版-待看Reponse to Customer's Suggestions-2022110-V001--1647350669.docx
The file mesalab_git.tar.zst is 64 GB and appears to contain Geedge/MESA source code repositories, including Git commit history. None of the reports so far have looked at this source code in depth, so there is still plenty to study and learn.
The files inside mesalab_git.tar.zst are Git bundles. You can clone from a bundle just like you can from an SSH or HTTPS URL. Here's an example:
$ tar -xvf mesalab_git.tar.zst -- ./MESA_Platform/http.bundle
./MESA_Platform/http.bundle
# If your version of tar doesn't support .tar.zst files, you may need to do something like:
# zstd -dc mesalab_git.tar.zst | tar -xvf - -- ./MESA_Platform/http.bundle
$ git bundle list-heads MESA_Platform/http.bundle
fedf3431b3a1e29ee3d27d130e9651b7f73b79aa refs/heads/Fix-TSG-16812
30fc2e796a1ed0eb6f5cd47bd8ccb1dcf40225b1 refs/heads/develop
0ddf0cd934dd0ad9ec742790e6aeb4980bcdb64e refs/heads/master
b0df6e0c2846300ac15673a19fc10ce5fd409153 refs/heads/obsolete-docanalyze-use-zlib
3fb34e8bbfc561cbf8b6e8af1e8835b8974f6ef1 refs/tags/v2.0.0
e8f12eeef500b246ce3fade3cb886e3cd7cbc2b9 refs/tags/v2.0.1
[...]
$ git clone MESA_Platform/http.bundle MESA_Platform/http
Cloning into 'MESA_Platform/http'...
Receiving objects: 100% (531/531), 2.55 MiB | 45.03 MiB/s, done.
Resolving deltas: 100% (290/290), done.
$ cd MESA_Platform/http
MESA_Platform/http$ ls
autorelease.sh
autorevision.sh
bin
ci
cmake
CMakeLists.txt
readme.md
src
test
MESA_Platform/http$ git branch -a
* master
remotes/origin/Fix-TSG-16812
remotes/origin/HEAD -> origin/master
remotes/origin/develop
remotes/origin/master
remotes/origin/obsolete-docanalyze-use-zlib
MESA_Platform/http$ git log
commit 0ddf0cd934dd0ad9ec742790e6aeb4980bcdb64e (HEAD -> master, origin/master, origin/HEAD)
Author: 李佳 <[email protected]>
Date: Wed Mar 20 08:21:06 2024 +0000
Add unit test
commit 0571d0bc63c240d4c0adccaa40869a76cfe6013b (tag: v2.0.20)
Author: 刘学利 <[email protected]>
Date: Thu Mar 7 05:30:32 2024 +0000
OMPUB-1170: Bugfix memory leak
commit b8f494c571d412e748d7cb832ae7e94c41ac8b5b (tag: v2.0.19)
Author: liuxueli <[email protected]>
Date: Wed Mar 6 16:49:07 2024 +0800
OMPUB-1170: Bugfix memory leak
commit 328131dcc4cb95e399fce8947507cf2a92cf1b76 (tag: v2.0.18)
Author: liuxueli <[email protected]>
Date: Wed Jan 24 10:29:15 2024 +0800
Feature: HTTP unzip content is consistent with the packet life cycle
commit e78749d810f9c261cab54ec56fa35e17f18a757a (tag: v2.0.17)
Author: 杨威 <[email protected]>
Date: Tue Sep 19 08:49:03 2023 +0000
Update ci/travis.sh
[...]
Issue numbers like "OMPUB-1170" can be looked up in geedge_jira.tar.zst:
$ tar -O -xf geedge_jira.tar.zst -- ./issues/OMPUB-1170.json | jq .fields.summary
"【WMS-UTR项目】多台tsgx出现tsg_os_container_restart告警"
Here's a listing of the contents of mesalab_git.tar.zst:
File listing of mesalab_git.tar.zst
-rw-r--r-- 0/0 4207469 2015-10-20 20:00 ./AV/digest_detection.bundle
-rw-r--r-- 0/0 328996 2015-10-20 20:00 ./AV/frag_monitor.bundle
-rw-r--r-- 0/0 12651137 2015-10-20 20:00 ./AV/frag_rssb.bundle
-rw-r--r-- 0/0 2685 2015-10-20 20:00 ./Alpha_lib/hello_ci_world.bundle
-rw-r--r-- 0/0 35115933 2015-10-20 20:00 ./BaiyangLi/ConfSummary.bundle
-rw-r--r-- 0/0 76346747 2015-10-20 20:00 ./BaiyangLi/IPLocator.bundle
-rw-r--r-- 0/0 113901 2015-10-20 20:00 ./EnderByEndera/commdetection.bundle
-rw-r--r-- 0/0 3799294 2015-10-20 20:00 ./EnderByEndera/realtime_protection.bundle
-rw-r--r-- 0/0 65667560 2015-10-20 20:00 ./Grityu/model_duplication.bundle
-rw-r--r-- 0/0 327308894 2015-10-20 20:00 ./IPReuse/Deploy_Env.bundle
-rw-r--r-- 0/0 5709341 2015-10-20 20:00 ./IPReuse/IPReuse_docs.bundle
-rw-r--r-- 0/0 311380 2015-10-20 20:00 ./IPReuse/code.bundle
-rw-r--r-- 0/0 257797 2015-10-20 20:00 ./IPReuse/mctrl.bundle
-rw-r--r-- 0/0 73383725 2015-10-20 20:00 ./IPReuse/mgw.bundle
-rw-r--r-- 0/0 72748028 2015-10-20 20:00 ./IPReuse/mrl.bundle
-rw-r--r-- 0/0 137343 2015-10-20 20:00 ./IPReuse/udpecho.bundle
-rw-r--r-- 0/0 154208 2015-10-20 20:00 ./IPReuse/vpn_access.bundle
-rw-r--r-- 0/0 35378805 2015-10-20 20:00 ./IPReuse/vpn_cgi.bundle
-rw-r--r-- 0/0 135686611 2015-10-20 20:00 ./IPReuse/vpn_install.bundle
-rw-r--r-- 0/0 12937 2015-10-20 20:00 ./Jiangshan/miniodemo.bundle
-rw-r--r-- 0/0 143427105 2015-10-20 20:00 ./K18_NTCS_WEB/NTC.bundle
-rw-r--r-- 0/0 140691229 2015-10-20 20:00 ./K18_NTCS_WEB/argus-ntc.bundle
-rw-r--r-- 0/0 87926696 2015-10-20 20:00 ./K18_NTCS_WEB/argus-service.bundle
-rw-r--r-- 0/0 111924888 2015-10-20 20:00 ./K18_NTCS_WEB/nfs.bundle
-rw-r--r-- 0/0 12263 2015-10-20 20:00 ./LiFulian/quic-block.bundle
-rw-r--r-- 0/0 378999132 2015-10-20 20:00 ./MESA_Platform/build-env.bundle
-rw-r--r-- 0/0 2477189 2015-10-20 20:00 ./MESA_Platform/dns.bundle
-rw-r--r-- 0/0 40606892 2015-10-20 20:00 ./MESA_Platform/gquic.bundle
-rw-r--r-- 0/0 2675883 2015-10-20 20:00 ./MESA_Platform/http.bundle
-rw-r--r-- 0/0 70446451 2015-10-20 20:00 ./MESA_Platform/marsio.bundle
-rw-r--r-- 0/0 62987183 2015-10-20 20:00 ./MESA_Platform/quic.bundle
-rw-r--r-- 0/0 87835695 2015-10-20 20:00 ./MESA_Platform/sapp.bundle
-rw-r--r-- 0/0 17847926 2015-10-20 20:00 ./MESA_Platform/ssl.bundle
-rw-r--r-- 0/0 721068 2015-10-20 20:00 ./MESA_framework/MESA_handle_logger.bundle
-rw-r--r-- 0/0 982245 2015-10-20 20:00 ./MESA_framework/mesa_jump_layer.bundle
-rw-r--r-- 0/0 270734598 2015-10-20 20:00 ./Minato/coredns_dnsovertor.bundle
-rw-r--r-- 0/0 29031093 2015-10-20 20:00 ./OreoPang/piratedvideowebsite.bundle
-rw-r--r-- 0/0 102213 2015-10-20 20:00 ./PanGu/DeployEnv.bundle
-rw-r--r-- 0/0 178830465 2015-10-20 20:00 ./PanGu/ObjectScanner.bundle
-rw-r--r-- 0/0 23756034 2015-10-20 20:00 ./PanGu/PanGu_docs.bundle
-rw-r--r-- 0/0 27624 2015-10-20 20:00 ./PanGu/mesa_plug.bundle
-rw-r--r-- 0/0 27947 2015-10-20 20:00 ./PanGu/ntc_app_plug.bundle
-rw-r--r-- 0/0 61017 2015-10-20 20:00 ./PanGu/ntc_http_collect.bundle
-rw-r--r-- 0/0 55818 2015-10-20 20:00 ./PanGu/ntc_ip_comm.bundle
-rw-r--r-- 0/0 35879 2015-10-20 20:00 ./PanGu/ntc_radius_plug.bundle
-rw-r--r-- 0/0 47807 2015-10-20 20:00 ./PanGu/ntc_ssl_collect.bundle
-rw-r--r-- 0/0 2015164 2015-10-20 20:00 ./PanGu/pangu_valve.bundle
-rw-r--r-- 0/0 385476900 2015-10-20 20:00 ./PanGu/t2httpcontentscanner.bundle
-rw-r--r-- 0/0 207877454 2015-10-20 20:00 ./ZhangJianlong/galaxy-auto-deploy-cluster.bundle
-rw-r--r-- 0/0 23449095 2015-10-20 20:00 ./active-defense/houyi-deploy.bundle
-rw-r--r-- 0/0 11577 2015-10-20 20:00 ./appsketch-works/app-test-fork.bundle
-rw-r--r-- 0/0 1040030 2015-10-20 20:00 ./appsketch-works/app-test-log.bundle
-rw-r--r-- 0/0 413372 2015-10-20 20:00 ./appsketch-works/app-test.bundle
-rw-r--r-- 0/0 4356 2015-10-20 20:00 ./appsketch-works/app-tiktok.bundle
-rw-r--r-- 0/0 3001 2015-10-20 20:00 ./appsketch-works/asw-build.bundle
-rw-r--r-- 0/0 1934710 2015-10-20 20:00 ./appsketch-works/asw-controller.bundle
-rw-r--r-- 0/0 11992128 2015-10-20 20:00 ./appsketch-works/asw-gui.bundle
-rw-r--r-- 0/0 44996 2015-10-20 20:00 ./appsketch-works/asw-runner.bundle
-rw-r--r-- 0/0 5656069 2015-10-20 20:00 ./appsketch-works/device-api.bundle
-rw-r--r-- 0/0 9931 2015-10-20 20:00 ./appsketch-works/pcap-comment.bundle
-rw-r--r-- 0/0 13036 2015-10-20 20:00 ./appsketch-works/pcap-decode.bundle
-rw-r--r-- 0/0 3002 2015-10-20 20:00 ./appsketch-works/webshark.bundle
-rw-r--r-- 0/0 9955 2015-10-20 20:00 ./chaoc/demo-fqdn-sampling-statistics.bundle
-rw-r--r-- 0/0 42606 2015-10-20 20:00 ./chaoc/easy-stream-application.bundle
-rw-r--r-- 0/0 2768 2015-10-20 20:00 ./chaoc/flink-networks.bundle
-rw-r--r-- 0/0 2982 2015-10-20 20:00 ./chaoc/ipfix-decoder.bundle
-rw-r--r-- 0/0 6530 2015-10-20 20:00 ./chaoc/test-json-serialization.bundle
-rw-r--r-- 0/0 11467997 2015-10-20 20:00 ./chenguanlin/chenguanlin_thesis.bundle
-rw-r--r-- 0/0 511935 2015-10-20 20:00 ./chenguanlin/gie_server.bundle
-rw-r--r-- 0/0 61454 2015-10-20 20:00 ./chenguanlin/td_evaluation.bundle
-rw-r--r-- 0/0 7449973 2015-10-20 20:00 ./chengyifei/e2tc.bundle
-rw-r--r-- 0/0 975394 2015-10-20 20:00 ./chengyifei/yy_strategy_adjust.bundle
-rw-r--r-- 0/0 74098809 2015-10-20 20:00 ./chongming/traffic_replay.bundle
-rw-r--r-- 0/0 451553507 2015-10-20 20:00 ./chongming/tsg_test.bundle
-rw-r--r-- 0/0 1845474 2015-10-20 20:00 ./common_tools/tcp_burst.bundle
-rw-r--r-- 0/0 3094911 2015-10-20 20:00 ./common_tools/tcpdump_mesa.bundle
-rw-r--r-- 0/0 782567 2015-10-20 20:00 ./cuiyiming/MESA_flexible_logger.bundle
-rw-r--r-- 0/0 50633508 2015-10-20 20:00 ./cuiyiming/MESA_summer_training_2018.bundle
-rw-r--r-- 0/0 11585235 2015-10-20 20:00 ./cuiyiming/feature_extract_plugin.bundle
-rw-r--r-- 0/0 98720797 2015-10-20 20:00 ./cuiyiming/gradproj.bundle
-rw-r--r-- 0/0 537134 2015-10-20 20:00 ./cuiyiming/lua_sapp.bundle
-rw-r--r-- 0/0 67442278 2015-10-20 20:00 ./current2023/evasion-detect.bundle
-rw-r--r-- 0/0 577001 2015-10-20 20:00 ./current2023/evasion-test.bundle
-rw-r--r-- 0/0 63790410 2015-10-20 20:00 ./current2023/ui.bundle
-rw-r--r-- 0/0 2814073 2015-10-20 20:00 ./cyber-narrator/cn-reporter-template.bundle
-rw-r--r-- 0/0 329535336 2015-10-20 20:00 ./cyber-narrator/cn-ui.bundle
-rw-r--r-- 0/0 105716721 2015-10-20 20:00 ./cyber-narrator/cn-web.bundle
-rw-r--r-- 0/0 90878 2015-10-20 20:00 ./cyber-narrator/license-admin-api.bundle
-rw-r--r-- 0/0 20475871 2015-10-20 20:00 ./cyber_narrator/flink-stream-schedule-platform.bundle
-rw-r--r-- 0/0 253115154 2015-10-20 20:00 ./daxiaoxu/xmr_bsexpr1.bundle
-rw-r--r-- 0/0 36058713 2015-10-20 20:00 ./daxiaoxu/xmr_bsexpr2.bundle
-rw-r--r-- 0/0 273248 2015-10-20 20:00 ./daxiaoxu/xmr_bsexpr3.bundle
-rw-r--r-- 0/0 20341272 2015-10-20 20:00 ./dengzeyi/sequenceshield.bundle
-rw-r--r-- 0/0 197136681 2015-10-20 20:00 ./docs/logo.bundle
-rw-r--r-- 0/0 2302685 2015-10-20 20:00 ./docs/regulations.bundle
-rw-r--r-- 0/0 20929 2015-10-20 20:00 ./dongxiaoyan/autotest_tsg.bundle
-rw-r--r-- 0/0 24816 2015-10-20 20:00 ./dongxiaoyan/gap_nezha_ui.bundle
-rw-r--r-- 0/0 2119602854 2015-10-20 20:00 ./dongxiaoyan/gap_tsg_api.bundle
-rw-r--r-- 0/0 17935172 2015-10-20 20:00 ./dongxiaoyan/gap_tsg_ui.bundle
-rw-r--r-- 0/0 72823586 2015-10-20 20:00 ./dongxiaoyan/tsg_autotest.bundle
-rw-r--r-- 0/0 31808452 2015-10-20 20:00 ./doris/doris_dispatch.bundle
-rw-r--r-- 0/0 34751183 2015-10-20 20:00 ./durain/durain_doc.bundle
-rw-r--r-- 0/0 7738 2015-10-20 20:00 ./fumingwei/sapp_test.bundle
-rw-r--r-- 0/0 5547 2015-10-20 20:00 ./fumingwei/tsg-containerd.bundle
-rw-r--r-- 0/0 462355 2015-10-20 20:00 ./galaxy/K18/galaxy-push-service-.bundle
-rw-r--r-- 0/0 87975634 2015-10-20 20:00 ./galaxy/K18/galaxy-service.bundle
-rw-r--r-- 0/0 8647477 2015-10-20 20:00 ./galaxy/deployment/ansible-deploy-hub.bundle
-rw-r--r-- 0/0 1094698678 2015-10-20 20:00 ./galaxy/deployment/bmj-deploy.bundle
-rw-r--r-- 0/0 171577701 2015-10-20 20:00 ./galaxy/deployment/k8s.bundle
-rw-r--r-- 0/0 604858552 2015-10-20 20:00 ./galaxy/deployment/online-config.bundle
-rw-r--r-- 0/0 71534 2015-10-20 20:00 ./galaxy/deployment/schema-updater-tool.bundle
-rw-r--r-- 0/0 20412815 2015-10-20 20:00 ./galaxy/deployment/tsg-olap-data-initialization.bundle
-rw-r--r-- 0/0 112623299 2015-10-20 20:00 ./galaxy/deployment/updata-record.bundle
-rw-r--r-- 0/0 752206562 2015-10-20 20:00 ./galaxy/galaxy-integration.bundle
-rw-r--r-- 0/0 45259 2015-10-20 20:00 ./galaxy/galaxy-offline-service.bundle
-rw-r--r-- 0/0 9801 2015-10-20 20:00 ./galaxy/platform/algorithm/business-rules-engine.bundle
-rw-r--r-- 0/0 181614 2015-10-20 20:00 ./galaxy/platform/algorithm/druid-extensions.bundle
-rw-r--r-- 0/0 60133 2015-10-20 20:00 ./galaxy/platform/algorithm/sketches.bundle
-rw-r--r-- 0/0 54347 2015-10-20 20:00 ./galaxy/platform/algorithm/snowflake.bundle
-rw-r--r-- 0/0 48233213 2015-10-20 20:00 ./galaxy/platform/galaxy-data-platform.bundle
-rw-r--r-- 0/0 14226827 2015-10-20 20:00 ./galaxy/platform/galaxy-job.bundle
-rw-r--r-- 0/0 78198 2015-10-20 20:00 ./galaxy/platform/galaxy-navigation.bundle
-rw-r--r-- 0/0 292910130 2015-10-20 20:00 ./galaxy/platform/galaxy-qgw-service.bundle
-rw-r--r-- 0/0 459089 2015-10-20 20:00 ./galaxy/platform/galaxy-report-service.bundle
-rw-r--r-- 0/0 23389965 2015-10-20 20:00 ./galaxy/platform/galaxy-tool.bundle
-rw-r--r-- 0/0 129670055 2015-10-20 20:00 ./galaxy/platform/galaxy-troubleshooting-api.bundle
-rw-r--r-- 0/0 112490 2015-10-20 20:00 ./galaxy/platform/galaxy-ua-parser.bundle
-rw-r--r-- 0/0 39278379 2015-10-20 20:00 ./galaxy/platform/groot-stream.bundle
-rw-r--r-- 0/0 18874351 2015-10-20 20:00 ./galaxy/platform/tsg-olap-troubleshooting.bundle
-rw-r--r-- 0/0 39380 2015-10-20 20:00 ./galaxy/tsg_olap/app-protocol-stat-traffic-agent.bundle
-rw-r--r-- 0/0 98603 2015-10-20 20:00 ./galaxy/tsg_olap/app-protocol-stat-traffic-merge.bundle
-rw-r--r-- 0/0 15104 2015-10-20 20:00 ./galaxy/tsg_olap/app_recommend.bundle
-rw-r--r-- 0/0 513146684 2015-10-20 20:00 ./galaxy/tsg_olap/dll-multipoint-aggregation.bundle
-rw-r--r-- 0/0 285852 2015-10-20 20:00 ./galaxy/tsg_olap/dos-detection-job.bundle
-rw-r--r-- 0/0 138912 2015-10-20 20:00 ./galaxy/tsg_olap/file-chunk-combiner.bundle
-rw-r--r-- 0/0 59922 2015-10-20 20:00 ./galaxy/tsg_olap/flume/dynamic_complement.bundle
-rw-r--r-- 0/0 17393 2015-10-20 20:00 ./galaxy/tsg_olap/flume/flume-interceptor.bundle
-rw-r--r-- 0/0 10247 2015-10-20 20:00 ./galaxy/tsg_olap/flume/interceptor/flume-http-avro-gtpc.bundle
-rw-r--r-- 0/0 48244586 2015-10-20 20:00 ./galaxy/tsg_olap/generate-baseline.bundle
-rw-r--r-- 0/0 349266 2015-10-20 20:00 ./galaxy/tsg_olap/log-completion-schema.bundle
-rw-r--r-- 0/0 68212 2015-10-20 20:00 ./galaxy/tsg_olap/log-olap-analysis-schema.bundle
-rw-r--r-- 0/0 71301876 2015-10-20 20:00 ./galaxy/tsg_olap/log-stream-doublewrite.bundle
-rw-r--r-- 0/0 65574 2015-10-20 20:00 ./galaxy/tsg_olap/log-stream-voip-relation.bundle
-rw-r--r-- 0/0 46514 2015-10-20 20:00 ./galaxy/tsg_olap/p19-file-sync-service.bundle
-rw-r--r-- 0/0 38345 2015-10-20 20:00 ./galaxy/tsg_olap/radius-account-knowledge.bundle
-rw-r--r-- 0/0 41161 2015-10-20 20:00 ./galaxy/tsg_olap/radius-relationship-hbase.bundle
-rw-r--r-- 0/0 27033 2015-10-20 20:00 ./galaxy/tsg_olap/relationship-gtpc-user.bundle
-rw-r--r-- 0/0 13858166 2015-10-20 20:00 ./galaxy/tsg_olap/sip-rtp-correlation.bundle
-rw-r--r-- 0/0 33151 2015-10-20 20:00 ./galaxy/tsg_olap/storm/log-address-hbase.bundle
-rw-r--r-- 0/0 60982 2015-10-20 20:00 ./galaxy/tsg_olap/storm/log-stream-aggregation.bundle
-rw-r--r-- 0/0 229667 2015-10-20 20:00 ./galaxy/tsg_olap/storm/log-stream-completion.bundle
-rw-r--r-- 0/0 18753 2015-10-20 20:00 ./galaxy/tsg_olap/storm/log-stream-connections.bundle
-rw-r--r-- 0/0 45986 2015-10-20 20:00 ./galaxy/tsg_olap/storm/log-stream-topn.bundle
-rw-r--r-- 0/0 20493 2015-10-20 20:00 ./galaxy/tsg_olap/storm/log-subscriber-hbase-datacenter.bundle
-rw-r--r-- 0/0 14294 2015-10-20 20:00 ./galaxy/tsg_olap/storm/radius-account-knowledge.bundle
-rw-r--r-- 0/0 44738 2015-10-20 20:00 ./galaxy/tsg_olap/storm/storm-olap-aggregation.bundle
-rw-r--r-- 0/0 61138 2015-10-20 20:00 ./galaxy/tsg_olap/storm-dos-detection.bundle
-rw-r--r-- 0/0 92311 2015-10-20 20:00 ./galaxy/tsg_olap/topn-metrics.bundle
-rw-r--r-- 0/0 10468 2015-10-20 20:00 ./galaxy/tsg_olap/tsg-complement.bundle
-rw-r--r-- 0/0 45468 2015-10-20 20:00 ./galaxy/tsg_olap/tsg_galaxy_producer-v3.0.20191115.bundle
-rw-r--r-- 0/0 399303565 2015-10-20 20:00 ./galaxy/tsg_olap/xj-log-etl.bundle
-rw-r--r-- 0/0 13852974 2015-10-20 20:00 ./gregory/yydns_vue.bundle
-rw-r--r-- 0/0 1861380 2015-10-20 20:00 ./handingkang/alias_prefix.bundle
-rw-r--r-- 0/0 39925 2015-10-20 20:00 ./handingkang/dnscan_dbdesign.bundle
-rw-r--r-- 0/0 33554 2015-10-20 20:00 ./handingkang/fakedns6-v2.bundle
-rw-r--r-- 0/0 11439062 2015-10-20 20:00 ./handingkang/fakedns6.bundle
-rw-r--r-- 0/0 6861369 2015-10-20 20:00 ./handingkang/ohmybs.bundle
-rw-r--r-- 0/0 1034429 2015-10-20 20:00 ./handingkang/ohmydns.bundle
-rw-r--r-- 0/0 2071234 2015-10-20 20:00 ./handingkang/ohmydns2.bundle
-rw-r--r-- 0/0 32456 2015-10-20 20:00 ./handingkang/ohmyserver.bundle
-rw-r--r-- 0/0 76711356 2015-10-20 20:00 ./handingkang/ohmyweb.bundle
-rw-r--r-- 0/0 3699580 2015-10-20 20:00 ./handingkang/ohxmap.bundle
-rw-r--r-- 0/0 13479 2015-10-20 20:00 ./handingkang/prober.bundle
-rw-r--r-- 0/0 322134378 2015-10-20 20:00 ./handingkang/yserver.bundle
-rw-r--r-- 0/0 26145078 2015-10-20 20:00 ./handingkang/yydns.bundle
-rw-r--r-- 0/0 589422 2015-10-20 20:00 ./handingkang/yyserver.bundle
-rw-r--r-- 0/0 8390 2015-10-20 20:00 ./hcy/190823-bcs.bundle
-rw-r--r-- 0/0 109357451 2015-10-20 20:00 ./hcy/ConfSummary.bundle
-rw-r--r-- 0/0 8296361 2015-10-20 20:00 ./hcy/TechSummary.bundle
-rw-r--r-- 0/0 4589 2015-10-20 20:00 ./hewenliang/https-measure.bundle
-rw-r--r-- 0/0 51451703 2015-10-20 20:00 ./hezhengjie/heatao_techsum.bundle
-rw-r--r-- 0/0 370591 2015-10-20 20:00 ./hezhengjie/videoportaldetection.bundle
-rw-r--r-- 0/0 167087379 2015-10-20 20:00 ./intelligence-learning-engine/vpn-finder-plugins.bundle
-rw-r--r-- 0/0 1544434 2015-10-20 20:00 ./jiangpenghui/openlookeng_poc.bundle
-rw-r--r-- 0/0 21308 2015-10-20 20:00 ./jiangpenghui/qq_file_send.bundle
-rw-r--r-- 0/0 100116 2015-10-20 20:00 ./jiangping/bloomfilter.bundle
-rw-r--r-- 0/0 30081661 2015-10-20 20:00 ./jiangping/msflow.bundle
-rw-r--r-- 0/0 14298 2015-10-20 20:00 ./jiangping/supervlan.bundle
-rw-r--r-- 0/0 23084 2015-10-20 20:00 ./l1453/ddos_classify.bundle
-rw-r--r-- 0/0 99875 2015-10-20 20:00 ./l1453/ddos_detect.bundle
-rw-r--r-- 0/0 14220555 2015-10-20 20:00 ./l1453/ddos_openworld.bundle
-rw-r--r-- 0/0 80780 2015-10-20 20:00 ./lijia/tsg_oam.bundle
-rw-r--r-- 0/0 133847587 2015-10-20 20:00 ./liliqing/appdiscover.bundle
-rw-r--r-- 0/0 13817098 2015-10-20 20:00 ./linxin/coredump-tools.bundle
-rw-r--r-- 0/0 13118 2015-10-20 20:00 ./linxin/deviceplugindemo.bundle
-rw-r--r-- 0/0 37161 2015-10-20 20:00 ./linxin/webhookdemo.bundle
-rw-r--r-- 0/0 10528 2015-10-20 20:00 ./lirenjie/conferencesummary.bundle
-rw-r--r-- 0/0 46300 2015-10-20 20:00 ./lirenjie/lrj_vxlan.bundle
-rw-r--r-- 0/0 17033246 2015-10-20 20:00 ./little_stone/fingerprint.bundle
-rw-r--r-- 0/0 6180 2015-10-20 20:00 ./little_stone/mzy_logapi.bundle
-rw-r--r-- 0/0 5363638 2015-10-20 20:00 ./little_stone/webcomponent.bundle
-rw-r--r-- 0/0 5205 2015-10-20 20:00 ./little_stone/webhopper.bundle
-rw-r--r-- 0/0 8500759 2015-10-20 20:00 ./liuchang/mesa_sts.bundle
-rw-r--r-- 0/0 25485145 2015-10-20 20:00 ./liuchang/pkt_seq_matcher.bundle
-rw-r--r-- 0/0 906652 2015-10-20 20:00 ./liujunpeng/Minio.bundle
-rw-r--r-- 0/0 109544 2015-10-20 20:00 ./liujunpeng/hiredisMESA.bundle
-rw-r--r-- 0/0 3503690 2015-10-20 20:00 ./liujunpeng/redis.bundle
-rw-r--r-- 0/0 2712102 2015-10-20 20:00 ./liujunpeng/redis_cluster_install.bundle
-rw-r--r-- 0/0 64326024 2015-10-20 20:00 ./liuwentan/maat-rust-binding.bundle
-rw-r--r-- 0/0 1571688 2015-10-20 20:00 ./liuxueli/install-standalone-redis.bundle
-rw-r--r-- 0/0 11941 2015-10-20 20:00 ./liuyang/inline_device.bundle
-rw-r--r-- 0/0 550233 2015-10-20 20:00 ./liuyu/bbq.bundle
-rw-r--r-- 0/0 17676428 2015-10-20 20:00 ./lixinyan/diamondv.bundle
-rw-r--r-- 0/0 444434 2015-10-20 20:00 ./lixinyan/email-mapping-system.bundle
-rw-r--r-- 0/0 673946709 2015-10-20 20:00 ./lixinyan/email-spoofing-detection.bundle
-rw-r--r-- 0/0 519288 2015-10-20 20:00 ./liyubing/p4exercise.bundle
-rw-r--r-- 0/0 18550 2015-10-20 20:00 ./luwenpeng/certificate.bundle
-rw-r--r-- 0/0 10212 2015-10-20 20:00 ./luwenpeng/mini-rust-runtime.bundle
-rw-r--r-- 0/0 42564 2015-10-20 20:00 ./luwenpeng/rust_dpi.bundle
-rw-r--r-- 0/0 2652 2015-10-20 20:00 ./luwenpeng/stellar.bundle
-rw-r--r-- 0/0 11315049 2015-10-20 20:00 ./lyf/sdprojects.bundle
-rw-r--r-- 0/0 124337 2015-10-20 20:00 ./maxiaoqing/Task.bundle
-rw-r--r-- 0/0 4276 2015-10-20 20:00 ./maxiaoqing/av_container_identify.bundle
-rw-r--r-- 0/0 3826 2015-10-20 20:00 ./modikai/cache_prober.bundle
-rw-r--r-- 0/0 3005 2015-10-20 20:00 ./modikai/diamondv.bundle
-rw-r--r-- 0/0 11128383 2015-10-20 20:00 ./modikai/dtool.bundle
-rw-r--r-- 0/0 7760296 2015-10-20 20:00 ./modikai/echodns.bundle
-rw-r--r-- 0/0 12353268 2015-10-20 20:00 ./modikai/edns_svcb_https.bundle
-rw-r--r-- 0/0 3213 2015-10-20 20:00 ./modikai/fpdns_client.bundle
-rw-r--r-- 0/0 17026560 2015-10-20 20:00 ./modikai/fpdns_server.bundle
-rw-r--r-- 0/0 2967 2015-10-20 20:00 ./modikai/gfw_test.bundle
-rw-r--r-- 0/0 3763183 2015-10-20 20:00 ./modikai/rogue_ns.bundle
-rw-r--r-- 0/0 373732 2015-10-20 20:00 ./nezha/demo_exporter.bundle
-rw-r--r-- 0/0 477962 2015-10-20 20:00 ./nezha/doc.bundle
-rw-r--r-- 0/0 656754042 2015-10-20 20:00 ./nezha/nezha-fronted.bundle
-rw-r--r-- 0/0 282419 2015-10-20 20:00 ./nezha/nz-agent.bundle
-rw-r--r-- 0/0 676286894 2015-10-20 20:00 ./nezha/nz-build-env.bundle
-rw-r--r-- 0/0 1917895965 2015-10-20 20:00 ./nezha/nz-build.bundle
-rw-r--r-- 0/0 220847 2015-10-20 20:00 ./nezha/nz-confagent.bundle
-rw-r--r-- 0/0 112281 2015-10-20 20:00 ./nezha/nz-talon.bundle
-rw-r--r-- 0/0 198376 2015-10-20 20:00 ./nezha/nz-transfer.bundle
-rw-r--r-- 0/0 255494757 2015-10-20 20:00 ./nezha/nz-web.bundle
-rw-r--r-- 0/0 27087 2015-10-20 20:00 ./nezha/olp_exporter.bundle
-rw-r--r-- 0/0 3117 2015-10-20 20:00 ./nezha/playbook.bundle
-rw-r--r-- 0/0 2361771 2015-10-20 20:00 ./niubinghui/luapluginmanage.bundle
-rw-r--r-- 0/0 10028665 2015-10-20 20:00 ./nms/nmsclient.bundle
-rw-r--r-- 0/0 197966742 2015-10-20 20:00 ./nms/nmsdoc.bundle
-rw-r--r-- 0/0 27883477 2015-10-20 20:00 ./nms/nmsserver.bundle
-rw-r--r-- 0/0 8363468 2015-10-20 20:00 ./nms/nmssync.bundle
-rw-r--r-- 0/0 126962650 2015-10-20 20:00 ./nms/nmsweb.bundle
-rw-r--r-- 0/0 14818848 2015-10-20 20:00 ./nms/oam.bundle
-rw-r--r-- 0/0 496590238 2015-10-20 20:00 ./operation-and-maintenance/ansible-playbook-test.bundle
-rw-r--r-- 0/0 35887814 2015-10-20 20:00 ./public_resources/benchmark_pcap.bundle
-rw-r--r-- 0/0 2817638 2015-10-20 20:00 ./public_resources/sapp_doc.bundle
-rw-r--r-- 0/0 400094528 2015-10-20 20:00 ./pxz/hos_client_cpp_module.bundle
-rw-r--r-- 0/0 10917030 2015-10-20 20:00 ./pxz/tsg_lua_module.bundle
-rw-r--r-- 0/0 2807384 2015-10-20 20:00 ./pzx/tensor-k18.bundle
-rw-r--r-- 0/0 2015950430 2015-10-20 20:00 ./qiuyuqi/diamondv.bundle
-rw-r--r-- 0/0 3336 2015-10-20 20:00 ./qiuyuqi/dnscan_dbdesign.bundle
-rw-r--r-- 0/0 1742555 2015-10-20 20:00 ./renkaige/redis_cluster_install.bundle
-rw-r--r-- 0/0 81944539 2015-10-20 20:00 ./shihaoyue/yy_deploy_script.bundle
-rw-r--r-- 0/0 787555 2015-10-20 20:00 ./shihaoyue/yy_llm.bundle
-rw-r--r-- 0/0 3722058858 2015-10-20 20:00 ./solutions/tsg-scripts.bundle
-rw-r--r-- 0/0 3549540 2015-10-20 20:00 ./stellar/dns_decoder.bundle
-rw-r--r-- 0/0 8963689 2015-10-20 20:00 ./stellar/ftp_decoder.bundle
-rw-r--r-- 0/0 7628725 2015-10-20 20:00 ./stellar/http_decoder.bundle
-rw-r--r-- 0/0 51131296 2015-10-20 20:00 ./stellar/quic_decoder.bundle
-rw-r--r-- 0/0 16048393 2015-10-20 20:00 ./stellar/ssl_decoder.bundle
-rw-r--r-- 0/0 1809615 2015-10-20 20:00 ./stellar/stellar-2022.bundle
-rw-r--r-- 0/0 6633 2015-10-20 20:00 ./stellar/stellar-dev-env.bundle
-rw-r--r-- 0/0 20173431 2015-10-20 20:00 ./stellar/stellar-on-sapp.bundle
-rw-r--r-- 0/0 1325020 2015-10-20 20:00 ./stellar/stellar-rs.bundle
-rw-r--r-- 0/0 412346940 2015-10-20 20:00 ./stellar/stellar.bundle
-rw-r--r-- 0/0 31414004 2015-10-20 20:00 ./swarmkv/swarmkv.bundle
-rw-r--r-- 0/0 1191714242 2015-10-20 20:00 ./tango/9140_hardware.bundle
-rw-r--r-- 0/0 3119108 2015-10-20 20:00 ./tango/FieldStat.bundle
-rw-r--r-- 0/0 67384197 2015-10-20 20:00 ./tango/adc_hardware.bundle
-rw-r--r-- 0/0 42345465 2015-10-20 20:00 ./tango/certstore.bundle
-rw-r--r-- 0/0 45218 2015-10-20 20:00 ./tango/fw_dns_plug.bundle
-rw-r--r-- 0/0 2064796 2015-10-20 20:00 ./tango/kni.bundle
-rw-r--r-- 0/0 575063419 2015-10-20 20:00 ./tango/maat.bundle
-rw-r--r-- 0/0 7476395 2015-10-20 20:00 ./tango/performance-test-nginx-server.bundle
-rw-r--r-- 0/0 54661319 2015-10-20 20:00 ./tango/shaping-engine.bundle
-rw-r--r-- 0/0 127261868 2015-10-20 20:00 ./tango/tango_docs.bundle
-rw-r--r-- 0/0 48146 2015-10-20 20:00 ./tango/tfe-kmod.bundle
-rw-r--r-- 0/0 123688869 2015-10-20 20:00 ./tango/tfe.bundle
-rw-r--r-- 0/0 3529484 2015-10-20 20:00 ./tango/tsg-service-chaining-engine.bundle
-rw-r--r-- 0/0 126030194 2015-10-20 20:00 ./tango/tsg_container.bundle
-rw-r--r-- 0/0 3119932 2015-10-20 20:00 ./tango/tsg_master.bundle
-rw-r--r-- 0/0 53297 2015-10-20 20:00 ./tango/tsgx_hardware.bundle
-rw-r--r-- 0/0 19774489 2015-10-20 20:00 ./tango/verify-policy.bundle
-rw-r--r-- 0/0 127099807 2015-10-20 20:00 ./tongzongzhen/dpdk.bundle
-rw-r--r-- 0/0 1430734 2015-10-20 20:00 ./tongzongzhen/fuzzing-demo.bundle
-rw-r--r-- 0/0 2517682 2015-10-20 20:00 ./tsg/PacketAdapter.bundle
-rw-r--r-- 0/0 357716047 2015-10-20 20:00 ./tsg/cli-deploy.bundle
-rw-r--r-- 0/0 3164954 2015-10-20 20:00 ./tsg/dp_telemetry_app.bundle
-rw-r--r-- 0/0 18743445 2015-10-20 20:00 ./tsg/hasp-tools.bundle
-rw-r--r-- 0/0 543888171 2015-10-20 20:00 ./tsg/oam.bundle
-rw-r--r-- 0/0 12197460753 2015-10-20 20:00 ./tsg/tsg-deploy.bundle
-rw-r--r-- 0/0 391812321 2015-10-20 20:00 ./tsg/tsg-diagnose.bundle
-rw-r--r-- 0/0 66615780 2015-10-20 20:00 ./tsg/tsg-doc.bundle
-rw-r--r-- 0/0 3734555897 2015-10-20 20:00 ./tsg/tsg-os-buildimage.bundle
-rw-r--r-- 0/0 792940795 2015-10-20 20:00 ./tsg/tsg-os-onie.bundle
-rw-r--r-- 0/0 1090920 2015-10-20 20:00 ./tsg/tsg-performance-test-tools.bundle
-rw-r--r-- 0/0 98299245 2015-10-20 20:00 ./tsg/tsg-scripts-platform.bundle
-rw-r--r-- 0/0 957 2015-10-20 20:00 ./tsg/tsg_test.bundle
-rw-r--r-- 0/0 71806569 2015-10-20 20:00 ./tsg/wannat-ansible-deploy.bundle
-rw-r--r-- 0/0 5737448 2015-10-20 20:00 ./tsg-manual/tsg-admin-guide.bundle
-rw-r--r-- 0/0 44449639 2015-10-20 20:00 ./tsg-ui/demo.bundle
-rw-r--r-- 0/0 346651 2015-10-20 20:00 ./vendor/cJSON.bundle
-rw-r--r-- 0/0 97743 2015-10-20 20:00 ./vendor/hiredis.bundle
-rw-r--r-- 0/0 4438486 2015-10-20 20:00 ./vendor/pcre.bundle
-rw-r--r-- 0/0 4957429 2015-10-20 20:00 ./vendor/rdkafka.bundle
-rw-r--r-- 0/0 1936462 2015-10-20 20:00 ./voip-analysis/sip-voip-completion.bundle
-rw-r--r-- 0/0 6764 2015-10-20 20:00 ./wangfengmei/ipreset.bundle
-rw-r--r-- 0/0 365753 2015-10-20 20:00 ./wanglihui/ip-learning-graph.bundle
-rw-r--r-- 0/0 10032 2015-10-20 20:00 ./wangmeiqi/2ch-tcn.bundle
-rw-r--r-- 0/0 1539545583 2015-10-20 20:00 ./wangmeiqi/datacollect_new.bundle
-rw-r--r-- 0/0 13109224 2015-10-20 20:00 ./wangmeiqi/datacollect_old.bundle
-rw-r--r-- 0/0 14631800 2015-10-20 20:00 ./wangmeiqi/hswfp.bundle
-rw-r--r-- 0/0 29962588 2015-10-20 20:00 ./wangmeiqi/obfs4_meek_snowflake.bundle
-rw-r--r-- 0/0 502845 2015-10-20 20:00 ./wangmeiqi/obfs4_verify.bundle
-rw-r--r-- 0/0 3320 2015-10-20 20:00 ./wangmeiqi/tf.bundle
-rw-r--r-- 0/0 177907959 2015-10-20 20:00 ./wangmeiqi/wfp_dataprocess.bundle
-rw-r--r-- 0/0 49755 2015-10-20 20:00 ./wangwei/cn-object-scheduler.bundle
-rw-r--r-- 0/0 54928 2015-10-20 20:00 ./wangwei/fj-transform-api.bundle
-rw-r--r-- 0/0 70947 2015-10-20 20:00 ./wangyan/singleflowaggregation.bundle
-rw-r--r-- 0/0 71144202 2015-10-20 20:00 ./wangyouzhan/comm_audit.bundle
-rw-r--r-- 0/0 27686 2015-10-20 20:00 ./wangyouzhan/dns_jt_audit.bundle
-rw-r--r-- 0/0 25808 2015-10-20 20:00 ./wangyouzhan/http_jt_audit.bundle
-rw-r--r-- 0/0 120025 2015-10-20 20:00 ./wangyouzhan/http_statistic_fs.bundle
-rw-r--r-- 0/0 1957270 2015-10-20 20:00 ./wangyu/imc_2017_2018.bundle
-rw-r--r-- 0/0 6567673 2015-10-20 20:00 ./web-sketch/webskt-query-agent.bundle
-rw-r--r-- 0/0 10957193 2015-10-20 20:00 ./wuhongwei/2021.bundle
-rw-r--r-- 0/0 4228640 2015-10-20 20:00 ./wujiating/censorship_detection.bundle
-rw-r--r-- 0/0 3454 2015-10-20 20:00 ./wujiating/cnirc-2nd.bundle
-rw-r--r-- 0/0 168824543 2015-10-20 20:00 ./wujiating/detection.bundle
-rw-r--r-- 0/0 2016081791 2015-10-20 20:00 ./wujiating/diamondv.bundle
-rw-r--r-- 0/0 2929689391 2015-10-20 20:00 ./wujiating/fingerprinting.bundle
-rw-r--r-- 0/0 8398655 2015-10-20 20:00 ./wujiating/google-2020.bundle
-rw-r--r-- 0/0 1989947 2015-10-20 20:00 ./wujiating/python-https.bundle
-rw-r--r-- 0/0 189050 2015-10-20 20:00 ./yangyongqiang/yyq_test.bundle
-rw-r--r-- 0/0 263189 2015-10-20 20:00 ./yangzhiqing/2w_web_tance.bundle
-rw-r--r-- 0/0 524 2015-10-20 20:00 ./yangzhiqing/demo1.bundle
-rw-r--r-- 0/0 4332172 2015-10-20 20:00 ./yangzhiqing/erqi_web_domain_zhili.bundle
-rw-r--r-- 0/0 324329286 2015-10-20 20:00 ./yangzhiqing/fwxxzc_erqi.bundle
-rw-r--r-- 0/0 101208939 2015-10-20 20:00 ./yangzhiqing/lvtong.bundle
-rw-r--r-- 0/0 3462203 2015-10-20 20:00 ./yangzhiqing/xd-yicundu.bundle
-rw-r--r-- 0/0 1138168 2015-10-20 20:00 ./yinjiangyi/uaanalyser.bundle
-rw-r--r-- 0/0 22410219 2015-10-20 20:00 ./yinjiangyi/webskt-query-agent.bundle
-rw-r--r-- 0/0 40849 2015-10-20 20:00 ./yulingjing/url_label_restiful.bundle
-rw-r--r-- 0/0 18302 2015-10-20 20:00 ./yzc/http_check.bundle
-rw-r--r-- 0/0 6036 2015-10-20 20:00 ./yzc/http_count.bundle
-rw-r--r-- 0/0 4434 2015-10-20 20:00 ./zengmeng/231031nxdomain.bundle
-rw-r--r-- 0/0 6468 2015-10-20 20:00 ./zengmeng/240825dnssecpool.bundle
-rw-r--r-- 0/0 235417406 2015-10-20 20:00 ./zhangchengwei/MinioRelated.bundle
-rw-r--r-- 0/0 39301 2015-10-20 20:00 ./zhangchengwei/qq_online_file.bundle
-rw-r--r-- 0/0 126566 2015-10-20 20:00 ./zhanghongqing/knowledge-log.bundle
-rw-r--r-- 0/0 1908691184 2015-10-20 20:00 ./zhangqingfeng/zhangqingfeng.bundle
-rw-r--r-- 0/0 23569932 2015-10-20 20:00 ./zhangshuai/ConfSummary.bundle
-rw-r--r-- 0/0 17863599 2015-10-20 20:00 ./zhangshuo1/domain-classification.bundle
-rw-r--r-- 0/0 58497561 2015-10-20 20:00 ./zhangyang/diagnose-tools.bundle
-rw-r--r-- 0/0 9973 2015-10-20 20:00 ./zhangyang/ffi_demo.bundle
-rw-r--r-- 0/0 53049 2015-10-20 20:00 ./zhangyang/fs4-demo.bundle
-rw-r--r-- 0/0 17552172 2015-10-20 20:00 ./zhangyang/libzt.bundle
-rw-r--r-- 0/0 10315184 2015-10-20 20:00 ./zhangyang/lwip.bundle
-rw-r--r-- 0/0 150396 2015-10-20 20:00 ./zhangyang/maat_demo.bundle
-rw-r--r-- 0/0 28115 2015-10-20 20:00 ./zhangyang/mini-rust-runtime.bundle
-rw-r--r-- 0/0 5350849 2015-10-20 20:00 ./zhangyang/monoio.bundle
-rw-r--r-- 0/0 379972664 2015-10-20 20:00 ./zhangyang/qemu-uintr.bundle
-rw-r--r-- 0/0 124183 2015-10-20 20:00 ./zhangyang/rs-timeout.bundle
-rw-r--r-- 0/0 9041463 2015-10-20 20:00 ./zhangyang/uintr-event.bundle
-rw-r--r-- 0/0 1728405298 2015-10-20 20:00 ./zhangyang/uintr-linux-kernel.bundle
-rw-r--r-- 0/0 626544 2015-10-20 20:00 ./zhangyang/variable_monitor.bundle
-rw-r--r-- 0/0 68814 2015-10-20 20:00 ./zhangyang/watch_monitor.bundle
-rw-r--r-- 0/0 159397818 2015-10-20 20:00 ./zhangyang/zerotierone.bundle
-rw-r--r-- 0/0 2884416271 2015-10-20 20:00 ./zhangzhihan/device-management-scripts.bundle
-rw-r--r-- 0/0 235091 2015-10-20 20:00 ./zhangzhihao/1a.bundle
-rw-r--r-- 0/0 7620 2015-10-20 20:00 ./zhangzhihao/ccproxy.bundle
-rw-r--r-- 0/0 384759422 2015-10-20 20:00 ./zhangzhihao/heavykeeper.bundle
-rw-r--r-- 0/0 29812 2015-10-20 20:00 ./zhangzhihao/rdma-example.bundle
-rw-r--r-- 0/0 122633 2015-10-20 20:00 ./zhangzhihao/softiwarp.bundle
-rw-r--r-- 0/0 20353792 2015-10-20 20:00 ./zhaokun/tsg_policy_api.bundle
-rw-r--r-- 0/0 269393524 2015-10-20 20:00 ./zhaokun/tsg_ui_script.bundle
-rw-r--r-- 0/0 31802 2015-10-20 20:00 ./zhaoyijun/nat_format.bundle
-rw-r--r-- 0/0 4181738 2015-10-20 20:00 ./zhaoyixiang/realtime_protection.bundle
-rw-r--r-- 0/0 149919112 2015-10-20 20:00 ./zhaoyixiang/scanner.bundle
-rw-r--r-- 0/0 261609623 2015-10-20 20:00 ./zhaoyixiang/ssl.bundle
-rw-r--r-- 0/0 2933151 2015-10-20 20:00 ./zhijinghua/dns-log-transforming.bundle
-rw-r--r-- 0/0 5015970 2015-10-20 20:00 ./zhijinghua/mesa-traffic-identification.bundle
-rw-r--r-- 0/0 26140 2015-10-20 20:00 ./zhijinghua/portscan-detection.bundle
-rw-r--r-- 0/0 3040539 2015-10-20 20:00 ./zhongyoub/nfv-conclusion.bundle
-rw-r--r-- 0/0 1250448169 2015-10-20 20:00 ./zhuyujia/diamondv.bundle
-rw-r--r-- 0/0 5363638 2015-10-20 20:00 ./zhuyujia/webcomponent.bundle
-rw-r--r-- 0/0 1608253521 2015-10-20 20:00 ./zhuyujia/webhopper.bundle
-rw-r--r-- 0/0 26145294 2015-10-20 20:00 ./zhuyujia/yydns.bundle
-rw-r--r-- 0/0 14394722 2015-10-20 20:00 ./zhuyujia/yydns_vue.bundle
-rw-r--r-- 0/0 701112 2015-10-20 20:00 ./zhuzhenjun/libosfp.bundle
-rw-r--r-- 0/0 38871 2015-10-20 20:00 ./zx_dataserker/field_splitter_complement.bundle
-rw-r--r-- 0/0 246412 2015-10-20 20:00 ./zx_dataserker/yb_flume_cus_sink_file.bundle
-rw-r--r-- 0/0 198711635 2015-10-20 20:00 ./zyq/time_series_anomaly_detection.bundle
Based on a skim of the filenames, these are some repositories I would prioritize to look at first:
- IPReuse/IPReuse_docs
- IPReuse/vpn_access
- IPReuse/vpn_install
- MESA_Platform/dns
- https://github.com/net4people/bbs/issues/519#issuecomment-3382616912
- MESA_Platform/gquic
- https://github.com/net4people/bbs/issues/519#issuecomment-3298801281
- MESA_Platform/http
- MESA_Platform/marsio
- MESA_Platform/quic
- https://github.com/net4people/bbs/issues/519#issuecomment-3298801281
- MESA_Platform/sapp
- MESA_Platform/ssl
- active-defense/houyi-deploy
- common_tools/tcp_burst
- common_tools/tcpdump_mesa
- cuiyiming/lua_sapp
- cyber-narrator/cn-web
- cyber-narrator/license-admin-api
- docs/regulations
- https://github.com/net4people/bbs/issues/519#issuecomment-3361891106
- dongxiaoyan/gap_tsg_api
- galaxy/deployment/k8s
- galaxy/deployment/updata-record
- https://github.com/net4people/bbs/issues/519#issuecomment-3312377183
- galaxy/platform/galaxy-qgw-service
- https://github.com/net4people/bbs/issues/519#issuecomment-3382616912
- galaxy/tsg_olap/dll-multipoint-aggregation
- hezhengjie/videoportaldetection
- intelligence-learning-engine/vpn-finder-plugins
- https://github.com/net4people/bbs/issues/519#issuecomment-3305475392
- liujunpeng/hiredisMESA
- liuwentan/maat-rust-binding
- nezha/nz-agent
- solutions/tsg-scripts
- stellar/dns_decoder
- stellar/ftp_decoder
- stellar/http_decoder
- stellar/quic_decoder
- stellar/ssl_decoder
- stellar/stellar
- tango/maat
- https://github.com/net4people/bbs/issues/444#issuecomment-3315071704
- https://github.com/net4people/bbs/issues/519#issuecomment-3382371248
- tango/shaping-engine
- tango/tfe
- tsg-manual/tsg-admin-guide
- tsg/tsg-deploy
- tsg/tsg-doc
- wangmeiqi/obfs4_meek_snowflake
- https://github.com/net4people/bbs/issues/519#issuecomment-3290129409
- wangmeiqi/obfs4_verify
- https://github.com/net4people/bbs/issues/519#issuecomment-3289654410
- zhangshuo1/domain-classification
- zhaokun/tsg_ui_script
- https://github.com/net4people/bbs/issues/519#issuecomment-3492343020
- zhijinghua/mesa-traffic-identification
If there's interest, maybe we can organize teams to divide the source code repositories and investigate them.
If there's interest, maybe we can organize teams to divide the source code repositories and investigate them.
wangmeiqi/obfs4_verify
This looks like a couple of rudimentary active probers for obfs4. They take a bridge IP:port and the bridge's out-of-band "cert" information (which is assumed to be known) and try handshaking with the server to see if it responds the way an obfs4 bridge would.
6188 README.md
121933 obfs4验证文档.docx
2999 parse.go
396970 pyelligator-master.zip
12967 testverify.go
7015 testverify.py
7799 verify_obfs4.py
obfs4验证文档.docx is a document that explains the purpose of the project, walks through the steps of the obfs4 handshake, and comments on the Go code.
obfs4节点验证文档
一、原理 客户端与服务器使用Tor obfs4插件进行通信前，首先要建立握手。通过模拟obfs4客户端的握手行为向待验证的obfs4节点发送握手请求，如果能得到预期的响应，则验证目标节点为obfs4节点。
Obfs4 Node Verification Document
Before a client and server communicate using the Tor obfs4 plugin, they must first establish a handshake. This process simulates the handshake behavior of an obfs4 client and sends a handshake request to the obfs4 node to be verified. If the expected response is received, the target node is verified as an obfs4 node.
The file testverify.go is a Go version of the prober. It consists mainly of code copied from transports/obfs4/obfs4.go and transports/obfs4/handshake_ntor.go in the original obfs4proxy source code, along with a small main function to attempt a handshake with a hardcoded bridge.
func main() {
var ptName string
ptName = "obfs4"
var certStr string
certStr = "iJ8il3a2gVXuNdZoaPwQ0QgdOJyBAi4fcY642f6sTErVNZ14Ax7c9w9qa36mUXQhbm9vOg"
// certStr = "M6tiPcFv8YK2jE8pYZb9AKMMHHag4OrhHFWmOXHR+J9s8Ty9X9V+Bn0emEZmfnqhdtHkdA"
var iatStr string
iatStr = "0"
var address string
address = "185.185.251.132:443"
// address = "45.32.201.89:51433"
var result int
result = verify(ptName, certStr, address, iatStr)
fmt.Println(result)
}
testverify.py and verify_obfs4.py look like 2 different revisions of a Python version of the prober. It may be a translation of the Go into Python, because I don't recognize the implementation. testverify.py has the same 2 bridge addresses as testverify.go. verify_obfs4.py has a different one:
if __name__ == '__main__':
ptName = "obfs4"
for i in range(10):
item=bridgestr()
item.certStr = "dCLDdS35RUyZ/H93CQ7BlEdCF4QOCvw9+AmB116o6CU0ZGhm2TNDjwee9XYi/SVn9/gnKQ"
item.address="104.168.126.106:42154"
result = verify(ptName, item.certStr, item.address)
print result
i=i+1
Whether these are real obfs4 bridges, I don't know.
The repository has 7 commits, all on 2024-06-28 by meiqi wang <[email protected]>. It looks like a test project that was not updated or maintained. It has hardcoded bridge IP addresses and credentials and reports output just by printing to stdout. The code looks amateurish. It doesn't look like an operational piece of software.
Perhaps notably, this repository does not use any of the public key distinguishability attacks that were known in 2024, nor show any awareness of them.
This is data from our Intra app showing how successful the app is in recovering from SNI-based blocking. Intra triggers a retry on TLS connections with TLS record fragmentation if it fails to get a response before a timeout, and we measure whether the retry fails or succeeds ("traffic we can recover").
Success rate in Myanmar significantly dropped after May 2024, aligning it with the rate from China. This is aligned with the timeline provided in the report.
(Note that it drops further for both countries in August 2025)
Success rate in Myanmar significantly dropped after May 2024, aligning it with the rate from China. This is aligned with the timeline provided in the report.
Interesting. Thank you for checking that.
I don't see a reference to Intra in geedge_jira.tar.zst, but there is one issue that references Outline, issues/OSS-378.json. The issue title is 【M22项目】VPN特征提取-宋龙坤 ([Project M22] VPN feature extraction - Song Longkun).
2024-09-27 宋龙坤 (Song Longkun):
20240924对Orbot进行逆向分析，解析有效域名1个，除此之外未发现其他有效或有效特征； 20240924对Ostrich VPN进行逆向分析，解析有效域名2个，除此之外未发现其他有效或有效特征； 20240924对Outline VPN进行逆向分析，解析有效域名两个，除此之外未发现其他有效或有效特 征； 20240925对PandaVPN Lite进行逆向分析，解析有效域名2个，除此之外未发现其他有效或有效特征； 20240925对Pawxy进行逆向分析，解析有效域名5个，疑似134个服务器IP，除此之外未发现其他 有效或有效特征； 20240926对ProtonMail进行逆向分析，解析有效域名4个，除此之外未发现其他有效或有效特征 ； 20240926对Proxy OvpnSpider进行逆向分析，未发现有效或有效特征； PrivatePackets.io、Proxy.sh VPN官网无效，应用商店未找到对应应用。
20240924 Reverse analysis of Orbot revealed one valid domain name, but no other valid or valid features were found. 20240924 Reverse analysis of Ostrich VPN revealed two valid domain names, but no other valid or valid features were found. 20240924 Reverse analysis of Outline VPN revealed two valid domain names, but no other valid or valid features were found. 20240925 Reverse analysis of PandaVPN Lite revealed two valid domain names, but no other valid or valid features were found. 20240925 Reverse analysis of Pawxy revealed five valid domain names and 134 suspected server IP addresses, but no other valid or valid features were found. 20240926 Reverse analysis of ProtonMail revealed four valid domain names, but no other valid or valid features were found. 20240926 Reverse analysis of Proxy OvpnSpider revealed no valid or effective features. The official websites for PrivatePackets.io and Proxy.sh VPNs are inactive, and no corresponding apps were found in the app store.
2024-10-31 宋龙坤 (Song Longkun):
20241030 VPN序号137 共计提取Pawxy VPN 服务器IP 144个，目前在安卓模拟器平台中连续对该VPN的所有节点拨测20次均无法正常连接，阻断成功。 VPN序号132 Outline VPN需要使用他人的Outline服务器私钥或自己创建Outline服务器私钥才可使用。对该VPN的官网及APK包进行分析，未发现有效及疑似特征。 VPN序号146 编写Proxy OvpnSpider自动捕包程序，并提取服务器IP 107个。
20241030 VPN No. 137: A total of 144 Pawxy VPN server IP addresses were extracted. 20 consecutive calls to all nodes of this VPN on an Android emulator failed to connect, successfully blocking the connection. VPN No. 132: Outline VPN requires the use of a third-party Outline server private key or a custom-created one. Analysis of the VPN's official website and APK package revealed no valid or suspicious features. VPN No. 146: A Proxy OvpnSpider automated packet capture program was developed to extract 107 server IP addresses.
wangmeiqi/obfs4_meek_snowflake
This repository looks like a fingerprinter for meek, obfs4, and Snowflake, based on the methods of Deep Fingerprinting (ACM CCS 2018).
3726 ClosedWorld_DF_NoDef.py
6212 README.md
3080 environment.yml
256 readme
3556 test_meek.py
3563 test_obfs4.py
3582 test_snow.py
792 模型情况.txt
17454928 models/meek_bk.h5
17454928 models/obfs4_bk.h5
17454928 models/snow_bk.h5
README.md is just an autogenerated GitLab README. The file readme has usage instructions:
- 测试meek模型：python test_meek.py ./data/meek_mix.npz ./models/meek_bk.h5
- 测试obfs4模型：python test_obfs4.py ./data/obfs4_mix.npz ./models/obfs4_bk.h5
- 测试snowflake模型：python test_snow.py ./data/snow_mix.npz ./models/snow_bk.h5
- Test the meek model: python test_meek.py ./data/meek_mix.npz ./models/meek_bk.h5
- Test the obfs4 model: python test_obfs4.py ./data/obfs4_mix.npz ./models/obfs4_bk.h5
- Test the snowflake model: python test_snow.py ./data/snow_mix.npz ./models/snow_bk.h5
The models/*_bk.h5 are included in the repository, but the data/*_mix.npz files are not. The models/*_bk.h5 files are in Hierarchical Data Format, according to file(1). The file 模型情况.txt (model circumstances) gives the training/testing breakdown of each model:
三个模型结构：DF模型 数据长度：前30个包
meek模型 训练：3000个正例（文涛那边的meek流） 30000个负例（崇儒那边的背景tcp流） 测试数据：2200个正例（新捕的meek流）22096个负例（20000个崇儒背景tcp流，2000个obfs4流，96个雪花tcp流）
obfs4模型 训练：20,000个正例（文涛obfs4流） 200,000个负例（崇儒背景tcp流） 测试：20,000个正例（文涛obfs4流）202,296个负例（200,000个崇儒背景tcp流，2200个meek流，96个雪花tcp流）
snowflake模型 训练：2000个正例（1000文涛snowflake流，1000新捕snowflake流） 20000个负例（崇儒背景udp流） 测试：2000个正例（1000文涛snowflake流，1000新捕snowflake流） 20000个负例（崇儒背景udp流）
Three model structures: DF model Data length: First 30 packets
meek model training: 3,000 positive examples (meek traffic from Wentao), 30,000 negative examples (background TCP traffic from Chongru) Test data: 2,200 positive examples (newly captured meek traffic), 22,096 negative examples (20,000 background TCP traffic from Chongru, 2,000 obfs4 traffic, 96 snowflake TCP traffic)
obfs4 model training: 20,000 positive examples (Wentao obfs4 traffic), 200,000 negative examples (background TCP traffic from Chongru) Test data: 20,000 positive examples (Wentao obfs4 traffic), 202,296 negative examples (200,000 background TCP traffic from Chongru, 2,200 Meek traffic, 96 snowflake TCP traffic)
snowflake model Training: 2000 positive examples (1000 Wentao snowflake streams, 1000 newly captured snowflake streams) 20,000 negative examples (Chongru background UDP streams) Testing: 2000 positive examples (1000 Wentao snowflake streams, 1000 newly captured snowflake streams) 20,000 negative examples (Chongru background UDP streams)
It's interesting that they include traffic from other transports as part of the negative samples during testing (e.g. obfs4 and Snowflake as negative examples for meek). I don't know what 文涛 (Wentao), 崇儒 (Chongru), and 新捕 (Xinbu) are. (EDIT: 新捕 = newly captured.)
ClosedWorld_DF_NoDef.py is an edited version of the file of the same name in the deep-fingerprinting/df repository.
test_meek.py, test_obfs4.py, and test_snow.py are all basically the same file, just with a different transport name in each one. These files appear to originate in ClosedWorld_DF_NoDef.py. It looks like these programs apply a model (.h5 file) to test data (.npz file) and report statistics such as precision and recall. They are Python 2 programs, not Python 3.
Like wangmeiqi/obfs4_verify, all the commits in this repository are by meiqi wang <[email protected]> and all occur on 2024-06-28. It looks like student project code, not something operational.
I don't see a reference to Intra in geedge_jira.tar.zst, but there is one issue that references Outline, issues/OSS-378.json. The issue title is 【M22项目】VPN特征提取-宋龙坤 ([Project M22] VPN feature extraction - Song Longkun).
@wkrp thanks for checking. Do you know what the "two valid domain names" is about? As for Intra, I'd guess the drop is just more strict censorship, not really targeting of Intra.
I don't know what 文涛 (Wentao), 崇儒 (Chongru), and 新捕 (Xinbu) are.
The first ones look like ordinary Chinese given name, and the last one is literally newly captured.
- Wang Wentao: https://en.wikipedia.org/wiki/Wang_Wentao
- Chong ru? Literally worshipping Confucianism.
Do you know what the "two valid domain names" is about?
My best guess at what OSS-378 is about is that it has to do with the "mobile device lab" and "static and dynamic analysis" of VPN apps. Like, they search the binary for URLs and IP addresses, then they run the program multiple times to see what DNS queries and network connections it makes.
OSS-378 contains a link to a Confluence document, M22-VPN List.html, which is present in geedge_docs.tar.zst (along with many other pages that have "M22" in the title). "M22-VPN List" seems to contain a giant table of ≈280 VPNs, including Outline, Orbot, Mullvad, and others.
Outline is number 132 on the list, and its priority is high.
| 序号 (number) | 优先级 (priority) | 是否提供特征 (features available) | VPN名称 (VPN name) | 图标 (icon) | 用户提供的链接 (user-provided links) | 官网 (official website) | Android包名 (Android package name) | IOS包名 (iOS package name) | 支持平台（Windows/Android/iOS） (supported platforms) | Windows下载地址 (Windows download address) | Android下载地址 (Android download address) | 最后更新时间（Android） (last updated (Android)) | 最新版本 （Android） (latest version (Android)) | 历史更新时间（apkpure.net） (historical updates (apkpure.net)) | 版本信息 (version information) | 收费情况(完全免费，提供部分免费节点，完全收费) (pricing (fully free, some free nodes available, fully paid)) | 价格(按月计费) (price (monthly)) | 下载量（Android） (downloads (Android)) | 能否使用 (availability) | M现场能否使用 (availability at M-sites (?)) | 备注 (notes) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 132 | 高 (high) | Outline VPN | https://getoutline.org/ | https://getoutline.org/ | Windows/Mac/Android/iOS/Linux/Chrome | https://s3.amazonaws.com/outline-releases/client/windows/stable/Outline-Client.exe | https://play.google.com/store/apps/details?id=org.outline.android.client | 2024-04-15 | 1.13.0 | 2024-04-15 | 1.13.0 | 完全免费 (fully free) | - | 1000k | 是 (yes) | 是 (yes) |
I don't know what 文涛 (Wentao), 崇儒 (Chongru), and 新捕 (Xinbu) are.
The first ones look like ordinary Chinese given name, and the last one is literally newly captured.
- Wang Wentao: https://en.wikipedia.org/wiki/Wang_Wentao
- Chong ru? Literally worshipping Confucianism.
All of them are Chinese given names.
We (@FelixLange1998 and I) would love to look at the ssl/tls files but both the torrent and direct download seem to be quite slow. Did anyone manage to download the whole set of files?
While the censorship infrastructure having the ability to conduct MITM with malicious CAs isn't entirely surprising, a lack of certificate chain hash pinning within graphical clients of encrypted proxies like Xray is quite worrying though, especially when the devices running the encrypted proxy clients on may have been planted malicious CAs that few people bothers to check. The graphical clients and shareable link standards can benefit quite well from supporting hash pinning in my opinion.
- https://web.archive.org/web/20241202193445/http://www.mesalab.cn/ (contains pictures of undergraduates)
So, MESA is abbreviation for Massive Effective Stream Analysis, but the Chinese name is totally unrelated to this but Processing Architecture Group (处理架构组).
I doubt this is imitating the Mesa Laboratory in 1960s, Colorado.
While the censorship infrastructure having the ability to conduct MITM with malicious CAs isn't entirely surprising, a lack of certificate chain hash pinning within graphical clients of encrypted proxies like Xray is quite worrying though, especially when the devices running the encrypted proxy clients on may have been planted malicious CAs that few people bothers to check. The graphical clients and shareable link standards can benefit quite well from supporting hash pinning in my opinion.
我也想过这件事，不过对 Xray-core 来说似乎不太实用，原因有三：
- Xray 主推 REALITY，哪怕是“偷自己”，完全不依赖 CA，可以抵御证书链攻击，就连认证也率先加上了可选的抗量子，TLS 还没有
- 如果要用 CDN，则证书经常换，不同入口节点的证书可能都不同，pin 证书这个方式不太现实
- Xray 正在倡导过 CDN 等场景使用 VLESS Encryption，它遵循非常高的安全标准，可以有效防止被解密/MITM 出被代理的数据
还有就是现在很多直连机场都在使用 REALITY 了，越来越多的 TLS-like 连接正在变得无法被 MITM https://github.com/XTLS/Xray-core/issues/5066#issuecomment-3229899426
此外中转机场的 SS 有被解密后 MITM 内层 TLS 的风险，这个安全漏洞就挺严重的，我可以在这里发一个贴子详细说明
I've considered this too, but it seems impractical for Xray-core for three reasons:
- Xray primarily promotes REALITY. Even when "stealing from itself," it completely bypasses reliance on CAs, defends against certificate chain attacks, and has pioneered optional post-quantum authentication, but TLS hasn’t yet
- If using a CDN, certificates frequently change, and different entry nodes may have different certificates, making certificate pinning impractical.
- Xray is actively promoting VLESS Encryption for scenarios like CDNs. It adheres to very high security standards, effectively preventing decryption/MITM attacks on proxied data.
Additionally, many direct-connect VPNs now use REALITY, making TLS-like connections increasingly resistant to MITM attacks: https://github.com/XTLS/Xray-core/issues/5066#issuecomment-3229899426
Furthermore, relay-based VPNs like Shadowsocks carry the risk of MITM attacks on the inner TLS layer after decryption. This security vulnerability is quite severe—I can post a detailed explanation here.
如果要用 CDN，则证书经常换，不同入口节点的证书可能都不同，pin 证书这个方式不太现实
可能 pin root 证书好一点，我不确定 Xray 现有的 PinnedPeerCertificateChainSha256 PinnedPeerCertificatePublicKeySha256 是否支持
不过套 CDN 总归是建议用 VLESS Encryption 的，那就无所谓，~~我觉得是时候把单纯的 TLS / QUIC 也列为“不够安全”了~~
If using a CDN, certificates frequently change, and different entry nodes may have different certificates, making certificate pinning impractical.
Pinning the root certificate might be better, though I'm unsure if Xray's existing PinnedPeerCertificateChainSha256 and PinnedPeerCertificatePublicKeySha256 support this.
However, when using a CDN, it's generally recommended to employ VLESS Encryption, so it doesn't really matter. ~~I think it's time to classify plain TLS/QUIC as "insufficiently secure" too.~~
Maybe pinning the root certificate is better. I'm not sure if Xray's existing PinnedPeerCertificateChainSha256 and PinnedPeerCertificatePublicKeySha256 support it.
@RPRX That's exactly what I'm thinking, pinning only the possible root certificates. Cloudflare has LE, GTS, Sectigo and SSL.com, CloudFront uses Amazon's internal service, Fastly uses Certainly... So on and so forth. REALITY isn't exactly applicable when it's needed to pair with standard web infrastructure, so root certificate pinning would be quite preferable for clients to have, especially for the shareable links. Regarding VLESS encryption... I'd advocate for it to be used whenever third-party infrastructure is needed, but if TLS could be decrypted by the censors in the first place, then we'll have the dilemma that Shadowsocks et al have. Web infrastructure providers like CDNs can care less though.
@PoneyClairDeLune 不过 pin 这件事其实很难推动，我认为更根本的解决方案是不应继续将 TLS / QUIC 视为可靠的加密方式 https://github.com/net4people/bbs/issues/526
However, pinning is actually quite difficult to implement. I believe the more fundamental solution is to stop treating TLS/QUIC as reliable encryption methods https://github.com/net4people/bbs/issues/526
I don't know what 文涛 (Wentao), 崇儒 (Chongru), and 新捕 (Xinbu) are.
The first ones look like ordinary Chinese given name, and the last one is literally newly captured.
- Wang Wentao: https://en.wikipedia.org/wiki/Wang_Wentao
- Chong ru? Literally worshipping Confucianism.
Nah, you are overthinking They are actually Mandarin first name
So, MESA is abbreviation for Massive Effective Stream Analysis, but the Chinese name is totally unrelated to this but Processing Architecture Group (处理架构组).
That's right. MESA (处理架构组) is one of several groups (组) inside the 2nd Research Lab (第二研究室) of the Institute of Information Engineering. The 2nd Lab is called NERCIS, National Engineering Research Center of Information Security (信息内容安全国家工程研究中心), but until recently it was called NELIST, National Engineering Laboratory for Information Security Technologies (信息内容安全技术国家工程实验室).
An online post lists the research groups (研究组) and topic groups (课题组) in the 2nd Lab:
- 信息检索研究组 (information retrieval research group)
- 社会计算课题组 (social computing topic group)
- Web 挖掘课题组 (web mining topic group)
- 知识挖掘课题组 (knowledge mining topic group)
- 内容计算课题组 (content computing topic group)
- 前瞻技术课题组 (forward-looking technologies topic group)
- 网络信息对抗课题组 (cyber information countermeasures topic group)
- 保密防护课题组 (confidentiality protection topic group)
- 网络安全课题组 (network security topic group)
- 数据管理课题组 (data management topic group)
- 处理架构组 (processing architecture group, MESA)
While the censorship infrastructure having the ability to conduct MITM with malicious CAs isn't entirely surprising, a lack of certificate chain hash pinning within graphical clients of encrypted proxies like Xray is quite worrying though, especially when the devices running the encrypted proxy clients on may have been planted malicious CAs that few people bothers to check. The graphical clients and shareable link standards can benefit quite well from supporting hash pinning in my opinion.
I don't think an installed CA would even be trusted by Golang or Rust executable. Even native Android app won't trust CAs in user storage by default (Google Play would complain this if developer had this in Network Security Config).
For iOS, it depends on TLS library, Shadowrocket seems to use OpenSSL by default instead of system's SecureTransport, so unaffected too.
The file “96711429_attachments_石逢钊-加密流量识别简述” from mesalab_docs.tar.zst’s study/attachments looks interesting to me. It seems to be the tech ground for GFW to identify encrypted data (it’s a survey/overview, not a design spec).
It lists the following as tech reference:
- FS-Net: A Flow Sequence Network for Encrypted Traffic Classification
- Deep fingerprinting: Undermining website fingerprinting defenses with deep learning
- service usage classification with encrypted internet traffic in mobile messaging apps
The first thing I found interesting is that the paper “FS-Net: A Flow Sequence Network for Encrypted Traffic Classification” utilizes packet length and order as information for classifying encrypted traffic (FS‑Net explicitly takes packet‑length sequences as input and models their sequence with bi‑GRUs/encoder‑decoder).
This pattern matches Diwen Xue’s finding in “Fingerprinting Obfuscated Proxy Traffic with Encapsulated TLS Handshakes,” which identifies TLS‑over‑TLS by patterns in packet length, timing, and direction that remain visible post‑encryption. Although they employ different classification methods, both use packet size and order as key features.
I’ll keep digging into these three papers and see if they align with current GFW design and share my thoughts here :)
“识别时序特征”也不是新闻了，多一层加密对此几乎没有帮助，对于 Trojan 这样的无需深度学习就能识别 TLS in TLS：Trojan-killer
更值得关注的是“网站/App 指纹识别”，这个要做到精准可用挺难的（无 SNI 时），根据 GFW 对 ECH 的态度，可能进展不多，这也是业界继 ECH 之后着力解决的下一个问题，一个比较有意义的现实事件是“ChatGPT padding”，不过它的前提也是针对了特定的 SNI
“Identifying temporal patterns” is hardly news anymore, and adding another layer of encryption offers almost no benefit. For Trojans that don't require deep learning to detect TLS-in-TLS: Trojan-killer
More noteworthy is “website/app fingerprinting,” which is challenging to implement accurately and reliably (without SNI). Given the GFW's stance on ECH, progress may be limited. This is the next major problem the industry is tackling after ECH. A relatively significant real-world example is the “ChatGPT padding” incident, though it also targeted a specific SNI.
The file “96711429_attachments_石逢钊-加密流量识别简述” from
mesalab_docs.tar.zst’sstudy/attachmentslooks interesting to me. It seems to be the tech ground for GFW to identify encrypted data (it’s a survey/overview, not a design spec).
@SaamoCha good find!
Deep Fingerprinting is the apparent basis for the wangmeiqi/obfs4_meek_snowflake repository in mesalab_git.tar.zst.
FS-Net is one of the highly cited MESA publications. (ET-BERT, also on the topic of encrypted traffic classification, is another.) The authors of FS-Net are all IIE or MESA people:
- 刘畅 (Liu Chang) dblp
- 贺龙涛 (He Longtao) homepage dblp
- 熊刚 (Xiong Gang) mesalab.cn profile homepage dblp
- 曹自刚 (Cao Zigang) dblp
- 李镇 (Li Zhen) homepage dblp
熊刚 (Xiong Gang) is probably the most famous of the authors. He even has an article on the Chinese Wikipedia that talks about his involvement in the GFW: https://zh.wikipedia.org/wiki/熊刚.
Another MESA student, 何正杰 (He Zhengjie), has a blog with a few posts that mention FS-Net and other encrypted traffic classification research:
- 2021-02-12 流量识别概述 (archive) Flow identification overview
- 2020-10-18 DataCon加密流量参赛总结 (archive) Summary of DataCon encrypted data competition
I skimmed over the TLS/QUIC parsing files in MESA_Platform.
From what I can tell, their TLS parsing (in ssl.bundle) supports TLS record fragmentation, extracts hostnames from SNI, and also detects ESNI and ECH.
Interestingly, both of their quic parsers (quic.bundle and gquic.bundle) have unique functions to extract the hostname from the SNI, they are different from each other and from the hostname extraction in their TLS parsing
Interestingly, both of their quic parsers (quic.bundle and gquic.bundle) have unique functions to extract the hostname from the SNI, they are different from each other
We know that there are differences in the many DNS parsers that operate in different places in the Great Firewall, which have detectable differences in how they parse DNS messages (whether they follow name compression pointers, for example, and in how they interpret flags). Does it look like there are similar detectable parsing differences in the two QUIC SNI parsers? The idea would be to craft a QUIC message that is parsed by one and not the other, to make it possible to remotely identify which of the parsers is operational. Like "Triplet Censors" Section 4.1, or "Even Censors Have a Backup".
Some things to try with regard to SNI parsing:
- Varying letter case:
ExAmPlE.cOM - Leading and trailing whitespace
example.comexample.comexample.com - Trailing dot:
example.com.or even just a single dot. - Empty labels:
example..com - IP addresses, with and without port number, with and without brackets in the case of IPv6:
192.0.2.1192.0.2.1:4432001:db8::1[2001:db8::1][2001:db8::]:443 - Labels longer than 63 bytes:
0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdeXXXXXXXXXX.example.com - Very long SNI (e.g. 1024 bytes or more), designed to test if the parser has a fixed-length buffer
- Two different server_name extensions in the same handshake message (maybe the parser prefers the first or the last)
Do you find a table of initial_salts? As in https://github.com/net4people/bbs/issues/468#issuecomment-2779728140.
https://datatracker.ietf.org/doc/html/rfc9001/#section-5.2
initial_salt = 0x38762cf7f55934b34d179ae6a4c80cadccbb7f0a
https://datatracker.ietf.org/doc/html/rfc9369/#section-3.3.1
initial_salt = 0x0dede3def700a6db819381be6e269dcbf9bd2ed9
P.S. There's also stellar/quic_decoder. Stellar is mentioned in footnote 10 on page 24 of the InterSecLab report.
From what I can tell, their TLS parsing (in ssl.bundle) supports TLS record fragmentation, extracts hostnames from SNI, and also detects ESNI and ECH.
Geedge’s architecture is now showing signs of tight coupling between DPI, SNI extraction(https://github.com/net4people/bbs/issues/526 ), session correlation, and per-user targeting, I’m increasingly concerned that every visible handshake is already a compromise.
Strategically, I’d argue more energy on architectures that bypass the inspection surface entirely — via out-of-band TLS, ephemeral circuits, or mesh overlays, rather than trying to guess what the censor is willing to tolerate this week or next.
Do you find a table of initial_salts? As in https://github.com/net4people/bbs/issues/468#issuecomment-2779728140.
Yes, for quic.bundle its
const quic_str_t initial_salt_v1 = quic_string(
"\x38\x76\x2c\xf7\xf5\x59\x34\xb3\x4d\x17\x9a\xe6\xa4\xc8\x0c\xad\xcc\xbb\x7f\x0a");
const quic_str_t initial_salt_draft_22 = quic_string(
"\x7f\xbc\xdb\x0e\x7c\x66\xbb\xe9\x19\x3a\x96\xcd\x21\x51\x9e\xbd\x7a\x02\x64\x4a");
const quic_str_t initial_salt_draft_23 = quic_string(
"\xc3\xee\xf7\x12\xc7\x2e\xbb\x5a\x11\xa7\xd2\x43\x2b\xb4\x63\x65\xbe\xf9\xf5\x02");
const quic_str_t initial_salt_draft_29 = quic_string(
"\xaf\xbf\xec\x28\x99\x93\xd2\x4c\x9e\x97\x86\xf1\x9c\x61\x11\xe0\x43\x90\xa8\x99");
const quic_str_t initial_salt_draft_q50 = quic_string(
"\x50\x45\x74\xEF\xD0\x66\xFE\x2F\x9D\x94\x5C\xFC\xDB\xD3\xA7\xF0\xD3\xB5\x6B\x45");
const quic_str_t initial_salt_draft_t50 = quic_string(
"\x7f\xf5\x79\xe5\xac\xd0\x72\x91\x55\x80\x30\x4c\x43\xa2\x36\x7c\x60\x48\x83\x10");
const quic_str_t initial_salt_draft_t51 = quic_string(
"\x7a\x4e\xde\xf4\xe7\xcc\xee\x5f\xa4\x50\x6c\x19\x12\x4f\xc8\xcc\xda\x6e\x03\x3d");
and for gquic.bundle its
static const guint8 handshake_salt_draft_22[20] = {
0x7f, 0xbc, 0xdb, 0x0e, 0x7c, 0x66, 0xbb, 0xe9, 0x19, 0x3a,
0x96, 0xcd, 0x21, 0x51, 0x9e, 0xbd, 0x7a, 0x02, 0x64, 0x4a
};
static const guint8 handshake_salt_draft_23[20] = {
0xc3, 0xee, 0xf7, 0x12, 0xc7, 0x2e, 0xbb, 0x5a, 0x11, 0xa7,
0xd2, 0x43, 0x2b, 0xb4, 0x63, 0x65, 0xbe, 0xf9, 0xf5, 0x02,
};
static const guint8 handshake_salt_draft_29[20] = {
0xaf, 0xbf, 0xec, 0x28, 0x99, 0x93, 0xd2, 0x4c, 0x9e, 0x97,
0x86, 0xf1, 0x9c, 0x61, 0x11, 0xe0, 0x43, 0x90, 0xa8, 0x99
};
static const guint8 handshake_salt_v1[20] = {
0x38, 0x76, 0x2c, 0xf7, 0xf5, 0x59, 0x34, 0xb3, 0x4d, 0x17,
0x9a, 0xe6, 0xa4, 0xc8, 0x0c, 0xad, 0xcc, 0xbb, 0x7f, 0x0a
};
static const guint8 hanshake_salt_draft_q50[20] = {
0x50, 0x45, 0x74, 0xEF, 0xD0, 0x66, 0xFE, 0x2F, 0x9D, 0x94,
0x5C, 0xFC, 0xDB, 0xD3, 0xA7, 0xF0, 0xD3, 0xB5, 0x6B, 0x45
};
static const guint8 hanshake_salt_draft_t50[20] = {
0x7f, 0xf5, 0x79, 0xe5, 0xac, 0xd0, 0x72, 0x91, 0x55, 0x80,
0x30, 0x4c, 0x43, 0xa2, 0x36, 0x7c, 0x60, 0x48, 0x83, 0x10
};
static const guint8 hanshake_salt_draft_t51[20] = {
0x7a, 0x4e, 0xde, 0xf4, 0xe7, 0xcc, 0xee, 0x5f, 0xa4, 0x50,
0x6c, 0x19, 0x12, 0x4f, 0xc8, 0xcc, 0xda, 0x6e, 0x03, 0x3d
};
Only quic.bundle seems to have the v1 salt, both do not have the v2 salt but they might have updated since...
Does it look like there are similar detectable parsing differences in the two QUIC SNI parsers?
After a second look, both SNI parsers (quic.bundle and gquic.bundle) seem to parse the SNI the same way although their code is different:
- verify that the
server_name_list_lengthis present and not longer than the remaining bytes - verify that the
server_name_typeis0x00(indicating a hostname) - verify that the
server_name_lengthis present and not longer than the remaining bytes - parse
server_name_lengthmany bytes into the SNI field of the CH struct
The SNI parser of the TLS implementation works differently: It iterates over all entries in the server_name_list and parses the first entry with a server_name_type that is 0x00, ignoring all others. Thus, preceding the actual server_name with another server_name that has a server_name_type other than 0x00 circumvents the quic parsers but not the TLS parser.
For further differences (i.e., parsing differences in the ClientHello message), I have to spend more time reading the source code / running the code, and testing it with our tools.
Testing different hostnames in the SNI would not yield different results for the parsers in quic.bundle, gquic.bundle, and ssl.bundle, as they only parse the SNI value into a struct. They do not compare the parsed value against a list of hostnames, nor do they make a censorship decision. Testing things such as long SNI etc,. could yield different results!
A Statement on Project Integrity, Partnership Governance, and the IIE Incident
Introduction
In recent weeks, a significant amount of public attention has been directed toward a data leak involving one of our long-term academic partners. This event has spurred a great deal of speculation. However, we feel it is necessary to state unequivocally that the public discourse has so far missed the true gravity of the situation. The data leak, while representing a regrettable lapse in operational security, is merely a symptom. The disease—the issue that we are treating with the utmost seriousness—is a profound breach of professional ethics, a violation of foundational trust, and the calculated misappropriation of core intellectual property by our partner, the Institute of Information Engineering (IIE) of the Chinese Academy of Sciences.
The purpose of this document is to provide a clear, factual account of this incident from our perspective as the project’s core engineering and management team. We will outline the history of our collaborative model, detail the precise nature of IIE’s transgression, articulate our unshakeable position on the principles that have been violated, and describe the decisive, system-wide measures we are now implementing to rectify the damage and ensure the absolute integrity of our project going forward. This is not a public relations exercise; it is a declaration of principles and a blueprint for action.
Part 1: The Context of Our Collaborative R&D Model
No engineering project of this scale, complexity, and strategic importance can be built in a vacuum. The breadth of expertise required—from theoretical cryptography and protocol analysis to hardware acceleration and large-scale systems engineering—is far too vast to be housed within a single organization. From our inception, we understood that success would depend on our ability to build a robust, decentralized network of trusted collaborators, drawing on the best minds from academia, research institutions, and, where appropriate, the commercial sector.
Our relationship with the entities that would eventually form the IIE began nearly two decades ago, in the early 2000s. In those formative years, the challenges were more tactical, and our collaborations were correspondingly ad-hoc. When faced with a specific algorithmic problem—be it a novel encryption scheme or a new network protocol—we would engage directly with top individual laboratories, such as the State Key Laboratory of Information Security (housed within the Institute of Software, CAS) or specialized teams at the Institute of Computing Technology. The terms of engagement were simple and clean: we provided the real-world engineering problem and the necessary data; they provided the academic solution, often in the form of a research paper and a proof-of-concept algorithm. It was a straightforward, project-based model.
By 2011, the technological landscape had grown orders of magnitude more complex. The rise of sophisticated encryption and protocol obfuscation techniques meant that our reactive, project-by-project approach was no longer sufficient. We required a partner capable of sustained, long-term, and systemic research. It was against this backdrop that the national leadership made the strategic decision to consolidate the country’s top information security research talent from various CAS institutes into a single, focused entity: the Institute of Information Engineering (IIE). Its mission was explicit: to serve as a dedicated, national-level “Institute of Theory and Algorithms” for our project and others like it.
Following its establishment, our collaboration with IIE entered a highly productive “honeymoon period.” We invested heavily in the partnership, providing substantial funding, priority access to complex challenges, and vast datasets. In return, IIE delivered significant theoretical breakthroughs that were critical to our progress. It was during this period that a certain “tacit understanding” (默许) developed. We permitted—and, by our lack of objection, implicitly encouraged—IIE to commercialize some of the derivative research that emerged from our collaboration.
The rationale seemed sound at the time. We believed it would serve as a powerful incentive, helping IIE attract and retain world-class talent and allowing researchers to see their work have a broader impact. We viewed it as a symbiotic relationship: our real-world problems would fuel their academic inquiry, and their commercial successes, properly firewalled from our core mission, would be a testament to the high caliber of their work. We operated on the assumption of good faith—that a clear, professional line existed between the commercialization of one’s own intellectual derivations and the proprietary, mission-critical assets of the parent project.
That assumption has proven to be catastrophically wrong.
Part 2: The Breach: From Tacit Understanding to Malicious Misappropriation
The recent data leak, for all the attention it garnered, was merely the loose thread that, when pulled, unraveled a much darker reality. The leaked files provided the catalyst for a full-scale internal investigation, including a meticulous forensic analysis of the code lineage of IIE’s commercial products. What our technical teams discovered was not a minor overstep or a misunderstanding of an informal agreement. It was a calculated, systematic, and shameless act of intellectual property theft on an industrial scale.
Let us be perfectly clear. The code found within IIE’s commercial security products was not “based on,” “inspired by,” or “derived from” their research for us. In numerous, critical instances, the code was a direct, line-for-line copy-paste of our proprietary, operational code from our core engineering environment. This is code that was developed in-house, by our teams, to manage the most sensitive functions of our system. It was shared with IIE under the strictest of confidentiality agreements for the sole purpose of joint research and development.
They took this trusted asset and sold it.
This is not the commercialization of academic research; it is the theft of a state-level engineering asset. This is not a matter of “plagiarizing” a paper; it is the equivalent of a defense contractor stealing the blueprints for a classified project and selling them on the open market. The act is a flagrant violation of every professional and ethical norm that underpins high-security collaborative work.
The damage, however, extends far beyond our own project. Our system is a highly complex aggregation of technologies, integrating specialized modules from a wide array of partners. In stealing and exposing large blocks of our integrated code, IIE has also exposed the technical fingerprints, proprietary algorithms, and unique coding styles of numerous other collaborators—universities and even commercial vendors who have upheld their agreements with integrity.
IIE’s recklessness has created a catastrophic chain reaction, dragging innocent and trusted partners into the fallout of their malfeasance. They have not only betrayed our trust; they have jeopardized the security and confidentiality of the entire collaborative ecosystem we have spent two decades building. This is a critical supply-chain security failure, initiated by a malicious actor who was meant to be one of our most trusted guards.
Part 3: Our Position and The Principles at Stake
Our response to this situation is not driven by the public embarrassment of a data leak. We are a technical organization; we understand that security incidents are a statistical inevitability. Our response is driven by a cold fury over a fundamental betrayal of trust.
This incident is an attack on the very foundation of our development model. We work with external partners by extending a hand of trust, granting them access to our most difficult problems and sensitive data. We do so with the explicit understanding that they are partners in a shared mission, bound by rules both written and unwritten. The principle is simple: a partner’s role is to contribute to the project’s strength and success.
IIE chose to act not as a partner, but as a parasite. They viewed our core assets not as a shared responsibility, but as a resource to be plundered for their own commercial benefit. This transforms the relationship from a symbiotic one into an adversarial one. When a collaborator, given the keys to the kingdom, begins melting down the crown jewels to sell the gold, the partnership is not merely broken; it is revealed to have been a charade.
This is why we view this transgression with such severity. It is not a contractual dispute to be mediated by lawyers. It is a fundamental violation of the principles of integrity, confidentiality, and professional honor. Allowing it to pass without a decisive and severe response would be an invitation for every other partner to question the rules, and it would signal that our project’s core assets are, in fact, open for exploitation. That will not happen.
Part 4: The Path Forward: A System-Wide Rectification
The leadership’s deliberations on this matter are concluded, and our path forward is clear and resolute. The goal is not simply to punish a single transgression, but to fundamentally overhaul our partnership governance framework to ensure this can never happen again. The following measures are being implemented immediately:
1. Complete Re-evaluation of the IIE Partnership: The collaborative relationship between our project and the Institute of Information Engineering is suspended, effective immediately. All joint projects are frozen, all data-sharing has ceased, and their access to our systems has been revoked. A full-scale review is underway to determine the total extent of the IP theft and to decide on the final disposition of the partnership, which will include, at a minimum, severe contractual and financial penalties, and likely its permanent termination.
2. System-Wide Partner IP Audit: We are initiating a mandatory, comprehensive audit of the intellectual property and codebases of all external partners. This intrusive but necessary step will verify the provenance of all code within our ecosystem and ensure there are no other instances of misappropriation. We will work with our trusted partners to make this process as efficient as possible, but it is non-negotiable.
3. A New Framework for Partnership Governance: The era of “tacit understandings” is over. We are drafting a new, legally binding partnership framework that will be a prerequisite for any future collaboration. Key features will include: A Zero-Tolerance Policy: The commercialization of any project-related technology, research, or code—derivative or otherwise—will be explicitly forbidden without a formal, written, case-by-case review and approval process at the highest levels. Ironclad IP Clauses: All contracts will feature brutally clear clauses on the ownership of intellectual property, with predefined, severe penalties for any breach. Mandatory Provenance and Audits: All partners will be required to maintain strict code provenance records. We will reserve the right to conduct regular, no-notice security and code audits, performed by our own teams or trusted third parties.
4. Unambiguous Accountability: The consequences for IIE will be designed to serve as an unmistakable precedent. We will make it clear to our entire ecosystem that the cost of violating our trust and stealing our assets is intolerably, prohibitively high.
Conclusion
This has been a deeply damaging episode. It was a betrayal by a partner we helped create and empower. However, our project is defined not by the challenges we face, but by how we respond to them. This incident, for all the harm it has caused, will ultimately serve as a crucible. It has forced us to confront a fundamental weakness in our governance model, and in doing so, it has given us the mandate to forge a stronger, more secure, and more disciplined engineering culture.
We are cleaning our house. We are reinforcing our foundations. The integrity of this project and the security of its core assets are absolute and non-negotiable. Our focus is renewed, and our resolve is hardened. The work continues.
This is not a public relations exercise; it is a declaration of principles and a blueprint for action. What our technical teams discovered was not a minor overstep or a misunderstanding of an informal agreement. It was a calculated, systematic, and shameless act of intellectual property theft on an industrial scale. Part 1: The Context of Our Collaborative R&D Model Part 2: The Breach: From Tacit Understanding to Malicious Misappropriation Part 4: The Path Forward: A System-Wide Rectification
Stop using LLM to fake things
