Blizzard Installer Customisation

[stoneharry]

I'm working on replicating the full Blizzard patching process, whereby your login to WoW and a patch is sent to you containing a downloader, the downloader downloads a installer that then installs the patch and starts WoW back up updated.

With the help of Schlumpf, all but the last stage has been achieved.

The Blizzard Installer is made up of a series of parts in a single file:

• The main installer program
• An attached MPQ archive
• BsnI data (installer data)
• Signature data

Schlumpf wrote a tool to extract the base program from it, and then to be able to assemble a patch onto the installer program with the necessary BsnI data.

However, both the assembler and extractor through exceptions when I try to use them. Inflation is failing. For example, in the extractor, this line of code:

Code: [Select]

   int result = inflateInit (&stream); // this returns -2
    if (result)
    {
      return result;
    }
Returns -2 which throws an exception that inflation failed.

The source and cmake files can be found here: https://dl.dropbox.com/u/1102355/BsnI.zip

The full function that this error is returned from is shown below:

Code: [Select]

 int wrap_inflate ( unsigned char* output, int size_output
                   , const unsigned char* input, int size_input
                   , int* written_output
                   )
  {
    z_stream stream;

    stream.zalloc = NULL;
    stream.zfree = NULL;
    stream.next_in = const_cast<Bytef*> (input);
    stream.avail_in = size_input;
    stream.next_out = output;
    stream.avail_out = size_output;

    int result = inflateInit (&stream); // this returns -2
    if (result)
    {
      return result;
    }
    int inflateResult = inflate (&stream, 4);
    if (inflateResult == 1)
    {
      *written_output = stream.total_out;
      return inflateEnd (&stream);
    }
    else
    {
      inflateEnd (&stream);
      if (inflateResult != 2 && (inflateResult != -5 || stream.avail_in))
      {
        return inflateResult;
      }
      return -3;
    }
  }
If anyone is able to reproduce and fix this, then it would be greatly appreciated. I have no idea what could be wrong. I have tested it with the 3.0.1 to 3.0.2 installer and the 3.3.5 to 3.3.5a installer.

[schlumpf]

Code: [Select]

#define Z_STREAM_ERROR (-2)

inflateInit returns Z_OK if success, Z_MEM_ERROR if there was not enough memory, Z_VERSION_ERROR if the zlib library version is incompatible with the version assumed by the caller, or Z_STREAM_ERROR if the parameters are invalid, such as a null pointer to the structure. msg is set to null if there is no error message. inflateInit does not perform any decompression apart from possibly reading the zlib header if present: actual decompression will be done by inflate(). (So next_in and avail_in may be modified, but next_out and avail_out are unused and unchanged.) The current implementation of inflateInit() does not process any header information -- that is deferred until inflate() is called.

[stoneharry]

All the data seems to be set. Output has no contents but it is initialised. I do not understand why it would think the parameters are invalid.

Unless next_in and input are the issues (next_in is input casted).

Input is: &(*output)[0], and output is a empty unsigned character vector.

Tracing this back:

Code: [Select]

 std::vector<unsigned char> output_data (entry->inflated_data_size);
  zlib::inflate (input_data, &output_data);

It seems output_data is still the same empty vector.

So I am confused as to why it would consider any of these parameters invalid.

[schlumpf]

output_data is supposed to be empty, but the exact size given in the BsnI. Input should not be &(*output)[0] though, but &input[0]. Oo

[stoneharry]

output_data is supposed to be empty, but the exact size given in the BsnI. Input should not be &(*output)[0] though, but &input[0]. Oo

Yeah, it is correct - I was wrong. I misread it.

Code: [Select]

 int wrap_inflate ( unsigned char* output, int size_output
                   , const unsigned char* input, int size_input
                   , int* written_output
                   )
Being called by:

Code: [Select]

const int res (wrap_inflate (&(*output)[0], output->size(), &input[0], input.size(), &inflated));

[schlumpf]

Version of zlib?

[stoneharry]

Version of zlib?

#define ZLIB_VERSION "1.2.3"
#define ZLIB_VERNUM 0x1230

Edit: Updated my zlib binary in the executable directory, now result is returning -3. Code:

Code: [Select]

 int wrap_inflate ( unsigned char* output, int size_output
                   , const unsigned char* input, int size_input
                   , int* written_output
                   )
  {
    z_stream stream;

    stream.zalloc = NULL;
    stream.zfree = NULL;
    stream.next_in = const_cast<Bytef*> (input);
    stream.avail_in = size_input;
    stream.next_out = output;
    stream.avail_out = size_output;

    int result = inflateInit (&stream);
    if (result)
    {
      return result;
    }
    int inflateResult = inflate (&stream, 4);
std::cout << std::endl << "Inflate result from inflate(&stream, 4) = " << inflateResult << std::endl;
    if (inflateResult == 1)
    {
      *written_output = stream.total_out;
      return inflateEnd (&stream);
    }
    else
    {
      inflateEnd (&stream);
 std::cout << "if inflateResult != 2 && (inflateResult != 5 || stream.availin) return result, else return -3" << std::endl;
 std::cout << "stream.avail_in: " << stream.avail_in;
      if (inflateResult != 2 && (inflateResult != -5 || stream.avail_in))
      {
        return inflateResult;
      }
      return -3; // this is being returned
    }
  }
Result:

[stoneharry]

#define Z_BUF_ERROR    (-5)

Z_BUF_ERROR if no progress is possible (for example avail_in or avail_out was zero).

stream.avail_in = size_input;
stream.avail_out = size_output;

Both size_input and size_output have a value.

stream.avail_in is 0.
stream.avail_out is 12499.

So because avail_in is zero, that could trigger this error. However, I don't know why this would be the case. It becomes 0 after:

int inflateResult = inflate (&stream, 4);

[schlumpf]

Why is avail_in 0? It should be about half of avail_out, as given in the BsnI entry.

[stoneharry]

Why is avail_in 0? It should be about half of avail_out, as given in the BsnI entry.

It is initially this:



Then it becomes 0 after:

inflateInit (&stream);

However it is not half of avail_out in the first place.

[schlumpf]

Being half was only an estimation. Any non-zero number will do.
Given that total_in/out are not the same as avail_in/out: This really is the state before calling anything in zlib?

[stoneharry]

Being half was only an estimation. Any non-zero number will do.
Given that total_in/out are not the same as avail_in/out: This really is the state before calling anything in zlib?

Yes, it is the initial state.

Main calls extract_entry (input_file, &entry);

extract_entry calls zlib::inflate (input_data, &output_data);

zlib::inflate calls wrap_inflate (&(*output)[0], output->size(), &input[0], input.size(), &inflated)

wrap_inflate executes:

Code: [Select]

 int wrap_inflate ( unsigned char* output, int size_output
                   , const unsigned char* input, int size_input
                   , int* written_output
                   )
  {
    z_stream stream;

    stream.zalloc = NULL;
    stream.zfree = NULL;
    stream.next_in = const_cast<Bytef*> (input);
    stream.avail_in = size_input;
    stream.next_out = output;
    stream.avail_out = size_output;

Then I breakpoint and prevent further execution. That is when the screenshot shows.

After calling the next line:

int result = inflateInit (&stream);

avail_in becomes 0.

[schlumpf]

In your screenshot, zalloc and zfree are non NULL. It is technically impossible that this is the state at that line.

[stoneharry]

In your screenshot, zalloc and zfree are non NULL. It is technically impossible that this is the state at that line.

I don't know why, but that is the case:


http://i.imgur.com/VGxrtj7.jpg

edit: Pretty sure that's just showing the memory address, and it has a value of NULL still.

[schlumpf]

The addresses would be closer together. Also, it would not be logical at all, to display the address of anything: It is a void* = NULL. There is no more address than the position of the variable itself (on the stack) and the value NULL.