Hey! So I'm actually the builder of UNIXV4.dev (via my company Squiz Software Pty Ltd).
I went to bed last night with a couple of people poking around… woke up to a whole lot more. Appreciate the load test!!
I’ve fixed the rate-limit issues people were hitting. There’s still a global cap of 100 concurrent sessions + per-user limits to keep things stable during spikes.
I’ve also added an “Attributions & Acknowledgements” section.
The backstory is wild: UNIX v4 being recovered from a ~1973 tape at the University of Utah after being effectively “lost” for decades. Reading about the recovery and then poking around in it under SIMH on my PC is what pushed me to wrap it up as a public, browser-based terminal that other people could take a look at - and hopefully get as much out of it as I did.
Have fun exploring it all (especially all the primitive bits — remember: use "chdir" instead of "cd", and "#" is backspace).
If whoever wrote this wants to add an authentic (and somewhat period correct) terminal front-end, I wrote a VT420 hardware emulator that works in the browser and we can wire them together!
More like the VT-05. The VT-52 came a few years later. But yeah, the VT-420 is way later.
Fun fact: The VT-52 didn't have a loudspeaker for the bell sound. Instead, it had a electromechanical relay which was set up to self-oscillate.
"Typing a character produced a noise by activating a relay. The relay was also used as a buzzer to sound the bell character, producing a sound that "has been compared to the sound of a '52 Chevy stripping its gears."
> the knowledge that a buffer overflow could be exploited for arbitrary code execution had not yet come of age.
Meaning, people hadn't figured that out, or it wasn't a commonplace technique? They must have seen buffer overflows crash running software; it doesn't take much imagination to think about the next steps.
Most computers did not exist in an adversarial environment at the time.
Perhaps the most "adversarial" context would be: undergraduate timeshare use. So the mainframes of the day, which would be the typical platform for undergrad programming (if timeshare was even offered to undergrads in 1973) might be expected to be somewhat hardened to attacks of various kinds since undergrads trying to hack their grade higher, get more CPU time, etc, was a known thing.
But Unix machines, and minicomputers in general, were not used for undergrad purposes. They were only available to be used by PhD candidates and other higher order beings. Those dudes had the root password anyway, so no need to harden the machine against their potential attacks. There was no networking to speak of, so no malicious traffic to worry about. The first worm didn't appear until the late 1980s.
So if you had talked to a Unix sysadmin in 1973 (all...1 of them) they probably would understand the general concept of someone running a program that crapped onto kernel memory with the result they could have root privileges, but there would have been no plausible adversary around with any reason to mount that attack. Plus every cycle and every byte counted, so there would have been many more fish to fry before worrying about buffer overflow problems.
This is Unix V4 from 1973. The total number of installations world wide was around 20, all inside Bell Labs. There was no networking support at all, so security was mostly physical, i.e., office building security (though you could dial in with a modem). Multi-user support was a bunch of serial-line terminals. Pretty much everyone knew everyone else who was on the system.
> By supplying addresses outside of the space allocated to the users program, it is often possible to get the monitor to obtain unauthorized data for that user, or at the very least, generate a set of conditions in the monitor that causes a system crash.
> In one contemporary operating system, one of the functions provided is to move limited amounts of information between system and user space. The code performing this function does not check the source and destination addresses properly, permitting portions of the monitor to be overlaid by the user. This can be used to inject code into the monitor that will permit the user to seize control of the machine.
(Volume 1 is at https://apps.dtic.mil/sti/citations/AD0758206 .) However general awareness of the security implications seems to have been very limited before the Morris worm, and then even for several years after that. Even in late 1996 an article which in its own words "attempt[ed] to explain what buffer overflows are, and how their exploits work" could still be published in Phrack magazine, and in fact even be quite a milestone https://en.wikipedia.org/wiki/Buffer_overflow#History . Some people had definitely been thinking about hardware bounds checking for a long time by then https://homes.cs.washington.edu/~levy/capabook/ but I don't know how much they'd specifically considered just this kind of security threat.
Exploiting this is close to trivial because the adjacent buffer contains the pw entry. So, you can control what the input is compared with.
That way the password check can be bypassed without injecting code.
Well-known vulns are all over this code. For example, mkdir had a TOCTTOU which persisted into v7 (and I believe 2BSD); it was implemented as a setuid binary which did a mknod followed by a chown to create the directory. Code which invoked mkdir could set up a race replacing the root-owned directory, before the chown, with a link to something else -- which would then get chowned to the user running mkdir. The target had to be on the same filesystem as some writable directory, but on many installations of the day, a mkdir in /tmp followed by this race was good enough to get you ownership of /etc/passwd.
This was finally cleaned up in 4.2bsd, when mkdir was made a single syscall which was guaranteed to alter only the particular inode it allocated.
Being able to cat directories like that doesn't surprise me as much as the contents being readable. Is there not a bunch of binary garbage in between the filenames?
I'm amused at how circular this is. Unix v4 is first OS written in C, now running on top of an unbelievable amount of C (and C++). Classic circular computer science delight.
I spent about a week insulting Claude to get port it to x86_64. It's running nicely in QEMU. We're also trying to get the C compiler in there working as well.
Did they get a license from Novell for this or is this as illegal as many of the other emulator sites with copyrighted software on them? Considering the page doesn't mention it, I'm leaning towards it being copyright infringement.
This copy of Unix v4 came from AT&T and not one of the freely licensed ones Caldera released. Caldera may own the rights now for this unearthed copy, but I am not aware that they have provided licenses for this new release.
In the sense that the company I work for would be financially harmed if copyright infringement of software was freely allowed. I benefit from the ability of people being able to sell rights to use software.
It's one thing to digitize and archive ancient software, it's another thing to allow people to freely use it without acquiring the proper license for it.
> By using this service, you acknowledge that terminal sessions may be logged for educational and debugging purposes. No personal data is collected beyond your IP address.
Is this all open source and is the code available? So that we know where the data is truly going?
And even more to the point: this is a website. What is he afraid of this website doing that all the other websites don't already do? Why single this one out?
It would be an excellent phishing attack if your target is senior IT. You filter out every non-geek, of course, and certainly your responses would lean heavily toward an older crowd. They's all see 'Unix v4', be too excited to consider the risks, and being a 1973 OS assume it is innocent and safe (not thinking about the platform delivering it).
Yeah it’s unlikely that this site will collect any meaningful data and it’s unlikely that you lose any meaningful data by playing with a virtual unix from the 70ies.
Hey! So I'm actually the builder of UNIXV4.dev (via my company Squiz Software Pty Ltd).
I went to bed last night with a couple of people poking around… woke up to a whole lot more. Appreciate the load test!!
I’ve fixed the rate-limit issues people were hitting. There’s still a global cap of 100 concurrent sessions + per-user limits to keep things stable during spikes.
I’ve also added an “Attributions & Acknowledgements” section.
The backstory is wild: UNIX v4 being recovered from a ~1973 tape at the University of Utah after being effectively “lost” for decades. Reading about the recovery and then poking around in it under SIMH on my PC is what pushed me to wrap it up as a public, browser-based terminal that other people could take a look at - and hopefully get as much out of it as I did.
Have fun exploring it all (especially all the primitive bits — remember: use "chdir" instead of "cd", and "#" is backspace).
- Daniel
If whoever wrote this wants to add an authentic (and somewhat period correct) terminal front-end, I wrote a VT420 hardware emulator that works in the browser and we can wire them together!
https://mmastrac.github.io/blaze/
(the API is undocumented but stupidly simple: an async js_read() function and a sync js_write() function)
You'll want VT-52 for this era.
More like the VT-05. The VT-52 came a few years later. But yeah, the VT-420 is way later.
Fun fact: The VT-52 didn't have a loudspeaker for the bell sound. Instead, it had a electromechanical relay which was set up to self-oscillate.
"Typing a character produced a noise by activating a relay. The relay was also used as a buzzer to sound the bell character, producing a sound that "has been compared to the sound of a '52 Chevy stripping its gears."
2 replies →
I wrote a VT52 hardware simulation: https://github.com/larsbrinkhoff/terminal-simulator
Reading the source unearths interesting things: https://sigma-star.at/blog/2025/12/unix-v4-buffer-overflow/
> the knowledge that a buffer overflow could be exploited for arbitrary code execution had not yet come of age.
Meaning, people hadn't figured that out, or it wasn't a commonplace technique? They must have seen buffer overflows crash running software; it doesn't take much imagination to think about the next steps.
Most computers did not exist in an adversarial environment at the time.
Perhaps the most "adversarial" context would be: undergraduate timeshare use. So the mainframes of the day, which would be the typical platform for undergrad programming (if timeshare was even offered to undergrads in 1973) might be expected to be somewhat hardened to attacks of various kinds since undergrads trying to hack their grade higher, get more CPU time, etc, was a known thing.
But Unix machines, and minicomputers in general, were not used for undergrad purposes. They were only available to be used by PhD candidates and other higher order beings. Those dudes had the root password anyway, so no need to harden the machine against their potential attacks. There was no networking to speak of, so no malicious traffic to worry about. The first worm didn't appear until the late 1980s.
So if you had talked to a Unix sysadmin in 1973 (all...1 of them) they probably would understand the general concept of someone running a program that crapped onto kernel memory with the result they could have root privileges, but there would have been no plausible adversary around with any reason to mount that attack. Plus every cycle and every byte counted, so there would have been many more fish to fry before worrying about buffer overflow problems.
3 replies →
This is Unix V4 from 1973. The total number of installations world wide was around 20, all inside Bell Labs. There was no networking support at all, so security was mostly physical, i.e., office building security (though you could dial in with a modem). Multi-user support was a bunch of serial-line terminals. Pretty much everyone knew everyone else who was on the system.
1 reply →
I'm not an expert, but a quick look at https://en.wikipedia.org/wiki/Buffer_overflow#History suggests that some people, at least, had figured it out by 1972 https://apps.dtic.mil/sti/citations/AD0772806 :
> By supplying addresses outside of the space allocated to the users program, it is often possible to get the monitor to obtain unauthorized data for that user, or at the very least, generate a set of conditions in the monitor that causes a system crash.
> In one contemporary operating system, one of the functions provided is to move limited amounts of information between system and user space. The code performing this function does not check the source and destination addresses properly, permitting portions of the monitor to be overlaid by the user. This can be used to inject code into the monitor that will permit the user to seize control of the machine.
(Volume 1 is at https://apps.dtic.mil/sti/citations/AD0758206 .) However general awareness of the security implications seems to have been very limited before the Morris worm, and then even for several years after that. Even in late 1996 an article which in its own words "attempt[ed] to explain what buffer overflows are, and how their exploits work" could still be published in Phrack magazine, and in fact even be quite a milestone https://en.wikipedia.org/wiki/Buffer_overflow#History . Some people had definitely been thinking about hardware bounds checking for a long time by then https://homes.cs.washington.edu/~levy/capabook/ but I don't know how much they'd specifically considered just this kind of security threat.
My Educated guess, both.
Malicious attempts at exploiting would require physical access.
This was 1970's running on a PDP hardware. These were not normally connected to the internet so the attack vector of attacking would be have literal.
Any bugs would probably been of been fixed prior to and isn't this the first alpha of unix? So probably patched later in versions.
I kept expecting an exploit :) Something to poke at on a slow evening, I guess, though with the buffer in static memory it might be difficult.
Exploiting this is close to trivial because the adjacent buffer contains the pw entry. So, you can control what the input is compared with. That way the password check can be bypassed without injecting code.
1 reply →
Well-known vulns are all over this code. For example, mkdir had a TOCTTOU which persisted into v7 (and I believe 2BSD); it was implemented as a setuid binary which did a mknod followed by a chown to create the directory. Code which invoked mkdir could set up a race replacing the root-owned directory, before the chown, with a link to something else -- which would then get chowned to the user running mkdir. The target had to be on the same filesystem as some writable directory, but on many installations of the day, a mkdir in /tmp followed by this race was good enough to get you ownership of /etc/passwd.
This was finally cleaned up in 4.2bsd, when mkdir was made a single syscall which was guaranteed to alter only the particular inode it allocated.
Things that I noticed are not yet there in this version: /proc, uptime, uname
Things that are working: `cal 2026`, coredumps
Things that might be broken or aren't working as expected: ps (only returns "No mem")
And utmp is in /tmp?
And no /usr/sbin or /sbin? And nothing in /usr/local?
The messages from `write root` are only in uppercase.
/proc is a Linux thing.
/proc is only copied (and extended) by Linux. It was introduced in UNIX V8. It is also in Solaris and FreeBSD.
2 replies →
I managed to get in after a few tries. But then I got a timeout. I think I'm going to wait until the HN deathhug is over :D
I wonder how hard is it to do the entire thing in browser/js. It seems hugged to death right now due to backend connections.
people ran linux and win 95 in browser, would be fine
Glad to have played with it a bit before it got Slashdotted. ;)
Everything really is a file: if you do `cat /` you'll get back the internal representation of the directory entries in / (analogous to ls)
And they still had coredumps at the time if you press ctrl-\
Being able to cat directories like that doesn't surprise me as much as the contents being readable. Is there not a bunch of binary garbage in between the filenames?
I remember `cat` on directories working on Unixen much newer than v4. Not sure if it ever was the case on Linux tho.
I'm amused at how circular this is. Unix v4 is first OS written in C, now running on top of an unbelievable amount of C (and C++). Classic circular computer science delight.
I spent about a week insulting Claude to get port it to x86_64. It's running nicely in QEMU. We're also trying to get the C compiler in there working as well.
Do you use secure boot ?
Getting a rate limit error, but I haven't used the program.
I am glad it already has `ed`, the standard text editor.
But it's lacking some features available in newer versions of ed, such as using 'n' to print line numbers.
Rate limited! a new record!
I'm going to guess we're on the same VPN.
Almost slashdotted.
Amber, always amber. Like the screens in Alien's Nostromo (1979).
Thank you for this, I enjoy digital archaeology. :)
The fi ligatures in the Help & Info section are killing me.
death by hn..
Did they get a license from Novell for this or is this as illegal as many of the other emulator sites with copyrighted software on them? Considering the page doesn't mention it, I'm leaning towards it being copyright infringement.
In 2002, Caldera licensed Research Unix <= 7th edition and 32-bit 32V Unix under a BSD-style license.
Gotta stick the "This product includes software developed or owned by Caldera International, Inc." notice on it though.
This copy of Unix v4 came from AT&T and not one of the freely licensed ones Caldera released. Caldera may own the rights now for this unearthed copy, but I am not aware that they have provided licenses for this new release.
6 replies →
Personal financial stake in this, or do you regularly police the use of ancient software?
>Personal financial stake in this
In the sense that the company I work for would be financially harmed if copyright infringement of software was freely allowed. I benefit from the ability of people being able to sell rights to use software.
It's one thing to digitize and archive ancient software, it's another thing to allow people to freely use it without acquiring the proper license for it.
11 replies →
What do you think about GOG?
It's good to have competition against Steam.
GOG is perfectly legal.
[dead]
Just a heads up:
> By using this service, you acknowledge that terminal sessions may be logged for educational and debugging purposes. No personal data is collected beyond your IP address.
Is this all open source and is the code available? So that we know where the data is truly going?
Hard to trust it if it isn't fully OSS.
This is a cool demo though.
> Hard to trust it
Clarification requested: How is ‘trust’ applicable to this site?
I don't want them to see my blunders in the chess game I lost against the 40 year old computer program.
Even if it was open source how do you know its not a fork?
And even more to the point: this is a website. What is he afraid of this website doing that all the other websites don't already do? Why single this one out?
2 replies →
It would be an excellent phishing attack if your target is senior IT. You filter out every non-geek, of course, and certainly your responses would lean heavily toward an older crowd. They's all see 'Unix v4', be too excited to consider the risks, and being a 1973 OS assume it is innocent and safe (not thinking about the platform delivering it).
Maybe you'd get too many retirees ...
Now you just need
> Hard to trust it if it isn't fully OSS
It's an emulated PDP-11, could you elaborate on the threat model here?
I get that companies are being gross about logging everything online, but come on. It's okay to have fun.
Who in their right mind is using this for anything other than curiosity's sake?
Little bit of banking on an emulator on a random website, why not?
1 reply →
Yeah it’s unlikely that this site will collect any meaningful data and it’s unlikely that you lose any meaningful data by playing with a virtual unix from the 70ies.
You aren’t getting downvoted enough.