RaspberryPiでWifiドングルを使用しようとしています。ドングルのベンダーは、ARMアーキテクチャで正常にコンパイルできるLinuxドライバーを提供していますが、ドライバーに付属する1つのオブジェクトファイルがx86アーキテクチャ用にプリコンパイルされているため、リンカーが失敗します。
その（かなり大きな）ファイルを再度コンパイルする方がはるかに簡単であることはわかっていますが、ソースコードにアクセスできません。
そのオブジェクトファイルをx86アーキテクチャからARMアーキテクチャに変換することは可能ですか？
ありがとうございました！
ええと、いや、それは時間の無駄のように私には見えます。Wi-Fiドライバーは複雑で、この1つの厄介なオブジェクトファイルは「大きい」と言います。翻訳するのに多くの苦痛があり、デバッグが成功する可能性はほとんどありません。また、この1つのオブジェクトファイルとシステムの残りの部分の間で受け渡されるパラメータは、x86とARMの間で直接変換されません。
理論的には、そうです。ソースコードにアクセスせずに実際のカーネルドライバでそれを行うのは難しいでしょう。
オブジェクトファイルの高品質な分解があり、オブジェクトファイル内のコードが「正常に動作する」場合（標準の呼び出し規約を使用し、自己変更コードはありません）、X86命令を自動的にarm命令に変換できます。ただし、おそらく高品質の分解はありません。特に、オブジェクトファイルの一部で、通常の再帰下降構文解析を実行するコードまたはデータとして適切に分類できない場合があります。データをコードとして誤って解釈すると、データはそのままコピーされるのではなく、ARMコードに変換されるため、誤った値になります。これにより、コードが正しく機能しなくなる可能性があります。
運が良ければ、オブジェクトファイル内のすべてのアドレスを適切に分類できたとしても、つまずく問題がいくつかあります。
X86の呼び出し規約は、ARMの呼び出し規約とは異なります。つまり、X86の呼び出し規約に関連するパターンを特定し、ARMの呼び出し規約を使用するように変更する必要があります。これは簡単な書き直しではありません。
ARMのハードウェアインターフェイスはX86とは異なります。コードを変換するには、ドライバーがどのように機能するかを理解する必要があります。それには、実質的なX86ハードウェア比較可能性レイヤー、またはドライバーの動作のリバースエンジニアリングが必要になります。ドライバーをリバースエンジニアリングできる場合は、それを翻訳する必要はありません。アームバージョンを書くことができます。
内部カーネルAPIは、ARMとX86で異なります。あなたはそれらの違いとそれらの間の翻訳方法を理解する必要があります。それはおそらく些細なことではありません。
Linuxカーネルは、コードが最初にカーネルにロードされるときにマシンコードを動的に書き換える「代替」メカニズムを使用します。たとえば、ユニプロセッサマシンでは、パフォーマンスを向上させるために、ロックがno-opsに置き換えられることがよくあります。「popcnt」のような命令は、それをサポートしていないマシンでの関数呼び出しなどに置き換えられます。カーネルでの使用は非常に一般的です。これは、上記の定義によれば、オブジェクト内のコードがファイルである可能性が高いことを意味します。オブジェクトファイルがそのメカニズムを使用していないことを確認するか、オブジェクトファイルの使用を変換する方法を見つける必要があります。
X86は、ARMとは異なるメモリモデルを使用します。X86コードを（競合状態を導入せずに）ARMに「安全に」変換するには、すべてのメモリアクセスの後にメモリフェンスを導入する必要があります。その結果、ARMチップのパフォーマンスが非常に悪くなります。いつメモリフェンスを導入する必要があるかを（どこでも実行せずに）把握することは、非常に難しい問題です。この種の分析で最も成功する試みには、オブジェクトファイルにはないカスタム型システムが必要です。
最善の策（成功への最短ルート）は、問題のオブジェクトファイルの機能をリバースエンジニアリングしてから、それを置き換えることです。
これを行うための合理的な方法はありません。x86は役に立たないため、製造元に連絡して、関連するコードをARMコードで提供できるかどうかを尋ねてください。それができない場合は、ハードウェアの別のサプライヤ（すべてのコンポーネントのARMバージョンまたは完全にオープンソース）またはソフトウェアのサプライヤ（別のコンポーネントがあると仮定）を見つける必要があります。そのソース]。
x86 GNU binutilsをインストールし、objdumpを使用してオブジェクトファイルを逆アセンブルすることにより、x86アセンブリを手動で変換できます。おそらくいくつかのアドレスは異なりますが、簡単なはずです。
はい、間違いなく静的なバイナリ変換を行うことができます。x86の分解は苦痛ですが、これが高レベルからコンパイルされた場合、それは可能な限り悪くはありません。
それは本当に努力する価値がありますか？代わりに命令セットシミュレータを試してみてください。使用された命令の数の分析を行いましたか？システムコールが必要ですか？
これまでのところ、分解についてどこまで進んでいますか？
たぶん、ファイルには、wifiファームウェアのバイナリダンプしか含まれていませんか？その場合、命令の変換は不要であり、objcopyを使用して変換を行うことができます。
objdump -x file.oを使用して、実際の実行可能コードがobjファイル内にあるかどうか、またはそれがデータのみであるかどうかを確認できます。
Hex-Raysデコンパイラーを使用してIDAにアクセスできる場合は、（ある程度の作業を行って）オブジェクトファイルをCコードに逆コンパイルしてから、ARM用に再コンパイルしてみてください。