A few months ago, the OS/2 Museum obtained a seemingly complete and error-free set of floppies with SFT NetWare 286 Level II version 2.0a. And just recently, a disk set of Advanced NetWare 86 2.0a turned up, though sadly incomplete.
Both releases are from 1986 and share one rather unpleasant feature: The NetWare OS won’t run without a hardware key card:
All or most old NetWare versions sold before circa 1988 needed a custom hardware key which had to match the serial number that was burned into the NetWare disks. I’m not sure what the exact history was, but it is known that the NetWare serial number could be provided by Novell’s DCB, or Disk Coprocessor Board:
I don’t quite understand what was the point of selling a custom disk controller and requiring a serial number match. But NetWare 2.0a could also run on off the shelf hardware using standard AT disk controllers and drives. For those machines, Novell provided a simple key card:
I’m not entirely sure if Novell was more worried about piracy by end users or by unscrupulous resellers. In any case, in 1986, during the era of NetWare 2.0a, a hardware key was required by NetWare.
Needless to say, if you are incredibly lucky and find a complete NetWare 2.0a disk set, and the disks are actually readable, the chances of also having the matching hardware key are close to nil. And even if you did have one, that does not at all help when trying to run NetWare 2.0a in an emulator. So, what do we do?
There are two obvious approaches. Either emulating the key card hardware, or patching the software to not need a key card.
Emulating a NetWare Key Card
First let’s examine the overall logic. NetWare 2.0a uses a 6-byte serial number which is different on every disk. It’s written into an object file NET$OS.OBJ, from where it propagates into the final NetWare executable, NET$OS.EXE.
The first four bytes are the serial number proper, stored in BCD format (eight digits). The first two digits tend to be zeros and may be left out on serial number stickers and such. The last two bytes are an “Application Number” which possibly controls NetWare capabilities such as the number of users supported.
When NetWare starts up, it reads six bytes of data from the key card. These six bytes have to match the serial and application number stored in NET$OS.OBJ.
The key card hardware is quite simple. It responds to I/O port reads in a fixed range from 23Ah to 23Fh. For reasons that may be lost to history, the serial number is stored in a strange format–possibly obfuscated, possibly somewhat scrambled for technical reasons.
Ports 23Ch to 23Fh return the serial number proper, while ports 23Ah and 23Bh provide the application number. Looking at the key card photo, it is possible that Novell had prototype boards where part of the serial number and/or application number could be set using jumpers.
This is how the serial number nibbles are returned by the key card. Note that all values must be bit-flipped after they are read from the card:
port 23Ch: [ S2L : S1L ] port 23Dh: [ S0H : S3L ] port 23Eh: [ S0L : S3H ] port 23Fh: [ S1H : S2H ] port 23Ah: [ S5H : S4H ] port 23Bh: [ S5L : S4L ] S0 to S5: Six bytes of serial number H = high nibble, L = low nibble All values bitwise complemented
There is really not much to it, and emulating such hardware is trivial. But it is still almost as annoying as the real key card: You must actually have the emulation, and it can unlock only a single copy of NetWare. That is quite annoying when experimenting, such as trying to figure out whether NetWare 86 2.0a 86 and NetWare 286 2.0a SFT II understand the same on-disk format (they don’t).
The only real advantage an emulated key card has is that it can run unmodified NetWare.
Fixing the Software
The other approach is to forget about the key card hardware entirely and patching out the hardware key checks instead.
I decided to go with a somewhat complicated but safe approach. Rather than patching out the serial number checks, I replaced the routine which reads the serial number from the key card. The replacement copies the serial number to the same location where the original routine placed it. That way, if NetWare in any way depended on the contents of the bytes holding the hardware serial number, it would still work fine (though I suspect it doesn’t care).
As it turns out, it’s not hard to find the serial number burned into NET$OS.OBJ / NET$OS.EXE, because it’s prefixed by a convenient ‘S/N=’ string. The existing serial number is read and copied to the end of the replacement routine, which moves it exactly where the routine reading the key card is expected to place it. Fortunately the replacement code is much smaller than the original, because it doesn’t have to bother bit-flipping and swapping all the nibbles around.
The patching logic is implemented in a Python script. This script requires Python 3. Everything is in there, including comments.
The patcher can be run against the NET$OS.EXE file. But not only that. There is a high likelihood that it can patch NET$OS.OBJ as well—as long as the original serial number and key card reading routines are each stored in a single LEDATA record, which is somewhere between highly likely and guaranteed.
Obviously if NET$OS.OBJ is patched, then a newly generated NET$OS.EXE won’t need any further treatment. The patching logic even makes sure that the checksum of the modified LEDATA record still matches, although the Novell linker does not appear to be at all concerned if it does not.
Rather conveniently, the patcher can also be used directly on raw floppy images containing NET$OS.OBJ or NET$OS.EXE. There is a slight chance that the patching might fail if the files were fragmented (i.e. if the crucial byte sequences were stored in non-consecutive sectors). This is extremely unlikely to happen with the original NetWare disks.
Applying the patch to the GENOS-3 disk of SFT NetWare 286 II 2.0a, which holds the generated NET$OS.EXE, we end up with the following:
From 1986 to 2024, NetWare 2.0a lives!
The patching script has obviously not received a lot of testing because there just aren’t that many copies of NetWare 2.0a available.
For reference, the above screenshot shows the System Configuration (SYSCON) utility running on a client system. It is a convenient method of displaying the server’s serial number as well as the application number.
Reinventing the Wheel
Needless to say, this has been done before. And not only has it been done—in the mid-1980s, a company called NetWork Business Systems out of Houston, Texas was proudly selling a tool called KeyCard Eliminator for $99. That was not cheap, but it was a lot cheaper than NetWare licenses, which cost more than a thousand dollars.
But finding these old cracking tools isn’t any easier than finding NetWare 2.0a… so I wrote my own. Problem solved.
I recall that I had a fascination with Hardware key dongles since the first time I saw one, which was a Parallel Port piece, but I don’t remember for which Software. Perhaps 20 or 25 years ago it didn’t matter that much due to cracks being able to remove the dongle checks like you just did, so for piracy purposes for as long that it runs it was fine, but as Software preservationism became a thing, now you suddently realize a need for these things to be emulated as to run unmodified original Software.
Very nice!!!
But in theory – can we just load serial number bytes into the memory before launching NET$OS, do they survive NET$OS loading? Or does check code still overwrite them, if keycard is not found, with zeros, perhaps? If we know memory region and those bytes survive there, it would be also trivial to write a small loader.
ps. sorry to ask so bluntly, but can we earthlings also download soon that historic Netware from somewhere, archive.or perhaps? 😉
The memory where the serial number lives is inside the NET$OS.EXE file so it’s going to be overwritten when it loads.
I need to put the 286 NetWare 2.0a SFT II on archive.org, yes… but first I need to scan the disks. I can’t promise it will be super fast.
I was certified (CNE) on 2.0a, good times.
Don’t remember ever needing a hardware based key card, but yeah, each server needed a serial number.
My understanding is that Advanced NetWare 2.12 dropped the hardware keys, and NetWare ELS never needed them.
“floppies with Advanced NetWare 286 2.0a SFT II”
Can you post a picture how this product was actually marked on the package?
I guess it is “SFT Netware 286 Level II 2.0a”.
Back then “Advanced” and “SFT” were actually two different product lines…
thanks,
raul, ex CNE
Thinking about it, this is probably one of the good things that the MCA bus did, even though it never caught on.
I find it amazing that as dominate as Netware was, that there is such a lack of detailed technical information about it.
The first Netware 86 I installed had a couple of gotchas. We sold it as a non-dedicated server with three workstations to run Microsoft Word (for MS-DOS). This was in the fall of 1986.
We went with G-Net as the network topology because it combined the hardware key on the network card and we knew not a lot.
This was using an HP Vectra, HP’s first IBM AT compatible. We were safe because the Vectra was on the approved hardware list. We had three problems that prevented us from delivering the system.
The Vectra used a custom caching disk controller, After some hair pulling we eventually found it was definitely not compatible with Netware 86. We had to replace it with a clone AT disk controller.
The second was there was some issue using G-Net. I do not remember what it was, and I can’t find anything about it today to remind me how it worked.
We switched to ArcNet and I think we used the cable we had for G-Net. I seem to remember that it messed with the available distances, but it did work well enough after rerouting the cables a bit. We had to keep the G-Net card installed as the key.
Extra part of the story that had nothing to do with the hardware key.
The third thing is we needed more memory on the non-dedicated server to run Word. I eventually found an 8-bit memory card that allowed me to set the base address at the 640K line giving us a total of 704K of conventional memory. I know this is not as fast as a 16-bit card, but I was desperate.
I wrote an assembly program to make it available in DOS. 1986 me was proud of it.
Pseudo code:
If the BIOS reports 704K go to Exit
Is there isn’t RAM at A000 go to Exit
Write 704 in the BIOS memory size location (02C0H in 40:0013H).
Set the BIOS flag (1234H in 40:0072H) for warm reboot without memory check.
Go to reset vector (f000:fff0H).
:Exit Return
The system and the non-dedicated server worked great for several years until it was upgraded to Netware 286.
You’re right, the disks are labeled “SFT NetWare 286 Level II V2.0a”. There’s a card that comes with it that says “SFT NetWare” but there’s also a sticker on it saying “Advanced NetWare 2.0a”. The Tutorial floppies say Advanced NetWare, not SFT NetWare (because of course they were the same).
But if you e.g. start SYSCON and look at the server version, it says “Advanced NetWare Version: 2.00”. It seems like Novell was not entirely consistent.
Michal: Not 100% sure but I would think that reading non-existing I/O ports would return all 1’s, i.e. FF. Maybe it would be possible to patch the files to have serial number 000000 and the application number to 00 too? The problem is that you’d probably end up with zero capabilities with an application number of 00, perhaps?
Rich Shealer:
I think that a reason for the lack of documentation re Netware and for that sake other PC related specialized topics from the days was that most people were at the level you describe that you were at in 1986, i.e. doing some trial-and-error stuff, partially due to lack of documentation and general knowledge back in the days. Combine this with an unwillingness to actually bring up problems with the vendors (perhaps due to contracts that stipulates that the customer had to pay even if the problem was due to an actual bug in the vendors product – compare for example with Microsoft Outlook 97 (not express) + their Exchange server, where multiple “move” auto sort rules matching at the same time ended up with the mail being duplicated in different places. This was obviously never fixed due to every organisation large enough to run Exchange not wanting to pay for not having to check the “stop processing whatnot” checkbox in the mail auto sorting rules dialog).
Netware was the big one at the time. I think it’s even more sad that the competitors (except for Microsoft/IBM) are even more poorly documented nowadays. Thinking about Artisoft Lantastic, Banyan Wines, 3Com 3Open+ and their 3Server server hardware boxes and whatnot. Sure, there are some documentation but there aren’t (m)any nice blog posts like the ones Michal makes, no Youtube videos (worth watching) and whatnot.
For other products there are at least the original documentation to rely on, like for example PCSA/Decnet with a VAX as a server and PCs as clients, although it’s a bit tricky to set up unless you already know what you are doing.
And then there is the lack of documenting interoperability between various systems. I enjoyed the videos Retrospectator 78 on Youtube made about mail in the mid 90’s, but miss anything about making the server talk to other things, and running both the MS Mail client and the Exchange/Outlook client with the same server setup, and also how the MS Mail client managed using a simple file server for communicating between users and whatnot, and also what interoperability products there were at the time. Very niche, but would be nice topics to read about
@Rich Shealer
Thank you for your input. I read your recollections with pleasure.
I guess this is the G/Net card you have in mind?
https://wiki.preterhuman.net/images/4/42/Gatewaygnet.jpg
If you have any more recollections, please share.
Yes, it’s sad that there’s so few remaining info on the early NW versions,
yet they came with the extensive amount of documentation ( i hope our host here
will scan, OCR and share the documents/manuals he has?).
Yes, I plan to scan the documentation (which I do have, though it may be incomplete). And yes, Novell did have quite extensive documentation.
As an aside, NetWare 2.0 documentation also survived in electronic form on Novell’s NSE (Network Support Encyclopedia) CD-ROMs.
The developer information for VAPs or NLMs was a lot harder to obtain. I imagine that Novell’s frequent exhortations as to the superiority of cooperative multitasking compared to preemptive multitasking would cause much dismay these days.
JMP1 sets the I/O port base address.
@RAY – It was 38 years ago, so it might have been. We replaced it with a short serialized card like in Michal’s picture.
Great job Michal. I remember genning up some 2.0a systems. You had a great number of boxes of disks that had to be fed in the right order to link the os all together with the right hardware options (Disk controller / Network card / etc.) One of the other tasks you had to do was run the DiskPrep? program on your hard drive. It would read/write the whole drive pretty extensively to mark out any bad blocks. Sometimes it would run for days and then tell you, Nope, don’t like that drive. You’d have to get a new drive and try it all over again. Ugh.
I think COMPSURF is the dreaded program you’re talking about.