From the code, BCM2835 peripherals pdf and [1], I gather that this is writing to the pixelvalve1 region of the Videocore to change PAL resolution. But there's nothing about this in the Videocore docs. Anybody here knows where this is documented and what pixelvalve0 in [1] is?
As I understand it, it's moving the active display area of the analogue output to a position 16 lines earlier than it would normally be. In effect that moves the top of the display area into the Vertical Blanking Interval.
From there the code is painting the required 0 and 1 pulses as a bitmap onto the top region of the Pi's display (which is now in the VBI area that teletext sets will be looking at.) Voila - right signal, right place, right time. Very elegant solution.
"UPDATE: This demo will also crash modern LCD TV's teletext decoder.
It's because the demo sends the same packet over and over and new
TVs can't handle it..."
It has nothing to do with digital or analog, it't that most modern TTV decoders don't like the format that this app sends data in.
It's a bit more complicated than that - as with all matters pertaining to agreed broadcast standards, the demo is sending data in the correct format but in a way which you would be unlikely to see in 'normal' use, hence the code drives a truck load of edge cases through the various TV manufacturers' implementation of the spec, and some of them fall over and crash hard.
To explain it in a bit more detail:
Teletext works by sending 40-byte data packets in the unused screen lines of an analogue television signal known as the 'vertical blanking interval' - basically a part of the TV signal where no picture is normally present, included only for timing purposes and to allow an old-style CRT monitor to drag the electron beam down from the bottom of the screen back up to the top again. (Oldskool console programmers will know all about this, also known as the flyback period.)
There are only so many usable screen lines in that period - say around 16. So the maximum number of data packets that can be sent via teletext is 16 packets per field, times 50 fields per second (PAL) = 800 packets.
A teletext page is usually 25 lines of these 40-byte data packets - although it's not required to send every line, as a line that is not sent is assumed to be blank - quite common between paragraphs. This will become important later. But assume 27 packets per page, maybe a few more or less depending on page content.
That means a typical VBI period, at absolute top speed, can carry maybe 1.3 pages per frame. (A page is roughly 1K in size - 25x40 bytes, remember.) So this is all pretty low speed stuff, and the TV manufacturers generally have plenty of time during the course of each picture field/frame to process these pages and do whatever they want to do.
Something else which will become important later - the transmission protocol of these pages is such that a page is only considered to have been completely received, when the next page (or indeed any other page) begins transmission. So for example, in some implementations, the process of starting a new page will trigger some software in the set to start assembling the packets that have been received to form the completed old page.
As I said, all pretty low speed. Nothing too taxing. So all the TV has to cope with, on a typical broadcast teletext service, is responding to a stream of packets along the lines of:
I am starting page 100. Here is line 1. Here is line 2. Here is line 3. Here is line 4. Here is line 5. Here is line 6. Here is line 7. (one fiftieth of a second goes by) Here is line 8. Here is line 9. Here is line 10. Here is line 11. Here is line 12. (another fiftieth of a second passes). Here is line 13. Here is line 15. Here is line 16. Here is line 17. Here is line 21. Here is line 22. Here is line 23. (Another fiftieth of a second passes). Here is line 24. I am starting page 101. Here is line 1... and so on.
Plenty of time to process all that, typically very low speed. (I've only used eight lines per field there, to give a more realistic example of what a 'real' teletext service transmits.)
So, clearly, a regular teletext service obviously takes a certain amount of time to transmit each page, which gives a regular teletext receiver a good amount of time to process it all. And teletext services in general don't transmit blank pages. Not because they can't or shouldn't, but because there's no point in doing so.
So here's where it gets interesting. This proof-of-concept code is ONLY sending 'here is a page' commands (also known as headers, or row zero packets) - and because no page content is being transmitted, that single 'here is a page' command is all that is needed to describe a blank page.
TV sees 'Here is page 100. Here is page 100. Here is page 100. Here is page 100. Here is page 100. Here is page 100. Here is page 100. Here is page 100...' and so on.
So if these pages are being interpreted by a TV's code, rather than hard-wired hardware, suddenly it has a whole lot less time to process what it perceives as a completed page, than it had before. Where under normal conditions the TV would expect to be seeing maybe 10 or 20 pages per second, NOW every single line of the VBI is describing a new page, so it's now seeing (e.g. 16 lines x 50 fields) = 800 pages every second.
If the software in the TV can't turn all those pages around in a fraction of the time that it would normally have - something which it was almost certainly never designed to do, and never tested against - then soon the code has fallen on the floor with its pants down. There's either a massive series of race conditions and collisions going on, or there's a stack filling up and overflowing instantly, or whatever kind of showstopping fault can occur in a situation like this. In some TVs the decoding process will fail silently, in others there'll be other effects, and in some the various watchdog processes in the set will eventually shut the TV off completely.
It's a beautiful example from the olden days - your code might work against the generally accepted and agreed real-world usage of a specification, but can it stand up to legal inputs which 'nobody would ever send' ?
And of course in a modern context, it does raise interesting possibilities - could you compromise a TV just by having it tune to a 'specially crafted' video signal? It might not be as hard as you'd think.
800 packets/sec x 40 byte/packet = 32 kByte/sec data throughput. Plenty of space for a nice exploit.
Heh, I wonder what happens if one could modify a DOCSIS modem to transmit on a DVB channel - in theory you could compromise an entire house, or worse, an entire block (depending on where the DOCSIS concentrator filters out uplink frequencies) by transmitting a fake DVB-C channel... it might even be better to look for problems in the DVB EPG code, because TV PC software can be better debugged.
sounds like buggy software if anything. Now I wonder how exactly does the crash manifest, is it an isolated crash in third party chip (dedicated TV tuner head), or something in main SoC that can be leveraged to take over whole "smart" TV.
This project seems to have gotten around the hardware quirk though.