Modify resource of wixtoolset Setup.exe destroys executable

[uholeschak]

Hello,
I tried to modify the version resource of a Setup.exe created by the wixtoolset burn engine. (http://wixtoolset.org/). This execuable has a cab file included.
After the resource modification operation the Setup.exe is very much smaller than the original one and it's impossible to execute it. Additionally the included cab file is destroyed.
Is RescoureLib only working with DLL files?
Ulrich

[dblock]

It should be able to work with other types as well, it would be good if you posted a minimum amount of code to reproduce the problem here or elsewhere.

[uholeschak]

I have now seen, that the attached CAB file at the end of the executable is the problem.
If if split up the file first, modify the resources and attach the CAB again it's working.
Resource Tuner Console has no problem with this condition, but it can't use if for several reasons.
Is it possible to fix this internally?

[dblock]

Probably. It would be helpful if you wrote a unit test within this library that reproduce the problem, to begin with - make a very small executable that exhibits this issue.

It's likely the CAB is appended without any record within the executable, however, so it may need some work.

[uholeschak]

Hello,
in the meantime I have seen, that removing the CAB file only works, if
the resource is not changing in size during modification.
I have attached my Setup.exe sample (It's not a complete installation,
only the bootstrapper part).
You could simply modify it's version resource and the setup will not
start any more (and the file size shrinks).
You will also notice that extracting the appended CAB file will fail
after the modification (e.g. test with 7zip).

Thanks,
Ulrich

Am 09.06.2014 11:53, schrieb Daniel Doubrovkine (dB.) @dblockdotorg:

Probably. It would be helpful if you wrote a unit test within this
library that reproduce the problem, to begin with - make a very small
executable that exhibits this issue.

It's likely the CAB is appended without any record within the
executable, however, so it may need some work.

—
Reply to this email directly or view it on GitHub
#19 (comment).

[dblock]

Attachments don't work via Github.

[uholeschak]

Hello,
you could download the file from:
http://www.holeschak.de/External/Setup.exe

Am 09.06.2014 12:27, schrieb Daniel Doubrovkine (dB.) @dblockdotorg:

Attachments don't work via Github.

—
Reply to this email directly or view it on GitHub
#19 (comment).

[DSBloom]

I am having this same exact issue using this library on an .exe that I created with the 7-zip 7zsd.sfx module.

The file size goes from 900kb to 111kb and the .exe is corrupt and will not run.

Here is my code:
string filename = exePath;

        VersionResource versionResource = new VersionResource();
        versionResource.LoadFrom(filename);
        versionResource.FileVersion = "1.2.3.4";
        StringFileInfo stringFileInfo = (StringFileInfo)versionResource["StringFileInfo"];

        stringFileInfo["LegalCopyright"] ="(C) " + DateTime.Now.Year;
        stringFileInfo["CompanyName"] = "MyComp\0";
        stringFileInfo["FileVersion"] = currentPackage.PackageVersion;
        stringFileInfo["OriginalFilename"] = "";
        stringFileInfo["ProductName"] = currentPackage.AppName;
        stringFileInfo["ProductVersion"] = currentPackage.AppVersion;
        stringFileInfo["FileDescription"] = "7z Setup SFX - Created with MyApp";

        versionResource.SaveTo(filename);

[DSBloom]

I solved the issue for myself by changing the resources on 7zsd.sfx BEFORE combining it with my archive, not on the resulting .exe file.

I don't think this is a bug in this library. I used the tool by Denis Zabavchik on CodeProject (http://www.codeproject.com/Articles/13355/Modification-of-Version-Information-Resources-in-C) and got the same result.

[Fergusson]

As described by nadcracker the same process applies for Wix executables.
If you need to modify an Wix generated setup.exe you must first seperate the exe and data apart, modify the exe and reassemble them. There are tools for this in the Wix Toolset. Search for "signing a Wix executable" which describes the process. Instead of signing ( which adds data to the executabe) you just modify the resources.
Nothing to be done on the Library side. I thi9nk this can be closed.

[xplicit]

Is there a chance this issue will be fixed? Currently there is no way to change resources (for example icon) on resulting self-extracting archive with this library. ResourceHacker does it with no problems.

[dblock]

Please contribute.

[xplicit]

I can contribute with testing the fix if it be done.

[rkieslinger]

@Fergusson Can you please describe your solution a little bit further? My bootstrapper is about 800 MB. If I extract the engine of my bundle by using Insignia, I get a 70 MB file. When I modify the version resource of the extracted engine, my file still shrinks to about 800 Kb.

[uholeschak]

Basically it's possible but it's a lot of work.
Check the wix tools source how to extract and insert the additional data.

[thoemmi]

As @Fergusson wrote above it's not an issue of ResourceLib.

If some can provide a repro, we might re-open this issue.

[dblock]

I do think it's a bug, not that I know how to fix it, in theory resourcelib should never "destroy" anything, no?

[thoemmi]

@dblock it might be a bug of resourcelib, but @nadcraker mentioned the same issue occurs even when using another library. A repro is required to investigate the origin of the "destruction".

[rkieslinger]

Resource Hacker is able to do it on my wix bundle.

[thoemmi]

@rolix7 can you provide us with a small (i.e. ≪ 800 MB) binary for reproduction?

[rkieslinger]

Yes, for sure. Where can I upload it?

[dblock]

Please make a pull request with ideally a failing test, or just the binary in your fork.

[rkieslinger]

I'm pretty new to github, so I hope I did nothing wrong.

[thoemmi]

Thanks @rolix7 , I could reproduce your issue with your pull request. However, it looks to me as its not resourcelib's fault. Before and after patching I was able to tread the resources with Resource Hacker, and everything looks ok. Maybe WiX creates non-standard PE files, which get corrupt when using Windows' API to modify resources.

Nevertheless I'll continue to look for the origin of the issue.

[Vasilich]

the threadstarter haven't said that he has problems with resources - i assume there are some PE sections that get lost after saving resource and reassembling PE Header.

[rkieslinger]

Here's the source code of WiX which is responsible for writing/reading the PE Header. Perhaps it's useful for some of you experts.

[thoemmi]

@rolix7 Thanks for the pointer to WiX's source code.
I further investigated the issue using dumpbin and reading the PE format specification.

TL;DR: to me it looks like WiX is doing it wrong

According to the output of dumpbin there are 7 sections in the executable @rolix7 provided:

#	Name	Range
1	.text	0x00000400 to 0x00049FFF
2	.rdata	0x0004A000 to 0x00068DFF
3	.data	0x00068E00 to 0x000697FF
4	.wixburn	0x00069800 to 0x000699FF
5	.tls	0x00069A00 to 0x00069BFF
6	.rsrc	0x00069C00 to 0x0006D7FF
7	.reloc	0x0006D800 to 0x000715FF

In a hex viewer you can see that after the last section, the file continues for another 104205 bytes, starting with 0x4D 0x53 0x43 0x46 (MSCF, the magic number starting a cab file).

I patched the StringFileInfo resource using resourcelib, which changed the content of the .rsrc section only. Afterwards the file ended at 0x000715FF, i.e. the following 104205 bytes were missing.

By the way, the .wixburn section contains following bytes:

RAW DATA #4
  0046C000: 00 43 F1 00 02 00 00 00 04 12 28 81 2C 64 40 48  .C±.......(.,d@H
  0046C010: B2 B1 34 64 EC 08 65 64 00 16 07 00 00 00 00 00  ▓▒4d∞.ed........
  0046C020: 00 00 00 00 00 00 00 00 01 00 00 00 02 00 00 00  ................
  0046C030: 92 8E 01 00 7B 08 00 00                          ....{...

which means

Field	Bytes	Value
magic number	0-3	0x00f14300
Version	4-7	0x00000002
Bundled GUID	8-23	{81281204-642c-4840-b2b1-3464ec086564}
Engine (stub) size	24-27	0x00071600
Original checksum	28-31	0x00000000
Original signature offset	32-35	0x00000000
Original signature size	36-39	0x00000000
Container Type (1 = CAB)	40-43	1
Container Count	44-47	2
Byte count of manifest + UX container	48-51	102,034
Byte count of attached container	52-55	2,171

Intermediate result

• the .wixburn section points to 104,205 bytes (102,034 + 2,171), starting at 0x00071600.
• the last PE section ends at 0x000715ff.
• after using the official Win32 API to edit resources, the file ends at 0x000715ff, and the following 104,205 byte are gone.

So after editing the resources, the exact payload WiX is referring to is eliminated.

Therefore my conclusion is that WiX

• adds a (small) section .wixburn pointing beyond the last section, and
• appends the payload (read: the cabinet file) at that location-

As far as I understand the specification, this procedure is not compliant with the PE format. That might be the reason why EndUpdateResource cuts the file after the last section when writing the changed resources.

Feel free to report this to the WiX team. Maybe I'm wrong. Anyway, I have also posted my analysis on my blog.

[rkieslinger]

@thoemmi Thanks for your great research! It really seems like it's a problem of WiX rather than resourcelib.

Nevertheless it would be interesting, how ResourceHacker is doing that job correctly.

[thoemmi]

I can only guess that Resource Hacker doesn't use the Win32 API for handling resources but manipulates the binary directly.

Can your PR #60 be closed?

[rkieslinger]

Yes, should I do it? As I said, i'm pretty new to github and I don't know the conventions yet.