(1) From SPDY to Hauppauge Card Firmware Issues
NOTE: unfinished: the links to give in places marked with literal string "LINKS" or "LINK" (without quotes). Once done, this note will be removed.
Timing and circumstances
If the reader is interested to read quickly about the raw issues, he or she can just skim or even entirely skip this "Timing and circumstances" little bunch of paragraphs (and possibly come back later for missing details). If skip, skip to The SPDY bug.
I had been engrossed in learning/researching online. Tor is installed in my Devuan. I often --except when I fire up Pale Moon for browsing and posting in forums or other-- I often for extended periods almost anything I do online, including downloading, not just browsing, all that I do with tor programs, the browser being one of the programs, and there being other ones like torsocks.
Whatever that it was that I was doing when I would go online, it was taking days upon days, partly open browsing with Pale Moon, partly hidden; well: as hidden as it gets (the Schmoogle is a big player in Tor development, so not all is to be trusted --not saying none of it is trustworthy either-- just that not all is to be trusted; I would hope there is still some level of obfuscation with Tor... gnunet
would be the solution, but that gnunet project surely would never be getting any funding from Goog the Schmoog, the spies of the world, would it?... and gnunet may be languishing, like true privacy online for little Joe users is languishing, really).
Regarding the very bad news that reveals again the nature of the Schmoog, which every *nix user should know about:
Of course I wasn't online all the time. Open the links in tabs in the browser, and study the content in peace while physically disconnected of course.
But once I felt the time I was spending in my online studies was starting getting into weeks and not just days, I realized I should finally take my network traces and screencasts (I always capture when I go online, with my uncenz program) in for analysis.
Any single PCAP is, for a thorough analysis, even on a fast system, many- many-fold the time necessary to analyze it versus its real duration time. If it is a minute lasting PCAP, it can be an hour of work to analyze it. But the times vary a lot. Anyway you really can't generally do the analysis as you capture, and you generally have to dedicate time to it. You can hardly work online and analyze your traces at the same time...
Also I haven't yet reached any true automating of the tasks of analyzing. Not in detail. The tshark-streams and tshark-hosts-conv do some things, but I would want to have an analysis like the:
does... Which Chaosreader does not, e.g., extract SSL streams, to my understanding. And I would certainly like to get SSL streams, not just extracted (the tshark-streams does extract them) but also those streams sorted and split/extracted/uncompressed into their component parts as well.
And I figured that I needed to do my analyses with my systems that are old and not fast (Asrock Extreme4, see link below), and that is so if I talk about the best ones that I have, while I have also other systems that are even older yet and slower (Abit AT8-32 --link below-- too slow to run tshark-streams and tshark-hosts-conv on any but the shorter duration PCAPs).
I do not talk about an older and another even older system, i.e. in singular. But I talk about my systems in, kind of, pairs. It's always master and clone of the same MBOs, two systems that I talk about, one Air-Gapped built, the other clone of it. Because in these events, in which the grsecurity shines splendidly like it always has, that grsecurity that the Schmoog has, likely in (tacit) cahoots with Mr Linux (the Torvalds guy), chased away from Linux community by ripping off their code, and which grsecurity has been the only thing that has been fixing Linus's kernel and giving the users of Linux true security for more than a decade and a half (and pls. remember that there is no privacy without security), in these events in which grsecurity shines, also another thing shows its modest goodness.
And that is the method that I apply in my poor user's security :).
Air-Gapped Gentoo Install, Tentative Air-Gapped Debian Install for Newbies Air-Gapped Devuan Install, Tentative
But, I was saying, once I started analyzing those traces, I, firstly, realized that I couldn't possibly do it on the older than the already old ones of my systems. But pls. find details in:
Use old amd64 gentoo image on new amd64 hardware, possible? (from Abit AT8-32 to Asrock Extreme4)
And, secondly, I noticed in a number of PCAPs a strange SPDY bug showing up.
The SPDY bug
Yes I noticed a strange SPDY bug showing up in a number of PCAPs.
(
LINKS here. SPDY not recommended
)
Here's what it looks like, the following is just STDOUT of a run of my tshark-streams.sh on the PCAP of 2017-07-29 13h (the dump_170729_1344_gdO.pcap). While it's clear to advanced users (who easily read the sources, the script tshark-streams.sh in this case) what the command might have been, here it is for the less advanced:
$ tshark-streams.sh -r dump_170729_1344_gdO.pcap
And this is a paste saved from the terminal as it was running:
/Cmn/mr_170814/dump_170729_1341_gdO_tStreams /Cmn/mr_170814 $SSLKEYLOGFILE: /home/mr/.sslkey.log $KEYLOGFILE: /home/mr/.sslkey.log $PCAP_FILE: dump_170729_1344_gdO.pcap $ext: pcap $dump: dump_170729_1344_gdO $filename: dump_170729_1344_gdO.pcap tshark -o "ssl.keylog_file: /home/mr/.sslkey.log" -r \ dump_170729_1344_gdO.pcap -T fields -e tcp.stream | sort -n | uniq ** (process:5456): WARNING **: Dissector bug, protocol SPDY, in packet 18809: /build/wireshark-9npE9b/wireshark-1.12.1+g01b65bf/epan/tvbuff.c:610: failed assertion "tvb && tvb->initialized" ############################################################ The list of stream numbers contained in the $PCAP_FILE: dump_170729_1344_gdO.pcap is listed in: -rw-r--r-- 1 mr mr 6595 2017-08-15 08:54 dump_170729_1344_gdO_streams.ls-1 Hit Enter to continue! ############################################################ Processing stream 000 ... ** (process:5626): WARNING **: Dissector bug, protocol SPDY, in packet 18809: /build/wireshark-9npE9b/wireshark-1.12.1+g01b65bf/epan/tvbuff.c:610: failed assertion "tvb && tvb->initialized" Extracted: -rw-r--r-- 1 mr mr 0 2017-08-15 08:54 dump_170729_1344_gdO_s000.bin ** (process:5794): WARNING **: Dissector bug, protocol SPDY, in packet 18809: /build/wireshark-9npE9b/wireshark-1.12.1+g01b65bf/epan/tvbuff.c:610: failed assertion "tvb && tvb->initialized" Extracted: -rw-r--r-- 1 mr mr 228 2017-08-15 08:54 dump_170729_1344_gdO_s000.txt
(the paste above has been manually wrapped for legibility)
And it went forever, on every call of the executable tshark that "Dissector bug, protocol SPDY" on that "packet 18809" would show. (With a few other traces it showed to be in some other number packet.)
Unfortunately all that was a little too new to me. I had seen things, such as with my Galaxy II mobile phone start a video call with me sitting alone two meters away from it... Well, of course I meant somebody starting it, from some operating room, or by having hacked the credentials at the provider's.
I had been used to filming hours of footage with it on political meetings and protests and Bleiburg commemorative trips and Masses and later finding that the best that I filmed has been --likely securely shredded-- erased from its memory cards and storage. Eventually they downright bricked it, after my journey with, among others, one of the last surviving Ustasha in Croatia, the journey to Drvar. I only had time to see that what I filmed in that occupied part of Croatia/Bosnia, which is called republic serbska, was very closely monitored and picked out what to erase. Very very little left of what I filmed during the really great time that we had there. And selectively erased other videos. And just after I transferred from the Galaxy II the footage left, it went bricked, out of no reason, out of thin air. There wasn't any starting of it any more since.
I had been for years in the knowledge of the mass tap on the population, and how the huge majority of all the gizmos and gadgets do listen to you for others, the shadows' of your part of the world's sake --or even some global players' sake-- and worse. How the speakers, virtually any speakers attached to your computing device can be turned into microphone, for the benefit of the same shadows.
But, dear God, why was I so slow to figure out how the old Composite cable input of my now at least 10 yrs old Hauppage HVR-3000 cards can be turned into a powerful enough means of hidden communication, for the shadows, to cause serious havoc into my systems...? Why so slow was I to understand that?
I am talking about the Composite input to Hauppauge HVR-3000 TV-card, to which I connect from the IPTV settop box of my provider T-com, and with Mencoder program I can capture (as I have been doing for at least ten years) video and audio on that input and get TV-programs recorded so I can view or analyze them later.
I'm asking that of myself, because on the next restart of that same system (singular now because it's the one system with two Hauppage HVR-3000 cards in it, in which I ran the tshark-streams.sh command that produced the output pasted above), and I needed to restart it because some time after I ran that one command (and many more tshark-streams.sh commands on other PCAPs) it started to crash.
That system truly started to crash days afterwards. So the connection that I am making between the SPDY dissector bug and the crashing wasn't an obvious one at first.
However, one bad news upon those restarts struck me hard.
It never previously was the case. My old Hauppage cards have worked for really long, and, interestingly, they continue to work, but for the crashing if the recording on the Composite input is being done on them... So the following bad news really never previously was the case (file cx88_failed_170827_2100.txt listed bottom opening page):
(this is early during booting of the system)
[ 1.622475] cx88[0]: i2c init: enabling analog demod on HVR1300/3000/4000 tuner [ 1.629194] TUNER: Unable to find symbol tda829x_probe() [ 1.822483] cx88[1]: i2c init: enabling analog demod on HVR1300/3000/4000 tuner [ 1.828574] TUNER: Unable to find symbol tda829x_probe() [ 1.900589] cx88[0]/2: cx2388x 8802 Driver Manager [ 1.900722] cx88[1]/2: cx2388x 8802 Driver Manager [ 1.901425] cx88[0]/2: cx8802 probe failed, err = -19 [ 1.901459] cx88[1]/2: cx8802 probe failed, err = -19 Please unlock disk sda2_crypt:
LINK here Devuan forums on disk encryption.
I emphasize: It hasn't happened before. The failures above I regard as strong indication that that SPDY bug further above messed up with my TV-cards firmware.
And, once I unlock the encrypted volumes and the system continues to boot just fine, I then get (this is literal, the messed up STDOUT is not my typoes):
[....] Setting up ALSA...warning: 'alsactl -E HOME=/run/alsa restore' failed with error message 'No state is present for card CX8811 Found hardware: "CX88x" "CX88" "" "0x0070" "0x1402" Hardware is initialized using a generic method No state is present for card CX8811 No state is present for card CX8811_1 Found hardware: "CX88x" "CX88" "" "0x0070" "0x1402" Hardware is initialized using a generic method [ ok ate is present for card CX8811_1'...done. [ ok ] Starting RPC port mapper daemon: rpcbind.
Again, the: "[ ok ate is present for card CX8811_1'...done." is not typoes, but it read literally so on the screen.
But the above is my manual copy of the screen, for completeness. The important is what the screen tells at start of boot further above, those failure are the strong indication.
I may be a fast touch typist by now, so you should probably trust I copied it correctly, but if you're a techie FOSS enthusiast like me, you'll much better yet like the Call Traces that I got! Especially because there's no worry in this for you... I may find all of this an interesting experience, but... I can't use some of the functionalities of my cards anymore... I can't use the Composite input on them, because as soon as I start the recording, which I briefly explained how I do it the last time on the Mencoder mailing list:
LINK HERE mencoder
my system will soon crash. So I can't use some functionalities of my TV-cards. And that is a lot of harm and could grow worse.
So I've simply last night unstuck the plug to the Composite input (which has been on one of the cards for probably hundreds of days without any issues), the plug being the video input connection from the IPTV settop box of my provider's where the SCART of the other end of the cable is attached into, and, unstuck as it now is, the system behaves again, without any issues since, while I wasn't able to record without crashes since some circa two days previous to unplugging it.
So, about those Call Traces, go read about grsecurity suspicious when HVR-3000 Composite attached in the next part of this story.
---
