The university only used the big stuff, though, not "low end" pizzaboxen like the versatile and (relatively) ubiquitous 9000/712 "Gecko," which besides being a popular 1990's RISC workstation of its own — id Software had one during their NeXTSTEP days — turned up as the system base in other surprising places. One of these was HP's own Agilent 16505A protocol analyser, and another was as the basis of the MIL-SPEC SAIC Galaxy portable workstations.
That dovetailed nicely with one of my major collecting specialties, which is non-x86 portables — I'm not just talking PowerBooks and ARM here, friends, and we'll explore some of those machines at a later time as well. But because these machines were often in classified or high-security environments, few escaped to the outside world and my current verified count of existing machines is just five, including my own. I managed to acquire a broken (like, literally fractured) Galaxy 1100 a number of years ago and tried gutting a 16505A to repair it but never got it past the boot screen, so when a working one turned up in March 2019 I jumped on it. This unit, which only required a minor amount of case repair, got refurbished with a SCSI2SD and a fresh installation of the PA-RISC port of NeXTSTEP 3.3, and runs it splendidly.
But now I've managed to land a second working unit, and comparing their original hard drives has been an interesting dive into the security bowels of the U.S. federal government (especially since these units can actually boot them, unlike my dead Apple Network Server prototype from Netscape/AOL). Plus, it seemed like a good opportunity to talk in more detail about their internals and their history, take a tour of HP-UX and HP VUE prior to the "one ring to rule them all" of the Common Desktop Environment, and what this 16-pound tank of a portable workstation was actually used for ... and why you should always clear your cache on a secure system lest someone like me find the hard disk decades later.
Before all that, though, a droll tale from the military-industrial complex.
In 1982, the United States Chief of Naval Operations sponsored the Desk-Top Computer (DTC) program to provide a common fleet standard for "tactical decision support"; at some unspecified point the acronym evolved specifically to "Desktop Tactical Computer." For cost reasons the CNO chose an off-the-shelf system rather than demanding TEMPEST and MIL-SPEC compliance. While the Hewlett-Packard 9836U and 9020A systems were initially selected, the HP 9020C (also known as the 9000 Model 520C, based on an 18MHz FOCUS CPU) won out and became widely deployed. DTC-1 was the first of the U. S. Navy's several deployments of Hewlett-Packard microcomputers. Although the subsequent DTC-2 deployment used Sun-4 hardware, the Navy returned to HP for what was renamed the "Tactical Advanced Computer" with TAC-3, selecting the HP Apollo 400 series.
In 1993, the Navy issued a solicitation for the newest iteration of TAC, TAC-4, intended as "the next generation of computer workstations, software, support services and logistics in support of Naval requirements, afloat and ashore. It will provide the 'common engine' for mission and mission support applications, tactical, and non-tactical." Despite simultaneous proposals from Sun and Digital, HP landed the contract again for an estimated US$672.6 million (about US$1.39 billion in 2023 dollars), the largest HP ever handled to that point, which included hardware and software deployment for multiple operating environments along with upgrading the existing TAC-3 machines. HP filled this need with their up-and-coming PA-RISC hardware, in particular the 9000/712 workstation as a desktop client along with other 9000/700 machines like the /743i, /744 and later the J210, gradually moving to more conventional PCs and Intel servers as the multi-year contract progressed. TAC-4 was a big deal to HP and the effort was hardly secret; HP even printed up large stickers like these, and TAC-4 branding was also part of the operating system as we'll show. (Dig the International Code of Signals flags for Tango Alfa Charlie, though that combination of flags doesn't mean anything in ICS.)
The machines could absolutely be used as "conventional" workstations with the lid closed and connected to external devices. Closing the lid does not power it off or sleep the system. Switches in the back select the internal keyboard and trackball supported by modifications to the 712's logic board, or you could attach a PS/2 keyboard and mouse. Headset output and two audio inputs, DE-9 RS-232 serial, VGA, parallel, SCSI and Ethernet (AUI or twisted-pair) complete the port selection.
The 80MHz PA-7100LC processor is under the blue metal heatsink; the crystal south of that serves as the main system oscillator, a 160MHz part divided down by 2 for the CPU clock. The PA-7100LC is a 2-way superscalar core that supports MAX-1 SIMD and has two integer units and one floating point with a five-stage pipeline. The CPU directly attaches to the bus and has its own onboard memory controller (MIOC). PA-RISC systems are unusual for supporting multiple levels of L1 cache, and sometimes of massive size: here, the PA-7100LC has 1K internally that prefetches from an additional 256K of directly attached direct-mapped external L1 to the left of it. On top of that, unlike most processors, the PA-RISC cache is physically tagged but virtually indexed. The 60MHz board has just 64K of external L1 which hobbled the slower board even more than the clock speed would suggest, and although the PA-7100LC is one of the minority of PA-RISC processors that could support L2 cache, the /712 logic board has no provision for it.
There are only four RAM slots on the 60MHz and 80MHz boards which take 72-pin 60ns FPM ECC SIMMs up to 32MB, so the limit is 128MB. Memory must be installed in pairs from the front going back; this machine has two 16MB sticks for 32MB of RAM, but my NeXTSTEP system has four 32MB sticks for the maximum 128MB. 64MB SIMMs exist but are not known to exceed the logic board maximum (the 100MHz variant can take six sticks for a ceiling of 192MB, but SAIC never used that board).
Also identifiable are the Western Digital WD37C65C floppy disk controller (dated 35th week 1995), the Crystal CS4125 16-bit "Harmony" audio chip (1st week 1996), a Fil-Mag 78Z1120D-01 10BaseT interface (35th week 1995) and a Maxim MAX211 RS-232 serial transceiver (1st week 1996). Both my units have version 2.2 ROMs which seems comparatively recent. Not visible here are the Intel 82C596CA 10Mbit Ethernet controller, the HP 1FT1 LASI ("LAN SCSI") ASIC containing the NCR 53C710 Fast & Narrow SCSI-2 controller as well as the system bus logic, and the HP 1FU2 CRX Artist onboard graphics ASIC with 1MB of VRAM, all on the underside of the board.
At the bottom of the board are the power connector, the SCSI pin header (the cable isn't keyed, so watch out), the speaker cable (red/black wires), the fan connector (unused on the Galaxys), and the floppy disk pin header. This is a regular 34-pin PC floppy disk connector, though it needs a twisted floppy disk cable to properly select the single disk as drive 0. You don't need the floppy connected to run the system, which makes it a bit easier to work with if you're just slinging SCSI disks. Both hard disks were Seagate Hawk ST32151N 5400rpm SCSI-2 "narrow" (i.e., 50-pin) drives.
The GIO slot in the Galaxy is occupied by a second graphics card, a custom SAIC job which looks like a second CRX Artist card to the operating system and uses the same HP 1FU2 ASIC. It carries 2MB of VRAM on the card, same as the on-board Artist graphics (the A2263-66520/A4025A VRAM card installed in front of the SAIC graphics board upgrades the on-board graphics to 2MB). 2MB Artists support up to 1280x1024 with 8-bit colour enhanced by HP Color Recovery, which uses a special DSP to implement a 24-bit visual in hardware with minimal dither artifacts.
Although the SAIC Artist card may have been derived from it, this card is definitely not the same as the A2878-90010/A2878A second monitor card. Unlike the A2878A, which cannot act as the console, the SAIC card not only can but does so by default because it, not the onboard Artist, drives the LCD (and some of the LCD video hardware is on the card as well). This yields the atypical situation where the built-in display is actually the secondary one; the primary display is in fact the external VGA connector which is always available. As there are two Artists in the Galaxy, it can support dual displays.
It's time to start the operating system.
SAIC HP-UX 10.10
Both of my machines came to me with HP-UX 10.10; what was loaded on top of that is, of course, the current topic of interest. Naturally they can run Linux or NetBSD, but where's the fun in that? They'll run 10.20 fine, 11.00 badly, not least because of its larger size (you'd want at least the full 128MB of RAM), and 11i past v1 not at all. It's possible later kernels don't support Cirrus, but unless you have and require the SAIC PCMCIA modem card, that's undoubtedly no perceptible loss — NeXTSTEP doesn't support it either. However, it's also notable that neither of these systems have any later version of HP-UX installed despite the length of time they were apparently in service (10.20 came out in September 1996).
There is no evidence that the Galaxys were ever sold commercially outside of their HP subcontract, though obviously some made it to the outside world like these units here, presumably through surplus resellers or scrappers and the like. That said, the most recent addition to my collection wasn't a TAC-4 system but rather vanilla HP-UX 10.10 with SAIC custom branding. We'll call this our "civilian" machine.
The reseller I bought it from said they couldn't break into it and thus were selling it as is (and knocked 25% off as an enticement). We can change the root password by bringing the kernel up single-user, but this particular machine surprisingly has an older version of the HP-UX Initial System Loader (ISL), specifically version A.00.25 dated November 10, 1992, and I think the different syntax it requires threw off the seller. We bring up ISL from the boot monitor with boot primary isl instead of just boot primary (here abbreviated to bo pri isl) and ordinarily would then give ISL the hpux -is command, but this version of ISL also needs you to specify where the kernel is (hpux -is /stand/vmunix).
Other than root, the only other user account with a password (there's no shadow password in this version of HP-UX) was an account jpo (short for jpoco, in the GECOS field) with a home directory /usr/jpo (not in /home). There were relatively few files here and only the default .profile (the user's shell was Korn shell) and graphical login setup, but .sh_history had some interesting stuff like
PS1=YOUR ORDER, YOUR HIGHNESS ECHO echo $PS1 PS1=xxxxx PS1="Your order, your highness" PS1=$ PS1=Your order, your highness PS1="Your order "
which seems like someone was playing around with the box, but later on there's more serious stuff like
mv ./tic cols ll cols pwd ./cols env man PATH cat /etc/default/login find / -name default 2>/dev/null cat /etc/default cat /usr/newconfig/etc/default /usr/newconfig/tcb/files/auth/system/default cols pwd vi autopvcs
which seems more consistent with developer work. None of these commands are of course timestamped. This user's last login in wtmp was April 17, 2000.
uname said
# uname -a HP-UX laptop01 B.10.10 A 9000/712 2008790574 two-user license
revealing its hostname as the supremely unoriginal laptop01, if your lap is the size of André the Giant's. But that wasn't its first host name, because there was also leftover mail to root from the system in /mbox and /var/mail/root, both timestamped January 1, 2000, and the mailboxes detail at least some portion of its history. On January 20, 1997, it was in the U.S. Pacific timezone named master and had a class A IPv4 address starting with 15.*, which at the time was entirely Hewlett-Packard's range. On February 24, 1997, its hostname was changed to mygal and it was given a nonsense address 123.45.67.8. On March 11, 1997, it was relocated to the Eastern timezone and renamed laptop01, but configured as "a standalone system" without a network address. That notification was the last mail message to root.
jpo had some mail, too, but only for a few days in February 2000. Among other things,
From jpo@laptop01 Mon Feb 7 05:19:24 EST 2000
Received: by laptop01
(1.39.111.2/16.2) id AA011208764; Mon, 7 Feb 2000 05:19:24 -0500
Date: Mon, 7 Feb 2000 05:19:24 -0500
From: jpo@laptop01
Return-Path: <jpo@laptop01>
Apparently-To: jpo@laptop01
###
#
#
#
#
#
###
# ####### # # #######
# # # # # #
# # # # # #
# # # # # #####
# # # # # #
# # # # # #
####### ####### # #######
###### # # ####### # #
# # # # # # #
# # # # # # #
###### # # # #######
# # # # # # #
# # # # # # #
# # ##### # # #
I'm going to assume these were test messages, but if they weren't, I hope they were very happy together. Other than similar messages and one piece of bounced mail, that was it. There was nothing past February 7, 2000.
I blanked out the root password and brought it up multi-user.
Those of you experienced with legacy proprietary Unixes and older hardware might think this is just an oddball Common Desktop Environment (CDE) login, but it's not, and it's not just the SAIC branding either. Instead, this is CDE's immediate ancestor, the HP Visual User Environment (VUE). The version we'll be using is 3.0, the final version of HP VUE initially introduced with HP-UX 9.0. My HP-UX 8.0 9000/350 runs VUE 2.0, the original VUE release for HP-UX and an upgraded port of VUE 1.0 that ran on Apollo Domain/OS after HP acquired them. HP-UX 10.20 in 1996 was the last version of HP-UX to ship with the HP Visual User Environment (VUE) as an option and the first to support CDE, three years after HP, IBM, Sun and Unix System Laboratories agreed to cease hostilities in the "Unix Wars" and develop a common user interface to battle their mutual enemy Microsoft.
The visual similarities are no accident: CDE was directly descended from VUE, itself based on Motif and the Motif Window Manager (mwm), so CDE also became based on Motif. While the other parties contributed various components to CDE, HP VUE had the most impact on the user experience; even the configuration files were similar enough such that HP could offer a largely automatic migration tool to convert them. We'll point out some of the (mostly minor) interface differences as we go along.
VUE Lite is a modest trimming of the core, featuring "enhanced system performance by omitting full icon-based file management, full session management, and file annotation" (per the 3.0 manual). I found little performance difference between the two on this system, but machines that are even slower or with comparatively more constrained RAM may see a positive improvement.
The most obvious difference, however, is the front panel. Out of the box I find VUE's more functional than CDE's: not only do you have six default workspace shortcuts ("One" through "Six") instead of CDE's default four, as well as the same clock, mail, style manager, printer, filer, trash, app drawer and help shortcuts, you also have a CPU load indicator and dedicated shortcuts for managing the workspaces or opening a terminal window or text editor. And those are things you do a lot. HP's badging is a little gratuitous but we'll grant them the indulgence (it just gives you an about box if you click on it).
Note that this doesn't list anything "sideloaded," of course. For example:
# ls /opt audio graphics nettladm upgrade dce ifor screencapture video dcelocal image sharedprint
Among other things, this system also has an image viewer, audio support for Harmony and display drivers, as well as OS support for the Distributed Computing Environment, the remote procedure call mechanism HP inherited from Apollo when it bought them out and became part of the collective vendor efforts behind OSF/1. Ironically, DCE primarily survives today in the form of Microsoft Distributed COM (via MSRPC).
The /opt/video directory is particularly interesting as it's a remnant piece of HP MPower, intended as a collabourative environment for VUE that supported scanning and faxing images and documents, shared X clients and whiteboarding, and working with video, audio and images. It doesn't seem to be configured on this system, though, and the only pieces of MPower present are the audio editor (which doesn't work), the screen capture tool and the image viewer. HP decommissioned it with HP-UX 11i and it was only supported on certain workstations and HP X terminals, but the strings in /opt/video/lbin/vlServer still have my favourite system message ever: "No Problem, Dudes and Dudettes"
While the help facility isn't unlike what we saw in Sun's OpenWindows functionally (which was PostScript-powered), obviously it most resembles CDE's help system visually. The VUE 3.0 Help Viewer was indeed accepted "almost as is" (in HP's words) as part of CDE.
However, what it views changed radically. CDE help documents start as SGML files using a DTD called HelpTag, and are then "compiled" into another SGML-based distribution format called Semantic Delivery Language (SDL, confusingly to modern audiences), the chief difference being that Semantic Delivery Language is optimized for more efficient display. An SDL "runtime help file" breaks up sections and chapters from HelpTag source into blocks and forms, merging them with various style sheets ("tables of semantics and styles," or TOSS) into a collection of self-contained virtual pages with no external dependencies other than images. Applications distribute a single .sdl file, plus any graphics. A list of identifiers (LOIDS) in the runtime help file serves as the index.
So VUE was just an earlier version of that scheme, right? Well, no. Let's look at this very same help "document" itself as displayed by the Help Viewer in /usr/vue/bin/helpview. In fact, it's several files:
# cd /usr/vue/help/C/Vueintro # ls -l total 232 -r--r--r-- 1 bin bin 5967 Nov 18 1995 Vueintro.hv -r--r--r-- 1 bin bin 2822 Nov 18 1995 Vueintro.hvk -r--r--r-- 1 bin bin 45206 Nov 18 1995 Vueintro00.ht dr-xr-xr-x 2 bin bin 1024 Feb 24 1997 graphics -r--r--r-- 1 bin bin 6644 Nov 18 1995 rVueintro.hv -r--r--r-- 1 bin bin 2822 Nov 18 1995 rVueintro.hvk -r--r--r-- 1 bin bin 51552 Nov 18 1995 rVueintro00.ht # ls graphics DT-icons.pm VIctrStyMgr.pm VIminHlpMgr.pm helpmgr.pm sampleicon.pm VIctrDskJet.pm VIctrSubPnl.pm VIminStyMgr.pm hplogo.xwd subpanel.pm VIctrDtMenu.pm VIctrWmMinz.pm VIminToolbx.pm info.pm sysadmin.pm VIctrFax.pm VIf1Key.pm VIminWmIcon.pm minifm.xwd tools.pm VIctrFilMgr.pm VIminDtIcon.pm VImseClick.pm minifp.xwd tour.pm VIctrLjet2.pm VIminFilMgr.pm VImseDrag.pm miniicons.xwd users.pm VIctrLjet3.pm VIminFrPan2.pm exit.pm miniterm.xwd welcome.xwd VIctrMktPla.pm VIminFrPanl.pm help-mgr.pm password.pm wspic.tif
Vueintro is presented to non-superusers; a special administrator-specific rVueintro is presented to root, which is what we see here. The .hv "Help Viewer" files define the topic list, topic hierarchy (what identifier is a topic's parent, or nothing for the top-level), and then a directory matching topics to the .ht file containing them and the byte offset within it. A keyword-topic index resides in the .hvk file. As for the graphics, they're all XPM (.pm), XWD (such as the "Welcome to Your HP Workstation!" text, which is actually an image), or TIFF (the nice artsy graphic, which is pre-dithered).
That's all straightforward enough, but the .ht file itself is mostly opaque binary other than the inexplicable text <TOPIC charset iso8859-1></TOPIC>. binwalk couldn't make head nor tail out of it. That solitary tag suggests some sort of SGML-based format, but nobody knows, apparently not even Hewlett-Packard themselves: HP in the 8/96 Hewlett-Packard Journal admitted that the "distribution format [for VUE 3.0] was known only within HP and then only by some members of one division. The specification of this distribution format was never published or intended for publication." They also considered the need for multiple files to be a liability (NARRATOR: It was.), "resulting in problems such as losing one or more of the files during installation." Oops.
The Personal toolbox draws from tools in the user's home directory (the default set here is provided from /usr/newconfig if none exist); General consists of the applications pre-installed on the machine. Network lets you run VUE actions on remote machines you have access to via DCE RPC, but naturally no such machines are present, and Marketplace was invariably empty since no upstream products are available.
HP also included a simple date book, and there were various "unsupported" applications including this Columns game. I appear to have been the first one to actually play it on this computer because the high score list was totally blank.
Before we leave for the SCIF to try TAC-4, though, let's take a brief look at HP VUE Lite.
TAC-4
That's enough background for us to move to the TAC-4 hard disk. Before we continue, let's get a couple things straight, especially since right now no one in the federal government can apparently handle classified information properly: nothing I'm going to show here has any known classification level, not even Controlled Unclassified Information, Sensitive But Unclassified or For Official Use Only, none of which are technically classified anyway. I myself carry a federal security clearance because $DAYJOB and I don't care to jeopardize it.
That said, I was also not able to find anything on the hard disk that appears to be classified in any case. Most likely such materials resided on a central server, which we'll show how we know this machine to have accessed. I will intentionally not provide IP addresses or certain unrelated FQDNs in case portions are still operational, but we can derive what the machine was used for, and as the purpose it served is already known openly I see no issue with talking about it here.
In single user I blanked the root password and took a look around. Its clock stopped at May 19, 1998, 4:08pm Eastern Daylight Time (last verifiable login was April 29, 1998, at 6:24am). There were no other users with a password other than root. The root user had no shell history, and only a default .profile and VUE configuration, but had run Netscape. We'll come back to this.
uname was exactly the same as the civilian installation except for the hostname (which was taped to the front; I've removed it):
# uname -a HP-UX osfhp03 B.10.10 A 9000/712 2008790574 two-user license
This machine was named osfhp03. The derivation of the HP part is obvious (I suppose there were at least three in this location), but not sure what OSF meant (Operational Support Facility?) except that it probably didn't mean OSF/1.
There was nothing in /home and nothing in /usr that looked like an orphaned home directory, but there was an odd directory /h:
# ls -a /h . AcctGrps CompT GZIP SAMBA h.tar .. COE DAZ JETADM USERS public APACHE COTS EM PrtDrivers data
The h.tar looked like it was sideloaded here from some other system and suggests it enabled server functions (given Apache, Jet Admin and Samba), though we don't know if this machine actually ran those, of course.
The COE directory is also noteworthy. This appears to be compliant with The Open Group's Common Operating Environment and at that time minimally required Perl and Netscape Navigator (on this system 5.003 and 4.04 respectively) along with a webserver (Apache). There is also a JVM installation and Tcl along with other components. COTS even had a PA-RISC version of Adobe Acrobat Reader 3. The USERS directory contained various profiles including for the web server and for anonymous FTP. The most recent file was date-stamped April 20, 1998.
I'm going to tell this story in the "right" order without cheating now that you've seen the basic interface. When I restarted and tried to enter VUE the machine put up the copyright message, but after an interminable wait stalled out with this fatal error:
Don't bother trying to resolve that from your home desktop because you can't. Broadly speaking, in a United States Department of Defense facility that handles sensitive or classified information, different classification levels live on different, separated networks as part of the overarching Defense Information System Network (DISN). Top Secret material and/or Sensitive Compartmented Information uses the DoD's Joint Worldwide Intelligence Communications System, or JWICS, and virtually any DoD SCIF will be connected to it. On the other hand, unclassified information travels on the Non-classified Internet Protocol Router Network (NIPRNet), which replaced MILNET (separated from ARPANET in 1983) in the early 1990s, though anything on any of the other networks can also be unclassified.
For the Secret or Confidential information in the middle, that goes over either JWICS or the Secure Internet Protocol Router Network, or SIPRNet. SIPRNet is sort of a pocket parallel Internet universe with its own services like SIPRNet-specific websites and E-mail. Unclassified information can also be on SIPRNet, including on SIPRNet-only sites. The giveaway that this system was connected to SIPRNet is the .smil.mil part: that second-level domain is unique to SIPRNet. For the U.S. Department of State, which also uses SIPRNet, there's a corresponding .sgov.gov.
What about the adnet. part? Well, that alone tells us generally where this machine was used. ADNET, the Anti-Drug Network Program, came out of the Defense Authorization Act for Fiscal Year 1989 and the Defense Appropriations Act of 1990 directing the Secretary of Defense to create a communications network for U.S. assets involved in drug interdiction and counternarcotics, whether dedicated or partial, civilian or military. It provides real-time secure communications (including radio and satellite, not just over SIPRNet), data sharing and analysis capabilities. As early as 1991, 88 DoD and law enforcement systems at 59 sites were already connected throughout the Western Hemisphere and Europe according to a December 1991 U.S. General Accounting Office brief.
To have that default domain in its DNS settings means this system must have been on the inside. Unlike the more careless user of our civilian unit, however, there are no residual system E-mail boxes here to get the history and the same GAO brief also documents 27 possible locations in that timezone in multiple settings — I might add none of them matching the acronym OSF — so we can't get much more specific than the eastern United States. In /h/COTS/ADNET there are jobs to execute in cron and various client binaries, but they're just things like an audio and animation player, FTP client and log rotator, and there's no knowing if this machine ever even ran them. By 2015, from the most recent Defense Information Systems Agency budget I could cursorily locate, there were 45 core sites in ADNET but over a thousand connected devices.
I mentioned that the root user had run Netscape at some point and while they only had default settings and bookmarks and an empty mailbox, they didn't clear their browser cache. There was exactly one site in the cache called adnetdns, an unclassified resource, downloaded over SIPRNet. Here is how it appeared on April 27, 1998, at 9:26AM Eastern, authentically rendered in Netscape Navigator 4:
Correspondingly, given its branding and identical operating system version, my best guess for what our civilian machine was doing was probably support for the (by then) legacy TAC-4 systems still in operation like this one. As such it was almost certainly used by SAIC themselves, probably out of or supervised by their Reston, Virginia office.
Okay, that's enough messing around; time to log in as root.
# ls /var/adm/sw/products 0200AC-core-pat InstantIgnite SOE TAC4-powerchute 0200AC-supplmnt International SUPPORT-TOOLS TAC4-xmcd Accounting InternetSrvcs SW-DIST TerminalMngr AudioSubsystem JournalFS ScreenCapture TextEditors B3782DA Keyshell SecurityMon TextFormatters Curses-Color LSSERV SharedPrint UUCP DCE-Core LVM SourceControl Upgrade DCE-CoreTools MSDOS-Utils Spelling VME-Services DFS-Core MailUtilities Streams VUE DigitalVideo NCSNCK Streams-TIO X11 DirectAccess NFS SystemAdmin X11BMS DiskQuota Networking SystemComm eeprom-driver Diskless NonHP-Terminfo TAC4-15-inch fax-application EMACS OS-Core TAC4-PDU ifiles GraphicsCommon PHCO_6641 TAC4-XPAX pcmcia-driver GraphicsPEX5RT PHKL_7615 TAC4-copyright pcomm HPUXEngRT700 PowerShade TAC4-ghostscript swlock INDEX PrinterMgmt TAC4-lmgrd xmodem ImagingSubsystem ProgSupport TAC4-logo zmodem
The TAC4-* packages are almost all standard utilities and it's noteworthy they were explicitly TAC-branded. I really don't know why a CD player (xmcd) or Ghostscript or license manager (lmgrd) needs to be tagged TAC-4, or even be part of it for that matter, but we'll assume they were defined portions of the overlay. Most of them deposited things in /opt:
# ls -a /opt . dce ifor sharedprint xpax .. dcelocal image upgrade TAC4 emacs nettladm video audio graphics screencapture xmcd # ls -ldt /opt/TAC4 drwxr-x--x 2 root sys 1024 Sep 19 1996 /opt/TAC4 # ls -alR /opt/TAC4 total 8 drwxr-x--x 2 root sys 1024 Sep 19 1996 . dr-xr-xr-x 17 bin bin 1024 Sep 19 1996 .. -rw-r----- 1 root sys 1185 Jul 19 1996 tac4-copyright
And yes, all it is is the copyright file, exactly the same text as VUE displays on login.
These packages seem to have come from the mysterious server port1. We know this because /.sw/sessions/swinstall.last has an entry for its tape drive (swinstall.source_tape = port1:/dev/rmt/c0t3d0BEST). Very likely that machine served multiple clients, this unit being only one of many.
I couldn't find anything on the machine that looked like it could have generated the GAO brief's screenshot, though. This machine might not have run it or it might have been obsolete by then.
What have we learned? We know that in 1997 the Navy announced the new IT-21 "Information Technology for the 21st Century" program to succeed TAC-4, intended to replace the older TAC-3 and DTC-series systems that were still in service. By then the desktop PC had won out as commodity hardware and the RISC warhorses were sent to pasture. This TAC-4 system seems to have been end-of-lifed in 1998 consistent with that timeline; combine this with the chip dates and it looks it was in service for only around two years. It would make sense that the SAIC support systems remained in place until the last TAC-4s were gone, which based on the civilian system's clock looks like around 2001, and so that was the lifetime of the initiative.
Second, we've also learned that whatever software magic there was to TAC-4, it either wasn't local or didn't exist. The observable software packages are almost all off the shelf. It would seem strange to selectively remove classified packages without taking the usual "nuke it from orbit" approach, so I think we're on solid ground concluding what we saw is what they got. I like these computers rather a lot and I have no doubt the Galaxys acquitted themselves well in their unique environments, but TAC-4 seems to have been virtually all about selling hardware, which the American military-industrial complex is all about too, and the desktop experience was therefore tarted up only as much as it needed to be to look "special." (And third, some of you got to learn about a DoD program you'd never heard of before.)
But there are some larger lessons as well. First off, assuming there really was any effort made to scrub the hard disk, items were still missed that could tell us a lot from a little, and it's fortunate for the Department of Defense this ended up with someone who knows how to handle classified material (unlike some Presidential administrations I could mention). But they get some opsec credit for apparently keeping nothing actually classified on the system itself, even though it might have been better just to shred the disk and surplus the rest — though if they did that I wouldn't have been able to write most of this article.
This is probably some of the last software environments we'll be able to preserve from settings like these, by the way. The Feds move slow, but security gadgets get budgets, and 20 years from now all we'll see are SSDs encrypted at rest if we get any hardware at all. High-security retrocomputing will thus become an entertaining exercise in finding back doors — or just plain brute force.
No comments:
Post a Comment
Comments are subject to moderation. Be nice.