The CRC scheme of an old proprietary BBS network

The CRC scheme of an old proprietary BBS network

I had lunch with a friend who I've known for many years this afternoon. I've known him from the days back when we all used to run dialup bulletin board systems. He's also one of the people who introduced me to listening to random things with scanners way back in the day.

Talking with him reminded me of a puzzle that existed in the BBS software we all used to run. It was a weak form of crypto which served to uniquely identify systems in the network, mostly so that spoofing each other required some deliberate effort. Here's how it worked.

Much like Fidonet, all systems had an address frequently called a "net/node" just because it was nnn/nnn, like 045/123, or 050/000, or 900/001, or whatever. Systems were generally grouped by area, such that all of net 045 might be a single local calling area (within an area code or LATA or similar), then 050 would be another, and so on. There were sometimes larger groupings by country, but those were done by humans. The software didn't know any better.

Anyway, when you joined the network, the "local net coordinator" was supposed to issue you an address in that net with a matching "CRC". This was a hex key in the form xxxx-xxxx, like 1234-cdef. Note that it appears to be a 32 bit value, but there's more to it, as I learned over the years. To identify yourself as that particular address, you needed to enter that code in your batch file which ran the netmail software. Without it, you couldn't talk to other systems via dialup.

The scheme for a while went like this: each net would elect their local net coordinator, and that person would then be issued a key generator by the author of the BBS and netmail software. This key generator would only function for that net - 001, 045, 050, 900, whatever. It could generate any node's CRC from 000 to 999 within that net, however.

Now, buried deep within all of this was a "seed" value. There were some utility programs on the author's BBS which shed some light on things. You could run this other program called NMC5 and give it a text string, and it would turn that into a numeric seed value -- but didn't tell you what it was. Then it would take net/nodes as input and would give CRC values.

In this sense, you could use his software to create your own network. It would have its own seed value and thus would not be compatible with the "official" network. That is, 001/001 from network A and 001/001 from network B would clash due to the different seed values. This also meant their CRCs were different (obviously).

One other interesting feature in this design was that echomail conferences ("echoes" in the vernacular) operated differently than their Fidonet counterparts. In this scheme, all messages flowed "upstream" to a "sponsor" which would then "bag" the messages daily. These bags would then flow "downstream" to the subscribers.

The netmail software which created echomail bags would only operate if you had a valid CRC for that echo ID, like E20/002, or E10/123, or whatever. What's more, those CRCs were also keyed to the sponsor's net/node address, so E20/002 sponsored by 001/001 was not equal to E20/002 sponsored by 602/456.

This is how things went for a while. Well, large collections of sysops being what they are, things were never really smooth. There were "wars" every so often, and things would fracture. At one point, a whole bunch of sysops broke off to run their own network with the same software, but with a new seed value. They also renumbered their systems at the same time, so now you'd have BBS A in network A with net 005 but BBS B in network B in net 500, even though they were in the same area.

The two networks, for the most part, did not interconnect. There were a couple of "gates" or "bridges" in a few places, but they basically headed off in their own different directions.

Still, back in the official network, there were still wars being fought over the limited nature of key generators and the power they conferred to their holders. People with them were more special than those without, for instance. Posting someone else's CRC was high treason... which is why when it happened and someone posted a bunch of CRCs for important hubs, it was a big deal.

Soon, the "security of the network" was "at risk". So dramatic! Anyway, we all had to start negotiating passwords to add to our established connections to augment the CRC system. In theory, you couldn't just trust the identity of an incoming connection any more, at least for those "compromised" addresses.

Well, even that wasn't good enough. The author of the software at one point decided to go nuclear and used his ability to write new software to really change things. He changed the last version of the Netmail software to always use the same seed value, and even published it (!) in the docs - $FABB. Once this rolled out, anyone could become any other address in the network just by setting it in a config file.

This really changed things. Now, instead of the three or four which had leaked in a public forum, you could become any address you possibly desired. At the same time, he also dropped the echomail CRC scheme entirely, claiming (truthfully) that it could have been cracked the whole time. You see, apparently there was no provision for the echomail software to know the seed, so you could work around it.

Let's say you were 012/456 in network A and wanted to spoof E10/001. You'd need CRC(A, 012/456, E10/001). You didn't have that, but you could grab EMC51 (the roll-your-own-key echomail generator) and create CRC(B, 012/456, E10/001) and get a perfectly valid key for that echo and your address... in another network. The thing is, the echomail software had no way to know it was for network A vs. B, so it would just accept it.

By that logic, he said it was broken and ripped it out as well. So now, you could pretend to be any node and could sponsor any echo at the same time. Somehow, the network didn't fall apart because of all of this. It definitely changed the way things worked, but the mail kept flowing.

What really killed that network was the slow eventual death of BBSes as people moved to TCP/IP dialups and web browsing. Once that took off, there was no real point to calling systems which were their own little walled gardens.

That's how the network addresses and CRCs were used. What I haven't figured out yet is how a "string like this" turned into a seed value like $1234, and then how that value could be mashed up with a network address to yield a CRC like aabb-ccdd.

I only know a few things about this system. First, there's the seed from the main network which is from the documentation: 0xFABB. Second, I have those three leaked CRC values from that 1990 (!) post I happened to keep because I found the whole thing curious.

Third, somewhere along the way, someone who knew far more about this told me that if the value is AAAA-BBBB, then AAAA xor BBBB xor "salt" gives you the seed. I had never heard of this salt value before. Further, salt xor seed xor AAAA should give BBBB.

I've been able to do a few things with this. One of the leaked addresses was 9472-34fc. 0x9472 xor 0x34fc is 0xa08e. That's not too interesting, but then look what happens with a second address: 4127-e1a9. 0x4127 xor 0xe1a9 is also 0xa08e.

That by itself is interesting and suggests that the hint I was given by someone way back when was actually meaningful. He told me one other thing: the salt was 5a35. That didn't make much sense to me until I happened to try taking 0xa08e (from above) xor 0xfabb.

Guess what? 0xa08e xor 0xfabb is 0x5a35.

I still don't know how this really works. I've been taking random pokes at it now and then on lazy weekend afternoons when I get bored. One of these days, I guess I'm going to have to disassemble nmc51 and/or emc51 or perhaps the actual netmail software to see what it's doing.

It will solve no actual technical problems, but it will let me have some idea as to what made that software tick oh so long ago. Being able to write about it would probably make for a useful "closure" chapter for that software.