Let's Reverse Engineer Discord • Hacker News Board

Re: Let's Reverse Engineer Discord

#111

Post by duskwuff » Mon, Jan 13, 2020, 8:51 PM UTC

caffeinewriter wrote: post #106

jagger27 wrote: post #102

Earlier quoted context omitted.

Wouldn’t it be possible to send a stream cipher encrypted packet of audio to a hub server where the codec has a “progressive” decoding mode? If I’m not mistaken, Opus can already do something like this. That way a client could set their desired bitrate and the server would truncate the packets before passing them off and doesn’t need to be re-encoded. This only works with a stream cipher though. Maybe an audio engine…

It looks like Ogg Vorbis has theoretical support in the spec for something called "Bitrate Peeling"[1], but there is no functional implementation for this yet, and there's been an open bounty on it since 2004.[2] This is a really neat idea though. Truncating the packet to change the bitrate per client without re-encoding. [1]: https://en.wikipedia.org/wiki/Bitrate_peeling [2]: https://wiki.xiph.org/index.php?title=Bo…

Peeling has been a goal for many audio/video codecs in the past. Nobody's been able to make it work acceptably, though -- either the low-bitrate version sounds awful, or the high-bitrate version increases in size to the point that it might as well just have a low-bitrate version alongside it.

Re: Let's Reverse Engineer Discord

#112

Post by gfodor » Mon, Jan 13, 2020, 8:55 PM UTC

gzer0 wrote: post #100

gfodor wrote: post #83

Earlier quoted context omitted.

No, it’s not, because PERC is a proposal and is not implemented in any browsers.

That does not mean it isn't possible; the implementation simply has not occurred.

That’s a pretty unique definition of “possible!”

You can just admit you googled it and didn’t realize it was not something you can do today in browsers, it’s ok :)

Re: Let's Reverse Engineer Discord

#113

Post by ianlevesque » Tue, Jan 14, 2020, 1:51 AM UTC

gfodor wrote: post #112

gzer0 wrote: post #100

Earlier quoted context omitted.

That does not mean it isn't possible; the implementation simply has not occurred.

That’s a pretty unique definition of “possible!” You can just admit you googled it and didn’t realize it was not something you can do today in browsers, it’s ok :)

You must be new here ;)

Re: Let's Reverse Engineer Discord

#114

Post by jagger27 » Tue, Jan 14, 2020, 3:17 AM UTC

duskwuff wrote: post #111

caffeinewriter wrote: post #106

Earlier quoted context omitted.

It looks like Ogg Vorbis has theoretical support in the spec for something called "Bitrate Peeling"[1], but there is no functional implementation for this yet, and there's been an open bounty on it since 2004.[2] This is a really neat idea though. Truncating the packet to change the bitrate per client without re-encoding. [1]: https://en.wikipedia.org/wiki/Bitrate_peeling [2]: https://wiki.xiph.org/index.php?title=Bo…

Peeling has been a goal for many audio/video codecs in the past. Nobody's been able to make it work acceptably, though -- either the low-bitrate version sounds awful, or the high-bitrate version increases in size to the point that it might as well just have a low-bitrate version alongside it.

So in that case you could peel off whichever stream you don’t need, but you waste some upload bandwidth over simply negotiating a bitrate in advance.

Re: Let's Reverse Engineer Discord

#115

Post by Mandatum » Tue, Jan 14, 2020, 4:10 AM UTC

bgitarts wrote: post #68

Just because invalid encrypted data is being dropped doesn't automatically mean the server is decrypting the data. It's possible to verify an encrypted message is valid without seeing it's content.

It's not possible to validate a message without decrypting it. You can verify a signed message, if that's what you mean?

This proves parsing or filtering is happening on Discord's end to the decrypted message.