各 Birthmark の定義などは たまぺーじ分家 からダウンロードできる pdf などを御覧下さい。
ref. [2004-03-12-5]
二つの論文に共通する部分で、我々が考えていることとの決定的な違いがある。この birthmark の目的だ。
彼らは birthmark は盗用を証明するものだと言っている。
しかし、我々は birthmark は盗用を証明するものではないと考えている。
birthmark はあくまで、盗用の疑いがあるプログラムを見つけ出すものだと考えている。
盗用の証明は watermark なり、code clone なりで行なえば良い。
birthmark は大量のプログラムの中から盗用だと疑わしいものを見つけ出すものだ。と考えている。
そして，二つの birthmark を共に実験していないのがちょっと引っかかる．
考察で終わるのが駄目と言っているわけではないが，考察が合っているかどうかを
実験で確かめるのも大切ではないのかなぁ．
しかも攻撃(難読化)に対する耐性って頭の中では整理しきれないと思うし，
原稿で挙げられている難読化手法の他にも沢山の主要な方法があったりするし．
例えば，文字列の暗号化とか，マルチスレッド化とか，数値の分割とか．．．
- Javaクラスファイルの等価変換に耐性を持つプログラム指紋抽出法
私が [2003-07-17] に ISEC で発表した birthmark 抽出方のうち、
CVFV(Constant Values in Field Variables) と IS (Inheritance Structure) の問題点が指摘されている。
CVFV は初期値を見るので、
public class Hoge{
private int fuga;
public Hoge(){
fuga = 3;
}
}
とあるのを
public class Hoge{
private int fuga;
public Hoge(){
fuga = 1;
fuga += 2;
}
}
に変えてしまえば改ざんできてしまうという指摘。
IS の方は
public class SuperClassA{
:
}
public class ChildA extends SuperClassA{
:
}
の二つのクラスの間に
public class DummySuperClassB extends SuperClassA{
// no any fields and methods
}
を入れ、ChildA クラスを
public class ChildA extends DummySuperClassB{
:
}
とすれば良いとの指摘。
ごもっとも。
ただし、CVFV の改ざん方法に対処するのはあくまでツールなので、余り問題にはならないと思う。
そのフィールドを注目すればできるような気がする。
とは言え、一旦別のローカル変数に代入されたりすると、お手上げなのは確か。
IS の方は、はい、まあ終わってます。
で、SMC については birthmark として有効だと書いているけど、他の二つと同じようなもんだと思うけどなぁ。
彼らは新たに提案する birthmark として「メソッドの有限オートマトン化」を挙げている。
手順をさらっと説明すると、
(1) オペランドスタックへの push から pop までの instruction を一つの疑似 instruction とする
(2) 上で得られた疑似 instruction のシーケンスのうち、入れ換え可能な instruction を一つのグループとする
(3) 上で得られたグループを条件分岐などのジャンプで繋ぎ、オートマトン化する
(4) 得られたオートマトンから無条件ジャンプを削除し、それを birthmark とする
こんな感じかなぁ。今手元に原稿がないので、ちょっとうろ覚え。
間違いに気付いた人がいれば突っ込んで下さい。後で私も確認します。
birthmark としては、私の提案したものよりも強い耐性を持つんだろうけど、
実装が大変な気がする。
まず、(1) から言うと push, pop って単純に並んでいるわけじゃない。
invoke 命令も push, pop を行なうので、その関係を見つける事が面倒臭そう。
例えば，
1: aload_0
2: iconst_0
3: aload_1
4: iconst_0
5: aload_0
6: arraylength
7: invokestatic System#arraycopy
という命令列だと
System.arraycopy(localVariable0, 0, localVariable1, 0, localVariable0.length)
という命令に相当するのだが，この場合，
push 1: aload_0
push 2: iconst_0
push 3: aload_1
push 4: iconst_0
push 5: aload_0
pop, push 6: arraylength
pop*5 7: invokestatic System#arraycopy
という関係だ．どこからどこまでを一つの擬似 instruction とするのかがわからない．
(2) については、副作用のあるクラスのメソッド呼出を考えると、入れ換え可能かどうかというのは
人が読まないとわからなそう。
(3), (4) は特に突っ込むべきところもない。
- 動的解析を用いたJava クラスファイルのプログラム指紋抽出法
こっちはコンセプトが終わっている気がする．
birthmark は盗用を発見する技術であって，盗用を証明するものではない．
発見するのだから，高速に，大量のプログラムを検査することが重要だと思う．
そして，誤検出は全然問題ではなく，それよりも盗用されたプログラムが検出できない
ということがないようにしなければならない．
で，この原稿ではクラスファイルを動的に解析している．
動的に解析するということは，もうほとんどの場合，自動化できない．
自動化できない時点で birthmark の目的が達成できないことになる．
で，肝心の手法ですが，原稿を何度も読み返したのですが，不明な箇所が多くて
よくわかりませんでした．
自分の提案した手法の弱点をこんなにさらけだしていいんだろうか・・・。
ちなみに，私がここに書いたいちゃもんらしきもの全てを満たしているわけではありません．
]
