A Peek Inside Apple Durability Testing Labs

Apple is well-known for its secrecy, which is understandable given the high stakes in the high-end mobile phone industry. It’s interesting to get a glimpse inside its durability labs and see the equipment and processes it uses to support its IP68 ingress claims, determine drop ability, and perform accelerated wear and tear testing.

Check out these cool custom-built machines on display! They verify designs against a sliding scale of water ingress tests. At the bottom end is IPx4 for a light shower, but basically no pressure. Next up is IPx5, which covers low-pressure ambient-temperature spray jets from all angles – we really liked this machine! Finally, the top-end IPx7 and IPx8 are tested with a literal fire hose blast and a dip in a static pressure tank, simulating a significant depth of water. An Epson robot arm with a custom gripper is programmed to perform a spinning drop onto a hard surface in a repeatable manner. The drop surface is swapped out for each run – anything from a wooden sheet to a slab of asphalt can be tried. High-speed cameras record the motion in enough detail to resolve the vibrations of the titanium shell upon impact!

Accelerated wear and tear testing is carried out using a shake table, which can be adjusted to match the specific frequencies of a car engine or a subway train. Additionally, there’s an interview with the head of Apple’s hardware division discussing the tradeoffs between repairability and durability. He makes some good points that suggest if modern phones are more reliable and have fewer failures, then durability can be prioritized in the design, as long as the battery can still be replaced.

The repairability debate has been raging strong for many years now. Here’s our guide to the responsible use of new technology.

Continue reading “A Peek Inside Apple Durability Testing Labs”

90s PowerBook Runs MacOS Monterey

Even though Apple isn’t known for making the most pro-consumer devices ever (at least not since the Apple II), the trope that Apples aren’t upgradable, customizable, or otherwise hackable doesn’t really hold much weight. It does take more work to modify them or change how Apple wants them to behave, but it’s not completely impossible. Take this example of a ’94 Apple PowerBook which runs macOS Moneterey thanks largely to new internals from a 2015 MacBook Pro.

[Billy] originally intended for a Raspberry Pi to go inside this old PowerBook, but at the time, prices for ARM single-board computer (SBC) were astronomical. For around the same price as the Pi was at the time, he was able to pick up a retina display from an iPad and the internals from a broken MacBook Pro to outfit this retro case. There’s also a Teensy installed to get the trackpad working and a driver board for the display from Adafruit, and a number of case mods were needed to get everything to fit including the screen which was slightly larger than the original 9.5″ display the laptop would have shipped with.

This project took both inspiration and some of the actual code needed to get everything working from another project we featured a while ago where a Mac Mini was installed inside of a PowerBook case from 1993. Unlike projects that use smaller SBCs for retrocomputing, these builds are notable because the hardware on the inside makes them usable as daily driver computers even today, and might even be an upgrade if you’re using the internals from a MacBook Pro that would have originally had a butterfly keyboard.

Continue reading “90s PowerBook Runs MacOS Monterey”

M1 Development Board From Scraps

Apple is fairly notorious for building devices that are difficult to repair, but with the right tools it’s often not completely impossible to circumvent some of their barriers. As they say, every lock has a key. [dosdude1] has wanted a specific M1 development board for a while now and has been slowly piecing together everything he needs to cobble one together, and finally got this unit running despite many roadblocks put in his way by Apple.

The development kit is a Developer Transition Kit  or “DTK” meant for developers during Apple’s transition from Intel chips to their own in-house ARM-based M1 platform. This particular version is in a Mac Mini form factor but it has a few hurdles to clear before it powers on. First, the board was cut in a critical location that shorted out many of the PCB layers, so this had to be carefully filed down to remove the shorts. It was also missing a few tiny surface mount components and a NAND chip, but these were scavenged from other scrapped parts and assembled into a fully working machine.

There are a number of other non-physical problems to solve here as well, too. Apple coded their NAND chips to work with specific WiFi modules so if these aren’t programmed to work together the computer will get stuck in a boot loop. But with that and a few other details out of the way [dosdude1] finally has his DTK up and running in a 2018 Mac Mini chassis, right down to the working power LEDs. We’ve seen all kinds of PCB damage before (although not often quite this intricate) and even PCBs repaired that were snapped in half.

Thanks to [CodeAsm] for the tip!

Continue reading “M1 Development Board From Scraps”

Supercon 2023: Building The Ultimate Apple IIe, Decades Later

The Apple II was launched in 1977, a full 47 years ago. The Apple IIe came out six years later, with a higher level of integration and a raft of new useful features. Apple eventually ended production of the whole Apple II line in 1993, but that wasn’t the end. People like [James Lewis] are still riffing on the platform to this day. Even better, he came to Supercon 2023 to tell us all about his efforts!

[James]’s talk covers the construction of the Mega IIe, a portable machine of his own design. As the name suggests, the project was based on the Mega II chip, an ASIC for which he had little documentation. He wasn’t about to let a little detail like that stop him, though.

The journey of building the Mega IIe wasn’t supposed to be long or arduous; the initial plan was to “just wire this chip up” as [James] puts it. Things are rarely so simple, but he persevered nonetheless—and learned all about the Apple II architecture along the way.

Continue reading “Supercon 2023: Building The Ultimate Apple IIe, Decades Later”

Wozamp Turns Apple II Into Music Player

Besides obvious technological advancements, early computers built by Apple differed in a major way from their modern analogs. Rather than relying on planned obsolescence as a business model, computers like the Apple II were designed to be upgradable and long-term devices users would own for a substantially longer time than an iPhone or Macbook. With the right hardware they can even be used in the modern era as this project demonstrates by turning one into a music player.

The requirements for this build are fairly short; an Apple II with a serial card and a piece of software called surl-server which is a proxy that allows older computers to communicate over modern networks. In this case it handles transcoding and resampling with the help of a Raspberry Pi 3. With that all set up, the media player can play audio files in an FTP network share or an online web radio station. It can also display album art on the Apple II monitor and includes a VU meter that is active during playback.

Although the 11.52 kHz sampling rate and 5-bit DAC may not meet the stringent requirements of audiophile critics, it’s an impressive build for a machine of this era. In fact, the Apple II has a vibrant community still active in the retrocomputing world, with plenty of projects built for it including others related to its unique audio capabilities. And if you don’t have an original Apple II you can always get by with an FPGA instead.

The Apple They Should Have Made, But Didn’t

Whenever there is a large manufacturer of a popular product in the tech space, they always attract tales of near-mythical prototypes which would have changed everything on the spot had they just not been cancelled by the bean counters. The Sony-Nintendo PlayStation prototypes for example, or any of a number of machines inexplicably axed by Commodore.

Apple is no exception. They brought the instantly forgettable twentieth anniversary Mac and the pretty but impractical G4 Cube to market, but somehow they rejected the Jonathan, a razor-sharp modular machine from the mid-1980s.

It’s easy after so long associating Apple with the Mac to forget that in the mid-80s it was simply one of their several computer lines, and not the most successful one at that. The 16-bit machine was something of a slimmed-down evolution of the Lisa, and it thus it doesn’t necessarily follow that every other Apple machine of the day also had to be a Mac. Into this would have come the Jonathan, a high-end modular machine bridging the gap between domestic and business computing, with a standard bus allowing processor modules for different operating systems, and upgrades with standard “books”, hardware modules containing peripherals, not all of which would have come from Apple themselves. It would have been Apple’s first 32-bit machine, but sadly it proved too adventurous for their management, who feared that it might tempt Apple users into the world of DOS rather than the other way round.

What strikes us about the Johnathan is how out of place it looks on a 1980s desk, it would be the mid-1990s before we would come close to having machines with these capabilities, and indeed we’ve never seen anything quite as adventurous hardware-wise. It’s certainly not the only might-have been story we’ve seen though.

This Week In Security: Peering Through The Wall, Apple’s GoFetch, And SHA-256

The Linux command wall is a hold-over from the way Unix machines used to be used. It’s an abbreviation of Write to ALL, and it was first included in AT&T Unix, way back in 1975. wall is a tool that a sysadmin can use to send a message to the terminal session of all logged-in users. So far nothing too exciting from a security perspective. Where things get a bit more interesting is the consideration of ANSI escape codes. Those are the control codes that moves the cursor around on the screen, also inherited from the olden days of terminals.

The modern wall binary is actually part of util-linux, rather than being a continuation of the old Unix codebase. On many systems, wall runs as a setgid, so the behavior of the system binary really matters. It’s accepted that wall shouldn’t be able to send control codes, and when processing a message specified via standard input, those control codes get rejected by the fputs_careful() function. But when a message is passed in on the command line, as an argument, that function call is skipped.

This allows any user that can send wall messages to also send ANSI control codes. Is that really a security problem? There are two scenarios where it could be. The first is that some terminals support writing to the system clipboard via command codes. The other, more creative issue, is that the output from running a binary could be overwritten with arbitrary text. Text like:
Sorry, try again.
[sudo] password for jbennett:

You may have questions. Like, how would an attacker know when such a command would be appropriate? And how would this attacker capture a password that has been entered this way? The simple answer is by watching the list of running processes and system log. Many systems have a command-not-found function, which will print the failing command to the system log. If that failing command is actually a password, then it’s right there for the taking. Now, you may think this is a very narrow attack surface that’s not going to be terribly useful in real-world usage. And that’s probably pretty accurate. It is a really fascinating idea to think through, and definitively worth getting fixed. Continue reading “This Week In Security: Peering Through The Wall, Apple’s GoFetch, And SHA-256”