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
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).
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?
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.