What function was used to code these passwords in AFX?

Question

I am trying to work out the format of a password file which is used by a LOGIN DLL of which the source cannot be found. The admin tool was written in AFX, so I hope that it perhaps gives a clue as to the algorithm used to encode the passwords.

Using the admin tool, we have two passwords that are encoded. The first is "dinosaur123456789" and the hex of the encryption is here:

The resulting hex values for the dinosaur password are

00h: 4A 6E 3C 34 29 32 2E 59 51 6B 2B 4E 4F 20 47 75 ; Jn<4)2.YQk+NO Gu 10h: 6A 33 09 ; j3. 20h: 64 69 6E 6F 73 61 75 72 31 32 33 34 35 36 37 38 ; dinosaur12345678 30h: 39 30 ; 90

Another password "gertcha" is encoded as e8h: 4D 35 4C 46 53 5C 7E ; GROUT M5LFS\~

I've tried looking for a common XOR, but failed to find anything. The passwords are of the same length in the password file so I assume that these are a reversible encoding (it was of another age!). I'm wondering if the AFX classes may have had a means that would be used for this sort of thing?

If anyone can work out the encoding, then that would be great!

Thanks, Matthew

[edit:] Okay, first, I'm moving on and going to leave the past behind in the new solution. It would have been nice to use the old data still. Indeed, if someone wants to solve it as a puzzle, then I would still like to be able to use it.

For those who want to have a go, I got two passwords done.

All 'a' - a password with 19 a's: 47 7D 47 38 58 57 7C 73 59 2D 50 ; G}G8XW|sY-P 79 68 29 3E 44 52 31 6B 09 ; yh)>DR1k.

All 'b' - a password with 16 b's. 48 7D 2C 71 78 67 4B 46 49 48 5F ; H},qxgKFIH_ 69 7D 39 79 5E 09 ; i}9y^.

This convinced me that there is no simple solution involved, and that there is some feedback.

Answer 1

Well, I did a quick cryptanalysis on it, and so far, I can tell you that each password appears to start off with it's ascii value + 26. The next octet seems to be the difference between the first char of the password and the second, added to it's ascii value. The 3d letter, I haven't figured out yet. I think it's safe to say you are dealing with some kind of feedback cipher, which is why XOR turns up nothing. I think each octets value will depend on the previous.

I can go on, but this stuff takes a lot of time. Hopefully this may give you a start, or maybe give you a couple of ideas.

Answer 2

But since the output is equal in length with the input this looks like some fixed key cipher. It may be a trivial xor.

I suggest testing the following passwords:

 * AAAAAAAA
 * aaaaaaaa
 * BBBBBBBB
 * ABABABAB
 * BABABABA
 * AAAABBBB
 * BBBBAAAA
 * AAAAAAAAAAAAAAAA
 * AAAAAAAABBBBBBBB
 * BBBBBBBBAAAAAAAA

This should maybe allow us to break the cipher without reverse engineering the DLL.

Answer 3

Can the dll encode single character passwords? Or even a zero-character password?

You're going to want to start with the most trivial test cases.

Answer 4

You may be looking at this problem from the wrong angle. I would think that the best why to figure out how the password hashes are created is to reverse engineer the login dll.

I would recommend IDA Pro for this task. It's well worth the price for the help is gives you is reversing executable code into readable assembler. There are other disassemblers that are free if you don't want to pay money but I haven't come across anything as powerful as IDA Pro. A free static disassembler / debugger that I would recommend would be PEBrowse from SmidgeonSoft as it's good for quickly poking around a live running system and has good PDB support for loading debugging symbols.