17

RAM常駐イメージをチェックサム自体に取得しようとしていますが、これは言うは易く行うは難しです。

コードは最初にクロス開発プラットフォームでコンパイルされ、.elf 出力が生成されます。ユーティリティを使用してバイナリ イメージを削除し、そのイメージをイメージ サイズと共にターゲット プラットフォームに焼き付けてフラッシュします。ターゲットが開始されると、バイナリが RAM の正しい領域にコピーされ、そこにジャンプします。このユーティリティは、RAM に送信される elf 内のすべての単語のチェックサムも計算し、それもフラッシュに焼き付けます。したがって、私のイメージは、理論的には、事前の開始アドレスとフラッシュに保存されたサイズを使用して、独自の RAM 常駐イメージをチェックサムし、フラッシュに保存された合計と比較できます。

とにかくそれが理論です。問題は、イメージの実行が開始.dataされると、変数が変更されるとセクションが変更されることです。合計が完了するまでに、合計されたイメージは、ユーティリティが合計を計算したイメージではなくなります。

チェックサムルーチンをアプリ内の他のすべての初期化の前に移動することで、アプリケーションで定義された変数による変更を排除しました (整合性チェックが失敗した場合に実行する理由は理にかなっていますよね?)。キラーはCランタイムそのものです。mallocポインターのキャスティングなどに関連して、入力前に変更された項目がいくつかあるようmain()です。

自己チェックサム C コードの全体的なアイデアは不十分ですか? アプリと CRT の .data を別のセクションに強制する方法があれば、CRT のスラッシュを回避できますが、(ほとんどの) イメージを実行する前にイメージの整合性をチェックすることが目標である場合、CRT データを初期化する必要があると主張する人もいるかもしれません。その一部になります。このようにコードチェックサム自体をRAMに作成する方法はありますか?

FWIW、私はこれの要件にこだわっているようです。個人的には、ram に転送する前に flashでバイナリをチェックサムし、ローダーと ram を信頼する方法だと思っていました。パラノイアはどこかで終わらなければなりませんよね？

その他の詳細: ツール チェーンは GNU であり、イメージには が含まれており.text、1 つの連続して読み込まれたチャンクとして含まれています。OS はなく、これはベア メタルが組み込まれています。プライマリ ローダーは基本的に、バイナリを RAM の所定のアドレスに格納します。再配置は発生しません。VM は使用されません。チェックサムは、初期化時に一度だけテストする必要があります。.rodata.datamemcpy

更新 これを行うことでそれが見つかりました..

__attribute__((constructor)) void sumItUp(void) {
    // sum it up
    // leave result where it can be found
}

malloc.. CRT init による/sbrk変数の初期化と、"impure.o" および "locale.o" が所有するいくつかの変数を除いて、ほぼすべての前に合計を取得できます。ここで、malloc/のsbrk値は、プロジェクト リンカー スクリプトから知っているものです。impure.o と locale.o を軽減できれば、ビジネスになる可能性があります。

更新 エントリ ポイントを制御できるので (プライマリ ローダーのフラッシュに記載されている内容により)、カスタム アセンブラ コードを使用してスタックと sdata ポインタを設定し、チェックサム ルーチンを呼び出すのが最善の方法のようです。次に、「通常の」_start コードに分岐します。

4

5 に答える 5

4

チェックサムが十分に早く行われる場合、スタック変数のみを使用し、データセクション変数に書き込むことはできません。 [もちろんグローバルデータを読み取ることができます]に物を格納するための変数。

正しい方法は、フラッシュとローダーがフラッシュにあるものをロードすることを信頼することであると私はかなり確信しています。コードをチェックサムしたい場合は、もちろん行って実行してください[もちろん、ローダーによって変更されていないと仮定します-たとえば、共有ライブラリのランタイムロードや、ランダムな仮想アドレス空間などの実行可能ファイル自体の再配置など]。しかし、フラッシュからロードされたデータは、実行が適切に開始されると信頼できなくなります。

これを行う必要があるという要件が他の誰かからある場合は、これを実装することは不可能であり、「現状の要件」は「壊れている」ことを説明してください。

于 2012-12-31T15:19:12.273 に答える
2

upxのような実行可能なパッカーのようにこれにアプローチすることをお勧めします。

他の回答とあなたの質問には、より適切な用語がないために緊張することがいくつかあります。

  • 私は、ローダーや強制されていないフラッシュ内の何かを信頼しません。
  • HTC の最近の携帯電話の 1 つを保護するために使用されたソース コードがネット上に出回っています。forum.xda-developers.com を調べて、見つけて例として使用できるかどうかを確認してください。
  • 私はこの要件に反対します。携帯電話メーカーは、自社の画像をロックダウンし続けることに多くの時間を費やし、最終的にはすべてのメーカーが打ち負かされます。これは悪循環のようです。
于 2012-12-31T17:13:15.390 に答える
1

リンカスクリプトを使用して、impure.oとlocale.oを他のすべての前または後に配置し、それらとmalloc / sbrkのもの以外のすべてをチェックサムできるようにすることはできますか？アプリケーションをロードするブートローダーでmallocとsbrkが呼び出されると思いますが、これらによって引き起こされるスラッシュを排除することはできませんか？

この要件と戦うように言うだけでは答えではありませんが、これは考えすぎのように思われることに同意します。詳細に立ち入ることはできないと思いますが、仕様の作成者は、宇宙線などによる通常のメモリの破損ではなく、悪意のあるユーザー/ハッカーを懸念していると思います。この場合、悪意のあるユーザーはユーザー/ハッカーはRAMにロードされるものを変更できます。チェックサムルーチン（それ自体はRAMから実行されていますが、正しいですか？）を変更するだけで、実行されなくなったチェックサムルーチンがどれほどうまく設計されていても、常に幸せなステータスを返すことができます。 。

彼らが定期的なメモリの破損を懸念している場合でも、このチェックサムルーチンは、メモリへの元のコピー中にエラーが発生した場合にのみキャッチします。これは、システムが実行されていないという理由だけで、実際にはそのようなエラーが発生する可能性が最も低い時間です。破損イベントの可能性が高いのに十分な長さ。

于 2012-12-31T17:40:02.410 に答える
0

RAM にコピーされる前に、フラッシュ常駐バイナリ イメージでチェックサム テストを実行するようにローダーを更新できますか?

于 2012-12-31T21:16:55.870 に答える
0

多くの（ほとんどの？）プラットフォームでは、プログラムローダーがいくつかのプログラムアドレス定数を「再配置」する可能性があるため、一般に、やりたいことは不可能です。

于 2012-12-31T15:43:54.147 に答える