A Modern Mac Using An Ancient Mac Display

April 24, 2021 by Jenny List 8 Comments

If you own an Apple product you probably live in a world with a few proprietary interfaces, but by and large your displays and desktop peripherals will use familiar ports such as USB and DisplayPort. For the Mac owner of yore though it was a different matter, as [Dandu] is here to tell us with the tale of a vintage Apple monochrome CRT monitor and a modern Mac.

There are no handy VGA ports to be found in this screen, instead it has a 15-pin D connector following a proprietary interface. With the right adapter it’s easy enough to produce VGA from the modern machine, but while it is in theory possible to map VGA pins to Apple pins there’s a snag with this particular model. Instead of using separate sync pins, it demands a composite sync of the type you might find in an analogue TV set that contains both horizontal and vertical sync pulses. The solution came through a simple transistor circuit, and then with the requisite settings on the modern Mac to deliver the 640×480 resolution it was possible to see a MacOS Catalina desktop on something more suited to a Mac II.

We’re more used to seeing CRT Macs in the form of the venerable SE/30, a machine that’s been on our radar for a long time.

The Long Journey Ahead For Linux On Apple Silicon

March 21, 2021 by Bryan Cockfield 41 Comments

An old joke from the Linux community about its prevalence in computing quips that Linux will run on anything, including some animals. While the joke is a little dated, it is true that Linux can run on just about any computing platform with a certain amount of elbow grease. The current exception is the new Apple M1 silicon, although one group called Asahi Linux is currently working to get Linux running on this novel hardware as well.

While the Apple M1 is specifically built to run macOS, there’s no technical reason why Linux couldn’t run on it once all of the kinks are ironed out. This progress report from last month outlines some of the current areas of focus, especially around booting non-Mac kernels. The new Apple silicon runs on an ARM processor and because of this it functions more like an embedded device than a PC with standardized BIOS or UEFI. This means a lot of workarounds to the proprietary boot process have to be created to get a Linux kernel to boot. Luckily there are already versions of Linux that run on ARM so a lot of work has already been done, but there’s still much ahead.

While it’s probably best to buy an x86 machine for the time being if you need a Linux on your own personal machine, it seems like only a matter of time until all of the barriers to Linux are overcome on the M1 silicon. If Linux is able to take advantage of some of the efficiency and performance benefits of these chips, it could be a game-changer in the Linux world and at least give us all another option for hardware. Of course, we will still be needing software that can run on ARM, too.

Thanks to [Mark] for the tip!

FTDI VCP Chips With Custom PIDs Not Working On MacOS 11 Big Sur

December 3, 2020 by Maya Posch 49 Comments

An anonymous reader pinged us about an issue that affects people who jumped onto the latest-and-greatest OS from the Apple gardens: USB devices that stop working due to the FTDI-based USB solution. At its core appears to be that the built-in FTDI driver provided by Apple (AppleUSBFTDI.dext) only supports FTDI chips which provide the standard FTDI vendor and product ID (e.g. 0x0403 and 0x6001 respectively for the FT232R). Many products however set a custom product ID (PID) to differentiate their device, though in the thread some mention that there are driver issues even with the default VID/PID combination.

Over the past years, Apple has been restricting and changing the way kernel extensions (KExt) and driver extensions (DExt) are handled. As these FTDI chips are often used for virtual com port (VCP) purposes, such as with Arduino boards and USB-TTL adapters, this is a rather cumbersome issue that would affect anyone using Big Sur in combination with such a hardware device.

So far only the FTDI team has been somewhat responsive based on the support forum thread, with Apple seemingly rather silent on the issue.

This Week In Security: Zero Days, Notarized Malware, Jedi Mind Tricks, And More

September 4, 2020 by Jonathan Bennett 5 Comments

Honeypots are an entertaining way to learn about new attacks. A simulated vulnerable system is exposed to the internet, inviting anyone to try to break into it. Rather than actually compromising a deployed device, and attacker just gives away information about how they would attack the real thing. A honeypot run by 360Netlab found something interesting back in April: an RCE attack against QNAP NAS devices. The vulnerability is found in the logout endpoint, which takes external values without properly sanitizing them. These values are used as part of an snprintf statement, and then executed with a system() call. Because there isn’t any sanitization, special characters like semicolons can be injected into the final command to be run, resulting in a trivial RCE.

QNAP has released new firmware that fixes the issue by replacing the system() call with execv(). This change means that the shell isn’t part of the execution process, and the command injection loses its bite. Version 4.3.3 was the first firmware release to contain this fix, so if you run a QNAP device, be sure to go check the firmware version. While this vulnerability was being used in the wild, there doesn’t seem to have been a widespread campaign exploiting it.

Continue reading “This Week In Security: Zero Days, Notarized Malware, Jedi Mind Tricks, And More” →

Linux Fu: Turn A Web App Into A Full Program

December 5, 2018 by Al Williams 68 Comments

I hate to admit it. I don’t really use Linux on my desktop anymore. Well, technically I do. I boot into Linux. Then I do about 95% of my work in Chrome. About the only native applications I use anymore are development tools, the shell, emacs, and GIMP. If I really wanted to, I could probably find replacements for nearly all of those that run in the browser. I don’t use it, but there’s even an ssh client in the browser. Mail client? Gmail. Blogging? WordPress. Notes? OneNote or Evernote. Wouldn’t it be great to run those as actual applications instead of tabs in a browser? You can and I’ll show you how.

Having apps inside Chrome can be a real problem. I wind up with dozens of tabs open — I’m bad about that anyway. Restarting chrome is a nightmare as it struggles to load 100 tabs all at once. (Related tip: Go to chrome://flags and turn “Offline Auto-Reload Mode” off and “Only Auto-Reload Visible Tabs” on.) I also waste a lot of time searching since I try to organize tabs by window. So I have to find the window that has, say, Gmail in it and then find Gmail among the twenty or so tabs in that window.

What I want is a way to wrap web applications in their own window so that they’d show up in the task bar with their own icon, but external web pages that open from these apps ought to open in Chrome rather than in the same window. If applications were outside of the single browser window, I could move them to different desktops and organize them like they were any other program, including adding them to a launcher. Hopefully, this would let me have fewer windows like this:

Continue reading “Linux Fu: Turn A Web App Into A Full Program” →

Apple Passwords: They All ‘Just Work’

January 12, 2018 by Brian Benchoff 40 Comments

When the Macintosh was released some thirty-odd years ago, to Steve Jobs’ triumphant return in the late 90s, there was one phrase to describe the simplicity of using a Mac. ‘It Just Works’. Whether this was a reference to the complete lack of games on the Mac (Marathon shoutout, tho) or a statement to the user-friendliness of the Mac, one thing is now apparent. Apple has improved the macOS to such a degree that all passwords just work. That is to say, security on the latest versions of macOS is abysmal, and every few weeks a new bug is reported.

The first such security vulnerability in macOS High Sierra was reported by [Lemi Ergin] on Twitter. Simply, anyone could login as root with an empty password after clicking the login button several times. The steps to reproduce were as simple as opening System Preferences, Clicking the lock to make changes, typing ‘root’ in the username field, and clicking the Unlock button. It should go without saying this is incredibly insecure, and although this is only a local exploit, it’s a mind-numbingly idiotic exploit. This issue was quickly fixed by Apple in the Security Update 2017-001

The most recent password flaw comes in the form of unlocking the App Store preferences that can be unlocked with any password. The steps to reproduce on macOS High Sierra are simply:

Click on System Preferences
Click on App Store
Click the padlock icon
Enter your username and any password
Click unlock

This issue has been fixed in the beta of macOS 10.13.3, which should be released within a month. The bug does not exist in macOS Sierra version 10.12.6 or earlier.

This is the second bug in macOS in as many months where passwords just work. Or don’t work, depending on how cheeky you want to be. While these bugs have been overshadowed with recent exploits of Intel’s ME and a million blog posts on Meltdown, these are very, very serious bugs that shouldn’t have happened in the first place. And, where there are two, there’s probably more.

We don’t know what’s up with the latest version of the macOS and the password problems, but we are eagerly awaiting the Medium post from a member of the macOS team going over these issues. We hope to see that in a decade or two.