NanDoKuの最近のブログ記事

　難読化用の属性に対応するのは前々から考えていたのですが、なかなか実装できませんでした。今回、別の不具合も発見されたのでそのついでに、実装に踏み切りました。検討している段階では、属性の削除など問題になりそうな点も有りましたが、実装してみると意外とすんなり機能するようになりました。これも、基本の設計がいい事にしておきましょう。

　さて、この難読化プログラム「NanDoku」ですが、実は設定ＧＵＩには無い機能が実装されています。アセンブリの設定で保存した「なんとかini」ファイルに
　ExtendOverload=True
と、追加すると、さらに強烈な同一名称の使用を行なうようになります。
大体、第１位置候補の文字使用率が１０％ほど上がります。
難読化自体に魅入られた方は一度試してみてください。
当プロジェクトのプログラムはこの設定で全て難読化しているので、それなりにの実績もあります。

なぜ、効率が上がるのかと、非公開なのかはまた機会があれば．．．

　久しぶりに真面目なプログラム修正です。最近すっかり自家製プログラムが手薄になっているので、そろそろ検討事項に並んでいるのに、手をつけていきたいと思っています。
　.Net 2.0 で追加された難読化関連の属性は全く気付いていませんでしたね。Webでいろいろ調べてみたところ、何とか対応できそうなので、技術的好奇心からその内実装されると思います。マイクロソフトも.そろそろ次の開発環境を匂わせているので、リリースされたらまたILコードと格闘する日がくるのだろうなぁ。この手のプログラムは終了が無いのが辛いところだ

　ImageGeterのリファクタリングを行なっていて、なんとなく難読化処理を行なってみたら、実行時にエラーが発生するでは有りませんか。「またもやNanDoKuにバグ発生か？怪しげな記述をしたかなぁ」などと考えながら、原因追求をしていくと
System.Windows.Forms.Application.SetCompatibleTextRenderingDefault(false);
という、C# 2005ではお決まりの記述でエラーが発生していることが分かりました？

なぜ？

しかも、このエラーDebugビルドで発生して、Releaseビルドでは発生しない？

なぜ？

さらに原因追求していくと、アセンブリの逆コンパイル→コンパイルのみで発生する
NanDoKuは関係ないようだし

迷宮入りか？

　難読化に関しての不具合は出尽くしていると思っていいましたが、まだバグが潜んでいました。イテレータのインナークラスの命名が想像を絶する奇怪さのため思ったより時間がかかり、年を超えちゃいましたね。

　最近何だかこのソフトの需要が増えているのですが、これは難読化が認知されてきたのか、.NETのプログラマーが増えたのかどちらなんでしょうかね

　難読化ツールの「NanDoKu」の雑誌掲載依頼を頂きました。
　今まで、ＰＣ情報系の雑誌での掲載はよくありましたが、ＰＣ開発系では初めてなので、ちょっとうれしいです。ただ、月刊DBマガジン自体は良く知っているのですが、難読化ツールがデータベース関連誌に紹介されるのは「？」です。