Chicago 73g/81 protection (Beta ID + Password)

[The Distractor]

So I decided to open IDA and take a look at 73g's and 81's SUWIN.EXE, to take a look at how the protection works.

There's a WORD value, that is set to two values, 0xFEED and 0xDEAD.

(There's also a XOR in one place to toggle the value.)

I believe that when the WORD value is set to 0xDEAD, which happens just before the "select components/just install" dialog is created, the setup does not ask for Beta ID/Password. However, I haven't tested to see if it actually installed that way. Easy to find out though, just a quick patch of a conditional jump.

An interesting thing happens if a certain code branch is taken based on the result of a function that checks some networking APIs.

The contents of a resource (TEXT - SETUP_INF) is grabbed. The contents are decrypted using a xor, using one byte from the string "felix" every iteration, (after the last byte, it cycles back to the first byte of the string).

(I don't know where "felix" comes from. It could be related to one of the codenames of a standalone DOS 7 that never happened, it could be someone's name.)

This ends up with a very interesting string: an LF-deliminated list of network shares!

I would paste both the lists from 73g and 81 here, but I don't have them right now.

I'm still unsure how this list is used, especially because when I got the SETUP_INF resource to decrypt, that WORD was set to 0xDEAD.

Regarding the General Error 57 dialog, it calls a function and compares a 4-character string against another one. (and if they match, that WORD is toggled.) I'm still not sure how each of the strings are obtained. Obviously, more to come later..

(I wish Hex-Rays worked with 16-bit x86 asm..)

Oh and by the way, the warez scener who cracked 73g SUWIN in January 1994 referenced the protection in CHICAFIX.COM:



EDIT: Here's the SETUP_INF resource, decrypted, from 73g:

Code: Select all

\\GUILO\CHICO
\\GUILO\DAILY
\\CHICAGO\PSG
\\CHICAGO\USER
\\SMADAMOT\CHICO
STRIKE
\\STRIKE\SYS
\\JAKE\SETUP
\\TAL\SLM
\\IRLSYS7\CHICAGO
\\GATE_NT\M5
\\AMS_XNS_SRV\CHICAGO
\\GIUNONE\CHICAGO
\\TCRD\CHICO-C
\\GMBHPGM1\INTERN
\\SGH_Z\CHICOREL
\\LUCIFER\M5
\\RICHARDIII\WINTEAM$
\\MATSJ1\CHICAGO
\\KKJUPITER\CHICOREL
\\ISRAEL\ISRPUB
\\SNOWBALL\CHICO
\\DECKER\CHICO
\\IRLWG1\CHICAGO
\\LTDPSS01\BETA
\\FOR\PRELEASE
\\ELVISP\PRODUCTS


fxfe

...and for 81:

Code: Select all

\\GUILO\CHICO
\\GUILO\DAILY
\\CHICAGO\PSG
\\CHICAGO\USER
\\SMADAMOT\CHICO
\\SMADAMOT\DIST
STRIKE
\\STRIKE\SYS
\\JAKE\SETUP
\\TAL\SLM
\\IRLSYS7\CHICAGO
\\GATE_NT\M5
\\AMS_XNS_SRV\CHICAGO
\\GIUNONE\CHICAGO
\\TCRD\CHICO-C
\\MUC-PROD-1\PGM_ONLY
\\SGH_Z\CHICOREL
\\LUCIFER\M5
\\RICHARDIII\WINTEAM$
\\MATSJ1\CHICAGO
\\KKJUPITER\CHICOREL
\\ISRAEL\ISRPUB
\\SNOWBALL\CHICO
\\DECKER\CHICO
\\IRLWG1\CHICAGO
\\LTDPSS01\BETA
\\FOR\PRELEASE
\\ELVISP\PRODUCTS
\\PDCHAND34\CHICAGO
\\PDCHAND35\CHICAGO
\\PDCHAND36\CHICAGO
\\PDCMONKEY\CHICAGO
\\EUROLABS\CHICAGO
\\PNPSVR\PNPDAILY
\\HITME\WEEKLY
\\HITME\DAILY


cfel

[Ahmed Jebara]

So I decided to open IDA and take a look at 73g's and 81's SUWIN.EXE, to take a look at how the protection works.

There's a WORD value, that is set to two values, 0xFEED and 0xDEAD.

(There's also a XOR in one place to toggle the value.)

I believe that when the WORD value is set to 0xDEAD, which happens just before the "select components/just install" dialog is created, the setup does not ask for Beta ID/Password. However, I haven't tested to see if it actually installed that way. Easy to find out though, just a quick patch of a conditional jump.

I've discovered that a year ago, you might guys remember it when I was on your IRC.

It's a JCE opcode iirc which before it compares the result of checking beta key, if they don't match it stores somewhere in memory 0xDEAD. Before that JCE there's a CMP WORD PTR [ThatAddress], 0xFEED. If they're not same it rather shows the G.E. 57. I've worked around it by changing it to *unconditional* jump (JMP) rather, and it worked.

I still have SUWIN.EXE somewhere in my archives that I patched

[The Distractor]

Update:

I figured out that the word is toggled if the last 4 characters of the password you entered match those that are stored somewhere within suwin, encrypted somehow.

This allowed Battler to get a working Beta Site ID/Password for 73g:
Beta Site ID: 101907
Password: 999b093b8

Tested working with untouched 73g.

(Oh and also, here's another way to crack 73g's suwin: patch the two bytes at 0x10b00 to two NOPs. This forces it to read and decrypt the SETUP_INF resource, and it ends up setting that WORD to 0xDEAD for somereason, don't know why.)

[Battler]

We have now found out that the expected last 4 bytes of the password vary according to both the first 4 bytes of the password and the beta site ID. We are still in the process of finding out how exactly they are generated. I personally suspect there must a fixed string or number somewhere that affects the generation (which would explain why 73g expects different last 4 bytes than eg. 81).

Here are 2 other combinations that should work with 73g:
140734 / d8f21a59a
186349 / 94736630f .

[longhornwhistler]

Is there anymore protection problems

[Battler]

Just to clarify, the Beta Site ID and password are checked against two different algorithms:
Algorithm #1: Let us take this combination: 140734 / d8f21a59a . We see the middle character of the password is 1. How do we arrive it at? The answer is thus: we sum the ASCII codes of the all other characters of the password + the ASCII codes of all digits of the beta site ID, then mod it with 9.
So as thus for the above case: middle_char = (0x31 + 0x34 + 0x30 + 0x37 + 0x33 + 0x34 + 0x64 + 0x38 + 0x66 + 0x32 +0x61 + 0x35 + 0x39 + 0x61) % 9.
If the Beta Site ID and password we have typed do not resolve to a password middle character we have calculated, we get a message box telling us the Beta Site ID and password we typed, are not correct, and have to type new ones.
Algorithm #2: This is the one we are still trying to figure out, but we currently know that it generates the last 4 characters of the password according to the first 4 characters of the password + the beta site ID. If the generated characters do not match the ones we typed, the check value (which by now has already been turned from 0xFEED to 0xDEAD) is XOR'ed with 0x2040, therefore becoming 0xFEED again. Result: General Error 57 is triggered. From what we have observed, the bulk of the code that generates them seems to be in code segment 2, with some in code segment 19 too. But there might be additional clues in code segment 5 too (where the XOR'ing of 0xDEAD back to 0xFEED is done).

[Battler]

So, regarding Algorithm #2, hounsell discovered the title of the General Error 57 message box is also used in the generation of the last 4 characters of the password. In addition, I have discovered that the offsets in the data segment at which the data is passed to the generation routines, also affect the generation.

In the end, by simply taking the relevant code straight out of SUWIN, and writing essentially my own wrapper around it, I was able to make a key generator. The link is: http://citadel.ringoflightning.net/CHICAKEY.ZIP . It includes the compiled .COM file, the .ASM source of most of it, and the used .BIN of segment 2 code from SUWIN.EXE (slightly modified so the CALL FAR's to the two small segment 19 routines are DWORD PTR-type, otherwise the CALLs won't work correctly in DOS).
Usage: You simply extract the .ZIP file in DOS, type CHICAKEY, then type the 6 decimal digits of the Beta Site ID (to keep in line with the Microsoft ones, I suggest using 1 as the first digit, followed by 5 random digits), and the first 4 hex digits of the password (just input any random 4 hex digits), press ENTER, and the generator will calculate for you the last 4 characters + the middle character of the password for Chicago 73g, 81, 122/189, and 224.

[Battler]

After some more work, version 2 of the generator is out. The link is: http://citadel.ringoflightning.net/CHICAKY2.ZIP . It fixes some bugs from the first version (one of my functions was accidentally left without a RET, I'm surprised it still worked that way), reduces the uncompressed version of the .COM file (since I found a better way to ensure the data gets passed to the generator functions at the correct offsets), and now also randomly generates the Beta Site ID and/or first 4 characters of the Password, if you leave either field empty. In addition, the splash string now has an ASCII art Windows logo. Also, due to the randomizer, this version of the generator requires at least a Pentium processor.

[Battler]

And here is version 3 of the generator! The link is: http://citadel.ringoflightning.net/CHICAKY3.ZIP . This version is fully compatible with the NEC PC-98 architecture (it now talks to the clock via the INT 21h DOS API, rather than using INT 1Ah, and it also has a secondary, ASCII art, version of the ANSI art Windows logo, displayed on both PC-98 and DOS/V, with the normal ANSI art version displayed on non-Japanese DOS). In addition, it removes unused code from the Microsoft portion (taken out of SUWIN.EXE), which is also modified to call the two segment 19 functions in the NEAR way now, rather than FAR - this version of the generator disposes with ALL FAR calls and turns them into near calls, and in addition removes the entire pseudo-multiple-segment framework since it was discovered that it's not needed at all, and that both the generator code, and the data passed to it, can be at any offset. This has permitted the reduction of the file size to 6.2 kB uncompressed (3.9 kB compressed). In comparison, version 2 was ~12 kB uncompressed (4.4 kB compressed), and version 1 was ~25 kB uncompressed (3.7 kB compressed). Also, due to the aforementioned discoveries, I have reduced the number of "call the generator" functions to one (from four), and modified it so that it gets called for all 4 supported Build series with much less code repetition.

Edit: Version 3.01 is out! The link is: http://citadel.ringoflightning.net/CHICK301.ZIP . Fixed another bug (regarding computation of the size of the string containing all the data needed for generation), and reduced the size further, to 6.0 kB uncompressed (3.7 kB compressed).

[carlaum1]

Battler, why the randomizer makes the whole key generator require a Pentium processor?

[Battler]

- carlaum1: You have a very good point. But then again, it would require at least a 386 anyway since the generation code itself uses 32-bit registers for example (that and because it's for Chicago, which is 32-bit and therefore itself requires at least a 386). But I could make it work below a Pentium, just disabling the randomizing stuff and outputting a warning message, while outright erroring out and refusing to work if the CPU is not at least a 386.

Update: Version 3.5 is out! The link is: http://citadel.ringoflightning.net/CHICKY35.ZIP . Made the CPU check routine only check for 386 and Pentium, rewrote the routine that resets the first 32 bytes of the generation buffer to some values the actual generation code expects, made the whole thing run on 386 and 486 too, but displaying a warning that the randomizer will not work on those CPU's, as well as made it quit on error if you attempt to give the program incomple Beta Site ID and/or Password first 4 characters and your CPU is not at least a Pentium. Also rewrote the function that calculates the modulo 9 to get the middle character of the Password.

[carlaum1]

Battler, is it impossible to make a randomizer that works in a 386 CPU? I don't know much about programming, that's why I'm asking.

[Battler]

- carlaum1: It's not, but it would use either the MS-DOS API call to read the system time, or the equivalent INT 1Ah system call, and that tends to have a less precise resolution than the RDTSC instruction that I use and which only exists on Pentium and above.

[carlaum1]

Battler, how your code detects a Pentium-class CPU? I read that Cyrix 6x86 doesn't support the RDTSC instruction. I don't have one to test, but depending on the way detecting works, it may think that one of those is a Pentium.

[Battler]

- carlaum1: It attempts to set a specific flag that can only be set on a Pentium and above, and if it fails to, it assumes the CPU is not a Pentium.

Anyway, version 4 of my generator is out! The link is: http://citadel.ringoflightning.net/CHICAKY4.ZIP . The generator can now run on any 386 or above CPU, even the randomizer (made it read the system clock using the DOS INT 21h API call if the CPU is below a Pentium, but RDTSC if it's a Pentium or above). Also added some command-line parameters, so you can now use this generator in batch files, for example (a good example of that would be using it in AUTOEXEC.BAT on a Chicago Setup boot disk!). Fixed some bugs. Removed some redundant code. Added a .TXT readme file with information on the advanced features, as well as with my contact information.

[Battler]

Version 5 of my generator is out! The link is: http://proxima.ringoflightning.net/CHICAKY5.ZIP . The generator now supports Builds 73f, 99, and 116. It can now also optionally output the information in .INI file format which is very useful since that way you can redirect output into a file and then read that file with mIRC, for example.