Skip to content
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
Closed

Modify resource of wixtoolset Setup.exe destroys executable #19

uholeschak opened this issue Jun 8, 2014 · 29 comments

Comments

@uholeschak
Copy link

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
Copy link
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
Copy link
Author

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
Copy link
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
Copy link
Author

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
Copy link
Collaborator

dblock commented Jun 9, 2014

Attachments don't work via Github.

@uholeschak
Copy link
Author

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
Copy link

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

@DSBloom
Copy link

DSBloom 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
Copy link

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
Copy link

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
Copy link
Collaborator

dblock commented Jun 13, 2017

Please contribute.

@xplicit
Copy link

xplicit commented Jun 14, 2017

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

@rkieslinger
Copy link

rkieslinger 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
Copy link
Author

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
Copy link
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 as completed Dec 6, 2017
@thoemmi thoemmi removed the bug? label Dec 6, 2017
@dblock
Copy link
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
Copy link
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".

@rkieslinger
Copy link

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

@thoemmi
Copy link
Member

thoemmi commented Dec 8, 2017

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

@rkieslinger
Copy link

Yes, for sure. Where can I upload it?

@dblock
Copy link
Collaborator

dblock commented Dec 9, 2017

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

@rkieslinger
Copy link

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

@thoemmi
Copy link
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
Copy link

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
Copy link

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
Copy link
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.

@rkieslinger
Copy link

@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
Copy link
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?

@rkieslinger
Copy link

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
Projects
None yet
Development

No branches or pull requests

8 participants