ダイナミックリンクライブラリ
ダイナミックリンクライブラリ
ファイル名拡張子
.dll
インターネットメディアの種類
application/vnd.microsoft.portable-executable
統一型識別子（UTI）com.microsoft.windows-dynamic-link-library
魔法の数字4D 5A（ASCIIMZ形式）
開発者マイクロソフト
コンテナ用共有ライブラリ

ダイナミックリンクライブラリ（DLL）は、Microsoft WindowsまたはOS/2オペレーティングシステムの共有ライブラリです。DLLには、実行可能コード（関数）、データ、およびリソースを含めることができます。

DLLファイルには、必須ではないにもかかわらず、ファイル拡張子.dllが付いていることがよくあります。拡張子は、ファイルの内容を説明するために使用されることがあります。例えば、.dllはActiveXコントロールやレガシー（16ビット）デバイスドライバ.ocxでよく使用される拡張子です。 .drv

リソースのみを含むDLLは、リソースDLLと呼ばれることがあります。例としては、共通拡張子のアイコン.iclライブラリや、共通拡張子とフォントライブラリが挙げられます。[ 1 ].fon.fot

DLLのファイル形式は、実行ファイル（EXE ）と同じです。DLLファイルとEXEファイルの主な違いは、オペレーティングシステムが実行を開始するためにエントリポイントを必要とするため、DLLは直接実行できないことです。Windowsは、DLLによって公開された関数を実行するためのユーティリティプログラム（RUNDLL.EXE/ RUNDLL32.EXE）を提供しています。これらは同じ形式であるため、EXEをDLLとして使用できます。コードは、DLLを読み込むのと同じメカニズムでEXEを読み込むことができます。

背景

Microsoft Windowsの初期バージョンでは、プログラムは単一のアドレス空間で同時に実行されていました。各プログラムは、CPUを他のプログラムに譲ることで連携動作し、グラフィカルユーザーインターフェース（GUI）がマルチタスク処理と最大限の応答性を実現できるように設計されていました。オペレーティングシステムレベルの操作はすべて、基盤となるオペレーティングシステムであるMS-DOSによって提供されていました。高レベルサービスはすべて、Windowsライブラリ（ダイナミックリンクライブラリ）によって提供されていました。描画APIであるグラフィックスデバイスインターフェースGDI.EXE（GDI）は、ユーザーインターフェースであるDLLに実装されていましたUSER.EXE。DOS上に追加されたこれらのレイヤーは、実行中のすべてのWindowsプログラム間で共有する必要がありました。これは、1メガバイト未満のRAMを搭載したマシンでWindowsを動作させるだけでなく、プログラム同士が連携できるようにするためでもありました。GDIのコードは、描画コマンドを特定のデバイス上の操作に変換する必要がありました。ディスプレイ上では、フレームバッファ内のピクセルを操作する必要がありました。プリンタに描画する場合は、API呼び出しをプリンタへの要求に変換する必要がありました。限られたデバイスセット（カラーグラフィックアダプタディスプレイ、HP LaserJetプリンタコマンド言語など）に対してハードコードされたサポートを提供することも可能でしたが、Microsoftは別のアプローチを選択しました。GDIは、「デバイスドライバ」と呼ばれる異なるコードを読み込むことで、異なる出力デバイスに対応します。

GDIが異なるデバイスドライバをロードすることを可能にしたのと同じアーキテクチャ概念により、Windowsシェルは異なるWindowsプログラムをロードし、これらのプログラムが共有USERライブラリとGDIライブラリからAPI呼び出しを呼び出すこともできるようになりました。この概念が「ダイナミックリンク」です。

従来の非共有静的ライブラリでは、実行ファイルが「リンク」段階でビルドされる際に、呼び出し元プログラムにコードセクションが単純に追加されます。2つのプログラムが同じルーチンを呼び出す場合、そのルーチンは両方のプログラムのリンク段階でインクルードされます。動的リンクでは、共有コードは単一の別ファイルに配置されます。このファイルを呼び出すプログラムは実行時にファイルに接続され、オペレーティングシステム（またはWindowsの初期バージョンの場合はOS拡張）がバインディングを実行します。

Windowsの初期バージョン（1.0から3.11）では、DLLがGUI全体の基盤でした。そのため、ディスプレイドライバは、統一されたデバイスドライバインターフェース（DDI）を介して同じ描画APIのカスタム実装を提供する、拡張子.DRVのDLLに過ぎませんでした。一方、描画API（GDI）とGUI API（USER）は、拡張子.EXEのシステムDLLであるGDIとUSERからエクスポートされた関数呼び出しに過ぎませんでした。

動的に読み込まれるライブラリのコレクションからオペレーティングシステムを構築するというこの概念は、2015年現在も続くWindowsの中核概念です。DLLは、モジュール性といった共有ライブラリの標準的な利点を提供します。モジュール性により、複数のアプリケーションで共有される単一の自己完結型DLL内のコードとデータに変更を加えることができ、アプリケーション自体に変更を加える必要はありません。

モジュール化のもう一つの利点は、プラグイン用の汎用インターフェースを使用できることです。単一のインターフェースを開発することで、既存のアプリケーション自体に変更を加えることなく、新旧のモジュールをランタイム時にシームレスに統合できます。この動的な拡張性の概念は、 ActiveXの基盤となるコンポーネントオブジェクトモデルによって極限まで追求されています。

Windows 1.x、2.x、3.x では、すべての Windows アプリケーションが同じアドレス空間とメモリを共有していました。DLL はこのアドレス空間に一度だけロードされ、それ以降はライブラリを使用するすべてのプログラムがそれにアクセスすることになります。ライブラリのデータはすべてのプログラム間で共有されていました。これは、間接的なプロセス間通信として使用することも、さまざまなプログラムを誤って破壊することもできました。Windows 95で32 ビットライブラリが導入されたことで、すべてのプロセスが独自のアドレス空間で実行されるようになりました。DLL コードは共有できますが、共有データがライブラリによって明示的に要求されている場合を除き、データは非公開です。とはいえ、Windows 95、Windows 98、Windows Meの大部分は16 ビット ライブラリから構築されており、起動時にPentium Proマイクロプロセッサのパフォーマンスが制限され、最終的に DOS ベースの Windows バージョンの安定性とスケーラビリティが制限されていました。

制限事項

DLL テクノロジは Windows アーキテクチャの中核ですが、欠点もあります。

DLL地獄

DLL地獄とは、間違ったバージョンのDLLが使用された場合にアプリケーションが不正な動作をすることを指します。[ 2 ]緩和戦略には次のようなものがあります。

共有メモリ空間

DLL の実行可能コードは、呼び出しプロセスのメモリ空間で同じアクセス権限で実行されるため、使用時のオーバーヘッドはほとんどありませんが、DLL に何らかのバグがある場合、呼び出しプログラムは保護されません。

特徴

アップグレード性

DLLテクノロジーにより、DLLを利用するコンポーネントを再コンパイルまたは再リンクすることなく、アプリケーションを変更できます。DLLを置き換えて、次回アプリケーションを実行する際に新しいバージョンのDLLを使用するようにすることができます。正しく動作させるには、DLLの変更は下位互換性を維持する必要があります。

オペレーティングシステムもDLLを介してアプリケーションに公開されているため、アップグレードが可能です。システムDLLを置き換えることで、次回アプリケーションを実行する際に新しいシステムDLLが使用されるようになります。

メモリ管理

Windows APIでは、DLL ファイルはセクションに編成されています。各セクションには、書き込み可能か読み取り専用か、実行可能か（コードの場合）実行不可か（データの場合）など、独自の属性セットがあります。

DLL 内のコードは通常、その DLL を使用するすべてのプロセス間で共有されます。つまり、DLL は物理メモリ内の単一の場所を占有し、ページ ファイル内のスペースは占有しません。Windows は DLL に位置独立コードを使用しません。代わりに、コードはロード時に再配置され、すべてのエントリ ポイントのアドレスが、DLL をロードする最初のプロセスのメモリ空間内の空き位置に固定されます。実行中のすべてのプロセスが単一の共通アドレス空間を占有していた以前のバージョンの Windows では、DLL のコードのコピーが 1 つあればすべてのプロセスで常に十分でした。しかし、プログラムごとに個別のアドレス空間を使用する新しいバージョンの Windows では、各プログラムが DLL のコードを格納するために同じ仮想アドレスを空けている場合にのみ、複数のプログラムで同じ DLL の再配置コピーを使用できます。一部のプログラム (または既にロードされている DLL の組み合わせ) でこれらのアドレスが空いていない場合、異なる再配置エントリ ポイントのセットを使用して、DLL のコードの追加の物理コピーを作成する必要があります。コード セクションによって占有されている物理メモリを再利用する場合、その内容は破棄され、後で必要に応じて DLL ファイルから直接再ロードされます。

コードセクションとは対照的に、DLL のデータセクションは通常プライベートです。つまり、DLL を使用する各プロセスは、DLL のすべてのデータの独自のコピーを保持します。オプションでデータセクションを共有にすることができ、この共有メモリ領域を介してプロセス間通信が可能になります。ただし、共有 DLL メモリの使用にはユーザー制限が適用されないため、セキュリティホールが発生します。つまり、1 つのプロセスが共有データを破損すると、他のすべての共有プロセスが望ましくない動作をする可能性があります。たとえば、ゲストアカウントで実行されているプロセスは、このようにして特権アカウントで実行されている別のプロセスを破損する可能性があります。これは、DLL で共有セクションの使用を避ける重要な理由です。

DLLが特定の実行可能パッカー（例：UPX）によって圧縮されている場合、そのすべてのコードセクションは読み取りおよび書き込みとしてマークされ、共有されません。読み取りおよび書き込みコードセクションは、プライベートデータセクションと同様に、各プロセスにプライベートです。したがって、共有データセクションを持つDLLは、複数のプログラムで同時に使用される予定の場合は圧縮しないでください。各プログラムインスタンスがDLLのコピーを個別に保持する必要があり、メモリ消費量が増加するためです。

ライブラリをインポートする

静的ライブラリと同様に、DLLのインポートライブラリもファイル拡張子で識別されます.lib。例えば、Windowsの基本機能（ファイル作成やメモリ管理など）の主要な動的ライブラリであるkernel32.dllはkernel32.lib、 を介してリンクされています。インポートライブラリと通常の静的ライブラリを区別する一般的な方法はサイズです。インポートライブラリは、リンク時に処理される実際のDLLを参照するシンボルのみを含むため、サイズがはるかに小さくなります。ただし、どちらもUnix ar形式のファイルです。

動的ライブラリへのリンクは、通常、ビルド時または実行ファイル作成時のリンク時にインポートライブラリへのリンクによって処理されます。作成された実行ファイルには、すべてのDLL関数呼び出しを参照するためのインポートアドレステーブル（IAT）が含まれます（参照されるDLL関数ごとに、IATに独自のエントリが含まれます）。実行時には、IATには、別途ロードされたDLL内の関数を直接指す適切なアドレスが設定されます。[ 3 ]

.dll.aCygwin/MSYSおよびMinGWでは、インポートライブラリには慣例的にWindows DLLのサフィックスとUnixのarサフィックスを組み合わせたサフィックスが付けられます。ファイル形式は似ていますが、インポートを示すシンボルが異なります（_head_foo_dllと__IMPORT_DESCRIPTOR_foo）。[ 4 ] GNU Binutilsツールチェーンはインポートライブラリを生成してリンクすることができますが、DLLに直接リンクする方が高速です。[ 5 ] MinGWの実験的なツールgenlibを使用すると、MSVCスタイルのシンボルを持つインポートライブラリを生成できます。

シンボルの解決とバインディング

DLL によってエクスポートされる各関数は、数値序数とオプションで名前によって識別されます。同様に、DLL から関数をインポートする場合も、序数または名前のいずれかで行うことができます。序数は、DLL エクスポートアドレステーブルにおける関数のアドレスポインタの位置を表します。内部関数は序数のみでエクスポートされるのが一般的です。ほとんどの Windows API 関数では、異なる Windows リリース間で名前のみが保持され、序数は変更される可能性があります。したがって、Windows API 関数を序数で確実にインポートすることはできません。

序数による関数のインポートは、名前によるインポートと比べてパフォーマンスがわずかに向上するだけです。DLLのエクスポートテーブルは名前順に並べられているため、関数の検索にはバイナリサーチを使用できます。見つかった名前のインデックスは、エクスポート序数テーブルで序数を検索する際に使用されます。16ビットWindowsでは、名前テーブルはソートされていなかったため、名前検索のオーバーヘッドがはるかに顕著でした。

実行ファイルを特定のバージョンのDLLにバインドすることも可能です。つまり、インポートされた関数のアドレスをコンパイル時に解決するということです。バインドされたインポートの場合、リンカーはインポートがバインドされているDLLのタイムスタンプとチェックサムを保存します。実行時に、Windowsは同じバージョンのライブラリが使用されているかどうかを確認し、使用されている場合はインポート処理をバイパスします。そうでない場合、つまり、バインドされたライブラリと異なるライブラリが使用されている場合は、Windowsは通常どおりインポートを処理します。

バインドされた実行ファイルは、コンパイルされた環境と同じ環境で実行した場合、読み込みが多少速くなり、異なる環境で実行した場合も読み込み時間は全く同じです。そのため、インポートをバインドすることによるデメリットはありません。例えば、すべての標準Windowsアプリケーションは、それぞれのWindowsリリースのシステムDLLにバインドされています。アプリケーションのインポートをターゲット環境にバインドする良い機会は、アプリケーションのインストール時です。これにより、ライブラリは次回のOSアップデートまで「バインド」された状態を維持できます。ただし、実行ファイルのチェックサムが変更されるため、署名付きプログラムや、ファイルバージョン管理にチェックサム（MD5チェックサムなど）を使用する構成管理ツールで管理されているプログラムでは実行できません。最近のWindowsバージョンでは、セキュリティ上の理由から、ロードされたすべてのライブラリに固定アドレスを割り当てる方式が廃止されたため、実行ファイルをバインドする機会と価値は減少しています。

明示的な実行時リンク

DLLファイルは、実行時に明示的にロードすることができます。Microsoftでは、このプロセスは単に実行時動的リンクと呼ばれています。API関数は、エクスポートされたシンボルをLoadLibrary名前で検索するために使用され、-はDLLをアンロードするために使用されます。これらの関数は、POSIX標準APIの、、およびに類似しています。 LoadLibraryExGetProcAddressFreeLibrarydlopendlsymdlclose

明示的な実行時リンクの手順は、言語構造ではなく Windows APIに依存するため、関数へのポインターをサポートするどの言語でも同じです。

遅延読み込み

通常、DLL のインポート ライブラリにリンクされたアプリケーションは、DLL が見つからない場合は起動に失敗します。これは、Windows がアプリケーションに必要な DLL をすべて見つけられないとアプリケーションを実行しないためです。ただし、アプリケーションをインポート ライブラリにリンクして、動的ライブラリの遅延読み込みを可能にすることができます。[ 6 ]LoadLibraryこの場合、オペレーティング システムはアプリケーションの起動時に DLL を検索または読み込みません。代わりに、リンカーによってアプリケーションにスタブが含められ、その関数の 1 つが呼び出されたときに を通じて DLL を検索して読み込みますGetProcAddress。DLL が見つからないか読み込まれない場合、または呼び出された関数が存在しない場合は、アプリケーションは例外を生成しますが、この例外はキャッチされて適切に処理される可能性があります。アプリケーションが例外を処理しない場合、オペレーティング システムによってキャッチされ、エラー メッセージとともにプログラムが終了します。

遅延読み込みメカニズムは通知フックも提供し、 DLL が読み込まれたときや DLL 関数が呼び出されたときに、 アプリケーションが追加の処理やエラー処理を実行できるようにします。

コンパイラと言語に関する考慮事項

デルファイ

libraryソースファイルでは、の代わりにキーワードが使用されますprogram。ファイルの末尾の 節には、エクスポートされる関数がリストされますexports。

Delphi ではLIB、DLL から関数をインポートするためにファイルは必要ありません。DLL にリンクするには、external関数宣言でキーワードを使用して DLL 名を示し、その後にnameシンボルの名前 (異なる場合) を指定するか、indexインデックスを識別します。

マイクロソフト ビジュアル ベーシック

Visual Basic (VB)では、実行時リンクのみがサポートされていますが、usingLoadLibraryおよびGetProcAddressAPI 関数に加えて、インポートされた関数の宣言も許可されます。

DLL宣言を通じてDLL関数をインポートする際、ファイルが見つからない 場合、VBは実行時エラーを生成します。開発者はこのエラーを検出し、適切に処理することができます。

VBでDLLを作成する場合、IDEはActiveX DLLの作成のみを許可しますが、エクスポートされる各関数の順序と名前を定義する.DEFファイルをリンカーに明示的にインクルードするよう指示する方法が開発されています[ 7 ]。これにより、ユーザーはVisual Basic（バージョン6以下）を使用して標準的なWindows DLLを作成し、「Declare」ステートメントで参照できるようになります。

CとC++

Microsoft Visual C++ (MSVC) は、標準C++にいくつかの拡張機能を提供しており、関数を C++ コード内で直接インポートまたはエクスポートするように指定することができます。これらの拡張機能は、 GCCの Windows 版を含む他の Windows Cおよび C++ コンパイラにも採用されています。これらの拡張機能では、関数宣言の前に属性を使用します。C 関数を C++ からアクセスする場合は、コンパイラに C リンケージを使用するように通知するために、C++ コード内でも宣言する必要があることに注意してください。[ 8 ]__declspecextern "C"

インポートまたはエクスポートする関数は、属性を使用して指定するだけでなく、プロジェクトで使用されるファイル__declspecのIMPORTセクションまたはEXPORTSセクションに記述することもできます。このファイルはコンパイラではなくリンカーによって処理されるため、C++に固有のものではありません。 DEFDEF

DLL のコンパイルにより、ファイルDLLとLIBファイルの両方が生成されます。LIBファイル (インポート ライブラリ) は、コンパイル時に DLL にリンクするために使用されます。実行時のリンクには必要ありません。DLL がコンポーネント オブジェクト モデル(COM) サーバーでない限り、DLLファイルは、PATH 環境変数にリストされているディレクトリのいずれか、既定のシステム ディレクトリ、またはそれを使用するプログラムと同じディレクトリに配置する必要があります。COM サーバー DLL は を使用して登録されregsvr32.exe、これにより、DLL の場所とグローバル一意 ID ( GUID ) がレジストリに配置されます。その後、プログラムは、レジストリで GUID を参照して DLL の場所を検索したり、クラス識別子とインターフェイス識別子を使用して COM オブジェクトのインスタンスを間接的に作成したりして、DLL を使用できるようになります。

プログラミング例

DLLインポートの使用

次の例は、言語固有のバインディングを使用して、コンパイル時に DLL にリンクするためのシンボルをインポートする方法を示しています。

デルファイ

{$APPTYPE コンソール}プログラム例;// 2 つの数値を加算する関数をインポートします。function AddNumbers ( a , b : Double ) : Double ; StdCall ; external 'Example.dll' ;// メインプログラムvar R : Double ;begin R := AddNumbers ( 1 , 2 ) ; Writeln ( '結果は次の通りです: ' , R ) ; end .

C

静的リンクを行う前に、 Example.libファイルをプロジェクトに含める必要があります（Example.dllが生成されることを前提としています） 。Example.libファイルは、DLL をコンパイルする際にコンパイラによって自動的に生成されます。上記のステートメントを実行しないと、リンカーが の定義をどこで見つければよいか分からず、リンクエラーが発生します。また、DLL ファイルExample.dll を、以下のコードで実行ファイルが生成される場所にコピーする必要がある場合もあります。 AddNumbers

#include <stdio.h> #include <windows.h>// 2 つの数値を加算する関数をインポートします。extern "C" __declspec ( dllimport ) double AddNumbers ( double a , double b );int main ( int argc , char * argv []) { double result = AddNumbers ( 1 , 2 ); printf ( "結果は: %f \n " , result ); return 0 ; }

明示的な実行時リンクの使用

次の例は、言語固有の Windows API バインディングを使用して、ランタイム読み込みおよびリンク機能を使用する方法を示しています。

4つのサンプルはすべてDLLプリロード攻撃に対して脆弱であることに注意する必要がある。example.dllは作成者が意図しない場所に解決される可能性があるため（明示的に除外しない限り、アプリケーションディレクトリはシステムライブラリの場所の前になり、 HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\SafeDllSearchMode[ 9 ] またはHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\CWDIllegalInDLLSearch[ 10 ]がない場合、現在の作業ディレクトリはシステムライブラリディレクトリの前に検索される）、悪意のあるバージョンのライブラリに解決される可能性がある。安全なライブラリのロードに関するMicrosoftのガイダンスについては、次の資料を参照のこと。DLL検索パスからアプリケーションディレクトリと現在の作業ディレクトリの両方を削除するには、SetDefaultDllDirectoriesinを使用するか、DLL検索パスから現在の作業ディレクトリを削除するには、 inを使用する必要がある。[ 11 ]kernel32SetDllDirectoryWkernel32

マイクロソフト ビジュアル ベーシック

Option Explicit Declare Function AddNumbers Lib "Example.dll" _ ( ByVal a As Double , ByVal b As Double ) As DoubleSub Main () Dim Result As Double Result = AddNumbers ( 1,2 ) Debug.Print "結果は次のようになりました: " & Result End Sub

デルファイ

プログラム例; {$APPTYPE CONSOLE}はWindowsを使用します; var AddNumbers : function ( a , b : integer ) : Double ; StdCall ; LibHandle : HMODULE ; begin LibHandle := LoadLibrary ( 'example.dll' ) ; if LibHandle <> 0 then AddNumbers := GetProcAddress ( LibHandle , 'AddNumbers' ) ; if Assigned ( AddNumbers ) then Writeln ( '1 + 2 =' , AddNumbers ( 1 , 2 ) ) ; Readln ; end .

C

#include <stdio.h> #include <windows.h>// DLL 関数シグネチャtypedef double ( * ImportedFunction )( double , double );int main ( int argc , char * argv []) { ImportedFunction addNumbers ; double result ; HINSTANCE hinstLib ;// DLL ファイルをロードしますhinstLib = LoadLibrary ( TEXT ( "Example.dll" )); if ( ! hinstLib ) { printf ( "ERROR: DLL をロードできません\n " ); return 1 ; }// 関数ポインターを取得します。addNumbers = ( ImportedFunction ) GetProcAddress ( hinstLib , "AddNumbers" ); if ( ! addNumbers ) { printf ( "ERROR: DLL 関数が見つかりません\n " ); FreeLibrary ( hinstLib ); return 1 ; }// 関数を呼び出します。result = addNumbers ( 1 , 3 );// DLL ファイルをアンロードしますFreeLibrary ( hinstLib );// 結果を表示printf ( "結果は: %f \n " , result );0を返す; }

パイソン

Python インタープリタは、共有ライブラリ内の関数の呼び出しを可能にする外部関数インターフェイス(FFI)を提供する ctypesモジュールを使用します。

Python ctypesバインディングはPOSIXシステム上でPOSIX APIを使用します。[ 12 ]

ctypesをインポートするmy_dll = ctypes 。cdll 。LoadLibrary ( "Example.dll" )# Pythonが関数によって返される型を理解するには、次の「restype」メソッドの仕様が必要です。my_dll . AddNumbers . restype = ctypes . c_doublep = my_dll . AddNumbers ( ctypes . c_double ( 1.0 ), ctypes . c_double ( 2.0 ))print ( "結果は次の通りです:" , p )

コンポーネントオブジェクトモデル

コンポーネントオブジェクトモデル（COM）は、DLLおよびEXEファイル内のオブジェクト実装をホストするためのバイナリ標準を定義します。これらのファイルの検索とバージョン管理のメカニズムに加え、言語に依存しない機械可読なインターフェース記述を提供します。COMオブジェクトをDLLにホストすることで、より軽量になり、クライアントプロセスとリソースを共有できるようになります。これにより、COMオブジェクトはVisual BasicやASPなどのシンプルなGUIフロントエンドに強力なバックエンドを実装できます。また、スクリプト言語からプログラミングすることも可能です。[ 13 ]

DLLハイジャック

DLLハイジャック、DLLスプーフィング、DLLプリロード、バイナリプランティングと呼ばれる脆弱性により、多くのプログラムは、これらのプログラムによって開かれたデータファイルと同じフォルダに含まれる悪意のあるDLLをロードして実行します。 [ 14 ] [ 15 ] [ 16 ] [ 17 ]この脆弱性は2000年にGeorgi Guninskiによって発見されました。 [ 18 ] 2010年8月にACROS Securityが再発見し、何百ものプログラムに脆弱性があることが判明したことで、この脆弱性は世界的に注目を集めました。[ 19 ]安全でない場所、つまりダウンロードやTempディレクトリ などのユーザーが書き込み可能なフォルダから実行されるプログラムは、ほぼ常にこの脆弱性の影響を受けます。[ 20 ] [ 21 ] [ 22 ] [ 23 ] [ 24 ] [ 25 ] [ 26 ]

参照

参考文献

  1. ^ Microsoft Corporation (2021年8月3日). 「リソースのみのDLLの作成」 . Microsoft Developer Network Library .
  2. ^ 「DLL地獄の終焉」。Microsoft Corporation。2008年5月6日時点のオリジナルよりアーカイブ。 2009年7月11日閲覧。
  3. ^ 「インポートアドレステーブルについて」 . Sandsprite.com . 2023年11月7日時点のオリジナルよりアーカイブ。 2023年11月7日閲覧。
  4. ^ 「DLLのビルドと使用」。インポートライブラリは通常のUNIXライクな.aライブラリですが、プログラムがDLLをどのように操作（「インポート」）するかをOSに伝えるために必要なわずかな情報のみが含まれています。この情報は.exeにリンクされます。
  5. ^ 「ld と WIN32」。ldドキュメント。
  6. ^ 「遅延ロードDLLのリンカーサポート」 Microsoft Corporation 2009年7月11日閲覧。
  7. ^ Petrusha, Ron (2005-04-26). 「Visual BasicでWindows DLLを作成する」 . O'Reilly Media . 2009年7月11日閲覧。
  8. ^ MSDN、extern を使用してリンクを指定する
  9. ^ 「ダイナミックリンクライブラリの検索順序」。Microsoft Developer Network。2023年2月9日。 2023年2月9日閲覧。
  10. ^ 「DLL 検索パス アルゴリズムを制御するための新しい CWDIllegalInDllSearch レジストリ エントリが利用可能になりました」。Microsoftサポート。
  11. ^ 「DLLプリロード攻撃を防ぐためのライブラリの安全なロード」 Microsoftサポート。 2019年10月28日閲覧。
  12. ^ 「ctypes — Python用外部関数ライブラリ」 . Pythonドキュメント. 2025年7月9日閲覧。
  13. ^ Satran, Michael (2020年8月21日). 「コンポーネント オブジェクト モデル (COM)」 . msdn.microsoft.com .
  14. ^ビョークルンド、アンドレアス;ヨハン・クレフシュテット。ウェスターグレン、スヴェン。「Windows における DLL スプーフィング」(PDF)。ウプサラ大学情報技術学部。2023 年 11 月 7 日のオリジナルからアーカイブ(PDF) 。2023 年11 月 7 日に取得。
  15. ^ 「DLLプリロード攻撃」 . msdn.com . 2018年3月25日閲覧。
  16. ^ 「DLLプリロードリモート攻撃ベクトルに関する詳細情報」 technet.com 2018年3月25日閲覧。
  17. ^ 「DLLプリロードリモート攻撃ベクトルに関する最新情報」 technet.com 2018年3月25日閲覧。
  18. ^ 「WindowsエクスプローラーからMS Officeドキュメントをダブルクリックすると、場合によっては任意のプログラムが実行される可能性がある」 www.guninski.com . 2018年3月25日閲覧。
  19. ^ 「バイナリプランティング - 忘れられた脆弱性の公式ウェブサイト。ACROS Security」www.binaryplanting.com。2018年3月25日閲覧。
  20. ^ Dormann, Will (2008年9月4日). 「Carpet Bombing and Directory Poisoning」 .カーネギーメロン大学 - SEIブログ. 2023年11月7日時点のオリジナルよりアーカイブ。 2023年11月7日閲覧。
  21. ^ 「開発者からMozillaへ：古いWindowsのインストールプロセスを廃止してほしい」 theregister.co.uk . 2018年3月25日閲覧。
  22. ^ 「Gpg4win - セキュリティアドバイザリ Gpg4win 2015-11-25」 www.gpg4win.org . 2018年3月25日閲覧。
  23. ^ 「McAfee KB - McAfee セキュリティ情報: 複数の McAfee インストーラーおよびアンインストーラーのセキュリティパッチ (CVE-2015-8991、CVE-2015-8992、CVE-2015-8993) (TS102462)」 . service.mcafee.com . 2018年3月25日閲覧。
  24. ^ 「fsc-2015-4 - F-Secure Labs」www.f-secure.com。2017年7月31日時点のオリジナルよりアーカイブ。 2018年3月25日閲覧。
  25. ^ 「ScanNow DLL検索順序ハイジャック脆弱性と廃止」 rapid7.com 2015年12月21日. 2018年3月25日閲覧。
  26. ^ Team, VeraCrypt. 「oss-sec: CVE-2016-1281: TrueCryptおよびVeraCrypt Windowsインストーラーは、権限昇格による任意のコード実行を許可する」 seclists.org . 2018年3月25日閲覧。
  • ハート、ジョンソン著『Windowsシステムプログラミング 第3版』Addison-Wesley、2005年、ISBN 0-321-25619-0。
  • レクター、ブレント他著『Win32プログラミング』Addison-Wesley Developers Press、1997年。ISBN 0-201-63492-9。
「 https://en.wikipedia.org/w/index.php?title=Dynamic-link_library&oldid=1334608706」から取得