如何对使用 Ghost-installer 编写的安装程序进行逆向工程?
我有一个安装程序,但没有任何源代码。 我需要“包装”此安装程序或编辑它以添加更多文件。 最好的方法是什么? 正如标题所提到的,安装程序是用 Ghost 安装程序编写的。
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.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
由于它不是 MSI,因此您不能使用 Orca 来编辑安装程序本身。 我之前写过自定义安装操作非常适合我的 MSI 安装程序。
由于您对 Ghost 安装程序没有太多控制权(如果有),我可能会编写一个自定义可执行文件来补充安装程序,它可以在安装程序之前或之后运行。 这将创建一些额外的文件来分发给您的客户,但您可以将整个文件作为 zip 存档分发。
首先,如果您想以与 Visual Studio 相同的方式创建非托管引导程序以确保安装先决条件,您可以通过 MSBuild 使用如下脚本来完成此操作:
这将生成一个“setup.exe”,它是安装程序的任何引导程序的事实上的文件名。 事实上,如果您想确保用户不会意外地跳过引导程序并直接进入安装程序,您可以将 Ghost 安装程序隐藏在“bin”文件夹或远离 zip 存档根目录的文件夹中。 这样,他们唯一直观的选项就是“setup.exe”。 如果您需要为客户提供非常清晰的信息,请包含“README.txt”。
此引导程序还确保客户端具有 .NET 2.0 Framework 作为先决条件,以便您的“CustomInstallerExecutable.exe”可以用 .NET 而不是非托管语言编写。 事实上,这个 MSBuild 脚本将在您新创建的引导程序旁边放下 .NET 2.0 Framework 安装程序(因为“ComponentsLocation”属性的“相对”值)。 如果您担心客户的 Ghost 安装程序下载的原始下载大小会膨胀,您可以使用其他属性值来帮助用户通过 Web 获取 .NET Framework。
现在,您的“CustomInstallerExecutable.exe”(用漂亮的托管 C# 编写)可以在运行 Ghost 安装程序之前(或之后)将额外的文件放到计算机上。 我之前编写过一些代码来从 .NET 可执行文件运行 MSI:
我认为您可以执行一些非常类似的操作来调用 Ghost 安装程序而不是 MSI。 如果您在 Ghost 安装程序之前运行此 .NET 可执行文件,则只需调用 Ghost 安装程序进程,然后退出“CustomInstallerExecutable.exe”进程,而不必等待 process.Exited 事件触发。 此事件等待将更多地用于运行“安装后”逻辑。
祝你好运,希望这有帮助。
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:
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:
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.