2

ビジネスの過程で 1 つ以上のヘルパー実行可能ファイルを使用するライブラリを開発しています。私の現在の実装では、ユーザーがヘルパー実行可能ファイルをシステムの既知の場所にインストールする必要があります。ライブラリが正しく機能するには、ヘルパー アプリが正しい場所にあり、正しいバージョンである必要があります。

システムが上記の方法で構成されているという要件を削除したいと思います。

ヘルパー実行可能ファイルをライブラリにバンドルして、実行時に解凍し、一時ディレクトリにインストールして、1 回の実行中に使用できるようにする方法はありますか? 実行の最後に、一時的な実行可能ファイルが削除される可能性があります。

実行可能ファイルのテキストを含む unsigned char 配列を含むファイルを自動的に生成することを検討しました。これは、ビルド プロセスの一部としてコンパイル時に行われます。実行時に、この文字列はファイルに書き込まれ、実行可能ファイルが作成されます。

実行可能ファイルをディスク (おそらくある種の RAM ディスク) に書き込まずに、そのようなタスクを実行することは可能でしょうか? 特定のウイルス スキャナやその他のセキュリティ ソフトウェアが、このような操作に反対していることを想像できました。他に心配すべきことはありますか？

このライブラリは、Windows と Linux でクロス プラットフォームで使用できるように C/C++ で開発されています。

4

7 に答える 7

6

「賢い人は問題を解決します。賢い人はそれを避けます。」- アルバート・アインシュタイン

この引用の精神から、この実行可能ファイルをエンド アプリケーションと一緒にバンドルすることをお勧めします。

ちょうど私の2セント。

于 2009-06-25T19:16:04.327 に答える
2

You can use xxd to convert a binary file to a C header file. 

$ echo -en "\001\002\005" > x.binary

$ xxd -i x.binary 
unsigned char x_binary[] = {
  0x01, 0x02, 0x05
};
unsigned int x_binary_len = 3;

xxd is pretty standard on *nix systems, and it's available on Windows with Cygwin or MinGW, or Vim includes it in the standard installer as well. This is an extremely cross-platform way to include binary data into compiled code.

Another approach is to use objcopy to append data on to the end of an executable -- IIRC you can obtain objcopy and use it for PEs on Windows.

One approach I like a little better than that is to just append raw data straight onto the end of your executable file. In the executable, you seek to the end of the file, and read in a number, indicating the size of the attached binary data. Then you seek backwards that many bytes, and fread that data and copy it out to the filesystem, where you could treat it as an executable file. This is incidentally the way that many, if not all, self-extracting executables are created.

If you append the binary data, it works with both Windows PE files and *nix ELF files -- neither of them read past the "limit" of the executable.

Of course, if you need to append multiple files, you can either append a tar/zip file to your exe, or you'll need a slightly more advance data structure to read what's been appended.

You'll also probably want to UPX your executables before you append them.

You might also be interested in the LZO library, which is reportedly one of the fastest-decompressing compression libraries. They have a MiniLZO library that you can use for a very lightweight decompressor. However, the LZO libraries are GPL licensed, so that might mean you can't include it in your source code unless your code is GPLed as well. On the other hand, there are commercial licenses available.

于 2009-09-18T17:18:59.287 に答える
1

unsigned char *配列を使用する場合とは少し異なるアプローチは、実行可能バイナリ全体をdllのリソースとして配置することです。実行時に、バイナリデータをローカルの一時ファイルとして保存してアプリを実行できます。ただし、メモリ内で実行可能ファイルを実行する方法があるかどうかはわかりません。

于 2009-06-25T16:08:14.240 に答える
1

Qt には、これを達成するための優れた方法があります: QResource

「Qt リソース システムは、バイナリ ファイルをアプリケーションの実行可能ファイルに格納するための、プラットフォームに依存しないメカニズムです。」

現在 Qt を使用しているかどうかはわかりませんが、「Windows と Linux でクロス プラットフォームで使用するための C++」と述べているため、使用していない場合でも、開始を検討する必要があるかもしれません。

于 2009-09-18T17:24:10.190 に答える
1

ライブラリが適切に機能するには、ヘルパー アプリが正しい場所にある必要があります。

Windows では、それは Program Files ディレクトリですか、それとも System32 ディレクトリですか?

これは問題になる可能性があります。アプリケーションがインストールされるとき、特に企業環境では、通常、管理者権限のコンテキストで行われます。UAC が有効 (デフォルト) の Vista 以降では、これは特定のディレクトリに書き込むために必要です。そして、ほとんどの Unix フレーバーには、誰もが覚えている限り、そのような賢明な制限がありました。

そのため、ホスト アプリケーションがライブラリを呼び出すときにそれを実行しようとすると、ファイルをインストールするのに十分な権限を持つコンテキストにない可能性があるため、ライブラリはホスト アプリケーションに制約を課します。

(ホスト アプリケーションがプロセスを管理レベルに昇格させる機能を持っていない場合、除外されるもう 1 つのことは、レジストリの変更、またはさまざまな Unice での構成ファイルの更新です。)

そうは言っても、ヘルパーを一時ディレクトリに解凍することを検討していると言うので、これはすべて意味がないかもしれません。

于 2009-06-25T19:42:53.617 に答える
0

さて、私の最初の考えは、このヘルパー実行可能ファイルは、ライブラリのコード自体では実行できなかったことを、おそらく必要に応じてセカンダリスレッドを使用して何をするのかということです。これは考慮すべきことかもしれません。

しかし、実際の質問については...「ライブラリ」が実際にdll（またはexe）としてバンドルされている場合、少なくともWindowsはライブラリ内にファイルを埋め込むための比較的簡単なサポートを提供します。

バージョン情報やアイコンなどを実行可能ファイルに埋め込むことができるリソースメカニズムでは、任意のデータチャンクを許可することもできます。使用している開発環境がわからないため、正確な方法はわかりません。ただし、大まかに言えば、「FILE」タイプなどの適切なタイプのカスタムリソースを作成し、埋め込みたいexeにポイントする必要があります。

次に、それを抽出したいときは、次のように記述します。

HRSRC hResource = FindResource(NULL, MAKEINTRESOURCE(IDR_MY_EMBEDDED_FILE), "FILE");
HGLOBAL hResourceData = LoadResource(NULL, hResource);
LPVOID pData = LockResource(hResourceData);
HANDLE hFile = CreateFile("DestinationPath\\Helper.exe", GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
DWORD dwBytesWritten = 0;
WriteFile(hFile, pData, SizeofResource(NULL, hResource), &dwBytesWritten, NULL);
CloseHandle(hFile);

（もちろん、希望するパス、ファイル名、および適切なエラーチェックを入力します）

その後、ヘルパーexeは通常のexeファイルとして存在するため、通常どおりに実行できます。

使用後にファイルを削除するにはCreateFile、特にのフラグを調べる必要がありますFILE_FLAG_DELETE_ON_CLOSE。また、新しいファイル名に渡されたNULLとフラグをMoveFileEx組み合わせる場合の使用を検討することもできます。MOVEFILE_DELAY_UNTIL_REBOOTそしてもちろん、実行可能ファイルがいつ終了したかがわかれば、自分のコードでいつでも削除できます。

Linuxの実行可能ファイルについては十分に知らないので、同様の機能が利用できるかどうかはわかりません。

Linuxが便利なメカニズムを提供していない場合、および/またはこのアイデアがWindowsのニーズに合わない場合は、ヘルパーexeのコンテンツからunsigned char配列を生成するというアイデアが、次善の埋め込み方法になると思います。ライブラリ内のexe。

于 2009-06-25T23:30:18.870 に答える
0

Windows には、実行可能ファイルをディスクに書き込まずにメモリ内から実行する方法があります。問題は、最新のセキュリティ システム (DEP) が原因で、これがおそらくすべてのシステムで機能するとは限らず、ほとんどすべてのマルウェア対策スキャナーがそれを検出してユーザーに警告することです。

私のアドバイスは、実行可能ファイルをディストリビューションに単純にパッケージ化することです。これは、これを実現するための最も信頼できる方法です。

于 2009-06-25T19:29:33.160 に答える