How can I reverse-engineer an installer that was written with ghost-installer?

Question

I have an installer for which I don't have any source code. I need to either "wrap" this installer or edit it to add a few more files. What's the best way to do this? As the title mentions, the installer was written w/ ghost installer.

Answer 1

Since it's not an MSI, you can't use Orca to edit the installer itself. And I have written custom install actions before as well for my MSI installers.

Since you don't have much control (if any) over your Ghost Installer, I would perhaps write a custom executable to supplement the installer, that can either run before or after the installer. This will create a few extra files to distribute to your customers, but you can distribute the entirety as a zip archive.

First of all, if you want to create an unmanaged bootstrapper the same way Visual Studio does to ensure prerequisites are installed, you can do it through MSBuild with a script like the following:

<Project ToolsVersion="3.5" DefaultTargets="BuildBootstrapper" xmlns="http://schemas.microsoft.com/developer/msbuild/2003"&gt;

  <ItemGroup>
    <BootstrapperFile Include="Microsoft.Net.Framework.2.0">
      <ProductName>Microsoft .NET Framework 2.0</ProductName>
    </BootstrapperFile>
  </ItemGroup>

  <Target Name="BuildBootstrapper">
    <GenerateBootstrapper
      ApplicationFile="CustomInstallerExecutable.exe"
      ApplicationName="Pretty Title of Application Goes Here"
      BootstrapperItems="@(BootstrapperFile)"
      ComponentsLocation="Relative" />
  </Target>

</Project>

This will produce a "setup.exe," which is the de facto file name for any bootstrapper of an installer. In fact, if you wanted to ensure the user didn't accidentally skip the bootstrapper and go straight to the installer, you could hide the Ghost Installer in a "bin" folder or something away from the root of the zip archive. That way, their only intuitive option is the "setup.exe." Include a "README.txt" as well if you need to be extremely clear for the customer's sake.

What this bootstrapper also does is make sure the client has the .NET 2.0 Framework as a prerequisite so that your "CustomInstallerExecutable.exe" can be written in .NET and not in an unmanaged language. In fact, this MSBuild script will plop down the .NET 2.0 Framework installer right beside your newly create bootstrapper (because of the "Relative" value of the "ComponentsLocation" attribute). There are other attribute values you can use that will facilitate the user getting the .NET Framework over the Web instead, if you are concerned about bloating the original download size of your Ghost Installer download to your customers.

Now your "CustomInstallerExecutable.exe" (written in beautiful, managed C#) can drop the extra files down on the machine before (or after) running the Ghost Installer. I have previously written some code to run an MSI from a .NET executable:

string msiString = "blahBlah.msi";

// Kick off Update installer
ProcessStartInfo startInfo = new ProcessStartInfo(
    "cmd.exe",
    "/c start /wait msiexec.exe /i " + msiString);
startInfo.WorkingDirectory = "bin";
startInfo.WindowStyle = ProcessWindowStyle.Hidden;

Process process = new Process
{
    StartInfo = startInfo,
    EnableRaisingEvents = true
};
process.Exited += new EventHandler(process_Exited);

process.Start();

I think you could do something very similar to call your Ghost Installer instead of an MSI. If you are running this .NET executable before the Ghost Installer, you can just invoke the Ghost Installer process and then exit your "CustomInstallerExecutable.exe" process and not wait for the process.Exited event to fire. This event waiting would be more for running "after install" logic.

Good luck and hope this is helpful.