dizquetv VS ghidra

In my experience, modern entertainment takes too much cognitive load to get up and running. With streaming/on demand, I have to make pointed decisions on what show I'm watching. I don't always want to make a decision right now of what to watch, I just want to watch something that's good enough or fits a certain theme. TV Channel creation programs, like DizqueTV[0] or ErsatzTV[1] have taken the load off, or at least lets me do that cognitive work in advance when making the channels.

You still need some way to get input to swap between these digital channels (I use Plex to surface my shows and schedule), but if you have existing local content it really feels like the "old" way of doing TV. You can even add commercials between episodes if you wanted!

I'm not sure if I'd call this foolproof for a 94-year-old, especially since sometimes the software needs to restart, but it's a step above modern streaming IMO.

[0] https://github.com/vexorian/dizquetv

Check out https://github.com/vexorian/dizquetv

For those interested in doing something similar there's a Plex add-on for making custom TV channels:

https://github.com/vexorian/dizquetv

Personally I want almost this. I want to rotate the TV shows my kids watch in the morning but I don't want to start part way through a show (the one part of the old analogue experience that I don't miss at all). Difficult to square that circle.

My idea is for each screen plugged in to its own Raspberry Pi 4 Model B 4GB running at the CLI. The Pi would have its own instance of dizqueTV and its stream viewed through some type of custom program running SMPlayer that is also on the PI and outputting the to hdmi port. DizqueTV would have FFMPEG disabled and the content directly accessed per this guide: https://github.com/vexorian/dizquetv/wiki/Raspberry-guide

I have a potato (J4105) Plex server and tried DizqueTV, ErsatzTV and Jason's DizqueTV fork very recently. But I couldn't get it stable unfortunately. When one series would work great, another one wouldn't, or even refused to play. Or certain program boundaries made the player crash from time to time. And watermark overlays were another story of it's own.

[1] https://github.com/boricj/ghidra/tree/feature/elfrelocatebleobjectexporter

I've been working on a specific reverse-engineering technique called _unlinking_ [1] on-and-off for the past 16 months or so. I'm on my third prototype (first a set of Ghidra scripts written in Jython [2], then a fork of Ghidra [3] and now a Ghidra extension [4]) and I've started a blog in order to document it [5], which side-tracked into writing a whole series of articles on reverse-engineering to introduce the topic.

What for, you may ask? Basically I'm trying to decompile a PlayStation 1 video game and I've quickly decided that dealing alone with multiple +500 KiB executables of complete utter spaghetti code wasn't going to work. Instead, I've decided that I'd rather divide-and-conquer the problem, so I've been tooling up to split executables into relocatable object files, in order to decompile those one at a time and _Ship of Theseus_-style my way to success.

Ironically, all of that stuff is so not done that I don't even know what meaningful feedback there could be. My prototypes do work, but only for 32 bit little endian statically-linked MIPS executables. The articles on my blog are draft-quality. As for the decompilation project itself that started all of this, it hasn't seen much progress due to all of those side-quests. The overall topic is so esoteric that so far I've only managed to hear about one group of two persons that tried to do anything remotely similar and one another anecdotal account [6] that this particular skill is very uncommon among reverse engineers.

Personally, I'm starting to think that maybe I could've actually reverse-engineered and decompiled the game in the time I took to get here. I've also tried to engage with Ghidra to upstream the foundations of my modifications in my fork, but after some back-and-forth it became clear that my prototype-grade stuff wasn't industrial-grade and couldn't be merged in its current state, which is why I'm currently reworking the code in my fork as a Ghidra extension.

To those that want to provide feedback after reading all of this: beware, I've had a lot of fun going down that rabbit hole, but this is one hell of a time sink _and_ a particularly tricky mind-bender.

[1] I don't actually _know_ what's the actual name for this technique, given that there are so few resources on it out there. I do know I didn't invent it.

[2] https://github.com/boricj/ghidra-unlinker-scripts

[3] https://github.com/boricj/ghidra/tree/feature/elfrelocateble...

[4] https://github.com/boricj/ghidra-unlinker-extension

[5] https://news.ycombinator.com/item?id=36575081#36590078

[6] https://news.ycombinator.com/item?id=35729232&p=3#35740761

- The relocation synthesizer for MIPS: https://github.com/boricj/ghidra/blob/feature/elfrelocateble...

  - The Ghidra analyzer that leverages this synthesizer: https://github.com/boricj/ghidra/blob/feature/elfrelocatebleobjectexporter/Ghidra/Features/Delinker/src/main/java/ghidra/app/analyzers/RelocationTableSynthesizerAnalyzer.java