C# - Arithmetic overflow - Decompression of string via gzipstream

Question

I'm having an issue with implementing a GZIP string decompressor. The compressed string is a20d32fdda14b300b28aa6b72982af3b as shown below. However, when running this code, I receive the error:

"System.OverflowException occurred
HResult=0x80131516
Message=Arithmetic operation resulted in an overflow.
StackTrace:
at GZipDecompressor.Decompress.Main(String[] args)
"

when executing the line starting with "byte[] buffer2"

using System;
using System.IO;
using System.IO.Compression;
using System.Text;

namespace GZipDecompressor
{
    class Decompress
    {
        public static void Main(string[] args)
        {
            string compressedText = "a20d32fdda14b300b28aa6b72982af3b";
            int length = compressedText.Length;
            byte[] buffer = Convert.FromBase64String(compressedText);
            using (MemoryStream stream = new MemoryStream())
            {
                stream.Write(buffer, 4, buffer.Length - 4);
                byte[] buffer2 = new byte[BitConverter.ToInt32(buffer, 0)];
                stream.Position = 0;
                using (GZipStream stream2 = new GZipStream(stream, CompressionMode.Decompress))
                {
                    stream2.Read(buffer2, 0, buffer2.Length);
                }
                Console.WriteLine(Encoding.UTF8.GetString(buffer2));
            }
        }
    }
}

Could someone please explain why this is happening and how to go about solving it.

Does the input contain the length of the original uncompressed data as an int in the first 4 bytes? — Lasse V. Karlsen, Jun 27 '17 at 11:45
How sure are you that your input string is actually valid? Where did it come from? — Chris, Jun 27 '17 at 11:46
Please address anyone using the @ syntax. Are you asking me? It's not my code, see my question in my first comment. Does the input contain the length as the first 4 bytes? — Lasse V. Karlsen, Jun 27 '17 at 11:49
@lomed: You might want to be more explicit with whatever point you are making. The line of code you are quoting is quite valid. The call to `ToInt32` will return an number made of the first four bytes in the array. I presume this is deliberate and is why the memory stream omits the first four bytes (because they have a different purpose). If you think there is something wrong you should say what it is rather than being vague... — Chris, Jun 27 '17 at 11:51
@LasseV.Karlsen: The string decompresses to 121013301333232an — Kavinda JD, Jun 27 '17 at 11:52
Then check, verify. First rewrite your program by grabbing that int (`BitConverter.ToInt32(buffer, 0)`) into a variable, then debug your program and check what the number you get is. Most likely you get a **really** big number. — Lasse V. Karlsen, Jun 27 '17 at 11:52
@KavindaJD are you sure `compressedText` is actually base64 encoded? It appears to contain only hexadecimal characters. — C.Evenhuis, Jun 27 '17 at 11:55
@Chris: This is more of a reverse engineering project. A program outputted a file with the name a20d32fdda14b300b28aa6b72982af3b. It was extracted from a larger, zip file. I am assuming that it uses a GZip decompression as I decompiled the .dll that carries out the decompression. — Kavinda JD, Jun 27 '17 at 11:56
A valid gzip stream starts with the bytes `0x1f 0x8b`. Your string does not contain these bytes, whether raw, as a hexstring or decoded as Base64. You'll have to take a closer look at what's producing this string. Note, also, that [ZIP is not GZip](https://stackoverflow.com/questions/20762094/). — Jeroen Mostert, Jun 27 '17 at 11:57
Then I'm voting to close this question as unclear. You should start on the principle that your code is just buggy, if your question is really "I have this magic file, how can I decode it", that's **a vastly different question**. — Lasse V. Karlsen, Jun 27 '17 at 11:58
@C.Evenhuis: I am assuming it is. I don't know of another form it could take. — Kavinda JD, Jun 27 '17 at 11:59
@KavindaJD Did you take into account it could be a hexadecimal representation of bytes? I don't know your level of expertise, so ruling out possibilities because you don't know of them might not be a good starting point. — C.Evenhuis, Jun 27 '17 at 12:02
The assumption that a filename contains encrypted data seems very strange. More likely this is just a guid generated to guarantee a unique filename. The fact that it is a 32 character string of hex digits would support this theory since this is exactly the same as a guid (except guids are usually displayed with `-` to separate blocks but they can be easily stripped). — Chris, Jun 27 '17 at 12:06

score 2 · Answer 1 · answered Jun 27 '17 at 11:53

2

BitConverter.ToInt32(buffer, 0) produces negative value which is invalid for array allocation.

answered Jun 27 '17 at 11:53

vasek

2,759
1
26
30

That would give a different exception message than the one shown. OP says it gives "Arithmetic operation resulted in an overflow", whereas the negative number (that yes, it is reproducible from the shown code) gives "Array dimensions exceeded supported range" – Lasse V. Karlsen Jun 27 '17 at 11:56
@LasseV.Karlsen I've also tried and at my box initializing an array with a negative length gives the _Arithmetic operation resulted in an overflow_ exception, too. – C.Evenhuis Jun 27 '17 at 11:57
1

It seems that the negative value *must* be in a variable. If you do `new byte[-1]` I get a compile error `Cannot create an array with a negative size`. If I do `int temp = -1; var array = new byte[temp];` I get the overflow error. – Chris Jun 27 '17 at 12:00
1

https://stackoverflow.com/questions/3762060/rationale-behind-overflowexception-thrown-with-negative-array-size – Chris Jun 27 '17 at 12:02
@LasseV.Karlsen: The number I get is -551719573. Negative as discussed. – Kavinda JD Jun 27 '17 at 12:09

C# - Arithmetic overflow - Decompression of string via gzipstream

1 Answers1