You might think that jailbreaking a PS4 to run unsigned code is a complicated process that takes fancy tools and lots of work. While developing said jailbreaks was naturally no mean feat, thankfully they’re far easier for the end user to perform. These days, all you need is an LG TV.
Of course, you can’t just use any LG TV. You’ll need a modern LG webOS smart TV, and you’ll need to jailbreak it before it can in turn be used to modify your PS4. Once that’s done, though, you can install the PPLGPwn tool for jailbreaking PS4s. It’s based on the PPPwn exploit released by [TheFlow], which was then optimized by [xfangxfang] and implemented for LG Smart TVs by [zauceee]. Once installed, you just need to hook up your PS4 to the TV via the Ethernet port. Then, with the exploit running on the TV, telling the PS4 to set up the LAN via PPPoE will be enough to complete the jailbreak.
There are other ways to jailbreak a PS4 that don’t involve the use of a specific television. Nonetheless, it’s neat to see the hack done in such an amusing way.
Any reader who has bought a TV in recent years will know that it’s now almost impossible to buy one that’s just a TV. Instead they are all “smart” TVs, with an on-board computer running a custom OS with a pile of streaming apps installed. It fits an age in which linear broadcast TV is looking increasingly archaic, but it brings with it a host of new challenges.
The root of the problem appears to be the TV running continuous network discovery attempts using random UUIDs, which when happening every few minutes for a year or more, overloads the key caches on other networked machines. The PC which brought the problem to light was a Windows machine, which leaves us sincerely hoping that our Linux boxen might be immune.
It’s fair to place this story more under the heading of bugs than of malicious intent, but even so it’s something that should never have made it to production. The linked story advises nobody to buy a HiSense TV, but to that we’d have to doubt that other manufactures wouldn’t be similarly affected.
So first up, we have BatBadBut, a pun based on the vulnerability being “about batch files and bad, but not the worst.” It’s a weird interaction between how Windows uses cmd.exe to execute batch files and how argument splitting and character escaping normally works. And what is apparently a documentation flaw in the Windows API.
When starting a process, even on Windows, the new executable is handed a set of arguments to parse. In Linux and friends, that is a pre-split list of arguments, the argv array. On Windows, it’s a single string, left up to the program to handle. The convention is to follow the same behavior as Linux, but the cmd.exe binary is a bit different. It uses the carrot ^ symbol instead of the backslash \ to escape special symbols, among other differences. The Rust devs took a look and decided that there are some cases where a given string just can’t be made safe for cmd.exe, and opted to just throw an error when a string met this criteria.
And that brings us to the big questions. Who’s fault is it, and how bad is it? I think there’s some shared blame here. The Microsoft documentation on CreateProcess() strongly suggests that it won’t execute a batch file without cmd.exe being explicitly called. On the other hand, This is established behavior, and scripting languages on Windows have to play the game by Microsoft’s rules. And the possible problem space is fairly narrow: Calling a batch file with untrusted arguments.
Almost all of the languages with this quirk have either released patches or documentation updates about the issue. There is a notable outlier, as the Java language will not receive a fix, not deeming it a vulnerability. It’s rather ironic, given that Java is probably the most likely language to actually find this problem in the wild. Continue reading “This Week In Security: BatBadBut, DLink, And Your TV Too”→
Many of us misspent our youth fixing televisions. But fixing a 1970s TV is a lot different than today — the parts were big and tubes were made to be replaced. Have you torn into a big flat screen lately? It is a different world, as [The Fixologist] shows us in the video below.
The TV in question was rescued from a neighbor who was about to throw it away. If you are like us, you’ll watch the first few minutes and see it powers up, but the screen is very dark. Back light problem, right? No problem. But it turned out to be more than we thought.
Honestly, we assumed it might be the power supply, and we would have put a power supply on the LED leads to test that first. That would have been smart because taking the panel off to reveal the LEDs was very difficult! There were two bad LEDs, though, so in the end you’d have had to do it anyway.
We were disappointed that after fixing the LED, he cracked the LCD panel during the reinstallation. So, in the end, this was more of a teardown video and not a repair video. He seemed to think a lot of the tape in the unit was to thwart repairs. That could be, but we wondered if it made manufacturing the TV easier which, after all, is mostly what they care about.
We are always fascinated when someone can take something and extend it in a clever way without changing the original thing. In the computer world, that’s old hat. New computers improve, but can usually run old software. In the real world, the addition of stereo to phonograph records and color to photography come to mind.
But there are few stories as strange or wide-ranging as the path to provide color TV. And it had to be done in a way that a color set could still get a black and white picture and black and white sets could still watch a color signal without color. You’d think there would be a “big bang” moment where color TV burst on the scene — no pun involving color burst intended. But there wasn’t. Instead, there was a long, twisted path with many competing interests and ideas to go from a world in black and white to one tinted with color phosphor.
Background
In 1928, Science and Invention magazine had plans for building a mechanical TV (although not color)
It is hard to imagine, but John Logie Baird transmitted color images as early as 1928 using a mechanical scanner. Bell Labs had a demonstration system, also mechanical, in 1929. Baird broadcast using his system in 1938. Even earlier, around 1900, there were attempts to create mechanical color image systems. Those systems were fickle or impractical, though.
Electronic scanning was the answer, but World War II froze most consumer electronics development. Baird showed an electronic color system in late 1944. However, it would be 1953 before NTSC (the National Television System Committee) adopted the standard color TV signal for the United States. It would be almost 20 years later before SECAM and PAL were standardized in other parts of the world.
Of course, these are all analog standards. The world’s gone digital now, but for nearly 50 years, analog color TV was the way people consumed TV in their homes. By 1941, NTSC produced a standard in the United States, but not for color TV. TV adoption didn’t really take off until after the war. But by 1950, the US had some 6 million TV sets.
This was both a plus — a large market — and a negative. No one wanted to obsolete those 6 million sets. Well, at least, the government regulators and consumers didn’t. But most color systems would be incompatible with those existing black and white sets. Continue reading “The Long Strange Trip To US Color TV”→
Cats are wonderful creatures to have around, and they provide us with hours of entertainment. So why not do a little something to entertain them in return? That’s exactly what [Becky Stern] did by making a cat TV that shows YouTube videos of birds and other cat-approved content. Not all cats seem to care about TV, but [Becky]’s cat Benchley really gets into it.
As you may have guessed, this is a fairly simple build, consisting largely of a Raspberry Pi, a speaker, and a screen — a 5″ HDMI LCD display to be exact. Seems like a nice size for cats. After getting the cat-puter up and running, [Becky] set about designing a 3D-printed enclosure to turn it into a TV. The first draft looked great in marble-effect filament, but lacked breathing holes for the Pi, so the final version has a nice honeycomb pattern that is too small for curious cat paws to fit through.
What their paws can do is accidentally pause the video via the touch screen, so [Becky] swapped the USB cable for a charge-only to prevent this. Be sure to check out the build video after the break, because there is plenty of cat cuteness to be had. [Benchley] was so into it that he went looking around back for cats and squirrels inside the box.
These days, paying for TV programming is a fact of life. You pay your cable company or some streaming service and the only question is do you want Apple TV and Hulu or would you rather switch one out for NetFlix? But back in the 1960s, paying for TV seemed unthinkable and was quite controversial. Cable TV systems were rare, and the airwaves were a public resource, so allowing someone to charge to watch TV on the public airwaves was hard to imagine. That was the backdrop behind the Telemeter — an early attempt to monetize TV programming that was more like a pay phone than a modern streaming service.
Rear view of the telemeter and coin box
[Lothar Stern] wrote about the device in the November 1959 issue of Popular Mechanics (see page 220). The device looked like a radio that sat on top of your TV. It added a whopping three pay-TV channels, and inside was a coin box, and — no kidding — a tape punch or recorder. These three channels were carried from a Telemeter studio over what appears to be a dedicated cable strung on existing phone poles.
Of course, TVs with coin boxes were nothing new. But those TVs were found in public places, airports, and hotels. The money was simply to turn the TV on for a set amount of time. This was different. A set-top box unscrambled channels delivered over a dedicated cable. Seems like old hat today, but a revolutionary idea in 1959.
