MC's Journal

Running CP/M: Microbee, Compis, and Yaze-AG

A couple of days ago I talked with a friend about computers in our primary schools. At her school they had a set of Microbee computers, a family of Australian Z80-based micros running CP/M. I don't know exactly what model they had, but after asking around among other friends some sort of Microbees seems to have been rather common in Swedish school in the mid-80s.

I remember seeing ads for Microbees in the 1980s and much later had an opportunity to play with a 32IC for a while. Quite nice little machines.

From 1985/86 my school had Compis computers, which I think was slightly more common, Compis being The Official Swedish School Computer. Compis was a 80186-based CP/M-86 machine with really nice, low keyboard and fairly high resolution monitors.

The system at my school were 640x400 monochrome (green) and a single colour-based machine with much slower graphics that everyone avoided. Allegedly there was also a version with 1280x800 monochrome (b/w), but I never saw anything like that.

The machines had floppy drives but were also connected to a shared 10 MiB hard disk. The hard-drive was only available in read-only form, except for one drive letter which only could have one user at a time. I remember a program called boxloss which unmounted this virtual drive from anyone who happened to be using it and mounting it for you. The password was “Fredrika”. I don't remember how you were supposed to mount it without stealing it like this. Anyone?

There was some kind of menu system, but if you really wanted to you could get at the CP/M prompt. This prompt, unfortunately, was the standard CCP, not any of the fancy ZCPR stuff that people running CP/M on Z80s were used to by then.

One thing that struck me during our conversation, and from many other conversations about computers in Swedish primary schools in the 1980s, was that the computers were very seldom used for anything! For instance, we were not allowed to use the computers to write texts! There were no word processor or text editor available, at least to my knowledge, and we were certainly not allowed to use the computers outside of specific “computer classes”.

This is particularly interesting if you look at the Microbee, since as far as I can tell all models had a built-in text editor!

We weren't allowed to use any advanced development tools either. On the Compis we had to write programs in COMAL, a language looking a lot like BASIC, but with proper procedures and functions. Really frustrating when I had the wonderful Turbo Pascal at home and I knew that Turbo Pascal was available on CP/M and for the Compis as well.

After our conversation I decided to look back at some development environments on CP/M and see if I could have lived with the environments back then...

I looked around for a Microbee emulator and found an emulator in Javascript, NanoWasp. Code on GitHub.

NanoWasp is unfortunately limited to a tape-drive system. It would be fun to work with something with floppy disk support. Anyone?

I didn't find any Compis emulators, but thought I'd look around for some more generic emulator to run CP/M on.

A popular emulator for CP/M seems to be the YAZE-AG Z80 emulator.

YAZE-AG comes pre-loaded with CP/M 3.1 and a lot of development tools. I was totally blown away by Turbo Modula-2! Look at drive M:.

Wikipedia tells me TM-2 was never marked by Borland but later became TopSpeed Modula-2 for MS-DOS. I had never used it before but it's really incredible. The environment is reminiscent of Turbo Pascal 3.0 with a small menu system and an WordStar-like editor, but the language is much richer.

According to this blurb the cost of TM-2 was $69.95. Tremendous value, indeed!

I would have been very happy indeed if this had been available at my school. I don't think TM-2 was available for CP/M-86, though, although it seems Logitech's Modula-2 compiler was. I think I would have been quite happy with just TP 3.0 as well, which was what I was programming in at home, but more important than this would have been access to the computers!

IPv6 Only FreeBSD

I'm setting up a couple of FreeBSD jails in an IPv6-only world. I was a bit surprised to note that although has a AAAA in DNS it's impossible to reach the DNS server that gives the AAAA answer over IPv6!

Only if I use a resolver that are both on IPv6 and legacy IP will I be able to install packages.

What can I do to help?

32th Chaos Communication Congress, part 4


More notes from my visit to 32C3. Part 1. Part 2. Part 3.

PQCHacks: A gentle introduction to post-quantum cryptography

Fahrplan link.

Daniel “djb” Bernstein & Tanja Lange.

Tanja and djb first had some soothing words: The D-wave quantum computer isn't universal:

...but universal quantum computers are coming and are very scary. They break all public-key crypto! AES-256 still hard, though.

Post-quantum crypto: the adversary has a quantum computer but we have ordinary computers.

PQcrypto conference 2006–2017.

There might be an entity (Ahem... NSA) that records all your communication. In 10 or 15 years you might be a Person of Interest. Then they break your RSA with their new quantum computer and read all your old correspondence.

Initial recommendations of long-term secure post-quantum systems

Signature hashes

Lamport suggested one-time signatures in 79, Merkle extends to more signatures.

For instance, use SHA3-256...

Can only send a single message. The message reveals the private key. And its hash is the public key.

A signature scheme for 1 bit messages: two private keys.

For 4 bits: 4 key pairs! Concatenate the public keys to create a new public key for the message.

Don't use the same secret key to sign two messages. Obviously, since we're revealing the private key when sending.

Lamports 1-time signature messages.

Merkle's 8-time signature system. Make 8 Lamport keys! And concate them and hash them. One hash is a public key, but many private keys.



Solution to statefulness: eliminate the state! Build a big tree of certificate authorities:

Signature sizes:

Code-based encryption

Based on coding theory. Examples of coding theory are parity checks, the ISBN control number or Hamming code.

Many more post-quantum suggestions


Coming 2017 summer school and workshops.

@pqc_eu on Twitter.

Verified Firewall Ruleset Verification: Math, Functional Programming, Theorem Proving, and an Introduction to Isabelle/HOL

Fahrplan link.

Cornelius Diekmann.

Cornelius told us about mathematical machine proofs for firewall rules. He cited previous works and said “tools do not understand real-world firewall rules”.

Needs to specify "what is a firewall?" a model of the semantics of Linux iptables.

Using a theorem prover, Isabelle.

Builds a model of the firewall, the filtering behavior. Only 11 filter behaviours defined in the complete semantics.

This is a mathematical specification - not an implementation. It describes what a firewall does. The specification for CallReturn, for instance, didn't use a call stack but had a description of calls to new iptables call chains.

Why do this?

You can use it to prove “semantics-preserving simplification”, for instance prove that the firewall filtering behaviour stays the same after optimization or after having removed logging.

Executable code

Specifications is done in Isabell, then exported to executable code. A selection of a languages: Haskell, for instance.


32th Chaos Communication Congress, part 3


More notes from my visit to 32C3. Part 1. Part 2.

Shopshifting: The potential for payment system abuse

Karsten Nohl, Fabian Bräunlein, and dexter.

Fahrplan link. Recording.

This talk was at the same time as the New memory corruption attacks so I saw the recording.

Payment terminal: reads the card's mag stripe or PIN/chip.

ZVT in the shop over a network connection. Very old installations use a serial port and the protocol is designed for this, which shows.

Attack 1: Against the customer

ARP spoofing to get a man in the middle on the local network. Inside the shop or, if using wifi, even outside.

We send only a command “read the card”, then we have the mag stripe! Then we go ahead with the transaction.

But how do we get the PIN?

ZVT payment terminals are supposed to work with an HSM: the PIN shouldn't be seen outside.

ZVT has a function: “Display a text, then enter a number” but this function must be signed. Can we sign it ourselves?

To find a valid MAC... The HSM leaks the correct MAC through a timing side channel! They found an active JTAG on the main CPU and could talk to the HSM. Brute force of the first byte and count the response time. It's compared byte by byte in the HSM! Returns immediately if it doesn't match!

Attack 2: Against the merchant

ZVT allows local terminal hijacking.

ARP spoofing to become MITM like before.

Reset the terminal ID to your own terminal ID. The attacker needs to be a merchant as well and have a terminal ID.

There is no authentication between cashier and pay terminal.

Attack 3: Attack on Poseidon

Poseidon is a dialect of global payment standard ISO 8583. De facto standard in Germany.

Authentication uses pre-shared keys. However the key is the same for many, many terminals! This leaves just a user name: the terminal id. Which is public information and printed on receipts!

For the attack to succeed:

Now you can, for example, print pre-paid call codes for your phone.

Another possibility is to “refund”, initiate a money transfer with a negative value! From any bank account! Completely independent from any earlier transactions.

Attack 4: Hardware

Buy a payment terminal on Ebay. It uses an internal HSM to protect secrets.

The HSM is a battery-backed SRAM under plastic cover. When a metal mesh in this plastic cover is breached the secrets are erased.

But the mesh is only connected in the corners. Can we get something under it? Yes! Inject a hypodermic needle and ground it. Ta-da! Then simply remove the lid.

There was an active JTAG port!

What can be done?

Short term:

Long term:


The main ZVT alternative is OPI, Open Payment Initiative. OPI still lacks authentication and encryption even though it's from 2003!

Poseidon's family: ISO 8583. Dialects used everywhere. The bad system-wide symmetric keys are not mandatory in the protocol and key distribution through Poseidon possible.

New memory corruption attacks

Mathias Payer & Nicholas Carlini.

HexHive Group,

Fahrplan link.


Status of deployed defenses

ASLR and DEP only effective in combination.

Two proposals

Stack integrity

Control-flow integrity, CFI

New attacks: control-flow bending

Bend a valid graph... Not calling new code, but allowed targets.

Circumvent control-flow integrety.

CFI'S limitation: statelessness.

Each state is verified without context. Unaware of constraints between states.

Weak CFI is already broken. Lots of papers about it.

Microsoft's control-flow guard is an instance of a weak CFI.

Strong CFI?

How secure is CFI? With and without stack integrity?

Analysis found a few functions, like memcpy() and malloc() that everyone uses. If everyone use them you can return to a lot of functions and build ROP chains easily.

Result: CFI without stack integrity is broken.

When we add stack integrity to the mix we can greatly increase the protection of the current systems, then:

However: an interpreter will still be vulnerable!

And there's lots of interpreters out there! An example is printf()! printf() format strings include: memory reads %s, memory writes %n, conditionals, %.#d, therefore: a Turing complete Brainfuck interpreter. In printf formats!

32th Chaos Communication Congress, part 2


More notes from my visit to 32C3. Part 1.

Unpatchable: Living with a vulnerable implanted device

Fahrplan link. Recording.

Marie Moe & Eireann Leverett.

Marie lives with a pacemaker: “A project to break my own heart.”

A rather low-key presentation with no alarming remote cracking of pacemakers, but interesting insights into medical implants. For instance, Marie's own pacemaker has two wireless interfaces: one near-field and another for remote monitoring/telemetry when used with an optional a base station in her home.

They bought a programmer for the pacemaker and some base stations on Ebay and did experiments. They could extend the programmable range to several metres!

Some issues:

Some research needed:

“We need to be able to verify the software that control our lives.”

“You to can do this research! Lots of low hanging fruit.”

There is na excemption to the Digital Millennium Copyright Act (DMCA) for research on medical devices and automotive devices. Reverse engineering possible without infringing copyright law.

The programmers are unique for the device. Some standardization, perhaps?

Much smaller pacemakers coming. Inside the heart!

“Are there laws requiring the doctor to tell them they are upgrading the software?”

No third party tests? No consumer laboratory?

How the Great Firewall discovers hidden circumvention servers

Fahrplan link.

Philipp Winter,

An analysis of how China's Great Firewall blocks traffic and knows what to block.

“We know what is blocked, how it is blocked, where it is topologically.”

“Most measurements are one-off, continuous measurements challaneging.”

Even if you use DNS resolver outside of China, a DPI looks at your traffic and spoofs the results. If you wait for a while... you get the real DNS reply as well! Not filtered!

Several data sets collected to see where the probes come from.

Collected 16 000 unique probe ip addresses! 95% addresses seen only once!

Reverse DNS with “adsl” in them... Looks like ISP addresses. The single IP address was almost 50% of the probes!?

Majority of probes comes from three ASes: 4837, 4134, 17622.

Do they hijack these addresses for GFW use? While the probe is active no communication with them possible: traceroute times out, no ping...

What do they have in common?

Physical infrastructure

Blocking is reliable but fails predictable

In 2012 probes were batched, perhaps started by cron.

Now real time. Median arrival time only 500 ms.

Blocked protocols

The probes doesn't seem to be using reference software. Handcrafted!? The probes look very different from ordinary software and can be easily identified.

Find your own probes


DPI must re-assemble the stream before pattern matching. Make the protocol harder ro reassemble. Server-side manipulation of TCP window size can hide the protocol signature. Used in brdgrd.

TCP/ip based circumvention difficult to deploy: “use this unknown kernel module, will you?”

Tor project pluggable transport to the rescue! Pluggable transports that work in China

CloudABI: Pure capability-based security for UNIX

Fahrplan link.

Ed Schouten,

A new Unix runtime with capabilities.

What's wrong with unix?

Unix doesn't stimulate you to run software securely. A web service only needs a specific set of capabilites but can do everything.

Access controls like apparmor not a real solution. Puts the burden on the package maintainers.

Untrusted third-party programs are also extremely unsafe. Can the OS provide better isolation?


Capabilities: Example, Capsicum. Programs starts as an ordinary process, opens all files it needs, then calls cap_enter(), process can still use file descriptors, read(), write() but can't use open() et cetera. Returns ENOTCAPABLE.

Used in FreeBSD by some programs: dhclient, hastd, ping, sshd, tcpdump, et cetera.

However, problems: code isn't designed to have system calls disabled!

Introducing CloudABI

A new posix-like runtime environment.

Default rights

Additional rights: file descriptors

Make sure you have the right set of file descriptors when starting the process.

A file descriptor is its own chroot.

Process descriptors: replacement for wait()/kill(). Special fork gives you a process descriptor. These descriptors can't be passed over Unix sockets.

File descriptors have permission bitmasks allowing fine-grained limiting of actions performed on them.

Example file descriptors for a web server:

This web server will be limited to the above and can't escape.


POSIX becomes tiny if you remove all interfaces that conflict with capabilities. Only 58 system calls available.

Goal: add support to existing posix operating systems.

Allows reuse of binaries without recompilation.

Upstreams: freebsd/arm64, /x86-64

Beta: Linux.

Developing for CloudABI

CloudABI ports - a collection of cross compiled libraries and tools.

Builds native packages: Freebsd pkg and Debian packages.

Use cases of CloudABI

Previous Page 3 of 32 Next Page