Part 2 of 3 in the TRAE Agent Reverse Engineering Series
In Part 1, I discovered TRAE's custom protocol trae://trae.ai-ide/agent/share/{AGENT_ID}, but browser DevTools couldn't monitor system-level protocol handlers. Time to bring out the big guns.
Enter Fiddler: Time for System-Level Monitoring
I’m not one of those CTF fanatics who live for inspecting every network packet (thankfully), but I realized I needed system-level network monitoring. Without batting an eye, I installed Fiddler Classic for the first time—and from there on, it was pretty self-explanatory.
The Configuration
- Tools → Options → HTTPS tab
- Check "Capture HTTPS CONNECTs" & "Decrypt HTTPS traffic"
- Click "Yes" to install Fiddler Root Certificates (necessary for decrypting HTTPS traffic)
Monitoring the Traffic
- Verify that "File → Capture Traffic" is checked (should be by default)
- Clear existing traffic: Edit → Remove → All Sessions (or CTRL+X)
Triggering the Request (TRAE Protocol)
- Open CMD (Win+R,
cmd, enter) - Type
start trae://trae.ai-ide/agent/share/337fa4 - Enter - You should see the agent loaded in your TRAE IDE
Second Breakthrough: Agent Icons Revealed
My first captured request read:
Result: 200 (OK)
Protocol: HTTPS
Host: p16-trae-material-sign-va.ibyteimg.com
URL: https://p16-trae-material-sign-va.ibyteimg.com/tos-maliva-i-traematerial-us/agent_avatar/random/image/<longImageUUID>.png?...
Body: 6,409 bytes
Content-Type: image/png
Process: trae:3220
Jackpot! Another breakthrough—I'd discovered how to get Agent Icons with ease. Looking at the URL, it includes x-expires and a signature, indicating that the images are signed and temporary, possibly to prevent hotlinking. hmm...
I won't lie—I'm a bit surprised that TRAE doesn't use its own CDN (they're using ibyteimg.com).
(This is me from later down the line, turns out they do use their own CDN, just not under their own domain, rather under ByteDance according to Netlify.ai.)
The 2-Hour Nightmare: A Mysterious Proxy
Just when everything seemed to be going smoothly, I hit another massive roadblock:
Result: 502 (Bad Gateway)
Protocol: HTTP
Host: Tunnel to localhost:5173
URL: Tunnel to localhost:5173
Body: 512 bytes
Content-Type: text/html; charset=UTF-8
Process: trae:3220
What seemed like another local server proxy turned out to be a nightmare that consumed no less than 2 hours. I tried my best figuring out why these requests were failing, WHAT this proxy was all to no avail!
I decided to feed my delusions so I could finally go back to sleep. I told myself:
"Thelocalhost:5173is just a 'man in the middle.' It receives thetrae://protocol, then makes an internal API call to get the agent's full data fromapi.trae.ai."
But why was it failing? Was it misconfigured? Was I doing something wrong?
None of it mattered—I was tired. I started closing my IDE, browser, and all other programs... until I saw it.
I had a CORS bypass proxy running on localhost:5173.
*sighs*
I knew very well that my curiosity wouldn't let me sleep! So here we are, back to hacking away at this thing for absolutely no reason!
Success: The Real API Calls Emerge
After retrying the entire process with the CORS bypass proxy turned off, my Fiddler request showed:
Result: 200 (OK)
Protocol: HTTPS
Host: api.trae.ai
Body: 0
Process: trae:3220
Encrypted HTTPS traffic flows through this CONNECT tunnel. Since HTTPS Decryption is enabled in Fiddler, the decrypted sessions running in this tunnel appear in the web session list.
Finally, the real API calls appeared... but this was just the beginning. The actual treasure—the agent data itself—was still locked behind authentication tokens and API endpoints I had yet to discover.
Next Steps: Part 3: The API Treasure Hunt →
Ready for the (hopefully) final showdown? The next post continues the investigation into TRAE’s agent sharing mechanism and dives into the API layer.
Series Navigation:
- Part 1: When 1AM Curiosity Meets CTF Skills
- Part 2: Fiddler, Proxies, and Network Analysis ← You are here
- Part 3: The API Treasure Hunt