Of Sun Ray laptops, MIPS and getting root on them

I like Sun Ray laptops. They make surprisingly useful thin clients. Here, going from right to left, I'm playing Quake on my Solaris UltraBook IIi while it serves a Sun Ray session via Sun Ray Server Software (SRSS) to my silver Sun Ray 2N in the middle, and on my Accutech Gobi on the left I'm root.

Wait, what? Root on a thin client?

Let's rewind a little.

In 1984 Sun Microsystems adopted as their corporate slogan John Gage's famous observation that "The Network is the Computer," one of many neat fragments of history left to rot after Larry "Destroyer of Worlds" Ellison's Oracle bought them out in 2010. (Fittingly, at least to me, Cloudflare acquired the rights to the disused trademark in 2019. This is an official Sun swag mousepad I picked up back in the day.) False starts like NeWS aside, Sun believed in the idea so deeply that they put significant resources into developing thin clients serviced by their hardware to complement their more typical workstations.

In Sun's ideal world, a user would run programs on a central server (a Sun, of course), having their session follow their smart card seamlessly from terminal to terminal along with any other shared resources they might require. While Sun produced the JavaOS-based JavaStation in 1996 — ironically based on Oracle's Network Computer concept — it used relatively expensive hardware, being essentially a miniaturized SPARCstation 4. Instead, the new proof of concept for a cheaper, more connected world was the 1997 NetWorkTerminal "NeWT" — one wonders if that abbreviation was a coincidence — based on Sun's MicroSPARC IIep CPU, and that prototype in turn evolved into the first Sun Ray thin client in 1999, codenamed Corona.

We first talked about the Sun Ray line some months back by looking at one of its last examples, the laptop Tadpole M1400 and its General Dynamics rebadge. Sun produced the first generation Sun Rays not only as sidecar desktop devices that connected to a monitor, keyboard and mouse, but even built some of them into CRT displays reminiscent of Apple's contemporary G3 iMac (which also inherited technologies from the Oracle Network Computer via the unreleased Macintosh NC) and LCD flat panels.

However, just like it had to go cheaper to win, if the Sun Ray way was to become truly omnipresent then it would have to go portable as well. That was where the 500nm microSPARC IIep, as diminutive as it was for SPARCs of the time, couldn't make the grade: the Sun Ray 1G required 20 watts just to run, not counting the display it was connected to, and at least five watts of that went to the 100MHz CPU alone. Downclocking it wasn't an option either, as the CPU was already too underpowered to cope with the stream; a 2006 InfoWorld article accused early Sun Rays of being "network-clobbering" and "stuttering." So Sun jumped from SPARC to MIPS with the Sun Ray 2, and that's where our story begins.

The MIPS migration occurred as a consequence of converting the first generation Sun Rays to Sun's bespoke Copernicus SoC, which combined the IIep core with 4MB of DRAM on chip (the ATI Rage 128 handling 2D graphics remained separate with its own dedicated memory). During Copernicus' development, Sun Ray engineer Marc Schneider had considered using the new low-power embedded MIPS Au1 core developed by fabless semiconductor company Alchemy, but there was little appetite at the time for rewriting the onboard firmware to run on a completely new architecture. Alchemy was founded in 1999 by refugees from DEC's StrongARM development team, which was dissolved after Intel acquired the IP in 1997 and turned it into their XScale CPU line (other team members went on to found SiByte, which developed a MIPS core of their own). The Au1 core was a scalar, in-order core based on the 1999 MIPS32 specification with five pipeline stages. It featured an R4000-class MMU, a 16/32-bit multiply-accumulate unit and a one-bit-per-cycle hardware divider. However, to shrink die space and reduce power consumption, the Au1 eliminated the FPU, removed support for MIPS-16 compressed instructions and supervisor mode, and replaced virtual address translation with a TLB-based strategy and an exception handler in software instead of having the hardware walk page tables. It could also completely stop all clocks to the core units until reactivated.

The first Au1 chip was the Au1000 SoC in 2001, a 180nm part with integrated SDRAM, flash, USB, serial (IrDA and UART) and Ethernet controllers. It had 16K each of I- and D-cache and ran up to 500MHz but with a top TDP of only 900 milliwatts. Although the Au1000 family, notably the beefier 1.2W Au1500 with an on-board PCI controller, got design wins in a few embedded applications, Alchemy was still just a small startup and ran into issues landing a second funding round to expand. In 2002 AMD bought Alchemy outright to directly compete with XScale in the embedded sector and introduced the 130nm Au1550 in 2004, a die-shrink of the Au1500 intended for high-security network applications with the SafeNet Security Engine providing an entropy-based RNG and hardware acceleration for DES, 3DES, AES, RC4, MD5 and SHA-1. It also ran up to 500MHz with the same cache and on-die peripherals but a new lower "typical" power draw of under 600mW, maxing out at 1460mW. Nothing in the SPARC ecosystem could match it for power consumption, making it suitable for portable Sun Rays, but it was nevertheless more capable than XScale, meaning the same chip could power the next generation of desktop Sun Rays too. Sun selected the Au1550 and the first Sun Ray 2 (internally designating the series as "P8") came out in 2005, paired with 4MB of Flash and an ATI R100-derived ES1000 framebuffer sharing 16MB of RAM. With this design Sun met its goal: the new hardware could more effortlessly handle more demanding applications at greater resolutions, and typical power consumption for the entire system was just four watts plus display.

The Sun Ray laptop story is a bit more prosaic. Yes, it may surprise some of you to hear that there really were Sun laptops. That said, however, Sun never designed a laptop of their own themselves even for their high-margin SPARC line, entirely relying on third parties to do so, and even the laptops that Sun did sell were designed and OEMed by others. Of these partner OEMs, the most notable were U.S.-based RDI and U.K.-based Tadpole, who later bought out RDI, and Taiwan-based Nature Worldwide Technology Corporation, nicknamed Naturetech. What Sun sold as their Ultra-3 laptop was actually a condominium of no less than five discrete models: Tadpole's UltraSPARC IIIi Viper and both versions of their UltraSPARC IIi SPARCle (all based on the Acer TravelMate 420 chassis) as the Ultra-3 A60, and Naturetech's UltraSPARC IIIi Mesostation 999 and UltraSPARC IIi PowerBook 888P as the Ultra-3 A61. The two lines were visually different, with the Tadpoles in an arresting lavender case and the 888 and 999 in severe graphite and black, causing some confusion among buyers as they were otherwise completely unrelated. I have an Viper A60 Ultra-3, which puts out a prodigious amount of heat and drains batteries dry in less than an hour full tilt, and you should never use it on your lap if you want to have children (or a filesystem).

In a like fashion, the first Sun Ray laptop didn't come from Sun either. Tadpole, then newly acquired by General Dynamics, used a modification of the SPARCle design as the 2005 Comet 12 and Comet 15 with the same UltraSPARC IIep and the same basic drawbacks. The SPARCle case was fine for an actual Solaris laptop, but calling the relatively heavy unit a thin client was a poor joke, and Sun didn't adopt it for sale. Naturetech subsequently took their own shot at the market when the Sun Ray 2 was released, using the desktop unit as a reference design and the same MIPS and ATI chipset but adapting the case and battery from another Taiwanese OEM laptop, the G220 notebook from Elitegroup. Naturetech called it the Jasper 320. Sun liked the thinner profile and reduced weight, and badged it as the Sun Ray 2N for test-marketing in Japan in 2006.

This is my personal 2N, acquired practically unused in its original packaging.

If this manifest is to be believed, this unit was made and shipped in 2007. The 2N came with both 10/100 Ethernet and 802.11b+g WiFi. The WiFi supports WEP, WPA-PSK and WPA2-PSK for authentication, and WEP, WPA-AES and WPA-TKIP for encryption.

Everything in the box, including a very brief manual (in English, however), battery and standard laptop power supply.

In case you didn't believe it's a Sun, it's right there on the top.

And it's right there on the keyboard. The layout is a standard JIS keyboard with Sun-specialized keys, though most aren't active in Sun Ray mode, and the firmware largely treats it like a US keyboard. The gap between the display hinges is where the battery would go ordinarily. Any G220-compatible battery will work and the machine was shipped with one. The touch pad isn't fabulous but it works.

On the left side is a VGA port for mirroring, Ethernet jack and (replacing the G220's PCMCIA slot) a smartcard slot. The phone jack on the corner, obviously originally for a built-in modem, is blocked off. The 2N's VGA port only supports display mirroring and cannot extend the desktop, which is why I conclude it was based on the original Sun Ray 2 rather than the enhanced 2FS, which can.

The right side just has three USB 1.1 ports. The rest is where the optical drive would have been with the G220 but is completely blocked off in the 2N. The firmware won't mount any devices connected here but does appear to recognize keyboards and mice. Three whole ports just for that purpose strikes me as an excessive number (after all, it already has a keyboard and track pad!) and it seems to be merely because the G220 had them.

On the front, there are headphone and microphone jacks (speakers are in the display), and on the rear are the battery terminals, Kensington lock and A/C barrel jack.

The underside is where it starts to get more interesting. Even though they served no real purpose, Naturetech kept the CPU, hard disk and RAM doors of the G220 and adapted the Jasper logic board to fit. They also kept the fan vent despite the fact none of these chips get hot enough to even merit a heat sink.

However, there's absolutely nothing in the hard disk bay, not even a connector.

Similarly, in the RAM bay, there's no RAM. Instead, the wireless card connects here with an SO-DIMM like connector, based on a Ralink RT2561T. Under it we see the Jasper designation on a sticker. The smartcard chip reader is visible on the southeast side.

The CPU is at position U25, a 500MHz Au1550. West of it in this view is the single Hynix 5DU281622ETP-5 16MB SDRAM chip, the lowest-binned 200MHz 8Mx16 in that family. Remember: cheap!

The nearby ATI ES1000 framebuffer is an R100 derivative and shares the SDRAM with the CPU. As a simple framebuffer this is adequate.

The display is a 12" 1024x768 75Hz/24-bit TFT LCD and isn't too bad, considering (a virtual desktop extends up to 1280x1024 as you move the pointer). Sun badging is prominent not only on the bezel but practically clubs you over the head as well when you turn it on.

If you've never used a Sun Ray device before, you might find the display window rather curious. Rather than localizing prompts and status text in the firmware, Sun chose to use an icon display language ("On-Screen Display") which vendors were obligated to implement. What text does appear is limited to addresses and status codes. The OSD shown here is an evolution of the blue-background OSD used by first generation Sun Rays, but has the same status codes and basic semantics. The first window it pops up shows its MAC address and status 1, meaning it's configuring the onboard Ethernet. Within seconds it will try to get a DHCP lease and find a host, much like any other active parasite.

It's time to connect this silvery zombie to a source of brains. The following grabs are directly from the VGA port through my INOGENI VGA2USB3 at the native resolution of 1024x768. The only edits are to censor my internal test network information because some of you are delightful and naughty.

Here are the five Kübler-Ross stages of Sun Ray grief connection:

Denial (1): I don't believe there's a network (yet).

Anger (21): I found Ethernet, but I have no DHCP address! What the Larry Ellison! (The Ethernet speed is correctly reported as 10Mbit half-duplex since I had it on the slow segment as a stress test. Remember this when we talk about the Gobi.)

Bargaining (22): I pleaded with the DHCP server and it gave me an address.

Depression (26): I found a server but it won't talk to me yet. (In this case, scottie, the Solaris laptop, had responded to the 2N's broadcast query and will shortly start the session. I guess you could insert a couple more stages in here like actually sending the broadcast query [27], but that interferes with my joke, dammit. You can also configure fixed DNS entries [sunray-config-servers, sunray-servers] or send DHCP option 49 [X Window System Display Manager] addresses to hint the client. The DHCP server on this network provides those entries.)

Acceptance (14): my siren call was answered, I have found a source of brains and I will now drain its CPU and resources (over UDP-based Appliance Link Protocol, or ALP). This particular connection is not secured nor authenticated, but encryption and server authentication are generally possible (codes 11 through 13). A watchdog timer will soft-reset the unit and start the stages of grief connection over again if a successful link isn't made.

Having connected, the screen is now a standard X display manager login. You log in. Simple! With a recognized smart card you can even completely skip this step.

Like most other Sun Ray clients including the Tadpole M1400, hot keys to change settings are available, including while connected. These keys become live shortly after the machine starts. The main menu is accessed with Stop-M (on this keyboard that's actually a three-finger salute of "yellow" Fℕ-Alt-M) and options are selected with the cursor keys. The "manual" documents two hot keys, Stop-M for this menu and Stop-W to access wireless profiles, but actually most of the documented hot key combinations work, along with Stop-V for displaying the unit's firmware version. The menu isn't particularly extensive, so here are the highlights.

The wireless profiles menu (directly accessible with Stop-W) provides three configurable profiles where the channel, SSID, authentication/encryption and key can be specified. In this case none are active because my internal network is wired-only.

Disappointingly, the entire security "menu" is one option, merely to set a password. Sheesh.

Under the status menu you can choose the radio status (spoiler alert: it's not on) and the firmware version. This unit reports NWTC,KiboP8 3.1.1_2007.03.06.20.11 plus its MAC. I don't have the exact history but "Kibo" appears to have been the Naturetech internal codename.

Prior to Sun Ray Software 5.2 firmware came in two flavours, the "non-GUI" version here with this minimal configuration menu and a "GUI" version with a more extensive menu allowing you to enter explicit parameters. Later on they were unified into a single firmware with the ability to enter the configuration menu appropriately controlled by the server. I am aware of at least one later GUI version of the 2N firmware tagged NWTC,KiboP8,Jasper320 GUI4.0_48_2007.09.05.16.59, but I don't have a copy of it.

The only other options control various tunables about the WiFi and screen blanking.

If you disconnect the zombie while it's feeding, it complains with an error 23, as all zombies do.

While attempting to reconnect the 2N will even try sending the "any server out there" broadcast packet (27) over WiFi, though since this one isn't configured with an SSID, there's no one to hear it scream.

Okay, fine, let's log in.

At the Solaris 10 desktop with the version dialogue up to prove we're here. From the Solaris side /opt/SUNWut/sbin/utquery -d IPADDRESS will tell you information about a connected client.

The 2N also works fine with kOpenRay, my very-occasionally-maintained updated fork of jOpenRay, an open-source Java reimplementation of ALP. Note that kOpenRay does not currently know how to respond to broadcast requests, so since we can't hardcode the address in the 2N's settings kOpenRay's IP address is provided by the local DHCP server. The kOpenRay console shows the device identified itself as a NWTC,KiboP8,Jasper320 3.1.1_2007.03.06.20.11. Also note the MAC (used as an ID), namespace and actual screen resolution (but also the virtual resolution of 1280x1024).

Playing the default Tetpnc session. Incidentally, inserting a smart card worked and was recorded by kOpenRay.

Unfortunately, the Sun Ray 2N was the only laptop Sun Ray that Sun would ever call its own. It achieved some sales in Japan and was spotted at various trade shows, but other than local usage by Sun's regional offices there was little market interest and Sun chose to quietly discontinue it.

For its part, Naturetech kept selling the device under its original Jasper 320 name and offered the design to other vendors, along with the later Amber 808, Opal 608 (8.4") and Opal 612 tablet versions. These were the only known Sun Ray tablets, featuring RFID and even biometric support. Fellow Taiwanese vendor Arima was interested and planned to launch the entire line as the Sunrise Ultra ThinPad and Solstice Ultra ThinTouch, though it isn't clear if any were actually sold. There was also a VPN-enabled version of the Jasper 320.

Accutech Ultrasystems, however, another Taiwanese computer manufacturer, saw the hardware as an opportunity not only to get into thin clients but also use Sun Ray technology as a security surveillance solution.

Accutech took the basic Jasper board and substantially reworked it with custom firmware and a built-in hardware VPN module, selling it as the Gobi8 with HSDPA/UMTS support and the Gobi7 without. The Accutech Gobi laptops were themselves resold by British vendor Aimtec under the same name.

To a cursory glance the silver-clad Gobi and the 2N are almost indistinguishable except for the logos on each lid, but there are mild differences in the external ports, and Accutech made significant changes to the hardware. That's where the pwnage part comes in.

I haven't had good luck with Gobis. Over the years I've accumulated three, but only one of them still fully works; the other two spontaneously suffered hardware failures such that they won't configure their network interfaces anymore. The most recent one shown with the 2N is my sole completely functional example and was sent to me by a generous donor. On the other hand, that means I have no compunction about stripping down the defective ones to figure out how they work.

The silver Gobis are the original ones, sold as the Gobi7, though both of my units appear to have been subsequently upgraded to Gobi8 (installing the additional 3G support and updating the firmware), apparently at the factory as the barcode sticker reads Gobi8. The thrashed black unit perilously held together with binder clips is an actual Gobi8 and was a later unit. This one was was my first Gobi and came to me busted up, so I hold blameless to its mistreatment, though it was mostly working at the time.

The keyboard is now regular English and no more Nihongo, sniffle.

Other than that, the most notable external differences between the 2N and the Gobis are a SIM card slot in the front next to the audio jacks and a CardBus PCMCIA module in the optical drive slot. These are all active though I don't have anything that goes in them (and we don't have 3G anymore in the United States).

If we pull out the 3G module, we're already getting hints that Accutech did a bit more than a fresh coat of firmware paint. Next to the card cage we see two Realtek RTL8201CP 10/100 Ethernet PHYceivers and a PH249015G quad 4-port pulse transformer to connect them to twisted pair Ethernet signals. Under the cage are two Hynix HY57V281620FTP-6 SDRAMs, 16MB each to equal 32MB.

But turn it over and there's another 32MB of RAM, plus 16MB of flash (Intel JS28F128), an ENE CB-1410QF PCI to CardBus bridge, and right in the middle — irony of ironies — an Intel XScale-based IXP425 Network Processor running at the lowest rated speed of 266MHz (PRIXP425ABB). This SoC supports UTOPIA 2 (for ATM networking), xDSL, 2x HSS (for mobile network authentication) and two Ethernet MACs, along with hardware support for SHA-1, MD5, DES, 3DES and AES. It has onboard controllers for a UART, SDRAM, USB and PCI. The Ethernet MACs no doubt connect to the PHYceivers on the other side. There are a whole bunch of obvious debug connectors here but I don't know the pinout.

The internal differences are even more substantial. Accutech got rid of the fan vent and moved the ATI GPU closer to the CPU, but also added another 16MB SDRAM (to equal 32MB) next to the Au1550. Although several regions are now unpopulated, including the SO-DIMMesque slot for the 2N's WiFi module, there are several more chips on the board — including two, count 'em, two Realtek RTL8305SC ICs. Each one of these is a single-chip, 5 port (!) 10/100 Ethernet switch controller, connected to a quad 4-port pulse transformer for twisted pair Ethernet (the YCL PH249015G chips), with the fifth port provided by the Pulse Electronics NS0013-NF single-port transformer. What the heck are these things doing?

Here is the complete logic board, which I dug out from my defective silver Gobi7. Note that while all the stickers say Gobi8, the board says Gobi7 too. On the first image you can see the HD64F3437TF16 (H8/3437) smart card reader chip with yellow grease pencil slashed across it, a Hitachi H8/300 16-bit microcontroller with 60K of on-board flash and 2K of RAM. Roughly in the centre of the second image is the Au1550's system flash chip, a 4MB Spansion S29AL032D.

By the way, there was actually something in the hard disk bay too, with its own RTL8305SC and transformer. Labeled the VPN Board ("REV. 2.0"), the WiFi antenna terminals connect here, showing it also serves as the WiFi module. The whole thing physically connects to the main logic board using the 44-pin laptop IDE connector, which is also populated in the Gobis.

There's a lot going on with this little board. Besides the Ethernet switch controller and pulse transformer, there's 32MB of SDRAM (Hynix HY57V561620FTP-H) and 8MB of flash (the Spansion FL064AIF).

If we dig it out and pop the cage off, there's one more chip, and it's a doozy: an Atheros AR2316A. That's a third SoC! It integrates a 2.4GHz radio, 802.11b/g MAC and baseband, 802.3 10/100 Ethernet MAC and MII interface, SDRAM and Flash controllers, UART — and a 180MHz MIPS R4000 core. At the very bottom (on this view) is another obvious set of UART headers, but I never got anything useful from the modules in the busted Gobis with my logic analyzer. On the other hand, that could be because those machines aren't working, and I wonder if heat had something to do with it because this chip is very poorly ventilated. One other interesting thing to note is that I can only see lines from two of the RTL8305SC's five ports going to the transformer. I guess they got a good enough deal on those to waste the other three.

The bottom line is, as we'll demonstrate in the next few screenshots, this laptop isn't just a MIPS laptop: it's three apparently completely independent RISC systems with their own memory, flash and operating system on an internal Ethernet network. All those NIC and switch chips are the internal communication interfaces from the Au1550 to the IXP425 and the AR2316A, but using the IDE bus lines instead of actual twisted pair. That's not what I was expecting to find in a Sun Ray!

It shouldn't surprise you that the interface in this unit isn't standard either. Let's fire it up.

Initially it seems like the same exact firmware as the 2N, even basically the same shade of blue background, except for the Gobi logo. And then ...

... the menu starts.

The Gobi firmware stores up to eight built-in profiles. This Gobi has three profiles set up in it normally: a "DHCP" profile that acts basically like the 2N did, fetching a lease and the display server addresses from the DHCP server; a hardcoded profile for kOpenRay; and then a third, more mysterious profile we'll save for the end. You can (with a bit of kludginess, the interface is obnoxiously non-orthogonal) edit or overwrite them and most people never used more than one anyhow. The Engrish command of the Taiwanese development team was imperfect and various odd typos and phrasings are scattered throughout the interface.

The setup menu lets you create a new profile, configure security options, display system firmware versions (or update them) and do a factory reset.

If you request the firmware versions, the core firmware on the Au1550 (here 4.0_VT035c) then queries both the 3G board (1.2.3.emobile.a) and the VPN board (2.1.0). This takes ... time. The Au1550's firmware can be updated from an appropriately configured Sun Ray server but the 3G and VPN firmware require a separate local TFTP server to download from (FTP also supported by the VPN board, but not the 3G board). Again, this is because they're actually separate systems that just happen to be crammed into the same case.

Also note the separate MACs for the "LAN" (the VPN board) and the Sun Ray itself, in addition to the WiFi, of course. We'll see an extreme example of the internal communication network at work when we get to the final profile.

Our first profile essentially makes the Gobi act like a 2N: no local configuration, get a DHCP address, figure out servers for itself (either from DHCP hints or broadcast queries).

Notice the line in the configuration about "Use web authentication." Those of you who remember our deep dive into the Sun Ray 3-based Tadpole M1400 will recall its own built-in login browser for public WiFi and the like (initially Links, and later WebKit). Just keep that in the back of your head for a few minutes.

In this mode, the ID comes up with the MAC of the Sun Ray 2 as expected, since we're not obviously using the VPN (and if you do a quick arp -a on a connected system, you'll see the Sun Ray 2 MAC). But that isn't the external Ethernet jack: this claims a full-duplex 100Mbit Ethernet connection when we're connected to the exact same 10Mbit half-duplex Ethernet segment I used for testing the 2N. What you're actually seeing is the internal Ethernet connection between the three component systems, which is 100Mbit.

Connecting to the Solaris Sun Ray server.

And at the login prompt. The Gobi, oddly, doesn't appear to support any hot keys except Props-F12 (yellow Fℕ-Ctrl-F12, the "moon" sleep key), which resets the unit — but only within the same profile. Similarly the watchdog timer just resets the currently running profile as well. The only way I could find to switch profiles was to powercycle the unit entirely.

So that's what we'll do and select our second profile. Like the first profile, this gets an address from a local DHCP server, but hardcodes the Sun Ray server address (you can also specify a firmware server address) instead of letting the client discover it from DNS or DHCP.

This seems like a minor, almost trivial change, but the Gobi handles this situation rather differently.

Instead of going directly to establishing a connection, the Gobi does a prolonged dance to obtain an address.

That's because in this mode, it's no longer the Sun Ray firmware that's getting the address and connecting to the host. Instead, it's the VPN board.

I've intentionally not suppressed this address to demonstrate to you that we're now using a completely Gobi-internal IP address (192.168.100.2) on that massive "IDE-Ethernet" switch, again at the false speed of 100Mbit, even though the Gobi is still plugged into the same 10Mbit half-duplex port. This IP address has no relationship to anything on my internal test network. In fact, this totally confuses SRSS on the Solaris server and it seemingly won't talk to it.

In kOpenRay's console we see what's wrong: there are two addresses, the realIP (VPN-confabulatory) and remoteIP (actual). With the first profile, these were the same; with this profile, only one of them is actually valid. The UDP packets are correctly sent to SRSS, but it replies back to the VPN-generated phony address which won't work (and isn't what it got from the DHCP server), and thus the ALP connection is never established. Unless your local network is or allows this subnet, you may not be able to connect at all either.

kOpenRay does work with the Gobi VPN because I added code to reply to the remote IP it provides instead of the phony "real" one.

It is my suspicion that the VPN board is involved even in the case of the first profile, given that a) the connection speed is wrong, b) the VPN boards are dead even via the UART ports and c) my dead Gobis power up and try to initialize their network connections, but fail, which should work if the Sun Ray firmware had a direct unimpeded path to the outside. If the VPN board dies, it looks like everything does. And it really does get stuffy in that hard disk bay.

Well, that's enough preamble. It's time to actually break something.

The final profile looks like the first profile, but with one change: this time, we're going to use the built-in minibrowser for "web authentication." Some of you are starting to smile in anticipation, because when there's a browser, there's often a hole. And there's a hole, by golly.

The first odd part is that we go into the "long dance" to get an IP rather than the fast Sun Ray direct mechanism. And then a new window appears:

This is the mini-browser. Ignore the fact it can't get to Snoracle's website, as this segment isn't allowed out onto the public Internet.

But we can surf Floodgap local resources from here, so let's pull up the Floodgap main page.

It's the right colours, more or less, but it's all text and no special fonts or images.

If we press Escape for the menu as directed, we see a familiar set of options. Some of you know what browser this is already. Hint: the M1400 was using a related package.

No, you don't get a clue from visiting the "Gobi7 homepage" (even though this is technically a Gobi8). Give up?

It's ELinks! (And it's a GPL violation!) More specifically, ELinks 0.11.3, which would be right for the timeframe of this firmware version.

The notion here is that you would connect, do whatever login process you needed to do, and having done so then quit the browser and let the VPN board do the rest of its dance. Spoiler alert the second — we're not going to let it get that far.

Two more things about the browser before we get stuck into it. First, here's its user agent string: it's running Linux 2.4.25. Naturally it reports the architecture as mips. But which one, the Au1550 or the AR2316A? I don't think the Sun Ray 2 firmware is Linux-based! (The M1400 was.)

Second, TLS v1.0 is supported, but there is no certificate validation and no store. This was really intended for public networks anyway where you would assume they were untrustworthy to begin with and presumably tunnel through them. There is no support for FTP or Gopher.

Anyway, enough messing around. Although there is at least one possibly useful buffer overflow in this version, we may have an even easier way to break it. The M1400's installation of Links was properly chrooted by Tadpole, so let's see if Accutech did the same. Will it let us look at file:///?

Oh no. Everything is busybox. But we can see that everything is busybox. Let's look at /bin.

Oh noooo. Is it going to be this easy?

Let's see if it will let me open /bin/sh ...

... with /bin/sh.

It halted. But wait a second: is that a root prompt?

Oh yes.

Oh yessssss. It is that easy.

There's no chroot at all. We're into the operating system. The Gobi is pwned.

The first order of business is to see what's running. Among the various kernel tasks and a couple self-explanatory processes, ps -ef tells us there's a Telnet daemon (!), a getty listening on what's most likely the serial UART at 115200bps (so this should definitely answer there if I ever need to test it), ELinks, our shell process, and a couple instances of a program called icosconfig. One of those was the job that stopped when we pulled the confused deputy gag on ELinks.

This is a Busybox shell, and obviously an old Busybox at that, but we can see from the environment variables that our parent process was the Telnet daemon (also Busybox), so this connection came over Telnet. Another weird thing is that our user ID is admin, not root. Let's have a look at the password file.

Despite at least one account claiming to be in the shadow file (pcap), there is no /etc/shadow, so everything is actually here. There are four user IDs, one being nobody, one named pcap (presumably for packet capture) that's effectively disabled, the admin account we're logged in as that's apparently a root clone, and root, which is also disabled. Only admin has a password.

But we can enable root, and Telnet is already listening, so let's get a session up where we can cut and paste and grab things instead of making another thousand screenshots. (Important note! If you're following along on your own Gobi, DON'T change the password file for this, because there's an easier way. But I had to do it myself to find out.) With the root password set to blank, let's log i...huh?

% telnet ██████████
Trying...
Connected to ██████████.
Escape character is '^]'.

(none) login: root
Cedar>

That's ... not a root prompt.

Cedar>ls
  Error: ls - invalid command

Cedar>help
  enable
  exit
  help
  ping
  quit
  show
  ?

Cedar>show
  Usage: show  <options>
  <options>:

  arp 
  auth ...
  config ...
  filter 
  interface ...
  ip ...
  ipsec ...
  memory 
  radio ...
  snmp 
  sntp 
  ssh 
  status 
  syslog 
  system ...
  telnet 
  vlan ...
  web 
  wireless ...
  wlan ...
  wds ...

Cedar>show system

  Model: Cedar 860AG
  Firmware Version: 2.1.0
  Firmware Build Time: Thu Nov 8 20:41:49 PST 2007
  System Name: (none)
  Login Name: root
  Session Timeout: 10 min
  System Time: 01/01/2000, 00:16:24
  System Uptime: 0 days 0 hours 16 mins 24 secs

Clearly we have some more corners of this system to explore (and we just found another GPL violation, potentially, in what Accutech did to Busybox). But right now I'd just like a proper shell (and the Accutech terminal doesn't seem to handle CTRL-C right either), so let's put telnetd on another port and ensure we get a shell. telnetd -p 2323 -l /bin/sh should do nicely.

We'll now switch over to a terminal session from my desktop Linux machine. But before we do:

The Cedar 860AG is, as defined by its manufacturer Intelicis, an enterprise access point with Ethernet and WiFi. This is no doubt what the Sun Ray firmware is using to configure its network settings during the "long dance," and if it loses connection to it, we've demonstrated it will likely be unable to connect to anything. That means a wrong move will brick this machine, especially since we're root and logged into the firmware, and there's no guarantee you can fix it from the UART. If you have one of these and you're following along, you deviate from this demonstration at your own risk. I'm not responsible for you wrecking your rare Sun Ray laptop.

First thing: who are we actually talking to? The Cedar 860AG mentions Atheros in its datasheet, so I have a good idea it's not the Au1550, and since there's a functioning /proc, /proc/cpuinfo confirms it:

# ls /
bin         home        lost+found  root        usr
dev         lib         mnt         sbin        var
etc         linuxrc     proc        tmp
# cat /proc/cpuinfo
system type             : Atheros AR5315
processor               : 0
cpu model               : unknown V6.4
BogoMIPS                : 183.50
wait instruction        : no
microsecond timers      : yes
tlb_entries             : 16
extra interrupt vector  : yes
hardware watchpoint     : no
VCED exceptions         : not available
VCEI exceptions         : not available

Interestingly it's detected as an "Atheros AR5315" but that's part of the same MIPS family. The architecture is well known to OpenWrt as quite a few routers use it, so add this little hidden one to the list.

The fun part about it being an independent system means even if the Au1550's Sun Ray firmware watchdog fires and the machine tries to reset, apparently the AR2316A locks it out while it's active. The console and framebuffer become inoperative until the machine is powercycled, but we remain logged in as long as we're connected remotely. Which leads to another question: who's the master processor on this laptop really?

# dmesg
# cat /proc/cmdline
console=ttyS0,115200 root=mtdblock2 mem=32M rw
# cat /proc/meminfo
        total:    used:    free:  shared: buffers:  cached:
Mem:  30789632 10969088 19820544        0        0  4980736
Swap:        0        0        0
MemTotal:        30068 kB
MemFree:         19356 kB
MemShared:           0 kB
Buffers:             0 kB
Cached:           4864 kB
SwapCached:          0 kB
Active:           1564 kB
Inactive:         5328 kB
HighTotal:           0 kB
HighFree:            0 kB
LowTotal:        30068 kB
LowFree:         19356 kB
SwapTotal:           0 kB
SwapFree:            0 kB
# cat /proc/swaps
Filename                        Type            Size    Used    Priority

No surprise: we saw a 32MB SDRAM chip, and that's what it has. There is nothing in dmesg, but the kernel command line demonstrates the root filesystem is flash via MTD. This is undoubtedly the flash chip we saw.

# ip addr
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
2: eth0: <BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:19:25:f1:c8:7d brd ff:ff:ff:ff:ff:ff
3: wifi0: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast qlen 199
    link/ether 00:19:25:f1:c8:7c brd ff:ff:ff:ff:ff:ff
4: sta0: <BROADCAST,MULTICAST> mtu 1500 qdisc noqueue 
    link/ether 00:19:25:f1:c8:7c brd ff:ff:ff:ff:ff:ff
5: wan: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue 
    link/ether 00:19:25:f1:c8:7d brd ff:ff:ff:ff:ff:ff
    inet ██████████/██ brd ██████████ scope global wan
6: lan: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue 
    link/ether 00:19:25:f1:c8:7d brd ff:ff:ff:ff:ff:ff
    inet 192.168.100.1/24 brd 192.168.100.255 scope global lan
    inet 192.168.11.1/24 brd 192.168.11.255 scope global lan:1
7: eth0.0: <BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc noqueue 
    link/ether 00:19:25:f1:c8:7d brd ff:ff:ff:ff:ff:ff
8: eth0.2: <BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc noqueue 
    link/ether 00:19:25:f1:c8:7d brd ff:ff:ff:ff:ff:ff
# netstat -a
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State      
tcp        0      0 *:2323                  *:*                     LISTEN      
tcp        0      0 *:telnet                *:*                     LISTEN      
tcp        0      0 ██████████:2323         ██████████:39326  ESTABLISHED 
tcp        0      0 192.168.11.1:telnet     192.168.11.5:50889      ESTABLISHED 
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags       Type       State         I-Node Path
unix  2      [ ACC ]     STREAM     LISTENING     1426   /tmp/socket0
unix  3      [ ]         DGRAM                    21     /dev/log
unix  3      [ ]         STREAM     CONNECTED     1391   
unix  3      [ ]         STREAM     CONNECTED     1390   
unix  2      [ ]         DGRAM                    633    

The output here is just about proof positive the VPN board fully controls the Ethernet jack. The only interface with the "external" (i.e., my internal test network) address is wan, and that MAC is the VPN board's (scroll back up for proof). What's interesting is that the same MAC is used for the internal Ethernet interconnect, and there's a second network 192.168.11.* to go with 192.168.100.*. Our stalled out console connection is over that network even though the VPN board seems to be listening on all interfaces and obviously responds on them.

I did a little test at this point just to see how wide open a barn door we had, but (to my relief and simultaneous vague disappointment) nothing responded to Telnet with the other two profiles. It looks like the hole only opens when the Accutech console browser does.

Let's bring the shell back up. What else answers on the internal network? We'll start with where the original Telnet connection originates from, but 192.168.11.5 doesn't answer on Telnet.

# telnet 192.168.11.5
telnet: Unable to connect to remote host (192.168.11.5): Connection refused

But after repeatedly checking numbers in that subnet, we find that 192.168.11.2 responds to pings. Does it talk to us?

# telnet 192.168.11.2

Entering character mode
Escape character is '^]'.


3g login: root
Password: 
Login incorrect

3g login: admin

Welcome to ICOS version 8.0

        Copyright (c) 2004-2007, Intelicis Corporation
        All rights reserved


Cedar>

We just found the IPX425 on the 3G board! And there's no password on the admin account! It looks like it's running the same type of embedded router operating system because we have a Cedar prompt. It calls itself "ICOS."

Cedar>show system

  Model: Cedar 860AG
  Firmware Version: 1.2.3.emobile.a
  Firmware Build Time: Mon Oct 15 15:23:02 PDT 2007

  System Name: 3g
  Login Name: admin
  Session Timeout: 10 min
  System Time: 01/01/1970, 00:07:35
  System Uptime: 0 days 0 hours 19 mins 35 secs
  
Cedar>show config

# Common Wireless Setting

# WLAN Intelicis-a
wlan add Intelicis-a
wlan Intelicis-a ssid Intelicis-a

# WLAN Intelicis-g
wlan add Intelicis-g
wlan Intelicis-g ssid Intelicis-g

# Serial port 1 configuration

# Radio 1 configuration
radio 1 freq a
radio 1 auto_channel_list 36,149
radio 1 basic_rates 6,12,24
radio 1 supported_rates 6,9,12,18,24,36,48,54
radio 1 wlanadd Intelicis-a

# Radio 2 configuration
radio 2 freq bg
radio 2 auto_channel_list 1,6,11
radio 2 basic_rates 1,2,5.5,11
radio 2 supported_rates 1,2,5.5,11,6,9,12,18,24,36,48,54
radio 2 wlanadd Intelicis-g

  Error: No /tmp/icos/bridge directory existed
# Network Protocol Configuration

Cedar>quit
Connection closed by foreign host.

It's a bit of a surprise to see this XScale core also identify itself as a Cedar 860AG. That said, the behaviour is a bit different from the Cedar prompt we got on the Atheros; it's quite possibly an earlier release of the software despite the later build date. It also looks like there's an embedded Linux or Unix under this too based on that error message referencing a missing /tmp/icos/bridge, but getting into it will probably require figuring out where the UART is. A project for another day.

From this we can reasonably conclude that 192.168.11.* is the internal "Ethernet-over-IDE" network, with .2 being the 3G board, .5 being the Au1550, and .1 being this, the VPN board (again: who's actually the main CPU?). Nothing appeared to answer on the 192.168.100.* network, so let's get back to the VPN board and this time dig around in the filesystem.

# df -k
Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/mtdblock2            6976      5304      1672  76% /
# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00030000 00010000 "RedBoot"
mtd1: 000e0000 00010000 "ICOS"
mtd2: 006d0000 00010000 "rootfs"
mtd3: 00010000 00010000 "RedBootCfg"
mtd4: 00010000 00010000 "AtherosCfg"

Aha, the boot loader is RedBoot! That's what Dusted-off Dreamcast Linux uses. With the rickety nature of this setup I'm concerned about dumping the individual partitions to the filesystem to exfiltrate them for analysis, but the firmware images I was provided by a kind soul seem compressed with a method I (nor binwalk) haven't figured out yet, so we might be able to get them off another way. While we think about that, let's look at some of the other binaries we saw running.

# busybox
BusyBox v1.00 (2007.11.01-21:12+0000) multi-call binary

Usage: busybox [function] [arguments]...
   or: [function] [arguments]...

        BusyBox is a multi-call binary that combines many common Unix
        utilities into a single executable.  Most people will create a
        link to busybox for each function they wish to use, and BusyBox
        will act like whatever it was invoked as.

Currently defined functions:
        [, ash, awk, busybox, cat, chgrp, chmod, chown, chroot, cp, cut,
        date, dd, df, dirname, dmesg, echo, egrep, expr, false, ftpget,
        ftpput, getty, grep, gunzip, gzip, halt, head, hostname, httpd,
        id, ifconfig, ifdown, ifup, inetd, init, insmod, iproute, kill,
        killall, klogd, linuxrc, ln, logger, login, ls, lsmod, md5sum,
        mkdir, mknod, modprobe, mount, mv, netstat, od, passwd, ping,
        printf, ps, pwd, reboot, rm, rmmod, route, run-parts, sdiff, sed,
        sh, sleep, sort, start-stop-daemon, swapoff, swapon, sync, sysctl,
        syslogd, tail, tar, telnet, telnetd, test, tftp, top, touch, tr,
        traceroute, true, tty, udhcpc, udhcpd, umount, uname, uptime,
        usleep, vconfig, vi, wc, which, whoami, zcat
# which icosconfig
/usr/sbin/icosconfig
# icosconfig
  Error: Missing argument
  Usage: icosconfig {bootinit | {get | set} {<module name> | serial_port | vlaninfo} <argument> | {init | save | reset | reboot} {system | <module name>} | shell | timer} 

I FTPed both files to my Linux desktop. file says they're an ELF 32-bit MSB executable, MIPS, MIPS32 version 1 (SYSV), dynamically linked, interpreter /lib/ld-uClibc.so.0, stripped. Combine uClibc (/lib/libuClibc-0.9.27.so) with the fact everything is busybox and we're actually looking at a uClinux system here. Cool.

icosconfig appears to be some sort of all-singing, all-dancing configurator like a proto-systemd, but worse, because it's even hackier. Shell commands appear liberally in the output of strings like

brctl addbr lan; ifconfig lan up; ifconfig eth0 up
brctl addbr lan; ifconfig lan up; ifconfig eth0 up; brctl addif lan eth0
brctl addbr vlan%d; ifconfig vlan%d up; vconfig add eth0 %d; ifconfig eth0.%d up
brctl addbr vlan%d; ifconfig vlan%d up; vconfig add eth0 %d; ifconfig eth0.%d up
ps -ef | grep "/sbin/dhcpcd-bin -Y -N %s " | grep -v grep 1>/dev/null 2>&1
route del default 1>/dev/null 2>&1 ; route add default gw %s dev %s 1>/dev/null 2>&1
grep -v "add -net 0.0.0.0 netmask 0.0.0.0 gw %s" %s/routecurr.conf > %s/routecurr.tmp; mv -f %s/routecurr.tmp %s/routecurr.conf
echo "add -net 0.0.0.0 netmask 0.0.0.0 gw %s dev %s" >> %s/routecurr.conf

It also contained the error message string we got when we were connected to the Cedar configuration prompt (and it contains the string Cedar), so it seems like Busybox login is hardcoded to call it by default. To prove this:

# login "-?"
login: illegal option -- ?
BusyBox v1.00 (2007.11.01-21:12+0000) multi-call binary

Usage: login [OPTION]... [username] [ENV=VAR ...]

Begin a new session on the system

Options:
        -f      Do not authenticate (user already authenticated)
        -h      Name of the remote host for this login.
        -p      Preserve environment.

# login -f admin
Cedar>show config
  Usage: show config  <options>
  <options>:

  all|startup|running|<config file name>

Cedar>show config all

Cedar>show config running

# IPSEC setting
ipsec off
ipsec autodial off
ipsec connect off
ipsec eazyvpn off
ipsec nat_traversal on
ipsec aggr_mode off
ipsec pfs off
ipsec replay_protect off
ipsec encryption 3des
ipsec hash md5
ipsec psk 
ipsec remote_ip 
ipsec remote_subnet 
ipsec remote_dhcp 
ipsec group_name 
ipsec group_key 
ipsec xauth_user 
ipsec xauth_password 
ipsec dns 
ipsec sunray 
ipsec firmware 
ipsec mtu 1356

# Interface setting
interface lan on
interface lan ip 0 addr 192.168.100.1 netmask 255.255.255.0 mode static
interface lan ip 1 addr 192.168.11.1 netmask 255.255.255.0 mode static
interface wan on
interface wan ip 0 addr 0.0.0.0 netmask 0.0.0.0 mode dhcp
interface sta0 off
interface sta0 ip 0 addr 0.0.0.0 netmask 0.0.0.0 mode dhcp

# WLAN Intelicis-g
wlan add Intelicis-g
wlan Intelicis-g ssid Intelicis-g

# Radio 1 (5GHz) configuration
radio 1 freq bg
radio 1 basic_rates 1,2,5.5,11
radio 1 supported_rates 1,2,5.5,11,6,9,12,18,24,36,48,54
radio 1 wlanadd Intelicis-g

# Network Protocol Configuration

Cedar>quit
#

Basically the configuration confirms what we saw from ip addr. It's interesting that show config all didn't actually show any config at, um, all.

To confirm icosconfig was the source of the prompt, I looked at the output of ps -ef from the shell on port 2323, then did login -f admin from the console and looked at ps -ef again. The new process was icosconfig shell, so:

# icosconfig shell
Cedar>

Now that we can access the Cedar prompt without having to log in over Telnet, at this point I went ahead and undid the change I made to root in /etc/passwd on the off chance it comes back to bite us later. That's why you don't need to do that yourself if you're following in my footsteps, as by this point we've figured out how to run it directly.

After all that, though, what was the password for the VPN board's admin account? When I first wrote this, I censored the hash in that screenshot because I figured that Accutech would have changed it to something random and embedded that in their binary. Indeed, letting John the Ripper at it on my 64-thread POWER9 Raptor Talos II for 72 hours didn't pop out anything obvious. Then I found the manual for the Cedar 860AG and the default username and password, which are admin and (no joke) changeitnow. Well, guess what worked on the first try, including for the Cedar prompt's enable command for additional privileges? And on the IPX425 3G board as well? You don't even need to crack the hash now. I mean, this thing just gets better and better the more I play with it.

Anyway, back to the filesystem. Exploration of ls -lR / shows many paths containing icos. ICOS looks like Intelicis' embedded baseline operating system which Accutech then customized as necessary for the 3G and VPN boards. Most of what's here are text configuration files like this one (I'm not sure if the enterprise number is supposed to be confidential, so I've suppressed it):

# cat /etc/icos/system/info
#Base template for system module to dynamically generate 
#proprietary snmpd config file upon initialization
#
#Enterprise number of Intelicis Corp. is ████
prompt=Cedar
enable_prompt=Cedar
model=Cedar 860AG
enterprise=████
syslocation=Intelicis Corporation
syscontact=support@intelicis.com

For obvious reasons, I won't mess with those configuration files; we'll stick to the commands exposed to us at the Cedar prompt.

Looking around some more, a fair amount of data was unpacked to /tmp for reasons unclear to me since /tmp is just part of the filesystem rather than in-memory. Fortunately some of these files have unusual dates, suggesting that they were just left there rather than the flash overwritten with new copies every time the VPN board starts (whew, that would be really bad).

# ls -l /tmp
-rwxr--r--    1 root     root         1354 Jan  1 00:00 elinks.conf
drwxr-xr-x    1 root     root            0 Jan  1 00:00 etc
-rw-r--r--    1 root     root           21 Jan  1 00:00 eth0.out
drwxr-xr-x    1 root     root            0 Jan  1 00:00 icos
drwxr-xr-x    1 root     root            0 Dec  9  2006 icosscripts
drwxr-xr-x    1 root     root            0 Jan  1 00:00 lib
drwxr-xr-x    1 root     root            0 Jan  1 00:00 lock
drwxr-xr-x    1 root     root            0 Jan  1 00:00 run
srw-------    1 root     root            0 Jan  1 00:01 socket0
-rw-r--r--    1 root     root           21 Jan  1 00:00 sta0.out
drwxr-xr-x    1 root     root            0 Jan  1 00:00 tmp
# ls -ldt /tmp
drwxrwxrwx    1 root     root            0 Jan  1 00:00 /tmp

Most of the elinks.conf file is comments. There are only a couple terminal options set and nothing else. When does the fail stop, exactly? Can I get off this fail bus?

There are also stub shell scripts in /usr/local/lib/ipsec/mips-uclibc/bin for mips-uclibc-gcc and others, but the actual compilers are not present, so these files just take up space just like the other pieces of ICOS that aren't actually used.

The overall impression is that Accutech just threw ICOS on the flash and did the minimum to make it work. In particular, I suspect icosconfig is basically as shipped; I don't think Accutech wrote it. Admittedly you probably wouldn't be motivated to clean the house either if you didn't think you'd get any uninvited guests.

Our last mystery is to figure out where the kernel is. We'll start by trying to get the RedBootCfg partition and see what it loads.

# dd bs=512 count=128 if=/dev/mtd3 | od -x
0000000     5265    6442    6f6f    7400    0000    0000    0000    0000
0000020     a800    0000    a800    0000    0003    0000    0000    0000
0000040     0003    0000    0000    0000    0000    0000    0000    0000
0000060     0000    0000    0000    0000    0000    0000    0000    0000
*
0000360     0000    0000    0000    0000    0000    0000    c69f    f81b
0000400     5265    6442    6f6f    7420    636f    6e66    6967    0000
0000420     a87e    f000    a87e    f000    0000    1000    0000    0000
0000440     0000    0000    0000    0000    0000    0000    0000    0000
*
[...]
*
0177760     0000    0000    0000    0000    dead    dead    a06c    e27e
0200000

I cut and pasted the output as input to this Perl script on my workstation:

#!/usr/bin/perl

$pos = 0;
select(STDOUT); $|++;

while(<>) {
        chomp;
        next if (/\+/); # skip dd output
        if (/^\*\s+$/) {
                $star = 1;
                next;
        }
        @h = ();
        ($oc, $h[0], $h[1], $h[2], $h[3], $h[4], $h[5], $h[6], $h[7], $x) =
                split(/\s+/, $_);
        next if length($x);
        $hex = ''; map { $hex .= $_ } @h;

        $npos = oct($oc);
        if ($star) {
                print STDOUT "\0" x ($npos - $pos);
                $star = 0;
        }
        print STDOUT pack("H*", $hex);
        $pos = $npos + length($hex)/2;
}

This yielded a 64K binary, exactly the size of the partition, so I figured it likely transferred correctly but it wasn't very helpful:

% strings mtd3
RedBoot
RedBoot config
FIS directory
kernel
rootfs
boot_script
boot_script_data
boot_script
fis load -d -b 0x80040000 kernel
go 0x80040000
boot_script_timeout
boot_script
bootp
bootp_my_gateway_ip
bootp
bootp_my_ip
bootp
bootp_my_ip_mask
bootp
bootp_server_ip
console_baud_rate
gdb_port
info_console_force
info_console_number
info_console_force
net_debug

Next I exfiltrated the ICOS partition. This seemed rather larger and was a good bet.

% file mtd1
mtd1: gzip compressed data, last modified: Fri Nov  9 04:44:12 2007, from Unix, original size modulo 2^32 0
% gunzip -c < mtd1 > gobi.kernel

gzip: stdin: decompression OK, trailing garbage ignored
% strings gobi.kernel | grep Linux
Linux version 2.4.25 (jiant@develop) ( /opt/devicescape/toolchains/mips-linux/bin/../libexec/gcc/mips-linux/3.4.1/collect2 --eh-frame-hdr -EB -dynamic-linker /lib/ld.so.1 -L/opt/devicescape/toolchains/mips-linux/mips-linux-uclibc/lib -L/opt/devicescape/toolchains/mips-linux/mips-linux-uclibc/lib -L/opt/devicescape/toolchains/mips-linux/bin/../lib/gcc/mips-linux/3.4.1 -L/opt/devicescape/toolchains/mips-linux/bin/../lib/gcc -L/opt/devicescape/toolchains/mips-linux/bin/../lib/gcc/mips-linux/3.4.1/../../../../mips-linux/lib -L/opt/devicescape/toolchains/mips-linux/bin/../lib/gcc/mips-linux/3.4.1/../../.. --dynamic-linker /lib/ld-uClibc.so.0 -rpath-link /opt/devicescape/toolchains/mips-linux/mips-linux-uclibc/lib /opt/devicescape/toolchains/mips-linux/mips-linux-uclibc/lib/crti.o /opt/devicescape/toolchains/mips-linux/mips-linux-uclibc/lib/crtbegin.o /opt/devicescape/toolchains/mips-linux/mips-linux-uclibc/lib/crt1.o -lgcc -lgcc_eh -lc -lgcc -lgcc_eh /opt/devicescape/toolchains/mips-linux/mips-linux-uclibc/lib/crtend.o /opt/devicescape/toolchains/mips-linux/mips-linux-uclibc/lib/crtn.o) #422 Thu Nov 8 20:41:49 PST 2007
[...]

Looks like we got it; the entire partition is the kernel, which in retrospect I should have immediately suspected from the name. I can't tell if this was something Accutech or Intelicis built but I'll lay good odds it was the latter.

That's enough messing around. Now that we're in it, what can we do with it? I'd love a way to open a client socket other than Telnet, for one thing, but it doesn't look easily possible. The Busybox version here lacks a number of core applets like netcat/nc and its shell doesn't understand /dev/tcp, and of the other non-Busybox executable files present none seem to offer such functionality. Creating a cross-compiler setup for a kernel this old (and matching the included uClibc) is likely to be a challenge. I did find some precompiled big-endian MIPS binaries of things like netcat and socat, but they either were for later versions of Linux or later CPUs, neither of which worked here.

But this Busybox does have awk, so at least we have some sort of scripting language better than the shell, and we do certainly have elinks, which got us to this point in the first place. We can do a lot with awk and an HTTP client. Maybe I'll try my hand at writing a MIPS ELF binary in a hex editor that does netcat in assembly language with syscalls. That sounds like a great future entry ...

The Gobis are in my humble opinion the most spectacular of the Sun Ray laptops for those nearly fatal idiosyncrasies, but while they were probably the Sun Ray 2 laptop produced in the largest numbers, no MIPS Sun Ray laptop is very common and none sold in volume. Both Accutech and Naturetech closed up shop shortly after. Post-Oracle, the 2011 Sun Ray 3 series upgraded to the 660MHz RMI (who bought Alchemy's IP from AMD) Au1380 and later the MIPS64 RMI (later Broadcom) XLS104, an SMT-4 750MHz CPU on a 90nm process, but although the core design remained very similar, power consumption for the later devices ranged from a typical 14W to as high as 36W.

No laptop Sun Ray 3 was ever produced. While the power requirement was a partial explanation, the biggest reason was simply that laptop Sun Rays had been replaced ... by laptops. The 2008 Tadpole M1400 we explored previously and its relatives were the last Sun Ray mobile systems, with the firmware newly ported to run on off-the-shelf Linux-based x86 hardware instead of MIPS. The way forward was thus obvious. Sun introduced a pure-software client in 2009, the Sun Desktop Access Client, which ran on Windows and later on Mac. With improved central management tools, the advantages of a firmware-locked purpose-built Sun Ray mobile system were outweighed by the cost and flexibility advantages of deploying locked-down commodity laptops instead. Oracle rebranded the Desktop Access Client as the Oracle Virtual Desktop Client before discontinuing the entire technology in 2014.

In the meantime, it turns out I had "another" MIPS Linux system inside my MIPS Sun Ray laptop all along and got to spend a delightful few days breaking into it. The 2N is a lot safer to use but a lot less interesting to work with even if the Gobi is interesting for all the wrong reasons: a unique but ramshackle multisystem architecture prone to failure, gaping holes that could have been trivially mitigated, and the indefensible use internally of default passwords. In fact, the Gobis' critical dependence on the VPN board for connectivity can't help but lead me to conclude that the AR2316A is the real central processor, and the Au1550 is just its front end. Only their rarity and the non-standard configuration required for penetration prevented these machines from being the stuff of hacker legend during their era. Like IoT, the S in "embedded" is apparently for security too.