Palm OS: Reincarnate

November 11, 2021 by Matthew Carlson 26 Comments

[pmig96] loves PalmOS and has set about on the arduous task of reimplementing PalmOS from scratch, dubbing it Pumpkin OS. Pumpkin OS can run on x86 and ARM at native speed as it is not an emulator. System calls are trapped and intercepted by Pumpkin OS. Because it doesn’t emulate, Palm apps currently need to be recompiled for x86, though it’s hoped to support apps that use ARMlets soon. Since there are over 800 different system traps in PalmOS, he hasn’t implemented them all yet.

Generally speaking, his saving grace is that 80% of the apps only use 20% of the API. His starting point was a script that took the headers from the PalmOS SDK and converted them into functions with just a debug message letting him know that it isn’t implemented yet and a default return value. Additionally, [pmig96] is taking away some of the restrictions on the old PalmOS, such as being limited to only one running app at a time.

As if an x86 desktop version wasn’t enough, [pmig96] recompiled Pumpkin OS to a Raspberry Pi 4 with a ubiquitous 3.5″ 320×480 TFT SPI touch screen. Linux maps the TFT screen to a frame buffer (dev/fb0 or dev/fb1). He added a quick optimization to only draw areas that have changed so that the SPI writes could be kept small to keep the frame rate performance.

[pmig96] isn’t the only one trying to breathe some new life into PalmOS, and we hope to see more progress on PumpkinOS in the future.

The Linux X86 Journey To Main()

November 5, 2021 by Al Williams 7 Comments

Have you ever had a program crash before your main function executes? it is rare, but it can happen. When it does, you need to understand what happens behind the scenes between the time the operating system starts your program and your first line of code in main executes. Luckily [Patrick Horgan] has a tutorial about the subject that’s very detailed. It doesn’t cover statically linked libraries but, as he points out, if you understand what he does cover, that’s easy to figure out on your own.

The operating system, it turns out, knows nothing about main. It does, however, know about a symbol called _start. Your runtime library provides this. That code contains some stack manipulation and eventually calls __libc_start_main which is also provided by the library. Continue reading “The Linux X86 Journey To Main()” →

In Search Of The First Comment

October 23, 2021 by Elliot Williams 105 Comments

Are you writing your code for humans or computers? I wasn’t there, but my guess is that at the dawn of computing, people thought that they were writing for the machines. After all, they were writing in machine language, and whatever bits they flipped into the electronic brain stayed in the electronic brain, unless punched out on paper tape. And the commands made the machine do things, not other people. Code was written strictly for computers.

Modern programming practice, on the other hand, is aimed firmly at people. Variable and function names are chosen to be long and to describe what they contain or do. “Readability” of code is a prized attribute. Indeed, sometimes the fact that it does the right thing at all almost seems to be an afterthought. (I kid!)

Somewhere along this path, there was an important evolutionary step, like the first fish using its flippers to walk on land. Comments were integrated into programming languages, formalizing the notes that coders of old surely wrote by hand in the margins of the paper first-drafts before keying it in. So I went looking for the missing link: the first computer language, and ideally the first program, with comments. I came up empty handed.

Or rather full handed. Every computer language that I could find had comments from the beginning. FORTRAN had comments, marked by a “C” as the first character in a line. APL had comments, marked by the bizarro rune ⍝. Even the custom language written for the Apollo 11 guidance computers had comments — the now-commonplace “#”. I couldn’t find an early programming language without comments.

My guess is that the first language with a comment must have been an assembly language, because I don’t know of any machines with a native comment instruction. (How cool and frivolous would that be?)

Assemblers simply translate mnemonic names to their machine instruction counterparts, but this gives them the important freedom to ignore anything starting with, traditionally, a semicolon. Even though you’re just transferring the contents of register X to the memory location pointed to in register Y, you can write that you’re “storing the height above ground (meters)” in the comments.

The crucial evolutionary step, though, is saving the comments along with the code. Simply ignoring everything that comes after the semicolon and throwing it away doesn’t count. Does anyone know? What was the first code to include comments as part of the code itself, and not simply as marginalia?

Supply Chain Attack: NPM Library Used By Facebook And Others Was Compromised

October 22, 2021 by Ryan Flowers 26 Comments

Here at Hackaday we love the good kinds of hacks, but now and then we need to bring up a less good kind. Today it was learned that the NPM package ua-parser-js was compromised, and any software using it as a library may have become victim of a supply chain attack. What is ua-parser-js and why does any of this matter?

In the early days of computing, programmers would write every bit of code they used themselves. Larger teams would work together to develop larger code bases, but it was all done in-house. These days software developers don’t write every piece of code. Instead they use libraries of code supplied by others.

For better or worse, repositories of code are now available to do even the smallest of functions so that a developer doesn’t have to write the function from scratch. One such registry is npm (Node Package Manager), who organize a collection of contributed libraries written in JavaScript. One only need to use npm to include a library in their code, and all of the functions of that code are available to the developer. One such example is ua-parser-js which is a User Agent Parser written in JavaScript. This library makes it easy for developers to find out the type of device and software being used to access a web page.

On October 22 2021, the developer of ua-parser-js found that attackers had uploaded a version of his software that contained malware for both Linux and Windows computers. The malicious versions were found to steal data (including passwords and Chrome cookies, perhaps much more) from computers or run a crypto-currency miner. This prompted GitHub to issue a Critical Severity Security Advisory.

What makes this compromise so dangerous is that ua-parser-js is considered to be part of a supply chain, and has been adopted even by Facebook for use in some of its customer facing software. The developer of ua-parser-js has already secured his GitHub account and uploaded new versions of the package that are clean. If you have any software that uses this library, make sure you’ve got the latest version!

Of course this is by no means a unique occurrence. Last month Maya Posch dug into growing issues that come from some flaws of trust in package management systems. The art for that article is a house of cards, an apt metaphor for a system that is only as stable as the security of each and every package being built upon.

Vizio In Hot Water Over Smart TV GPL Violations

October 22, 2021 by Tom Nardi 70 Comments

As most anyone in this community knows, there’s an excellent chance that any consumer product on the market that’s advertised as “smart” these days probably has some form of Linux running under the hood. We’re also keenly aware that getting companies to hold up their end of the bargain when it comes to using Linux and other GPL licensed software in their products, namely releasing their modified source, isn’t always as cut and dried as it should be.

Occasionally these non-compliant companies will get somebody so aggravated that they actually try to do something about it, which is where smart TV manufacturer Vizio currently finds itself. The Software Freedom Conservancy (SFC) recently announced they’re taking the Irvine, California based company to court over their repeated failures to meet the requirements of the GPL while developing their Linux-powered SmartCast TV firmware. In addition to the Linux kernel, the SFC also claims Vizio is using modified versions of various other GPL and LGPL protected works, such as U-Boot, bash, gawk, tar, glibc, and ffmpeg.

According to the SFC press release, the group isn’t looking for any monetary damages. They simply want Vizio to do what’s required of them as per the GPL and release the SmartCast source code, which they hope will allow for the development of an OpenWrt-like replacement firmware for older Vizio smart TVs. This is particularly important as older models will often stop receiving updates, and in many cases, will no longer be able to access all of the services they were advertised as being able to support. Clearly the SFC wants this case to be looked at as part of the larger Right to Repair debate, and given the terrible firmware we’ve seen some of these smart TVs ship with, we’re inclined to agree.

Now of course, we’ve seen cases like this pop up in the past. But what makes this one unique is that the SFC isn’t representing one of the developers who’s software has been found to be part of Vizio’s SmartCast, they’re actually the plaintiff. By taking the position of a consumer who has purchased a Vizio product that included GPL software, the SFC is considered a third-party beneficiary, and they are merely asking the court to be given what’s due to them under the terms of the license.

As firm believers in the open source movement, we have zero tolerance for license violators. Vizio isn’t some wide-eyed teen, randomly copying code they found from GitHub without understanding the implications. This is a multi-billion dollar company that absolutely should know better, and we’ll be happy to see them twist in the wind a bit before they’re ultimately forced to play by the rules.

Basics Of Remote Cellular Access: Watchdogs

October 14, 2021 by Lewin Day 21 Comments

When talking about remote machines, sometimes we mean really remote, beyond the realms of wired networks that can deliver the Internet. In these cases, remote cellular access is often the way to go. Thus far, we’ve explored the hardware and software sides required to control a machine remotely over a cellular connection.

However, things can and do go wrong. When that remote machine goes offline, getting someone on location to reboot it can be prohibitively difficult and expensive. For these situations, what you want is some way to kick things back into gear, ideally automatically. What you’re looking for is a watchdog timer!

Continue reading “Basics Of Remote Cellular Access: Watchdogs” →

Software Removes The Facebook From Facebook’s VR Headset (Mostly)

October 13, 2021 by Donald Papp 18 Comments

It’s not a jailbreak, but [basti564]’s Oculess software nevertheless allows one the option to remove telemetry and account dependencies from Facebook’s Oculus Quest VR headsets. It is not normally possible to use these devices without a valid Facebook account (or a legacy Oculus account in the case of the original Quest), so the ability to flip any kind of disconnect switch without bricking the hardware is a step forward, even if there are a few caveats to the process.

To be clear, the Quest devices still require normal activation and setup via a Facebook account. But once that initial activation is complete, Oculess allows one the option of disabling telemetry or completely disconnecting the headset from its Facebook account. Removing telemetry means that details about what apps are launched, how the device is used, and all other usage-related data is no longer sent to Facebook. Disconnecting will log the headset out of its account, but doing so means apps purchased from the store will no longer work and neither will factory-installed apps like Oculus TV or the Oculus web browser.

What will still work is the ability to sideload unsigned software, which are applications that are neither controlled nor distributed by Facebook. Sideloading isn’t on by default; it’s enabled by putting the headset into Developer Mode (a necessary step to installing Oculess in the first place, by the way.) There’s a fairly active scene around unsigned software for the Quest headsets, as evidenced by the existence of the alternate app store SideQuest.

Facebook’s control over their hardware and its walled-garden ecosystem continues to increase, but clearly there are people interested in putting the brakes on where they can. It’s possible the devices might see a full jailbreak someday, but even if so, what happens then?