0

I'm trying to help a small business transition out of an obsolete, obscure piece of software, and app support is, unfortunately, non-existent. To fully export the data for the new system, I need to be able to decrypt/decipher a string in one of the database fields. But cryptography is not my specialty and I have not been able to reverse engineer what seems to be a very simple encryption/cipher algorithm.

I can create plaintext strings using the app, then see what they look like encrypted in the database. I can copy the encrypted string from one database record to another and it still decrypts just fine no matter which record I open in the app. This suggests to me either the method is keyless, or it's a static/hardcoded key which is always the same. It smells like some kind of XOR method but I can't fully put my finger on it even though analysis of the input and output has provided significant clues.

More clues: The application is for the Windows platform (32 bit), apparently coded in VB6. It's built on a code base that was first released in 2001, and version updates have been incremental and backward-compatible, so I surmise the current version is derived from that original 2001 codebase. That means the encryption method is likely of that time (2001); newer encryption methods can likely be ruled out.

The encrypted output is always a hexadecimal string with a length which is a multiple of 16. For example, a 1-to-7-character input produces a 16-character hex output. An 8-to-15 char input produces a 32-char hex output. A 16-to-23 char input produces a 48-char hex output. Note that while some of the sample inputs are numeric, they are strings. Notice also that some of the output hex strings have the same endings or beginnings as others despite their inputs being different.

I am sure someone with a bit more experience than myself can sniff out the encoding algorithm in a jiffy. So here are some sample plaintext inputs and encrypted/ciphered outputs. What can you tell me?

Samples:

INPUT (PLAINTEXT STRING)   OUTPUT (HEX STRING)
=================================================================
0                          3603B5C0D407A6FF
1                          9034469951F9BDB6
2                          101080C2FB110A89
0000000                    8AB449F106D5F76A
00000000                   87E0460F100F7E5B7783D03238923053
000000000000000            87E0460F100F7E5B8AB449F106D5F76A
This is a sample string.   D9E1588915C9B1E00D688CBCA066B18D70DC39F1072896F77783D03238923053
Hello, world!              108350BBCE7441DB9BB6235DADC206B5
Bazinga!                   2C03D5CBAAEA807D7783D03238923053

I would be happy to supply any other sample input/output by request.

mindofsound
  • 1
  • 1

1 Answers1

0

It looks like DES.

Arbitrarily using a Key of hex    0000000000000000
and an initialization vector of   0000000000000000

The value 0000000 becomes  01a4f7bc5f3aa9ee
but value 00000000 becomes de8d55142b18deb7472b8bbb294d3f3d

I have no idea as to the correct Key and IV.

user10216038
  • 7,552
  • 2
  • 16
  • 19
  • Or any other 64-bit-block cipher -- like 3DES aka triple-DES aka TDEA, DES-X and other variants, IDEA, CAST, RC5, or even Skipjack -- in ECB mode (thus _no_ IV) with unambiguous padding such as PKCS5. – dave_thompson_085 Oct 27 '20 at 07:27
  • OK, that is somewhat helpful. I have attempted to decompile the application and search the code for strings which could be keys, although deciphering the assembly code is like trying to read Martian for me. No luck yet, but if I do find them, I appreciate you guys helping me narrow the encryption method possibilities. – mindofsound Oct 27 '20 at 20:36