解密数据开头的随机字符

I am using a TADOQuery component in Delphi to read the contents of a column in a database which have been encrypted by a 3rd party .net application using RijndaelManaged algorithm. I have "sucessfully" decrypted the data back to its original XML format but there are random characters at the beginning of decrypted data.

我在Delphi中使用TADOQuery组件来读取数据库中列的内容，这些列已使用RijndaelManaged算法由第三方.net应用程序加密。我已经“成功地”将数据解密回原来的XML格式，但在解密数据的开头有随机字符。

?_????g???M.0"?>
<template xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" id="846aaa43-dc42-4bc7-98bd-bf643fd324cb" xmlns="http://web.net/schema">
    etc, etc, etc...

I have a feeling that this is the BOM but cannot figure a way of ignoring it during the reading / decrypting of the data.

我觉得这是BOM，但在读取/解密数据期间无法想出忽略它的方法。

I read the data like this:

我读了这样的数据：

tmpMemoryStream : TMemoryStream;
Result : TByteArray; (array of byte)

tmpMemoryStream := TMemoryStream.Create;
tmpMemoryStream.LoadFromStream( ADOQuery1.CreateBlobStream(ADOQuery1.FieldByName('Design'), bmRead) );

setLength(Result, tmpMemoryStream.Size);
tmpMemoryStream.Read(Result, 0, tmpMemoryStream.size);

The resulting byte array is then passed to a function that decrypts the data.

然后将生成的字节数组传递给解密数据的函数。

Thanks in advance.

提前致谢。

EDIT 1

编辑1

Each encrypted file has the same header which looks like this:

每个加密文件都有相同的标题，如下所示：

A9 CD AA F5 AE 36 04 2F 04 2A A5 2F CE EF B0 83 C4 97 F7 CA 26 F7 28 ED F8 C3 26 F4 57 D5 CB EA 36 10 F9 9B A6 CE F2 67 6B 47 B9 16 6E A7 41 14 A2 CD 99 88 51 17 67 03 C0 C4 66 18 D6 2A 1F D2 DD 5F 24 83 14 87 96 35 90 B6 70 F1 E6 51 BD 7A AB 41 86 E8 4D F4 E0 B7 D4 0A 22 DA 26 BD 54 D4 DE D1 23 36 BE D8 C8 D9 EC D8 5B 0E 0B 1D BE D8 A3 BD B7 E4 37 40 EB 86 76 85 E5 F7 15 87 EB 47

The garbled first part of the decrypted data changes with each file, but as an example, looks like this:

解密数据的乱码第一部分随每个文件而变化，但作为示例，如下所示：

3F 3F 3F 3F 3F 36 04 2F 04 2A 3F 2F 3F 3F 3F 3F 3F 3F 3F 3F 26 3F 28 3F 3F 3F 26 3F 57 3F 3F 3F 36 10 3F 3F 3F 3F 3F 67 6B 47 3F 16 6E 3F 41 14 3F 3F 3F 3F 51 17 67 03 3F 3F 66 18 3F 2A 1F 3F 3F 5F 24 3F 14 3F 3F 35 3F 3F 70 3F 3F 51 3F 7A 3F 41 3F 3F 4D 3F 3F 3F 3F 0A 22 3F 26 3F 54 3F 3F 3F 23 36 3F 3F 3F 3F 3F 3F 5B 0E 0B 1D 3F 3F 3F 3F 3F 3F 37 40 3F 3F 76 3F 3F 3F 15 3F 3F 47

EDIT 2 It was a problem with the IV... I was using the following code:

编辑2这是IV的问题...我使用以下代码：

with myRijndaelManaged do
    begin
        BlockSize := 128;
        KeySize := 256;
        Key := myKey;
        IV := IV; <-- Should have been "myIV"
        Padding := PaddingMode.PKCS7;
        Mode := CipherMode.CBC;
    end;

Because it was in a with block, even though the IV variable wasn't set, it wasn't flagged as an error as it is a property of the myRijndaelManaged object. I changed IV to myIV which contained the correct byte array data.

因为它在with块中，即使没有设置IV变量，它也不会被标记为错误，因为它是myRijndaelManaged对象的属性。我将IV更改为myIV，其中包含正确的字节数组数据。

Thanks for the pointer @bartonjs

感谢指针@bartonjs

1 个解决方案

#1

This looks a rather lot like you are not setting the IV value during decryption, leading to the first 16 bytes having plaintext recovery problems.

这看起来很像你在解密期间没有设置IV值，导致前16个字节有明文恢复问题。

For full recovery you need the cipher text, key, and original IV (for modes other than ECB).

要完全恢复，您需要密文，密钥和原始IV（对于ECB以外的模式）。

#1