[Bbraun] has an old Macintosh SE computer. He was looking for a way to view the video output from the SE on a newer, modern computer. He ended up working out a pretty clever solution using a stm32f4discovery board.
First, the SE’s logic board was removed from its case and placed onto a desk for easier access. The discovery board was then hooked up to the SE’s processor direct slot (PDS) using normal jumper wires. The discovery board acts as a USB COM port on a newer Mac OSX computer. The discovery board watches the SE for writes to video memory. When it sees that the R/W pin goes low, it knows that a write is occurring. It then waits for /AS to go low, which indicates that an address is on the bus. The discovery board reads the address and verifies that it falls within the range of the video frame buffer. If it does, then the discovery board writes a copy of the data to a local buffer.
The OSX computer runs a simple app that can make a request to the discovery board via USB. When the board receives the request, it sends its local frame buffer data over the USB connection and back to the host. The OSX computer then displays that data in a window using CGImage. The demo video below was captured using this technique. Continue reading “Viewing A Macintosh SE’s Video On A Modern Computer”
The Macintosh Classic – a small all-in-one computer with a 9″ monochrome screen – was one of the more interesting machines ever released by Apple. It was the company’s first venture into a cost-reduced computer, and the first Macintosh to sell for less than $1000. Released in 1990, its list of features were nearly identical to the Macintosh Plus, released four years earlier. The Classic also had an interesting feature not found in any other Mac. It could boot a full OS, in this case System 6.0.3, by holding down a series of keys during boot. This made it an exceptional diskless workstation. It was cheap, and all you really needed was a word processor or spreadsheet program on a 1.44 MB floppy to do real work.
[Steve] over at Big Mess O’ Wires had the same idea as the Apple engineers back in the late 80s. Take a Macintosh Plus, give it a bit more ROM, and put an OS in there. [Steve] is going a bit farther than those Apple engineers could have dreamed. He’s built a rewritable ROM disk for the Mac Plus, turning this ancient computer into a completely configurable diskless workstation.
The build replaces the two stock ROM chips with an adapter board filled with 29F040B Flash chips. They’re exactly what you would expect – huge, old PDIPs loaded up with Flash instead of the slightly more difficult to reprogram EEPROM. Because of the additional space, two additional wires needed to connected to the CPU. The result is a full Megabyte of Flash available to the Macintosh at boot, in a computer where the normal removable disk drive capacity was only 800kB.
The hardware adapter for stuffing these flash chips inside a Mac Plus was made by [Rob Braun], while the software part of this build came from [Rob] and [Doug Brown]. They studied how the Macintosh Classic’s ROM disk driver worked, and [Rob Braun] developed a stand-alone ROM disk driver with a new pirate-themed startup icon. [Steve] then dug in and created an old-school Mac app in Metrowerks Codewarrior to write new values to the ROM. Anything from Shufflepuck to Glider, to a copy of System 7.1 can be placed on this ROM disk.
This isn’t the first time we’ve seen ROM boot disks for old Macs. There was a lot of spare address space floating around in the old Mac II-series computers, and [Doug Brown] found a good use for it. Some of these old computers had optional ROM SIMM. You can put up to 8 Megabytes in the address space reserved for the ROM, and using a similar ROM disk driver, [Doug] can put an entire system in ROM, or make the startup chime exceptionally long.
A router with WPS requires a PIN to allow other devices to connect, and this PIN should be unique to every router and not derived from other easily accessible data found on the router. When [Craig] took a look at the firmware of a D-Link DIR-810L 802.11ac router, he found exactly the opposite; the WPS PIN was easily decipherable because it was generated entirely from the router’s MAC address and could be reverse engineered by sniffing WiFi.
When [Craig] was taking a look at the disassembled firmware from his router, he noticed a bit of code that accessed the NVRAM used for storing device-specific information like a serial number. This bit of code wasn’t retrieving a WPS pin, but the WAN MAC address instead. Instead of being unique to each device and opaque to every other bit of data on the router, the WPS pin was simply generated (with a bit of math) from the MAC address. This means anyone upstream of the router can easily derive the WPS pin of the router, and essentially gives everyone the keys to the castle of this router.
A few years ago, it was discovered the WPS pin was extremely insecure anyway, able to be brute-forced in a matter of minutes. There are patches router manufacturers could apply to detect these brute force attacks, closing that vulnerability. [Craig]’s code, though, demonstrates that a very large number of D-Link routers effectively broadcast their WPS PIN to the world. To make things even worse, the BSSID found in every wireless frame is also derived from the WAN MAC address. [Craig] has literally broken WPS on a huge number of D-Link routers, thanks to a single engineer that decided to generate the WPS PIN from the MAC address.
[Craig] has an incomplete list of routers that are confirmed affected on his site, along with a list of confirmed unaffected routers.
Who of us out there don’t have a spare iPad and Mac Classic kicking around? If you are one of those lucky folks then this project is for you. [site hirac] has made a pretty neat stand for an iPad made out of a Mac Classic case (translated). It just happens that the screens of the Mac Classic and iPad are pretty darn close in size. Although the screen size is similar, the resolution is not. The original Macintosh Classic had a black and white screen with a resolution of 512 × 342 pixels. The iPad’s resolution of 1024 x 768 pixels has 450% more pixels than the original Mac.
To get the iPad to fit correctly, the case had to be significantly modified. First, all of the internals of the Mac were removed, leaving just an empty case. The front panel of the case was removed and a slot on the left side is made. This slot helps to allow the iPad to slide into the Mac. On the inside of the front panel quite a few of injection molded supports were trimmed away for clearance. A slot was also cut in the left side of the rear case half. When the case is re-assembled, the slots in the front and rear halves provide a large enough hole for the iPad to fit through. Oddly, there are some plastic features on the front panel that are at just the right height to hold the iPad in the ideal location to line up with the screen cutout in the case.
Continue reading “iPad Finds New Home in Mac Classic”
Check out this jumbled confirmation window. At first glance the message appears to contain a bunch of gibberish, but it can actually be read if you start at the right side and read each character moving left. The text displays like this because it is prefixed by a special Right-to-Left override Unicode character. The technique is being used in malware to obscure the actual extension of the file being launched. Notice that when written backwards your eye can still pick out the string “pdf” which may be enough to trick the uninitiated into approving the launch of the file.
This confirmation screen is launched when clicking on a piece of malware found in the wild a little over a week ago. If you do choose to run it, a decoy PDF file is opened in order not to arouse suspicion. But at the same time the program — which is signed with an Apple Developer ID — is installing itself in the home directory and making a cron job to launch at each boot. Sneaky!
[Mitchell Johnson] wanted to develop for the STM32F4 Discovery board on his Mac. There are a few ready-to-use options when it comes to the ARM toolchains, but he couldn’t find one that satisfied all of his needs. After working out all the kinks he wrote a guide and tweaked a script to install the ARM tools on a Mac.
The problem he had with some of the pre-packaged tool chains is that they didn’t support the hardware floating point functionality of STM’s Cortex-M4 chips. To get around this without doing his own ground-up build (which can be quite a challenge) he forked the Summon Arm Toolchain script and modified it to include ST-Link support in the build. One of the things that we like about that script is it installs the tools in a sub-directory of your home directory. This way if you already have another ARM toolchain you can switch between the two by tweaking your PATH variable.
[Ricard Dias] wrote in to tell us about his guide for developing Linux applications on a Mac. He really enjoys the development environment provided by XCode, and it doesn’t take much to make it work as an all-in-one solution for Linux development.
The real trick here is the use of SSH to access a Linux environment. In this example he uses Ubuntu running as a virtual machine, but also mentions that the same thing can be done just as easily with a separate box as long as it is on the same network as the Mac. SSHFS (the SSH Filesystem) lets him mount the development directory on the Linux box locally. This is where the XCode project and files will be stored, but building the program will be done by the Linux machine via a script calling the make comand via SSH. To test out the newly built program, [L] tunnels in using X11 forwarding for ssh, and the application will be shown as a window in OSX, even though it is running on the Ubuntu machine.
We love SSH and use it all the time. It’s amazing how hand it can be.