アカウント名:
パスワード:
最近復権しているテクニックですね。
リバースエンジニアリング対策としては一定の効果があるのでしょうが、何某かのOS上で動くコードでそれをやるのは危険ではないですか?やってる事自体はバッファオーバフロー攻撃とあんまし変わらない訳で(バッファオーバフローはスタック領域とコード領域の間のプロテクションの曖昧性を突いて強引に自己書き換えするので意味合いが違いますけど)
# セグメント種別にうるさい86系で自己書き換えをやって安定して動かせられる状況と言うのが今ひとつ# 実感出来ないのもありますが。これがMMUをキャンセルしてシングルタスク同然で動かしてるRISCとか# RAMにコード展開するマイコン装置ならまだ理解できますが…
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
192.168.0.1は、私が使っている IPアドレスですので勝手に使わないでください --- ある通りすがり
私の場合 (スコア:2, 興味深い)
586以降では命令キャッシュを破壊したりと不利益のほうが大きいので使う事はなくなりましたね、さすがに。
Re:私の場合 (スコア:1)
危なくないですか?(Re:私の場合 (スコア:1)
リバースエンジニアリング対策としては一定の効果があるのでしょうが、何某かのOS上で動くコードでそれをやるのは危険ではないですか?やってる事自体はバッファオーバフロー攻撃とあんまし変わらない訳で(バッファオーバフローはスタック領域とコード領域の間のプロテクションの曖昧性を突いて強引に自己書き換えするので意味合いが違いますけど)
# セグメント種別にうるさい86系で自己書き換えをやって安定して動かせられる状況と言うのが今ひとつ
# 実感出来ないのもありますが。これがMMUをキャンセルしてシングルタスク同然で動かしてるRISCとか
# RAMにコード展開するマイコン装置ならまだ理解できますが…
80x86 の命令の自己書き換え (スコア:2)
それが i486 のキャッシュ導入以降はかえってフレンドリーな動作になり、 Pentium に至ってはすでにパイプラインに入った命令が自己書き換えを受けた場合、 パイプラインを自動的に巻き戻してくれていました。
# P6 系から自己書き換えは再び面倒になったはず。
ところで x86 系 CPU で Self-Modifying Code や Cross-Modifying Code を行なう正しい作法は、 Intel64 and IA-32 Architectures Software Developer's Manual Volume 3A: System Programming Guide [intel.com] の 7.1.3 Handling Sef- and Cross-Modifying Code の章に記述されていますよ。
この作法を守って正しく動作しない場合は CPU のバグですな。
コンタミは発見の母
Re: (スコア:0)
マニュアルには自己書き換えの後に明示的なジャンプかシリアライズが必要とあります。
確かにOoOプロセッサでこんなものまで巻き戻すのは泣けてきそうです。
Re:危なくないですか?(Re:私の場合 (スコア:1)
コードテンプレートに処理を埋め込むとか、動的に生成したコードについて追加処理をインクリメンタルに埋め込む、あるいはより最適化した処理に置き換えるとか。