【プログラム】コンパイルされたらもう分からん。ソースコードの中にトロイの木馬が仕込む方法とは [896590257]
■ このスレッドは過去ログ倉庫に格納されています
見えない脆弱性をソースコードに埋め込む、プログラマーも欺く「トロイのソース」
2021.11.17 日経クロステック
プログラムに埋め込まれた脆弱性やマルウエア（コンピューターウイルス）などを見つける有効な手段の1つが、そのソースコードを丹念に調べること。
スキルのある開発者なら、ソースコードを調べることで異常に気づける。
だが、そういった開発者の目を欺く手法が発表された。ソースコードに細工を施せば、テキストエディターなどで表示されるソースコードの「見た目」を
変えられるというのだ。言い方を変えれば、目に見えない脆弱性を埋め込めるという。そんなことが可能なのだろうか。
■「トロイの木馬」のソースコード版
この新手法は、英ケンブリッジ大学の研究者らが2021年11月1日（現地時間）に発表した。「Trojan Source」と名付けられた。「Trojan Horse：トロイの木馬」にちなんだ命名だと考えられる。
ソースコードに仕込んだ脆弱性を、どのようにして開発者に気づかれないようにするのか。答えは単純。
■Unicodeを使う
「Unicodeの制御文字」を使ってソースコードの見た目を変えるのだ。Unicodeとは文字コードの一種。文字を扱うプログラムのほとんどが対応している。制御文字とは、ディスプレーやプリンター、
通信装置などに特別な動作をさせるための文字である。「文字」といっても、標準ではディスプレーなどには表示されない。そのほか1文字単位ではなくブロック単位で文字の表示を
入れ替える制御文字などもある。こういった制御文字をうまく組み合わせれば、脆弱性が埋め込まれたソースコードを、問題のないソースコードに見せかけることが可能になる。
■コメントや変数に忍ばせる
一般的なプログラミング言語では、ソースコードの任意の場所に制御文字を挿入できない。コンパイラーによる変換時（コンパイル時）にエラーが発生する。ただし、コメントと文字列は例外だ。
これらはコンパイラーによって解釈されないので、制御文字を含む任意の文字を入れられる。そこで、コメントや文字列に制御文字を入れることで、それらをソースコードの一部に見せかけたり、
ソースコードがコメントアウトされているように見せかけたりする。
https://xtech.nikkei.com/atcl/nxt/column/18/00676/111300092/ 処理追い付かない時にインラインアセンブラで書く程度の知識しか持ってないけど、逆アセンブルされたヤツは意味不明すぎる
リコンパイルしてダンプリストのコンペア取る方が現実的 >>こういった制御文字をうまく組み合わせれば
それが難しいんだよ >>84
例えデバッグコンパイルしても、レジスタフル動員して効率の良い命令選択を行い、マルチパイプラインを考慮した命令配置に入れ替えられるんで、ヒトには理解しにくいコードになりますね。
最適化レベル上げるともうわからないw >>13
8bitの時代は1バイトずらすと全然違う意味のコードになるようにしといて逆アセンブラをだますとか色んなテクニックがあったな マシン語ネイティブの俺ならダンプリストで解析可能だが？
なんならチェックサムだけでもうっすらわかるが？ >>90
もうゼッパチの時代じゃないですよ、おじいちゃん もう全部のアプリをGithubで自前ビルドさせりゃええわ
ちょうどVisualStudio2022も出たしな >>92
レビユーないなら堂々と仕込めばいいワケで、レビユーはやるけど「わかるコードは指摘するけど、わからないコードはまあいいや、オッケー」で通る会社だろなwww >>19
日経だぞw
あのwilltyですら騙されて記事にする程度の技術知識しかない無能系が記者やってんだぞ >>105
昔の環境しか知らんけどソースは呼び出す一行だけで
ウイルスのオブジェをメイクでリンクするくらいだよね >>29
それのソースは見たことないけど、自分の口座番号が書いてあるはずだからそれを発見されたら逮捕されると
わかってたはず。それを隠す特殊な方法使ったとしたらけっこう賢い。 >>78
えーとね、アセンブラで書くと言っても当然書きやすいように工夫するんだよ。
マクロ使って書くとアセンブラでもCみたいな制御構文が書けるし、代入もMOVじゃなくて = で書けるようにして、
一見すると高級言語みたいなソースにすることができる。 >>105
データセクションに
.data
db ういるす
でコンパイルするって事かな >>110
>>29は結構有名な話だけど、その銀行のエンジニアである犯人は架空口座として特殊な名前(ZZZだったかな？)を作り、ここに、四捨五入で切り捨てられる額を振り込んでたんだけど、境界テストをしてたプログラマが毎回テストにかかる最終名称が「こんな名前の人いるんだ？」と不思議がったのが発端でバレた。
MMMならバレなかったかもしれないw >>114
アメリカの話で、名前欄が(適当に作ったんで)違和感あったのが発見の要因だったみたいだね。 よく分からんけどテキストエディターで開いたらコメント外になってるんなら
その時点で気がつくんじゃね？ 8086 CPU のアセンブリ言語はニーモニック言語だった記憶
LB1
(処理コマンド)
LAD GR1,1,GR1
CPA GR1,N
JMI LB1
今のH8 CPU だとアセンブリ言語はC言語なんだっけな
main{}
{
int i:
for ( i=0: i<10: i++ ){
(処理コマンド)
}
} >>118
頭痛が痛い、みたいな文章になってるぞ。
無理すんな。 小一時間調べて頑張ったんや！
頭ズキズキ痛くなるのも我慢しながら！ >>119
すっげえ昔に使っただけなので記憶の外なんだが、8086にLAD命令なんてあったっけ？
lbl:
mov AX,10
dec AX
jnz lbl
なイメージ iniファイルを読み込むAPI関数があることを知らなかった人が
ご丁寧にiniファイルをOpenして引数で指定した項目を読み込むプログラムを自分で作ってるのを見たときはコーヒー吹いた。 Z80ならヘキサコードを直接読み書きできる人は普通にいた。
底辺な俺でも未だに主要な命令はヘキサで読める。 >>124
暗記モード。
CDがコール命令、FEが分岐かなんかw
覚えてるのはそんくらいかwww >>124
バグ見つけるとROMを外してROMライターに読み込ませた後に新しいROMを差し、ハンドアセンブルで修正して書き込んで再テスト。
取り外したROMは紫外線を当てて消去。
なんて時代は脳内がアセンブラだったけど、組み込みと言えど、いつしかICEに慣れ、それがJTAGになった頃にはハンドラも何もかもCだな。
(アセンブラ書くのは初期化処理位) 00がnopだからROMでも取り敢えず潰せばnopになるのがパッチ当てるのに便利だった >>126
ブランクエリアの0FFhはRST 38hになるけど当時は意味がわからなかった
一種のソフトウェア割り込みでMS-DOSのint 21hみたいなものだったんだな ■ このスレッドは過去ログ倉庫に格納されています
