Firstly I don't want to play vulnerability Olympics. Zoom does lots of things wrong, it should fix all of them, and its users are right to complain at each of them, I don't understand any value from trying to pick some of them as "less bad" based on tenuous claims about what you think might or might not be possible in other domains like video encoding.

> In that context 'I-frames might be both identical and magically align' seems even more contrived than the already more-famous-than-informative penguin.

Did you take a look at an actual H.264 video stream of something boring?

I downloaded a random example of an H.264 video of the generic movie lead-in you've seen a million times where giant numerals appear in descending sequence. The sequence repeats itself several times, allowing us to compare I-frames each time.

Let me quote from the first time a giant numeral two is displayed - briefly in hexadecimal:

> fc fe 7f 3f 9f cf e7 f3 f9 fc fe 7f 3f 9f cf e7

That's not encrypted, but on the other hand I also don't understand what it means because I am not an H.264 decoder. So an ECB encoded block would be just as meaningful to me.

Of course, we'd only get the same exact ECB encoded block if the input was the same... a few seconds later another I-frame of the same giant numeral two and:

> fc fe 7f 3f 9f cf e7 f3 f9 fc fe 7f 3f 9f cf e7

Ah. Well, maybe it's just a fluke? A few seconds later the same number is featured in the I-frame again and...

> fc fe 7f 3f 9f cf e7 f3 f9 fc fe 7f 3f 9f cf e7

Maybe I got real stupid in my old age but I think what's going on here is exactly what I already told you to expect. Given the same input the H.264 I-frame encoded is identical or at least so very similar as to be full of the same 16-byte sequences. Actually it's mostly 9-byte sequences, it's just that it needs so very, very many of them to encode an I-frame that statistically producing a recurring 16-byte sequence was almost inevitable.

Let me be clear here: I don't understand H.264 well enough to align this naturally frame aligned, I just took the raw data and pretended it was already 128-bit aligned because that logically cannot be worse than what you'd get if you knew what you were doing. I would be astonished if somebody who actually knows what they're doing can't get much better results from this.

You don't have to understand H.264. All you have to do is take the histogram of consecutive 16 byte blocks from the stream. It's like a 5 minute coding project. Then we don't have to wonder if there are aligned 16 byte block collisions; we can actually look at them and get a sense of where they are and how frequent they are relative to the size of the data. Can you do that? Or, failing that, can you provide a `curl` command anyone else could use to download the data you're looking at, so we can do it for you?

I can H.264 a series of images with solid-colored blocks and not see repeats. But who knows if my codec test harness is representative? I very much doubt it is. I'm certain that there are cases where there are not just collisions, but useful collisions. Let's understand what they are.

This isn't "vulnerability Olympics". It's simply about understanding what we are discussing.

You can see the phenomenon I described for yourself in:

http://demo.nimius.net/video_test/videos/test.mp4

This file contains audio, which in the Zoom pseudo-RTP is separate so you should strip that out with your preferred tool without changing the H.264 video though it won't change the results very much (it only re-assures us that the recurring data is in the video stream as I assumed) so if you don't have such tools don't worry too much.

It has the case we're interested in, because it's the simplest to understand: I-frames with identical content.

If you've put together a "codec test harness" that's what you want to simulate. Don't feed in penguins or "solid-coloured blocks" just feed in a still image, and watch as (unsurprisingly) it outputs the same I-frame each time it needs to do so, regular as clockwork. You're not simulating a Zoom stream of abstract art, but a shared desktop that's showing Pauline's Q3 revenue forecast for two whole minutes while her team discuss Tiger King or the desktop of a guy who left five minutes ago but didn't leave the meeting, or (more speculatively) an empty meeting room on camera.

This is the beginning. If we stop dismissing it as just "more complicated" than just a Penguin pixmap and bring in people who know more about video codecs we can explore how much more can be done. If every slide show has the company logo and the presenter's name on the first slide, does that correlate? Can we make a watermark that would survive being played back through one codec and then encoded by Zoom?

But there's a strong sense in which I don't care to do all that actual work. Some of these things might be possible and some not, but we're not building a cool demo for a convention we're just here to say that Zoom is terribly insecure and if people feel they must use it, treat it like a meeting held in the local coffee shop, assuming your local coffee shop is bugged by both the US and Chinese government.

This is useful. Thanks! Out of ~22,000 AES blocks, this has ~1000 colliding blocks:

    04608c1c211004608c1c00000007419b: 4 samples
    1004608c1c211004608c1c0000000741: 4 samples
    0963211004608c1c211004608c1c0000: 5 samples
    33c00963211004608c1c211004608c1c: 5 samples
    63211004608c1c211004608c1c000000: 5 samples
    f7df7df7df7df7df7df7df7df7df7df7: 5 samples
    0001000003ff0000000e000004000000: 6 samples
    211004608c1c211004608c1c00000007: 7 samples
    c00963211004608c1c211004608c1c00: 8 samples
    0001000003ff00000014000004000000: 9 samples
    0001000003ff0000000d000004000000: 25 samples
    75d75d75d75d75d75d75d75d75d75d75: 31 samples
    5d75d75d75d75d75d75d75d75d75d75d: 33 samples
    00000b0000000b0000000b0000000b00: 34 samples
    d75d75d75d75d75d75d75d75d75d75d7: 34 samples
    7f3f9fcfe7f3f9fcfe7f3f9fcfe7f3f9: 39 samples
    f3f9fcfe7f3f9fcfe7f3f9fcfe7f3f9f: 40 samples
    9fcfe7f3f9fcfe7f3f9fcfe7f3f9fcfe: 42 samples
    cfe7f3f9fcfe7f3f9fcfe7f3f9fcfe7f: 42 samples
    fcfe7f3f9fcfe7f3f9fcfe7f3f9fcfe7: 42 samples
    e7f3f9fcfe7f3f9fcfe7f3f9fcfe7f3f: 43 samples
    f9fcfe7f3f9fcfe7f3f9fcfe7f3f9fcf: 43 samples
    fe7f3f9fcfe7f3f9fcfe7f3f9fcfe7f3: 46 samples
    3f9fcfe7f3f9fcfe7f3f9fcfe7f3f9fc: 47 samples
    aebaebaebaebaebaebaebaebaebaebae: 60 samples
    baebaebaebaebaebaebaebaebaebaeba: 63 samples
    00000000000000000000000000000000: 69 samples
    ebaebaebaebaebaebaebaebaebaebaeb: 73 samples
    00060000000600000006000000060000: 147 samples

The collisions occur in runs, so, for instance, there's a run of ~40 "fcfe7f3f9fcfe7f3f9fcfe7f3f9fcfe7"'s towards the end of the file.

I-frame macroblocks in H.264 are DCT'd, like a JPEG; I have no intuition for what the repeats would signify, except that the encoding is deterministic and, I guess, within an I-frame, stateless? So identical samples will show up in the output?

(It might be easy to instrument an H.264 decoder to get an indication of what frame I'm in when I see a collision, which is I guess what I'll do next).

Did you ever find some sort of reasonable 'live streaming' type profile for encoding? I noticed ffmpeg's default seems to be putting more work into this than you'd expect from a realtime encoder which, in theory at least, might lead to fewer collisions than in a 'realistic' situation. I think tialaramex made a similar point somewhere upthread.

I don't think it would make a huge difference but the numbers might be higher/more representative. Another way might be to just capture zoom traffic of someone's Quarterly Synergies presentation or whatnot.

Edit: also thought of a silly upper-bound test for Team Penguin - you get plaintext of every colliding block in the stream. How much penguin can you get out of that?

I'm just noticing, by the way, that one of the repeats in this test pattern video is the same as the repeat you observed in the Star Wars opening crawl, so presumably that has nothing to do with content.