• Home
  • 開発などブログ

開発などブログ

feed icon RSS FEED
「C#」 カテゴリーの記事です。

「アタッシェケース#3」を正式版としました。

このエントリーをはてなブックマークに追加

β版リリース時にもブログ記事を書きましたが、バグ報告もなくなり、自身で使っていても、目立った不具合がなくなってきたため、正式版としました。それでも細かいバグはまだまだありそうですので、もし何かあれば報告をいただけるとうれしいです。

アタッシェケース#3アイコンhttps://hibara.org/software/attachecase/

前述の記事でも書きましたが、Ver.2からの変更点のおさらい。

  • ファイルフォーマットの変更（Ver.3独自）
  • パスワードの扱いについての改良（RFC2898によるキー派生）
  • 暗号化、復号の処理速度の向上
  • Windows 10（タッチ操作など）に対応
  • パスワード付きZIPファイルの作成機能（おまけ）

ver.2は、2004年の開発開始からほとんど修正されることのなかったファイルフォーマットに手を入れました。冗長な部分を削除し、やや弱かったパスワード部分の扱いを改良、メモリで扱う部分を大きくし、また高速化（並列処理）に適したフォーマットにしました。

ですので、Ver.3で暗号化されたファイルは、Ver.2では復号できませんので、あらかじめご注意ください。ただし、Ver.2ファイルはVer.3では開けます。つまり上位互換です。

パスワード付きZIPファイルへの対応はおまけです(笑)。知人からの要望を受けて、入れてみました。邪魔で不評なら将来的に削除、好評なら復号処理も入れようかと思います。

技術的な変更点は、

  • .NET Frameworkでの開発
  • コードサイニング証明書の付加

今までC++Builderで開発を行ってきましたが、毎年のバージョンアップ費用がもはや個人ユースとして耐えられなくなってきたのと、無料で使える、Microsoftの「Microsoft Visual Studio Express 2015 for Windows Desktop」にした方が、より多くの人にとって、オープンソースからのプルリクエストや、フォークがしやすいのではないかと思い、乗り換えてみました。

また、暗号化ツールという性質上、セキュリティ面での使用を躊躇してしまうのを少しでも軽減しようと、コードサイニング証明書を付加してみました。法人ではなく僕個人のもので、けっこうなお値段でしたが、少しでも安心して使っていただけるようにと自腹で負担しました(泣)。

より多くの人に使っていただけるのが、開発者としては望外の喜びです。

2016/09/05(月) 07:24 C#, アタッシェケース, プログラミング 8件のコメント
電卓の16進から10進へ

C#で文字列をバイナリサーチする

このエントリーをはてなブックマークに追加

前提として、僕のケースでは、『アタッシェケース#3』にて、ファイル先頭から固定値である「_AttacheCaseData」（16バイト）を検索していきます。それにより、自己実行形式ファイルのデータ境界が分かるようになります。

ウェブを検索してみたら、以下のサイトが近い感じがするのですが、

バイナリデータを検索する方法（vb.net）
http://www.my-hobby.jp/index.php/2012/01/vb-net2/

File.ReadAllBytes()で、一気にファイルをバイト単位での読み込みを行っています。僕のアタッシェケース#3では、出力されるファイルが、2GBを余裕で超えてくるファイルも扱う可能性もあるので、それは使えません。

そこで、File.ReadByte()を使います。知ってましたか、ReadByte();

// _AttacheCaseData
//byte[] AtcTokenByte = { 0x5F, 0x41, 0x74, 0x74, 0x61, 0x63, 0x68, 0x65, 0x43, 0x61, 0x73, 0x65, 0x44, 0x61, 0x74, 0x61};
int[] AtcTokenByte = { 95, 65, 116, 116, 97, 99, 104, 101, 67, 97, 115, 101, 68, 97, 116, 97};

using (FileStream fs = new FileStream(FilePath, FileMode.Open, FileAccess.Read))
{
  bool fToken = false;
  int b;
  while ((b = fs.ReadByte()) > -1)
  {
    //-----------------------------------
    // Check the token "_AttacheCaseData"
    if (b == AtcTokenByte[0])
    {
      fToken = true;
      for ( int i = 1; i < AtcTokenByte.Length; i++)
      {
        if (fs.ReadByte() != AtcTokenByte[i])
        {
          fToken = false;
          break;
        }
      }
      if ( fToken == true)
      {
        _fExecutableType = true;
        break;
      }
    }

  }// end while();

}

ReadByte()は、ストリームから１バイトずつ読み込んで行きます。ただし、返値がバイトではなく、Int32 にキャストされた符号なしバイト（int）で返ってくるのに要注意。

あらかじめ分かっている定数ならば、僕のようにint配列にしますが、場合によっては、byte値をその度にintにキャストして比較しても良いでしょう。

電卓の16進から10進へ

ちなみにbyte値をintにするには、Windowsの電卓を「プログラマ」にして「16進」→数値入力→「10進」にして、値を出しました。16進を10進に脳内変換で出来ちゃうプログラマーさんはすごいと思う（常識デスカ？）。

2016/08/22(月) 07:19 C#, アタッシェケース, プログラミング コメントはまだありません

「アタッシェケース#3」をリリースしました

このエントリーをはてなブックマークに追加

「アタッシェケース#3」のβテスト版をリリースしました。ようするにアタッシェケースの「Version.3」へのメジャーバージョンアップです。

アタッシェケース#3アイコンhttps://hibara.org/software/attachecase/　　　

僕が好んで使っていた統合開発環境「C++Builder」の価格高騰に伴いバージョンアップを諦め、無料で使える、Microsoftの「Microsoft Visual Studio Express 2015 for Windows Desktop」に乗り換えて、開発しました。言語は、C#ですので、ほぼフルスクラッチでの開発でした。

2004/07/25 に『ver.2』がリリースされてから、ここまで少しずつ改良を重ねてきましたが、 それはほとんどが本体側だけで、そこから生成される暗号化データの形式は、互換性を保つため、 ほぼ当時のままの設計で来ていました。

あれから年月が経つにつれて、当時の僕の拙いプログラミングから、パスワードの扱い方にやや弱い部分があることや、 暗号化するバッファの一部がとても小さく、暗号化・復号処理に時間がかかっていたことなどが分かって来ました。

また、データに格納するファイル情報が冗長になり、不要なもの、次第に使われなくなったものが多くなってきました。 そこで今回のメジャーバージョンをキッカケにして、データの仕様も全面的に見直し、再設計を行いました。 その結果、Ver.3 は、Ver.2よりも暗号強度の高いファイルを生成します。

そのため、暗号化ファイルは上位互換です。Ver.3で暗号化したファイルは、ver.2では開くことはできません。ただし、Ver.3では、Ver.2のファイルは開くことができます。

ソースコードは、GPLｖ３ライセンスとして、GitHubにもアップロードされています。ご興味のある方はぜひご覧いただき、フィードバックや改良案などいただけると嬉しいです（ただし、簡単な質問はググってね♥）。

また今回から、Windows 10にも正式対応しました。一応、タッチパネルを意識した作りをしたつもりですが、細かいところではどうでしょうか。タッチパネルを頻繁に使われる方で、この辺りの挙動でご不便なところがあれば、ご意見いただきたいです。

2016/08/14(日) 18:14 C#, アタッシェケース, プログラミング コメントはまだありません

DotNetZipでEncryptionAlgorithm.WinZipAes256が選択できない

このエントリーをはてなブックマークに追加

Visual Studio C#で『アタッシェケース』の新版を開発中です。その中で、パスワードZIPファイルを作成するために、DotNetZipというライブラリを使っています。

DotNetZip-Logo

ところが、以下のコードのように設定しても、コンパイルエラーとなります。

private void Zipup()
{
  if (filesToZip.Count == 0)
  {
    System.Console.WriteLine("Nothing to do.");
    return;
  }

 using (var output= new ZipOutputStream(outputFileName))
 {
   output.Password = "VerySecret!";
   output.Encryption = EncryptionAlgorithm.WinZipAes256;

   foreach (string inputFileName in filesToZip)
   {
     System.Console.WriteLine("file: {0}", inputFileName);

     output.PutNextEntry(inputFileName);
     using (var input = File.Open(inputFileName, FileMode.Open, FileAccess.Read,
                                     FileShare.Read | FileShare.Write ))
     {
       byte[] buffer= new byte[2048];
       int n;
       while ((n= input.Read(buffer,0,buffer.Length)) > 0)
       {
         output.Write(buffer,0,n);
       }
      }
    }
  }

}

Visual Studioのインテリセンスを表示させてみても、
None
PkzipWeak
Unsupported
と、肝心の「AES」が出てきません。おかしいなあ、とDotNetZipのソースを見てみたら、defineで切られているではありませんか。

AESはdefineで切られている

おそらくパスワード付きZIPのAESは、アーカイバによって解凍できなかったりするので、こういう扱いなのでしょうか。実際、DotNetZipヘルプの「EncryptionAlgorithm 列挙体」には、こう書かれていました。

Values of WinZipAes128 and WinZipAes256 are not part of the Zip specification, but rather imply the use of a vendor-specific extension from WinZip. If you want to produce interoperable Zip archives, do not use these values. For example, if you produce a zip archive using WinZipAes256, you will be able to open it in Windows Explorer on Windows XP and Vista, but you will not be able to extract entries; trying this will lead to an “unspecified error”. For this reason, some people have said that a zip archive that uses WinZip’s AES encryption is not actually a zip archive at all. A zip archive produced this way will be readable with the WinZip tool (Version 11 and beyond).

WinZipAes128 値と WinZipAes256 値は zip 仕様に含まれていませんが、WinZip のベンダー固有の拡張を使用することを意味しています。相互運用可能な Zip アーカイブを生成するには、これらの値を使用しないでください。たとえば、WinZipAes256 を使用して zip アーカイブを生成する場合、Windows XP および Vista で Windows Explorer で開くことができますが、エントリーを解凍することはできません。解凍しようとすると、「未定義のエラー」となります。このため、WinZip の AES 暗号化を使用した zip アーカイブは、実際にはまったく zip アーカイブでないと言う人もいます。この方法で生成された zip アーカイブは、WinZip ツール (バージョン 11 以降) で読み込むことができます。

ですので、AESをどうしても使いたい場合は、Visual Studioの「条件付きコンパイルシンボル」に「AESCRYPTO」を追加します。

プロジェクトのプロパティを開く

プロジェクトのプロパティを開いて、

条件付きコンパイルシンボル

追加すると、コンパイルも通り、インテリセンスにも「WinZipAes128」「WinZipAes256」の値が表示されるようになります。

2016/08/07(日) 07:26 C#, アタッシェケース, プログラミング コメントはまだありません

ウェブサイトをリニューアルしました（ノーサポート宣言）

このエントリーをはてなブックマークに追加

 

HiBARA Softwareロゴ

なぜ突然リニューアルを？　ヒマになったから(笑)。

ここ二年余り、サイトの更新はおろか、ソフトウェアの更新さえしておりませんでした・・・既知のバグも放置されている状態で、本当に申し訳ありません。

とはいえ、このサイトは、僕の個人的なサイトで、すべて手弁当でやってます。サーバ費用、運営コスト、ソフトウェアを更新していく労力。それはすべて使っていただている方の感謝があってこその原動力だったわけです。

ところが、最近は「バグ直すの当たり前だろ」や「今の時代、SSL（https）が当たり前なのでは？」といったメール、「日本年金機構がexeを安易に扱っていた。アタッシェケースもexeで出力できるけど対応しないのか！？」といったTwitterなど、もはや関係あるのやら、ないのやら、苦情ばかり。もう勘弁願います！

というわけで、本日より、

「ノーサポート」を宣言します！

メールは原則、返事しません（ヒマなときは返すこともあります）。基本、対応はせず、ユーザーさんには自己解決を望みます。そのためにオープンソースになっているのですから。

ただ、各地方自治体や、企業さんで、組織的に導入されている方々には不安を与えるかもしれません。それらは、サポートを有償で提供するという仕組みを考えています。こちらは別途ご相談いただければと思います。

さて、今後の予定ですが、ざっと行う順番を上げておきます。

  1. 現行の「アタッシェケース」のバグ修正。
  2. 新たに「アタッシェケース」をVisual Studio C#への移植
  3. 「MarkDown#Editor」のバグ修正とバージョンアップ
  4. 「暗号化ツール（ソリューション）」の提供

(2)については、すでに着手していて、暗号・復号までできています。早めにGitHubへ上げていこうかと考えています。

すでに僕は、C++Builderを見限っており、よりフォークやプルリクエストがしやすいように、誰でもが使えるツール上のプロジェクトに移したいという意図があります。

(1,3)はすみません、けっこうバグを残している状態なので、早めに対処して公開します。

(4)は、前の「有償サポート」と絡みますが、商用目的で暗号化モジュールを組み込みたいという方向けに、オープンソースで提供しようという試みを考えています。ファイルフォーマットはアタッシェケース形式ではなく、独自にカスタマイズできるようにしたいと思っています。

基本的にMITライセンスでの配布予定ですが、導入にあたってサポートが必要ならば、有償にて承るということになるでしょうか。

他にも作りたいソフトは山ほどあるのですが、とりあえずは二年ぶりということで、まずは順番に、優先度を決めて、やっていきたいと思います。

では今後ともよろしくお願いいたします。

2015/07/11(土) 16:02 C#, C++Builder, MarkDown#Editor, アタッシェケース, プログラミング コメントはまだありません

« 古い記事

s