10

開始しているプロセスでCoCreateInstanceへのすべての呼び出しを検出しようとしています(理想的には、子プロセスでも呼び出しを検出できます)。

これを実現するために、Windows 7 で Microsoft Visual Studio 2008 を使用して、標準ole32.dllライブラリ内の 1 つを除くすべての呼び出しを転送するプロキシ DLL を作成します (例: Intercepted: Windows Hacking via DLL Redirectionなど) 。結果の DLL は問題ないように見えますが、既存のプログラム (標準のActiveX コントロール テスト コンテナー (tstcon32.exe)をテスト アプリケーションとして使用しています) にプロキシ DLL を取得させることができません。私が何をしても、プログラムはProcess ExplorerC:\Windows\SysWow64\ole32.dllに従って常にピックアップしているようです。これまでにいくつかのことを試しました：

  1. プロキシ DLL を含むディレクトリを先頭に追加しPATH、プログラムを呼び出します。効果はないようでした。
  2. プロキシ DLL を、呼び出されたプログラムと同じディレクトリにコピーします。運がない。
  3. Dynamic-Link Library Redirection の.local記事で説明されているように、呼び出されたプログラムと同じディレクトリにファイルを作成し、プロキシ DLL を同じディレクトリに配置しますが、どちらも機能しませんでした。しかし、その後、これが最近の Windows バージョンでは機能しなくなったことを読みました。さらに、はレジストリ設定によると「既知の DLL」であるため、ベースのリダイレクトはおそらく機能しません。ole32.dllHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs.local
  4. マニフェストを使用したDLL リダイレクトの質問などで説明されているように、マニフェスト ベースのリダイレクトを使用しますが、それも効果がないようです。ただし、このアプローチは自明ではないように思われるため、何か間違ったことをした可能性があります。

ole32.dllスタブ DLL の使用など、呼び出しを標準 DLL にリダイレクトした経験のある人はいますか? どのようにしてアプリケーションにスタブ DLL を取得させましたか?

4

2 に答える 2

5

これは約6か月遅れていることに気づきましたが、同じことを試みていて、いくつかの追加のメモがあります。

  1. ole32.dllの所有権を取得し、から削除できますHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs。これにより、Windows がこれらのキーをロックしているという事実を回避できます。
  2. inSafeDllSearchの値を持つキーを作成すると、検索パスが変更されるはずです。0HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager

これらの手法と再起動の両方を適用しても、フックは機能しませんでした。さらに、レスキュー CD の 1 つ (Windows PE ベースの環境) を使用して VM を起動し、 にあるものを上書きしましたsystem32。その結果、Windows は起動しません。シンボル エラーはありませんが、LogonUI.exe. フックされた機能が壊れている可能性があるため、これが原因である可能性があります。

とにかく、それは実際の具体的なフック効果を生み出しました-「壊れた」と叫ぶものではありますが!. 残念ながら、デバッグが非常に難しいようで、フックの別の方法、つまりIAT パッチに頼っている可能性があります。

私が実行した別の実験を編集して、Dll 自身をターゲット プロセスのアドレス空間に明示的にロードしました。これを行うコードのスニペットは次のようになります。

wchar_t* TargetPath = argv[1];
wchar_t DllPath[] = L"N:\\experiments\\ole32.dll";
STARTUPINFOW si;
PROCESS_INFORMATION pi;
memset(&si, 0, sizeof(STARTUPINFOW));
memset(&pi, 0, sizeof(PROCESS_INFORMATION));

// create process suspended
BOOL bResult = CreateProcess(NULL, TargetPath, NULL, NULL, FALSE, 
    CREATE_SUSPENDED, NULL, NULL, &si, &pi);

// write DLL name to remote process
void* RemoteAddr = VirtualAllocEx(pi.hProcess, NULL, sizeof(DllPath)+1, 
    MEM_RESERVE | MEM_COMMIT, PAGE_READONLY);
WriteProcessMemory(pi.hProcess, RemoteAddr, DllPath, sizeof(DllPath), &BytesWritten);

// get handle to LoadLibraryW
PTHREAD_START_ROUTINE pfLoadLibrary = (PTHREAD_START_ROUTINE) 
    GetProcAddress(GetModuleHandle(L"kernel32.dll"), "LoadLibraryW");

// create remote thread calling LoadLibraryW
HANDLE hThread = CreateRemoteThread(pi.hProcess, NULL, 
    0, pfLoadLibrary, RemoteAddr, 0, NULL);

// start remote process
ResumeThread(pi.hThread);

簡潔にするためにエラー処理を削除しました。

基本的に、目的は、ターゲットが system32ole32.dllからロードされる前に、ターゲットのアドレス空間に my を強制的にロードすることでした。ole32.dll私の場合、ole32.dll後でアプリケーションのロード ルーチンでロードされていたので、理論的にはこれでうまくいくはずでした。実際には、そうではありませんでした。理由はわかりません。

実行時に DLL に未解決のシンボル警告があったため、元のコードを更新できませんでした。この手法は機能するので、どうやら、私ole32.dllのものとsystem32のものの両方をロードします。ライブラリが正常に読み込まれたことを確認するために、LoadLibrary(DllPath)上記のコードへの呼び出しを追加しました。

于 2012-10-22T13:56:43.773 に答える
2

おそらくwinapioverrideがあなたを助けることができます。何もプログラミングせずに、すべてのWinAPI呼び出しをログに記録できます。したがって、ロギングを行うプロセスにdllを挿入します。正しく思い出せば、プロセスが実際にコードを実行する前であっても、独自のカスタムdllを挿入することも可能です。ドキュメントには、comオブジェクトのスパイに関する情報が含まれています。

于 2011-05-04T14:24:49.270 に答える