.dllファイルは通常system32にありますが、現在はユーザーのAppDataフォルダーに常に不審ですか？
私は最近、マルウェアの検出とその後のWindows資産の感染を確認するために、いくつかのマルウェアレポートと関連ログを読む必要がありました。ログには、ユーザーのAppDataフォルダ内の.dllファイルが明確に示されています。これらの.dllファイルは、通常.dllにあるsystem32sと同じ名前になります（例：cryptbase.dll）。
この特定の例では、これは間違いなくマルウェアであり、不正な.dllsの解凍はマルウェアの通常のプロセスの一部でした。私はチャットでこれについて尋ねましたが、この動作の本当の信頼できる説明はマルウェア（この場合のように）または非常に悪いプログラミング慣行であり、その場合でもまれなシナリオであると言われました。
私の質問は2つあります。マルウェアまたは不適切なプログラミング以外の理由で、標準の.dllsystem32sと同じ名前の.dllファイルがユーザーのAppDataフォルダにあるシナリオはありますか？
さらに、AppDataにあり、.dllの.dllファイルのコピーのように見えるsystem32ファイルを、侵害の指標として扱うことは公正ですか？
MicrosoftがProgram Filesフォルダーのデフォルトの権限を調整したため、多くの開発者はコードの代替の場所としてAppDataを使用しています。この方法でインストールされたアプリケーションは、昇格または管理者レベルのアクセスを必要とせずに更新できるというロジックです。 （たとえば、Google Chromeがこれを行います）。
これはまた、通常、AppDataパスの下のどこかにあるsystem32フォルダーに通常存在する正当なライブラリーを見つけることを意味します。これらは通常、アプリケーション自体によって保守および更新されるランタイムコンポーネント（MSVCRT、GDI +、またはcapicomなど）です（通常、特定のバージョンが機能するために必要ですが、システムのコンポーネントではなくユーザーコンポーネントとしてプッシュされる場合もあります。標高なしで展開する必要があります）。
これは、オペレーティングシステムに属しているライブラリを見つける必要があることを意味しません。たとえば、schannel.dllがそこに見つかる正当な理由はありません。そのライブラリを維持する唯一のアプリケーションはオペレーティングシステムだからです。
そのため、AppDataの下のsystem32のdllと同じ名前のdllはnotが自動的に疑わしくなります。
distributionには適切ではありませんが、誰かが%appdata%システムライブラリのパスは、実行時シミング用です。
具体的には：特定のAPIコントラクト検証にランタイムインスペクションを実行したい場合（malloc/freeですが、これは既にAppVerifierによって管理されています）または一般的な使用状況のプロファイリング、検証を実行するシムレイヤーを記述して、正当なシステムライブラリに渡すことができます。
一般に、システムライブラリは適切なシステムまたは [〜＃〜] sxs [〜＃〜] パスにある必要があります。 Windows Logo Certification を使用するものはすべてこれに準拠しますが、多くのアプリは認証なしで配布されます。
あなたが実際にWindowsのデフォルトDLLを上書きするなら、私はそれを悪いプログラミングと呼びます。それらをSystem32以外の場所に置くと、次のことができます。
- システムに依存しない正確なDLLバージョンを使用します（例：Direct 9のDLLはWindows 10にはデフォルトで含まれていないため、そのクラッシュに依存するすべてのゲーム）
- 管理者権限なしで実行可能ファイルを更新します（FirefoxとChromeはそれを行います）
- システムを上書きするDLLアプリのみ（最初にそれを行う理由）
ソフトウェアが適切に作成されている場合、DLLはSystem32ではなくAppDataまたはそのインストールディレクトリに配置されます。
マルウェアが適切に作成されている場合、DLLはSystem32に配置されます。