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?
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″ 1024×768 75Hz/24-bit TFT LCD and isn’t too bad, considering (a virtual desktop extends up to 1280×1024 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 1024×768. 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 1280×1024).
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
chroot
ed 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
