能否逆向工程或重放WebRTC连接以自研Discord Go Live API？

Great question—let’s break this down into two parts: how WebRTC compares to HTTP for reverse-engineering, and how this applies to building a custom API for Discord’s Go Live feature.

WebRTC vs. HTTP: Reverse-Engineering & Replay Differences #

HTTP is a stateless request-response protocol with clear, repeatable text-based messages (like GET/POST payloads) that are easy to capture, replay, and reverse-engineer. WebRTC is far more complex because it’s a peer-to-peer (P2P) protocol with two distinct layers:

• Signaling Layer: This is the "control plane" that handles session setup (SDP offers/answers), ICE candidate exchange, and connection metadata. Signaling is almost always transported over HTTP/WebSocket (since browsers can’t directly open P2P connections without a middleman). This layer can be reverse-engineered, as it uses structured text (usually JSON) that’s easy to capture and analyze.
• Media Layer: This is the "data plane" for audio/video streams, sent over UDP with DTLS encryption. Each WebRTC session uses unique cryptographic keys, dynamic ICE candidates, and session IDs—so replaying media streams is effectively impossible. You can’t just "replay" a past media packet to establish a new connection.

Applying This to Discord Go Live #

Discord’s Go Live relies on WebRTC, but all the critical "API-like" actions (starting a stream, configuring its settings, joining a stream) happen in the signaling layer (via Discord’s WebSocket gateway). Here’s how you can leverage reverse-engineering for a custom API:

1. Capture & Analyze Discord’s WebSocket Signaling #

• Use your browser’s DevTools (Network tab > WebSockets) or tools like Wireshark to capture traffic when you start a Go Live stream in Discord. Look for the gateway connection (usually wss://gateway.discord.gg/) and inspect the messages sent/received.
• You’ll find structured JSON payloads for actions like:
  • Initiating a live stream (including guild ID, channel ID, stream resolution/framerate)
  • Exchanging SDP offers/answers (Discord may tweak standard SDP with custom flags for Go Live)
  • ICE candidate updates (to establish the P2P media path)
  • Stream state updates (like pausing/resuming or ending the stream)

2. Reconstruct the API Workflow #

Once you understand the message formats and sequence, you can construct your own requests to mimic Discord’s client behavior:

• Authenticate with Discord’s gateway using a valid user token (you’ll need to handle heartbeat events to keep the connection alive, per Discord’s gateway specs).
• Send a custom payload to initiate a Go Live stream, following the structure you captured (e.g., specifying the target voice channel and stream parameters).
• Handle the server’s SDP answer and ICE candidates to establish the WebRTC media connection with your own streaming client.

3. Key Limitations to Note #

• Protocol Changes: Discord regularly updates its gateway protocol, so your reverse-engineered API may break without warning.
• Compliance: Discord’s Terms of Service may prohibit reverse-engineering their private APIs—make sure you’re aware of the risks before building anything.
• Media Stream Complexity: While you can control the stream’s lifecycle via signaling, actually sending/receiving encrypted media requires implementing full WebRTC stack logic (DTLS, SRTP, codec handling) which is non-trivial.

Final Verdict #

You can reverse-engineer the signaling layer of WebRTC (which is what matters for building a Go Live API) in much the same way you’d reverse-engineer HTTP APIs. The media layer can’t be replayed, but that’s not necessary for controlling stream creation, configuration, or membership. Focus on capturing and replicating Discord’s WebSocket signaling messages, and you’ll be able to build a custom API for Go Live functionality.

内容的提问来源于stack exchange，提问作者Dave