New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Modify resource of wixtoolset Setup.exe destroys executable #19

Closed
uholeschak opened this Issue Jun 8, 2014 · 29 comments

Comments

Projects
None yet
8 participants
@uholeschak

uholeschak commented Jun 8, 2014

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

This comment has been minimized.

Show comment
Hide comment
@dblock

dblock Jun 8, 2014

Collaborator

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.

Collaborator

dblock commented Jun 8, 2014

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.

@dblock dblock added the bug? label Jun 8, 2014

@uholeschak

This comment has been minimized.

Show comment
Hide comment
@uholeschak

uholeschak Jun 9, 2014

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?

uholeschak commented Jun 9, 2014

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

This comment has been minimized.

Show comment
Hide comment
@dblock

dblock Jun 9, 2014

Collaborator

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.

Collaborator

dblock commented Jun 9, 2014

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

This comment has been minimized.

Show comment
Hide comment
@uholeschak

uholeschak Jun 9, 2014

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).

uholeschak commented Jun 9, 2014

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

This comment has been minimized.

Show comment
Hide comment
@dblock

dblock Jun 9, 2014

Collaborator

Attachments don't work via Github.

Collaborator

dblock commented Jun 9, 2014

Attachments don't work via Github.

@uholeschak

This comment has been minimized.

Show comment
Hide comment
@uholeschak

uholeschak Jun 9, 2014

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).

uholeschak commented Jun 9, 2014

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).

@nadcraker

This comment has been minimized.

Show comment
Hide comment
@nadcraker

nadcraker Aug 5, 2015

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);

nadcraker commented Aug 5, 2015

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);
@nadcraker

This comment has been minimized.

Show comment
Hide comment
@nadcraker

nadcraker Aug 5, 2015

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.

nadcraker commented Aug 5, 2015

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

This comment has been minimized.

Show comment
Hide comment
@Fergusson

Fergusson May 2, 2017

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.

Fergusson commented May 2, 2017

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

This comment has been minimized.

Show comment
Hide comment
@xplicit

xplicit Jun 13, 2017

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.

xplicit commented Jun 13, 2017

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

This comment has been minimized.

Show comment
Hide comment
@dblock

dblock Jun 13, 2017

Collaborator

Please contribute.

Collaborator

dblock commented Jun 13, 2017

Please contribute.

@xplicit

This comment has been minimized.

Show comment
Hide comment
@xplicit

xplicit Jun 14, 2017

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

xplicit commented Jun 14, 2017

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

@rolix7

This comment has been minimized.

Show comment
Hide comment
@rolix7

rolix7 Dec 6, 2017

@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.

rolix7 commented Dec 6, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@uholeschak

uholeschak Dec 6, 2017

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

uholeschak commented Dec 6, 2017

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

This comment has been minimized.

Show comment
Hide comment
@thoemmi

thoemmi Dec 6, 2017

Member

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

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

Member

thoemmi commented Dec 6, 2017

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

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

@thoemmi thoemmi closed this Dec 6, 2017

@thoemmi thoemmi removed the bug? label Dec 6, 2017

@dblock

This comment has been minimized.

Show comment
Hide comment
@dblock

dblock Dec 7, 2017

Collaborator

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

Collaborator

dblock commented Dec 7, 2017

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

@thoemmi

This comment has been minimized.

Show comment
Hide comment
@thoemmi

thoemmi Dec 7, 2017

Member

@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".

Member

thoemmi commented Dec 7, 2017

@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".

@rolix7

This comment has been minimized.

Show comment
Hide comment
@rolix7

rolix7 Dec 7, 2017

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

rolix7 commented Dec 7, 2017

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

@thoemmi

This comment has been minimized.

Show comment
Hide comment
@thoemmi

thoemmi Dec 8, 2017

Member

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

Member

thoemmi commented Dec 8, 2017

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

@rolix7

This comment has been minimized.

Show comment
Hide comment
@rolix7

rolix7 Dec 9, 2017

Yes, for sure. Where can I upload it?

rolix7 commented Dec 9, 2017

Yes, for sure. Where can I upload it?

@dblock

This comment has been minimized.

Show comment
Hide comment
@dblock

dblock Dec 9, 2017

Collaborator

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

Collaborator

dblock commented Dec 9, 2017

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

@rolix7

This comment has been minimized.

Show comment
Hide comment
@rolix7

rolix7 Dec 10, 2017

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

rolix7 commented Dec 10, 2017

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

@thoemmi

This comment has been minimized.

Show comment
Hide comment
@thoemmi

thoemmi Dec 10, 2017

Member

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.

Member

thoemmi commented Dec 10, 2017

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

This comment has been minimized.

Show comment
Hide comment
@Vasilich

Vasilich Dec 11, 2017

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.

Vasilich commented Dec 11, 2017

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.

@rolix7

This comment has been minimized.

Show comment
Hide comment
@rolix7

rolix7 Dec 11, 2017

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.

rolix7 commented Dec 11, 2017

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

This comment has been minimized.

Show comment
Hide comment
@thoemmi

thoemmi Dec 11, 2017

Member

@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.

Member

thoemmi commented Dec 11, 2017

@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.

@rolix7

This comment has been minimized.

Show comment
Hide comment
@rolix7

rolix7 Dec 13, 2017

@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.

rolix7 commented Dec 13, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@thoemmi

thoemmi Dec 14, 2017

Member

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?

Member

thoemmi commented Dec 14, 2017

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?

@rolix7

This comment has been minimized.

Show comment
Hide comment
@rolix7

rolix7 Dec 14, 2017

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

rolix7 commented Dec 14, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment