1

I'm working on decrypting something I didn't create. The authors encrypted it from a java program, and I'm trying to decrypt it in C#. They have given me the logic behind their encryption (the integer key array, encoding type, and TripleDES), and I've been trying to figure this out.

Long story short, I have been able to decrypt most of the text, however, the middle is always scrambled.

I've researched this a lot trying to figure it out, notably, the issue of Java's negative byte numbers. This might be the reason why my decryption partially works, because half of my given java key integers are negative. However, even when I manually change the byte number to correspond to the C# equivalent, or use BitConverter, I still get the same scrambled result.

The other thing could be that I can't seem to get the UTF-8 encoding to provide better results than ASCII.

The code. I store my 24 byte integers (as strings) in the App.Config and convert them to integers in the code:

I loop through all the strings to get the desired byte array: (ipstr is the n-th string in the loop)

int dii = Convert.ToInt32(ipstr);
byte[] intBytes2 = BitConverter.GetBytes(dii);
if (BitConverter.IsLittleEndian)
    Array.Reverse(intBytes2);
byte[] result = intBytes2;

Then I use the 4th index in the byte conversation to save the fully converted byte array for the tripleDES decryption.

FinalByteArr[j - 1] = result[3];

This seems like a lot of work, but it gets my Java-originated negative string keys to C# 0-256 byte key array.

Then I get all the bytes from their output file:

string path = @"E:\file.txt";
byte[] b1 = File.ReadAllBytes(path);
TripleDESCryptoServiceProvider objDESCrypto = new TripleDESCryptoServiceProvider();
MD5CryptoServiceProvider objHashMD5 = new MD5CryptoServiceProvider();
byte[] byteHash, byteBuff;
objHashMD5 = null;
objDESCrypto.Key = FinalByteArr;     
objDESCrypto.Mode = CipherMode.ECB;  
objDESCrypto.Padding = PaddingMode.PKCS7;
byteBuff = b1;  
string strDecrypted = ASCIIEncoding.ASCII.GetString(objDESCrypto.CreateDecryptor().TransformFinalBlock(byteBuff, 0, byteBuff.Length));

The odd thing is, this appears to work, and my file is decrypted for most of the characters. There are obvious words and numbers in the decrypted text. But about 30% of the middle characters are jumbled up. I've tried all the ciphermodes and paddingmodes without any improvement.

I can't post the actual result, because of confidentiality, but it looks a lot like this: 

PK   \2\5\1\5\1\8\2\4\2\0\?n?\Rotate??????????????%??8p??(u??Z??%??8p??(u??Z??%??8p??(u??Z\0\0\0\0\0\0\0\0\0\0\0\RotatePKRotate

Even when I use UTF-8 encoding for the last line, I get the same garbled mess in the middle, but instead of question marks I get lots of unique characters.

That's where I'm at. Any advice would be really helpful. I'm very confused, because I'd expect incorrect decryption creds to have nothing decrypted at all. But having some of the words appearing (and some not appearing) is strange.

Nicholas Pisca
  • 150
  • 1
  • 10
  • Anyone have a suggestion on this? I've tried several different permutations, but can't get the middle of the bytes to convert into something usable. – Nicholas Pisca Jun 25 '19 at 03:01
  • First off, how do you know it can even be decrypted at all? The encryption specs look fairly amateur, so it not unreasonable to assume the encryption authors also made the fairly common amateur mistake of treating the bytes that were returned by their encrypter as a valid string encoding. This mistake results in partial data loss which, combined with the poor ECB mode, can result in some blocks being corrupted while others are ok. – President James K. Polk Jun 26 '19 at 13:51
  • I know it can be decrypted, because these files are being opened in custom software. I'd assume that whatever decryption is being used in the software is working, then I should be able to do the same with my C# program. The file that I'm trying to decrypt opens in the program fine. I'm just trying to use the key to read the text for myself. Then I'm making an exporter that uses this same encryption, hence the reason why I'm trying to figure this out. – Nicholas Pisca Jun 26 '19 at 22:27
  • @JamesKPolk, The original authors did their encryption in java. I'm doing my decryption in C#. Would there be any reason why the bytes would encrypt differently from Java? I know java has only signed bytes, but I think I accommodated for that in my preliminary loop converting the negative key values to positive values using BitConverter. – Nicholas Pisca Jun 26 '19 at 22:30
  • @JamesKPolk, here's a simpler question: Is my decryption code properly written? Is my problem in the ReadAllBytes at the beginning, or is my problem in the GetString at the end? – Nicholas Pisca Jun 27 '19 at 00:37
  • It's impossible to know without knowing how it was encrypted. I have done all I can. – President James K. Polk Jun 27 '19 at 00:39
  • What do you need from the authors of the encryption to figure this out? They gave me the following: TripleDES, 24-int Key, and UTF-8 encoding. Is there something else I'd need? – Nicholas Pisca Jun 27 '19 at 00:41
  • 1
    You've already indicated mostly successful decryption, which means the key, algorithm, and mode are correct. The statements you've made about UTF-8 don't quite make sense, which is why I still stand behind my guess in the last two sentences of my first comment. Without seeing *the actual code* all I can do is guess and I've already done that. – President James K. Polk Jun 27 '19 at 00:49
  • Thanks for your comments. I'm just mainly confused on how their java encrypt/decrypt coding is able to read and write these files, but when I want to decrypt it in C# to read it, it has corrupted characters? If their code is sloppy, then wouldn't it fail on their end in Java during their decrypt process? – Nicholas Pisca Jun 27 '19 at 00:57
  • @JamesKPolk, is there any chance I can email you about this? I've been trying this in Java, and I'm getting similar but different results. Can you explain "poor ECB mode?" – Nicholas Pisca Jul 18 '19 at 22:34
  • ECB mode is an bad choice for encrypting multiple blocks. See the [encrypted Penguin](https://blog.filippo.io/the-ecb-penguin/). – President James K. Polk Jul 18 '19 at 23:28
  • @JamesKPolk Thanks for the link. I'm just confused on one last thing. How can they decrypt the file, but I can't? I have the key, shouldn't that be enough to decrypt it? I know they can decrypt it, because every time they import the file, it opens in their software. So on their end, the file info isn't garbled when they decrypt it. So that means they have a decryption subroutine that takes the file contents, decrypts them, and reads the information. – Nicholas Pisca Jul 24 '19 at 16:29
  • They haven't decrypted it. That penguin is the *encrypted* file. That's the whole point. You've encrypted a plaintext picture of a penguin in ECB mode and yet the ciphertext is still recognizable as a penguin. – President James K. Polk Jul 24 '19 at 17:08
  • @JamesKPolk They must be able to decrypt it. Here is their process in their software. You make a scene in their software. You click "export." It saves this file in its encrypted form. 10 days later, you want to go back to that scene. You click "Open" and it reads that file, recreating the scene in their software. I don't see how there is data loss if they are reading the exact same file that I'm supposedly not able to decrypt. – Nicholas Pisca Jul 24 '19 at 18:48
  • @JamesKPolk, I'm still confused on how they are able to decrypt the text. They encrypted it, and they are decrypting it. Why can't I? – Nicholas Pisca Aug 01 '19 at 22:18

0 Answers0