プログラムの難読化と組織ごとの常識
更新 2020/09/27(日)
文責 炭本 治之
■難読化という技術がある
SQLのSELECT文はデータを取得・加工するだけなので,
複雑であってもその複雑さはたかが知れています。
C#プログラムソースは,SELECT文とは比較にならないほど多様な機能を持つので,
プログラムソースを際限なく複雑なものにできます。
プログラムソースを意図的に複雑にすることによって,第三者がその
プログラムを理解できないようにする技術のことを「難読化」と呼びます。
難読化(obfuscation)には,いろいろなフェーズがあります。
(1)設計書作成
| システムエンジニアが分かり難い設計書を作ります
↓
(2)プログラムソース作成
| プログラマーが分かり難いプログラムソースを製造します
↓
(3)中間コードにビルド(コンパイル)
| コンパイラがリバースエンジニアリングしにくい中間コードを生成
↓ Visual Studio Professional にはこの機能があります
(4)機械語に変換
ハッカーがアセンブラを使って機械語プログラムを改造
生物学・医学の学術論文では,研究内容は全然たいしたことはないのに,
難解な専門用語,複雑な数式や理論が使われていて,理解することは非常に難しい
ということがありますね。
システム開発でもそれと同じような症状の成果物があるのです。
■難読化の目的
難読化することによって,技術を他人に奪われにくくすることができます。
これが難読化の本来の目的です。
しかし,ソフトウェア会社の中には,意図的に難読化したソースを納品して,
お客さんがプログラムを改修・カスタマイズすることを困難にし,
継続的にそのお客さんから仕事を受注しようとする会社があります。
また,一つの会社内でも,システム開発部が意図的にソースを難読化する
ことがあります。
難読化されたソースは,難読化されていないソースに比べて,管理に
多数の人材が必要です。
システム開発部の人材を多くすることができます。
システム開発部は大所帯になり,部長の権限はそれだけ大きく,給料は
多額にすることができます。
公務員や大企業でありがちな考え方ですが,この手口はいずれ発覚します。
フリーランスのエンジニアとして,様々な会社と契約して,様々な
プログラムソースを調査する経験を積むと,意図的に難読化してある
ソースに出会うことも珍しくありません。
また,ソースを書いた技術者が力量不足で,無意識に難読化されてしまった
ソースに出会うことは頻繁にあります。
ここの処理はこの書き方ではなくこのように書けば簡単なのに,
わざと難しく書いてプログラムを理解しにくくしてあるな。
このソースを書いたエンジニアは,イベントプロシージャに長々とロジックを
書くと分かりにくくなる,関数を使うべきだということを分かっていない。
そのように見抜くことができるようになります。
■常識は組織ごとに全然違う
学校卒業後に就職した会社にずっと所属して,転社経験のないエンジニアは,
自社のシステムのプログラムは,それがどのようなものであっても当たり前で,
普通のプログラム
と思っているものです。
なぜなら,他社ではどんなプログラムが作られて使われているかを
全然知らないから。
経験の長いフリーランスのエンジニアの視点では非常識なほど難解にして
あっても,そのことを認識できません。
常識というものは,会社によって全然違うのです。
私の経験では,営業職20人が同時に使う受発注システムにおいて,
・要件定義も,画面設計書も,動作設計書も,操作マニュアルもない
・ソースにコメントが書かれていない
・SQL(Oracle9i)が暗号化されているために,処理内容を解明できない部分がある
・排他制御が実装されていない!
という事例がありました。
最後のは難読化ではありませんが,笑い事では済まされない重大な欠陥です。
システム開発を受注したのは大手のシステム会社,実際に開発したのはその孫請け会社。
私がそこに参加したのは,検収が終わり契約金が支払われ,実運用開始された後。
営業会社から大手システム会社に2億3000万の金額が支払われた後でした。
その会社の営業職は,誤ったデータを手作業で修正するため,毎日深夜2時3時まで,
怒声が飛び交う中を残業して,毎月平均一人,病院送りになっていたそうです。
私も,そこでの勤務開始から1ヶ月後には,大声で怒鳴られるようになりました。
2004年頃,中国とタイに営業所があり,東京都中央区神田の「かつや」の近くに本社が
あったその販売会社。
その会社は2020年現在ではもう存在しません。
(終わり) ページの先頭へ
|