The Man Who Fell From The Wrong Side Of The Sky:2019年4月分

2019/4/1(Mon)

[オレオレN6] 新元号

本家のNなんとかBSDには関係のない話だけど、オレオレN6にはLC_TIMEのeraフィールドが一応は実装されてるので 対応した

つーかbitbucketのWebUI、ISO-2022/CTEXTなファイルの差分が0に誤判定されとるなと思ったら、git diff自体がバイナリ判定するんだな。

strftime(3)とstrptime(3)のera(%E)とalt_digit(%O)対応のコードほとんど完成してたはずなんだけど、ThinkPad X220のSSDが突然死したせいで作業中のやつ消えてバックアップどこにあるか探してねえんだよな。つーかプログラム書こうとするとPTSDで吐き気がしてくるからしゃーない、悪い やっぱつ令和。

何度も書くけれども役所も西暦にすれば大丈夫と主張する人は、明日にでもジーザスがサードカミングして改元を命じたり、デーモンが人間界を支配して西暦の廃止をするというリスク回避のできないやつなのだ。突然地球の公転時間が変わることくらい想定して実装しろよ。

そもそも未だ太陰暦使ってる国もあるのにUNIX他は対応してなくてクソとも主張してたが、2016年にサウジもヒジュラ暦廃してグレゴリオ暦に世俗化してあれが最後だったんだろうか。イラン暦はヒジュラ紀元だけど太陽暦なのでeraで吸収できるんだけどね。

2019/4/7(Sun)

[写真] 多重露光したフィルムの像分離ってできないんですかね

手巻きの古いカメラで撮影したフィルムは巻き上げ時のスリップ等の原因でコマ被りが発生するので、巻き上げがつっかかってもそこでストップせずなお撮影を続けてしまう意地汚い人は2コマ損をしてしまうのだ。まあワイのような育ちの悪い人間なんですけどね。

そんな理由でコマ被りしたフィルムをスキャナーでデジタル化する時、人間の脳ではこの多重露光してしまった像を分離することはたやすいのに、なんで画像処理ソフトではそれができないのかと思っちゃうんですよな。

あとカビがエマルジョンを浸食して色素変色した部分とかもなんだけど。Digital ROCみたいな補正技術は紫外線なんかでフィルムの全面が緩やかに退色したやつにしか有効じゃないからな。

というかあまりこの分野研究してる人いないような気がするんだよな、検索しても多重露光関連はHDRみたいな合成ばかりで、分離についての論文とか出てこないんだよね、Kodakが会社更生法下におかれなかった並行世界ならこの15年で研究進んでいたのかもしれない。

今更こんな応用の利かなそうなニッチな技術でかつ心理学的要素の大きいものを研究しても一銭にもならなそうだし一生お目にかかることはなさそうだ。 まぁそれだけ人間の脳ってすげーなーという話なんですが、AIとかいかに虚飾かってことやね。

2019/4/9(Tue)

[Hardware] 2019年にもなってParallel SCSI機器が増えるという地獄

先日 Minolta DiMAGE Scan Multi F-3000を買ったことでParallel SCSI HBA増設したマシンが必要になってしまった。

以前 今時のマシンで Parallel SCSI 機器を使うという記事で、今なら Adaptec ASC-29320LPEが鉄板でHBAだけなら津田梅子そしてケーブル込みでも渋沢栄一でお釣りがくるという記事を書いたけど、こっちはすでに家族用のマシンに刺さってて Nikon COOLSCAN III(LS-30)が繋がってるので抜くわけにもいかない。

そんでもう一枚買うかなぁと思ったんだが、この記事から3年も経ち当時より中古のタマ数がめっきり少なくなって値上がり傾向なのだ、よって貧乏人にはつらい。

ただ自分用のマシンはスモールファクターでない自作機で、貧乏人ゆえに未だPCIスロットが存在するマザボ使ってる強みがあるので、ジャンク箱の中にあった懐かしの AHA-2940刺して動かすことにした。

ただWindows 7のEOLも近づいてきてWindows 10への移行も視野に入れるとAHA-2940ってPCIスロット抜きにしてももはや鉄板じゃないのよね。

このHBAは64bit化のあおりでWindows Vistaの時点でIn-box driverからも削除されており、Microsemiが配布するWindows 7 32bit用ドライバを別途入れる必要がある(64bitで使うには更に.infの書換も必要)。 そしてこれが困ったことに未署名ドライバなのでWindows 7なら警告無視するだけでいいけどWindows 10相手だと非常にめんどくさいのだ。 ドライバ署名の強制を無効化にしたところで大型アップデート降ってくるたびに環境ぶっ壊されるからね…

ということで20年休まずにチクタクしてくれたAHA-2940も残念ながら窓から投げ捨てろリスト入りですな、おじいさんと一緒に100年くらい動いて欲しかったんだけどね。

ジャンク箱にはもう一枚 ASC-29160も転がっててこいつは署名付きの64bitドライバー存在するんだけど、SCSI BIOS上でテストすると問題ないにも関わらずドライバの初期化に失敗する、多分マザーボードとの相性だと思うんだけど…

つーわけでどっかジャンク屋に寄る機会があった時に IO-DATA SC-UPCILogitec LHA-521の中古が100円くらいで転がってたら欲しいのよね、これも古いカードでドライバ配布はWindows XPまでなんだけれどチップがSYMBIOS 53C875、よってWindows Vistaの頃までIn-box driverとして署名付きの64bit OS対応ドライバーがちゃんと存在したのだ。

検索するとVistaと同世代のWindows Server 2008 R2のIn-box driverからブッコ抜いたの再配布してる人もいるようだけど、さすがにこれライセンス違反よね。

まぁワイはNT4からアップグレードライセンス買い続けてるので自分のインストールメディアからブッコ抜くからセーフ、なんならVistaインスコして認識させたのちに→7→10とアップデートすりゃ誰も文句はつけられないのである。

ちなみにSYMBIOS 53C815チップ採用の IO-DATA SC-PCIはこのドライバでは 動かなかったので注意、NT4用のドライバは同じsymc8xx.sysだったから.inf書き換えれば動かすくらいはと思ったけど 「ドライバーはこのプラットフォーム用ではありません」エラーでダメだった。

(追記) 動いた、次のエントリで。

[Hardware] IO-DATA SC-PCI(SYMBIOS 53C815)をWindows 7やWindows 10で使う(32/64bit両対応)

前の記事でSYMBIOS 53C815チップ採用の IO-DATA SC-PCIはVista/Server 2008のドライバでも動かないと書いちゃったんだけど、エラーメッセージで気づくべきだったんだけど32bit OSに64bitのmini port driverインストールしようとしてサービスが起動できなかっただけだった、かなり恥ずかしいミス。

つーことで簡単に手順を、まずはWindows VistaあるいはWindows Server 2008をインストールする、あるいは DISMコマンドを使ってインストールDVDの中のイメージアーカイブ(install.wim)をマウントし

%SYSTEMROOT%\System32\DriverStore\FileRepository\symc8xx.inf_cea423c2

以下にあるsymc8xx.infとsymc8xx.sysをWindows 7/10の適当な場所にコピーする、symc8xx.infはx86/amd64共通だけどsymc8xx.sysはアーキテクチャ毎に異なるバイナリファイルなので注意。

そんで.infの書換自体は非常にかんたん、UTF-16LEの編集ができるエディタで以下のとおり53C815の情報を足すだけ。

$ diff -u symc8xx.inf.orig symc8xx.inf
--- symc8xx.inf.orig    2019-04-09 20:15:09.028356100 +0900
+++ symc8xx.inf 2019-04-09 20:15:18.213881500 +0900
@@ -32,21 +32,25 @@
 [LSI]

 [LSI.NTx86]
+%DevDesc3% = SYMC8XX_Inst, PCI\VEN_1000&DEV_0004
 %DevDesc5% = SYMC8XX_Inst, PCI\VEN_1000&DEV_0006
 %DevDesc6% = SYMC8XX_Inst, PCI\VEN_1000&DEV_000C
 %DevDesc8% = SYMC8XX_Inst, PCI\VEN_1000&DEV_000F

 [LSI.NTia64]
+%DevDesc3% = SYMC8XX_Inst, PCI\VEN_1000&DEV_0004
 %DevDesc5% = SYMC8XX_Inst, PCI\VEN_1000&DEV_0006
 %DevDesc6% = SYMC8XX_Inst, PCI\VEN_1000&DEV_000C
 %DevDesc8% = SYMC8XX_Inst, PCI\VEN_1000&DEV_000F

 [LSI.NTamd64]
+%DevDesc3% = SYMC8XX_Inst, PCI\VEN_1000&DEV_0004
 %DevDesc5% = SYMC8XX_Inst, PCI\VEN_1000&DEV_0006
 %DevDesc6% = SYMC8XX_Inst, PCI\VEN_1000&DEV_000C
 %DevDesc8% = SYMC8XX_Inst, PCI\VEN_1000&DEV_000F

 [Control Flags]
+ExcludeFromSelect = PCI\VEN_1000&DEV_0004
 ExcludeFromSelect = PCI\VEN_1000&DEV_0006
 ExcludeFromSelect = PCI\VEN_1000&DEV_000C
 ExcludeFromSelect = PCI\VEN_1000&DEV_000F
@@ -98,6 +102,7 @@
 [Strings]
 ; localizable
 LSI = "LSI Logic"
+DevDesc3 = "LSI Logic 815XS PCI SCSI Adapter; 53C815 Device"
 DevDesc5 = "LSI Logic 8600SP PCI SCSI Adapter; 53C860 Device"
 DevDesc6 = "LSI Logic 8951U, 8952U PCI SCSI Adapter; 53C895 Device"
 DevDesc8 = "LSI Logic 875XS|D, 2280X PCI SCSI Adapter; 53C875, 53C876 Device"

あとはデバイスマネージャーを開いて「不明なデバイス」を選択してドライバーの更新を実行してこいつらを指定すればWindows 7でもSC-PCIが使えるようになる。 いちおう手元ではMinolta DiMAGE Scan Multiがガシガシ動いてるので他のデバイスでも問題ないと思う。

Windows 10の場合は残念ながら.infを書き換えてしまったことで署名とハッシュが一致しなくなるので、ドライバ署名の強制を無効にしたりテストモードで起動する必要がある。 なので基本的にはAHA-2940と同様に窓から投げ捨てろリストですやね。

Windows 10環境で署名なしドライバのメンテナンスという無駄な努力をしたくない人は.inf書換の不要なコントローラー乗った製品を探すことっすね。 ちなみにsym8xx.infを読むとコントローラーが53C860, 53C895, 53C875, 53C876搭載ならそのまま動くようなので

あたりの製品を探すんですかね、まぁでも過去記事書いたように予算不足とかでない限りAdaptec ASC-29320LPE買うのが一番だと思う。

2019/4/10(Wed)

[Hardware] 続・IO-DATA SC-PCI(SYMBIOS 53C815)をWindows 7やWindows 10で使う(32/64bit両対応)

昨日の記事でVista/Server 2008付属のsymc8xxドライバでLSI Logic 53C815チップ採用のIO-DATA SC-PCIも動いたよと書いたけど、そもそもなんでinfから消されたかの謎を調査すべくNなんとかBSDでのドライバサポート状況を調べてみたら

と2種類あって、後者からはWindowsと同様に810/810A,815(Fast SCSI),820(Fast-Wide SCSI),860(Ultra SCSI)のサポートがドロップされてるのよね。 つーことで何らかのハード的な制限があってのことだろうから正常動作しないケースもありそう。 自分のとこではフィルムスキャナが問題なく動いてはいるんだけど、MOとかSCSI HDDとかだとダメなのかもしれない、ご注意あれ。

それと窓から投げ捨てろリスト入りしたAHA-2940について追加情報、aic78xxドライバは公式には32bitしか存在しないんだがVista/Server 2008にはdjsvsドライバというのが含まれていて

[Strings]
INF_PROVIDER="Microsoft"
ADP="Adaptec"
FLOPPY_DESCRIPTION="ADAPTEC SCSI Adapters - Microsoft Disk"
PCI\VEN_9004&DEV_7078&SUBSYS_70781414.DeviceDesc = "Adaptec AIC-7870 PCI SCSI Controller (Emulated)"

と名前は違ってるけれどもaic78xx用のドライバなので、inf書換えればAHA-2940も64bit OSでも動かせるという叡智を授かった。 ただデバイス名にわざわざ「Emulated」と サイクロップス先輩の声で脳内再生されるような文言が入ってるので、100%確実かどうかはわからんけど。

ということで残るは署名なしドライバ問題どうするかやな、以前は自己署名でもOKだったと聞いてたんだがAnniversary Update以降はそれも封じられたようだし。 ただinf書換だけならdism /add-driverでオフラインインストールしてしまえばカーネルモードドライバ自体は元の署名が残ってるから動作するかもしれないのでそのうち試してみる。

つかSCSIカード刺してるマザボはUEFIじゃないし、そうだったとしてもSCSI BIOSの為にCSM有効にするだろうからセキュアブートもクソもないのでいいのかな。

2019/4/11(Thu)

[Windows] 2019年4月の月例ロールアップ(KB4493472)を適用するとネットワークレベル認証でのRDP接続でエラーが発生する

あーもうめんどくせえ。

ちょうど1年前くらいの CVE-2018-0886 CredSSPの脆弱性によるリモートコード実行対策の時も接続先にパッチが適用されてないと繋がらないトラブル起きたけど、それとは別だと思う。どちらもKB4493472適用した状態で繋がらんようなったのでな。

それ以前にもRDPのバージョンが8.1になった時に互換性問題あったし、いい加減RDP捨てたいよね。

かといってX-WindowとかVNCは勘弁なので、なんかいいソリューション無いですかね追加投資無しで。

[Windows] 続・KB4493472

前記事のトラブルはKB4493472を適用後のWindows Server 2008 R2に接続しようとしたら発生したんだけど Windows Server 2012で起きてるこの現象と似てて、RDPで接続しようとするとイベントID 36870が大量に出てくるかんじ。 ただしイベントID 1057の方は一切出ていないので全く同じではない模様。

それ以前の問題としてRDPに繋がらないだけでなく

%ALLUSERSPROFILE%\Microsoft\Windows\Start Menu

以下がほとんどすっからかんになってて、コンパネからの管理者ツールの起動やら何やら全滅してしまって操作できねえのなクソが。 多分他にもいろいろシステムファイル消失してるような気がするぞこれ。

困ったことにシステムドライブに復元ポイント設定し忘れてたので再インストールですわこれ…自宅のファイルサーバ1台だけだからいいけど仕事で何台もあったらレッドモンドに事実上の弾道ミッソル全弾撃ち込んでるところですわ。

他のところだとセキュリティソフトでSophos入ってると起動できなくなるとか、地獄の門番頭三つ犬の問題でSQLServerなんかの認証がコケるとかの報告があるようだし、品質管理できてへんやんけーッ!!基本的なことがーーーー!!(画像略)

2019/4/12(Fri)

[Cygwin][i18n] mintty

ちょっと前(オッサン基準)にCygwinの標準ターミナルがminttyに変わったのだけど、この2019年にもなってWAVE DASH問題があって非常に使いづらい。 まーそもそもこの2019年に未だLANG=ja_JP.eucJP設定するような老人はさっさとソイレントグリーンに加工しちまえば解決するんですけどね…

要はShift_JIS(932)→UTF-8の変換で0x8160がU+301CでなくU+FF5Eに変換されてしまうので、UTF-8→EUC-JP(20932)に変換する時に0xA1C1にならず「対応する文字なし」になってしまうので文字自体が入力できないのだ。 結局のとこShift_JISからEUC-JPに変換する時に計算でなくいちいちUnicodeテーブル引く弊害なんだけどね、でもUnicodeの変換表はわきにおいといても規格上はShift_JISとEUC-JPの変換って厳密には0x5Cや0x7Eに互換性無いしな…

つーことで修正方法だけど、WAVE DASHが入力できさえすればいいならEUC-JPを20932でなく51932のエイリアスに変更するかなんやな。

$ diff -u src/charset.c.orig src/charset.c
--- src/charset.c.orig  2019-03-29 03:10:54.000000000 +0900
+++ src/charset.c       2019-04-12 00:22:27.172196600 +0900
@@ -54,8 +54,8 @@
   {   20866, "KOI8"},
   {   21866, "KOI8-U"},
   {   21866, "KOI8U"},
-  {   20932, "eucJP"},
-  {   20932, "EUC-JP"},
+  {   51932, "eucJP"},
+  {   51932, "EUC-JP"},
   {     874, "CP874"},
   {     874, "TIS620"},
   {     874, "TIS-620"},

これだと半角カナ(JIS X0201)と補助漢字(JIS X0212)とか入力できなくなるけど、ぶっちゃけja_JP.eucJPを未だに使ってる老人じゃあ困らなそうだし(自己紹介)。

もうちょいマシな方法を考えるなら出力が20932の時は入力を932ではなく943とみなしてCP_{A,OEM}CPを上書きするかだな、修正方法クッソ汚くなるけど。

コツコツとi18n周りを対応してた開発者はもっと表舞台に行ったか壊れたかでとうの昔に絶滅してしまったので、15年前には根絶されたような国際化トラブルがまたぞろ蔓延るようになって、まるで伝染病とか寄生虫の根絶みたいな話やなという気分になっている。 WikiPediaの日本住血吸虫根絶の歴史みたいにちゃんと記録を残す人すらいないだろうから、歴史修正主義でUTF-8以外は無かったことにするしかないのだ。 というか今の若い子ってi18nとかl10nとかの言葉知っているのだろうか…

文字コードはおいといても「言語」と「地域」の区別のできない開発者ばかりになってしまったので、iPhoneやらAndroidの言語設定を英語にしてるとAmazon Cloud Driveアプリなんかがamazon.co.jpでなくamazon.comにログインしようとしてそんなユーザー居ねえ!になったりするよねという話を前に書いたけど、 Microsoftアカウントにも伝染しているようで新規アカウント作成時に「outlook.jp」が選択肢に出てこなくなるのよな。

[Cygwin][I18N] 続・mintty

前の記事、単純にs/20932/51932/gしても動かんので?と思って再度コード読んだけど、Cygwin側でもstrfuncs.ccでEUC-JPの代替として20932使ってたりするので、-DHAS_LOCALESの場合はそっちで壊れるのな。

extern "C" int
__eucjp_wctomb (struct _reent *r, char *s, wchar_t wchar, mbstate_t *state)
{
  /* Unfortunately, the Windows eucJP codepage 20932 is not really 100%
     compatible to eucJP.  It's a cute approximation which makes it a
     doublebyte codepage.
     The JIS-X-0212 three byte codes (0x8f,0xa1-0xfe,0xa1-0xfe) are folded
     into two byte codes as follows: The 0x8f is stripped, the next byte is
     taken as is, the third byte is mapped into the lower 7-bit area by
     masking it with 0x7f.  So, for instance, the eucJP code 0x8f,0xdd,0xf8
     becomes 0xdd,0x78 in CP 20932.

     To be really eucJP compatible, we have to map the JIS-X-0212 characters
     between CP 20932 and eucJP ourselves. */
  if (s == NULL)
    return 0;

  if (wchar < 0x80)
    {
      *s = (char) wchar;
      return 1;
    }

  BOOL def_used = false;
  int ret = WideCharToMultiByte (20932, WC_NO_BEST_FIT_CHARS, &wchar, 1, s,
                                 3, NULL, &def_used);

以前はCygwinのmbrtowcってnewlibの実装使ってCSIだったんだが、しばらく前にMultiByteToWideCharのラッパーに変わったなんてすっかり忘れてたわ、よってWC_NO_BEST_FIT_CHARSの呪いによって~は?に化けてしまう。

まぁminttyからsshしてLANG=ja_JP.eucJPするのをやめてTeraTermでもputtyでも使えばいいだけなんだけどさ。

[Cygwin][I18N] 続々・mintty

だいぶワイまで認知が怪しくなってきているので、MultiByteToWideCharではコードページ51932は使えず、Mlang.dllのConvertINetMultiByteToUnicodeの方で変換する必要があるのを失念していた。つーことで単純にs/20932/51932/gしてもcharset.cの

// Check whether a codepage is installed.
static bool
valid_codepage(uint cp)
{
  CPINFO cpi;
  return GetCPInfo(cp, &cpi);
}

というコードでinvalid判定されてしまうって問題もあるやね、ということで修正は一筋縄ではいかないっぽい。

このcharset.cまわり全面的に書き直すくらいなら、時間超越能力を獲得しあのクソ忌々しい変換表いやウンコードそのものを歴史から消し去るために頭蓋骨をトレパネーションして第三の目チャクラを開いて第六感を(ここで文章は途絶えていた)

2019/4/13(Sat)

[Hardware] NCR/Symbios Logic/LSI Logic製SCSIカードをWindows 10で使う

先日の記事の続き、もうちょい調べたらドイツの Dawicontrol GmHがなんと現行でLSI Logic 53C875搭載のUltra Wide SCSI PCIカードを販売してる上に、既発のカードも未だサポート続けててWindows 10用のドライバもしっかり 提供されているのね。

多分モノ自体はLSI Logic提供のドライバなんだろうけど、ちゃんと自社でMicrosoft Windows Hardware Compatibility Publisherの署名をSHA256で貰ってるのがえらい。 わざわざ HLK通したってことなのでそれなりに時間も費用かかるしわざわざこんな旧式のハードにどこもやらんからな。 つーか電源管理周りとかこんな時代錯誤ハードでよく通過したよな…

Vistaから抜いたドライバだと署名がSHA1なので、現在MSはSHA256への移行を勧告してるのでまだアナウンスは無いけど将来的にブロックされる可能性があるのでな。 それに.infにセキュリティカタログ(.cat)による署名が無いのでドライバインストールの時に回避策はどっちみち必要だったのだ。 こっちのドライバにはちゃんと付属するので安心、なんか大型アップデートの度に勝手にアンインストールされるって話をきくので(未検証)。

ただinfには自社で採用してるチップだけしかデバイスID載せてないので、それ以外を採用してるカードで使うにはinf書換えないと自動でドライバインストールできないのが残念。 まぁinf書換えずともドライバインストール時に「互換性のあるハードウェアを表示」チェックを外して手動でインストールすればいいのだが。

あとドライバ流用が合法かどうかについては使用許諾の類が一切無いのでグレーということで。

ということでWindows 10時代でもPCIスロットがマザボにあればSCSIカードの選択肢はそこそこあるね、64bitドライバのないaic78u2(AHA-2940U2Wなど)とかWorkbit Ninja SCSI-3採用のカードはいかんともし難いが。

(追記) IO-DATA SC-PCIで手動インストール試してみたけど「このデバイスを開始できません(コード10)」で動かないね。 もしかしてチェック入ってるのかなこれ。

[Hardware] 64bit ASPIドライバ

世の害悪こと教えて掲示板のたぐいで探している人を時々みかけるのだが、そもそもいまどきSPTI/SPTDでなくASPIが必要なアプリケーションが存在するんですかね、その時代のアプリだと互換モードでも動くのかも怪しいし素直に代替アプリ探した方がいいと思うのだけど。

ちなみにワイの知ってる限りではAdaptec製品用であればXP Professional x64 Edition/Server 2003用のASPIドライバを出していた、 ASPIドライバ4.71.2に含まれてる。 最新は4.72があったはずなんだが黒歴史なのか公式のリンク無くなってる、ただどっちもaspi64.sysとwinaspi64.dllは同じものみたいなので忘れてよいはず。

もちろんXP用なので正常に動作するからわからんし、aspi64.sysはカーネルモードドライバだけど未署名なのでVista以降の64bitでは動かすのにテストモードとか署名の強制無効化などの手間が必要、ワイも検証する気はありません。 つーかaspi64.sysって他社カードかどうかのチェック用の為だけに存在してませんかねこれ(邪悪)。

ということで、どうしても64bit ASPIドライバが必要なとても謎い環境をお持ちの方はRATOC社製のSCSIカードを入手し Windows 10対応の有償ドライバを購入すれば、それにwinaspi64.dllが含まれてるようなので金の力(つよい)で解決すればいいと思う。

2019/4/14(Sun)

[Windows] Windows 10でのマルチメディアカードリーダーの挙動が変

家族マシンやらのWindows 10移行計画に各種ハードウェアの動作検証やってるんだけど、今日起きたトラブルはこれ。

先日USB接続のマルチメディアカードリーダー( iBuffalo BSCR15TU3)のメモリースティックスロットが接触不良になったので、新しいの( 同 BSCR05TU2)を買ったばかりなんですな *1メモステを捨てるべきな気もするがPRO-HG DUOとかもったいなしあとデュアルスロットでない機種(SONY DSC-WX1)も残ってるのだ。

ところがこいつWindows 10だとメディアの「取り外し」を実行すると刺してるメディアカードだけでなくリーダーごと取り外されてしまうので USBケーブル引っこ抜いて再度刺し直すか、デバイスマネージャーでハードウェアの再スキャンしないと認識しなくなってしまうのだ。

メーカーのページみても対応OSにWindows 8.1までしか無いのはそういうことか…しれっと在庫のみになってやがる。 というかマルチメディアカードリーダーでWindows 10対応製品が存在しないやんけ!

他のメーカーにはWindows 10対応を称する製品あるけどたぶんこれ同じ問題あるけど無視してるだけじゃねえかな。

アクセスランプ消えたらブチッとカード抜くでもいいけど、Windows10ではUSBメモリやSDカードへの書き込みが「高パフォーマンス」つまり遅延書き込みが既定になったはずなので *2、ファイル壊れる可能性が高まってるのでサポートコストで俺まで壊れてしまう。

正常に動いてたWindows 7と比較してみたんだけど、元はリムーバブルドライブとして表示されてたんだがWindows 10ではUSBドライブに変わってるのよね。 どっかで選択可能なのかと思ったのだけど、Windows 7にUSBメモリ刺してもリムーバブルドライブ表示だし、単なるリネームで挙動そのものが変わったって事ですかねこれ。

ということでもう一発レッドモンドに事実上の弾道ミサイル撃ち込んでやりたくなるのだが、なんか対策あるんかなこれ… 検索しても別件のUSB接続が安定せず切断を繰り返すバグや、にデバイスマネージャーでハードウェアの再スキャンしろというアホな対策しかヒットしないですわ。

*1:ずいぶんスペック下がったね?って感のいい子は嫌いだよ懐事情だ察しろ。
*2:なお1809では「クイック削除」つまり同期書き込みに戻されたもよう。

2019/4/15(Mon)

[Windows] Windows 10 64bitに未署名ドライバをインストール

前回の続き、VistaのIn-boxドライバから引っこ抜いた古いSCSIドライバ

がWindows 10 32/64bitともに自分の使う範囲では問題なく動くのを確認したので、SCSI機器の為だけに別個にオフラインでサポート切れOSを動かすみたいな運用はせずにすみそうやな。

ちなみにVistaのIn-boxドライバにはinfファイルに対する署名が含まれるセキュリティカタログ(.cat)が無いので、OSインストール後にドライバ適用しようとするとブロックされてしまう(component.manというXML署名はあるんだがこれは使えないようだ)。 どっちみちデバイスIDを追加するのにINF大幅に書換えてるのであってもなくても同じだけどね、対策方法は後述。

カーネルモードドライバはWindows 64bitの場合は署名が必須だけどこれはbinary blobにあればよく、infファイルが未署名でもインストールに一度成功してしまえば問題なさそう。つまり

というチェック条件みたい。

セキュアブートが有効だとMicrosoftのWHQL署名以外も蹴られるそうだけど、VistaのIn-boxドライバはSHA1形式ではあるけどMSによる署名があるのでブロックされることはないはず、ちょっと今UEFIなマシンは別件に使ってるので試験できんすまんな。 あとはSHA1もブロックされてSHA256のみになる可能性だけど、それまで生きてないと思うからええわ。

あとは大型アップデート時に勝手にアンインストールされることがあるとのことなので、そこの検証が必要なんやな。 あれアップグレードインストールと同等だからな…もしめんどくさいことになりそうならさすがに32bitに逃げる。

そんで未署名ドライバがブロックされる問題の対策として世の中では

するというクッソめんどくさい手順が必要で、binary blobに署名のないドライバを動かす場合は避けようがないのだけど、infの署名検証回避だけならもっと簡単に一回の再起動で済ませる方法ある。

これWindows PEから起動してオフラインで DISM /Add-Driverコマンド叩いてインストールしてしまえば何度も再起動繰り返す必要ないんだよな。

つまりinfの署名検証タイミングはDriverStoreにインストールするタイミングだけで、オフラインで統合してしまえばPlug & Playでデバイスが見つかった時には検証されないということ。

なんならインストールイメージにドライバ統合してしまってもいい、これも

ってするだけ、よくわからないなら NTLiteあたりのGUIお助けツールもあるからね。

2019/4/16(Tue)

[Windows] Windows 8以降のExplorerにあるいわゆるCtrl-Z問題

自宅システムをWindows 10に移行する上で最大のブロッカー要素ってこれなんよな。

いにしえよりExplorerには

というショートカットがあるのだけど、Windows 8以降は挙動が変わってあちこちで文句でてるのはたいへんに有名な話。

まず第一にExplorerで右クリックから「新規作成」で「新しいテキスト ドキュメント.txt」を作成し編集するユースケース、この時にCtrl-Zを押すと「新規作成」がUndoされてしまい編集したファイルが警告も無く消失してしまう *1(ゴミ箱には残らない)。

これWindows 7以前では「新規作成」はUndoの対象外だったので、Ctrl-Z押してもUndoされるのはそれより前にExplorerで行った作業だったのでファイルが消失することはなかったのよね。

そして第二に「新しいテキスト ドキュメント.txt」をExplorer上で「コピー/Ctrl-C」「貼り付け/Ctrl-V」で「新しいテキスト ドキュメント - コピー.txt」という複製を作成し編集するユースケース。 この時にもCtrl-Zを押すと「貼り付け」が取り消されるので複製は存在しなかった扱いで忽然とファイルが消える(当然こちらもゴミ箱にも残らない)。

こっちの場合はWindows 7以前だとCtrl-Zを押したタイミングで「このファイルを完全に削除しますか?」という警告が出た

ところが今のWindowsチームは純度の高いハピ粉でもキメ過ぎたのかこの警告を廃止してしまったようだ。

そもそもWindows 8以降では「削除/Delete」の場合の挙動も変わっていて、Windows 7以前では確認ダイアログが出たところがそのまま確認なしにゴミ箱直行となる、まぁゴミ箱漁ればいいだけなのでまだ罪は浅いけどね。 それにこれはゴミ箱のプロパティで「削除の確認メッセージを表示する」にチェックを入れればWindows 7以前と同じ挙動に設定にもできるからな。

しかしCtrl-Z問題にはWindows 7以前と同じ挙動にするための設定項目というのは存在しないのがほんと頭おかしい。

つーことで操作ミスでCtrl-Z押すと知らないうちにどこかでファイルが消えてしまう使えるかこんなクソOSという状態だったのだけど、Windows 8なんぞ誰も使ってないのであまり騒がれることも無かったのよね。 そんでWindows 7のEOLもみえてきたWindows 10のプレビューリリースの頃から注目というか 炎上しはじめたのだけど、MSも元の挙動に戻すみたいなアナウンスしてたので楽観論もあったのだが1809になった今でも直ってない。

まだ新規作成したファイルが0バイトの空っぽとかペーストしたファイルがコピー元と同一の間なら別にUndoされてもいいけど、それなら編集の開始した時点でUndo対象から外せってんだよな。 ファイルがいつまでもUndo操作キューにたまっててCtrl-Zを押すと警告も無く消えるとは思わねえよ以下罵詈雑言。

いまだにこのバグ(仕様じゃねぇよこんなの)開発者のお偉いさんにUndoとはUndoだからUndoであってこれが正しいンダーと主張してるお医者様とお薬が必要なタイプがおるんかもしれない。

ちなみに対策だけれどキーイベントを奪ってCtrl-ZとCtrl-Yを完全に無効化する常駐アプリ的なもの書くのはさして手間ではないしそれこそ AutoHotKeyあたり使えばいいんだろうけど、マウス操作をミスってファイルがどっか吹っ飛んだ時にCtrl-Zは便利なのよね。 なのでできればWindows 10以前と同じ動作にしたいんだが、操作履歴はExplorerしか知らんから難しいよな。

こんなんもうWindows 8リリースの2012年からの問題だし誰か対策考えてるやろと検索したけど、Ctrl-Zで消失したファイルはバックアップソフトで救出!みたいなクソ広告しか出てきやがらねえ。

まぁワイ自身はさすがに自衛できるし家族マシンについてはそもそも低PCスキルだからCtrl-ZつかってUndoしてるとはとても思えないので対策考えるだけ無駄かもしれない。 キーロガー的なもの入れてCtrl-Zがどれくらい使われてるか統計とるのがいいんですかねこれ。

*1:「新しいテキスト ドキュメント.txt」という名前を最初にリネームしてから編集開始してればCtrl-Zは「ファイル名の変更」のUndoになるので消えることは無いから気づきにくいんだけどね。

2019/4/17(Wed)

[写真] Minolta DiMAGE A1/Konika Minolta DiMAGE A2のPCコントロールはWindows 10 64bitでも使えるか?

デジカメは古くなればただのゴミというけど、 Minolta DiMAGE A1/ Konika Minolta DiMAGE A2は未だに使ってて楽しいカメラだね

まあ時代遅れの製品なので

と悪い所を上げるときりがないんだけど

とやっぱりカメラってのは操作性が命よね、いまどきのゴミラーレスの開発者を地獄の火の中に投げ込む者でありなんでも階層メニューと十字キーのクソカメラは腹を切って死ぬべきである。

このオールドデジカメをWindows 10 64bitと接続するには、USBケーブルが D-AVという今となっては入手しづらい形状(ジャンク屋の悪臭あふれるケーブルの入った箱と格闘すれば1本くらいはみつかる)なのが問題なくらいで、普通にマスストレージ(A2はPTPも可能)として接続できるので写真の取込に使うだけなら困ることはないだろう。

しかしこの機種にはそれ以外にも「PCコントロール」というモードがある。 これはDiMAGE Captureというソフトを使ってこのカメラをリモート制御するためのもので、専用ドライバが必要なのだがこいつのインストーラーはXP 32bitまでしか対応していない。

そもそもDiMAGE Captureは有償ソフトでとっくの昔に販売終了しており今さら入手すんのも難しいのだけど、開発用SDKが提供されていたこともあって

というフリーのよくできたオルタナティブが存在するのよね(後者はSDK使わずにプロトコル解析してLinuxとかで動かす気だったっぽい)、よって世界で3人くらいはWindows 10 64bitで動かしたい人はいるだろう。

ドライバ(DiMAGE Controlの作者がSDKの条件に従って再配布してるもの)をとりあえずバラしてみたんだけど、これ簡易デバドラ開発キットである Jungo WinDriverの汎用ドライバ(windrvr6.sys)使ってるレディメイドなのね、だから動かせる可能性あるな。

開発キットの価格表見てみたが案の定個人で買えるお値段ではない、まぁ動くかどうか確認するだけでもと評価版を入手してみたけど、最初にターゲットデバイスのドライバINFを作成するウィザードで Device Setup Classを指定するドロップダウンにImageが存在しないあたりで何かがおかしい。 まぁデバイスマネージャー上でどこのノードに生えてるようにみせるか問題なだけなはずだしと、Other選択してドライバINFを完成させてJungo Deviceとして認識させる。

しかしここでおもむろにDiMAGE Controlを起動してConnectを連打してもカメラが見つかりませんでダメ、もしかしてwindrvr6とwindrvr1400で互換性無かったりするんですかねこれ…

調査しようにもDiMAGE Capture SDKをいまさら入手する手段が無いので、DiMAGE Controlに含まれてるSDKのランタイムと思われる

の仕様からして判らん状態だからちょいと調査するのめんどくさいやなこれ、とりあえず動作確認が最後にとれてたWindows XP 32bit環境用意しますかね…

つーか本腰入れて調査するモチベあるのならMltRecによる解析結果をベースにlibUSBとかWinUSBで書き直すべき案件なんだろう、ただそこまでして動かしたいやつはぐっと減って世界で0人になると思われる。

2019/4/18(Thu)

[写真] Minolta DiMAGE A1/Konika Minolta DiMAGE A2のPCコントロールはWindows 10 64bitでも使えるか?(その2)

続き、Jungo WinDriverのFAQ読んだら互換性は11.5以降で無くなってるようね、手間のかからないシナリオはWinDriverの最新版でそのままDiMAGE Controlが動くことだったんだがしゃーない。

まぁ動いたとしても評価版からランタイムだけぶっこ抜くわけにもいかず開発ライセンスは個人で買えるお値段ではないしでどっちみち現実的ではなかったんだが。 あと他からの流用もアプリからWinDriver呼ぶときにライセンスキーの登録をしたりする必要があるようなので封じられてたりするっぽい。

じゃあプランBでSDKをWinUSBなりlibusbで書き直すかなんだけど

みたいなめんどくさい作業でやりたくねぇなぁこれ、SDKのヘッダとリンクライブラリは DiMAGE Controlのソースアーカイブの中にあったから多少マシになったけど。

本当はSDKのローレベルなUSB通信はUSBDevIF.dll/USBDevIF2.dllの担当なのでこいつらだけWinUSB or libusb化できればいいんだろうけど、おそらくウィザードとかで自動生成されるものっぽいんだが最新版とはだいぶAPI違うのでよくわからん。

2019/4/19(Fri)

[写真] Minolta DiMAGE Capture SDKで遊ぶ(その1)

続き、そもそもデバイスプログラミングとかまったくやらん人だし、SDKそのものが無いからヘッダファイルのコメントだけがドキュメンテーションなんで遊ぶというより苦行なんやな。

そんな状態なので、S1Onという関数があってもいったい何を10文字略したのだろうそもそもDECで生まれた ヌメロニムって人名のS12nが最初だよなとかいろいろ考えてしまったんだが、その真下にS1Offという関数もあってようやくこれは「S1=スイッチ」というジャパニーズオッサンニムと判明したサンキューイッチフォーエバーイッチ。

ドキュメント無いならリバースエンジニアリングはジャパンではリーガルなのでそれでいこう、セキュリティの調査だからね(すっとぼけ)。お世話になるのが使い方0.1%も理解してない IDA ProのFree版、これでだいたいの処理の流れを追っていく。

まずSDKの最初はOpenCamera()関数、引数はデバイスのプロダクトID(PID)なのでこれで複数存在する可能性のあるJungo WinDriverデバイスからDiMAGE A1/A2を特定してると思われる。

ここでしょーもないツッコミをすると、ベンダID(VID)は引数で指定せずハードコードされてるのが笑いどころで、KonicaとMinoltaの合併による社名変更でVID変わるんだが開発者には晴天の霹靂だったことがうかがえて大草原。 時期的にA1(2003年)はまだMinoltaだったけどA2(2004年)はKonica Minoltaになって最初の製品なのよね、PIDが0x0000から0x0002とピッカピカの第一号製品だったのだ。 まだバブル弾けれどその夢からは未だ醒めやらずのリーマンショック前、のちにカメラ事業自体がSONYに売り飛ばされるとすら思ってなかったのでしょう合掌。 たとえ自社製品だけ動かす専用ドライバだとしても、合併買収もろもろ考えてVIDも引数に含めておくのが正しい実装なのだ。

つってもライブラリの互換性が崩れてしまうので、どうせPIDは被ってないんだから対応するVIDを内部で切りかえるkludgeいれたっていい。 しかしこの開発者が用意したベストソリューションは、なんとA1用(MDSCRC.dll)とA2用(MDSCRC2.dll)にそれぞれ別の値をハードコードしたDLLを提供してそれぞれリンクしてくださいというやつ、おーまーえー(怒)。 よってアプリケーションはシングルバイナリでA1/A2を操作できないんですな、なもんでDiMAGE Controlも別々のバイナリが提供されているという次第。 まぁ最初にA1かA2か選ばせた上でLoadLibrary関数でどっちか呼べばシングルバイナリでもいけるじゃんと思うのだが、作者もめんどくさかったんだろう。

そもそも2台以上接続した場合は制御できない制限もあるしいかんせん作りが雑ですわね、戻り値は成功orエラーだけでデバイスのハンドル的なものはどっかグローバル変数に置いてるだろうから当然の結果なんだが。 複数台同時コントロールしたけりゃAPIそのものを新規に設計し直さないとダメねこれ、しないけど。

謎なのが引数にPID指定してるってことはOpenCamera()関数はカメラ側のUSBモードがPCコントロールモードになってることが前提っぽいんだけど、他のマスストレージ/PTPモードから遷移すると思われるAPIがある。

それはStartPCControlMode()関数とTerminatePCControlMode()関数なんだけど、おいおい挙動を確認すれば何かわかるだろう。 もしかするとCheckExistUSBCamera()関数というのもあるので、マスストレージ/PTPモードのカメラが見つかったらこいつらでPCコントロールモードにという流れかもしれん。 ちなみにDiMAGE ControlはOpenCamera()の直後にStartPCControlMode()しているので、OpenCamera()自体はPCコントロールモードのPID/VIDに頼ってないのかも。

もしくはStartPCControlMode()はUSBモードの切替ではなく単なるリソース初期化処理で、TerminatePCControlMode()はその解放かもしれない。あーなんかこっちと考えた方が当たってそうだな、ならOpenCamera()とStartPCControlMode()を分割する理由がより一層大きな謎になるだけなんだけどね。

ツッコミはここまでにして解析を進める、最初はカメラとの通信の確立でusbNativeInit()→usbNativeOpen()→usbNativeDeviceReset()→usbNativeWriteBulk()と呼び出した後に送受信用のスレッドを起こしている。 ここはWindows XP環境用意してUSBPCapで実際何が流れてんのか観測するのが先かな、発掘するのもめんどいし7のXPモードをVMware Player用にコンバートすりゃええか。

その後にはS1On()→CaptureImage()→StartIntervalCaptureMode()と立て続けにカメラに命令投げてるのはなんでだろうな、ライブビュー表示用の画像更新のためなんだろうか。 なおSDKにコールバック関数的なものは無いようなので、ライブビュー画像の更新はテメエで勝手にスレッド起こして定期的にpollして管理ってことっぽいので、よくわからん。 ちなみにUSBDevIF.dllにはバルク転送のAPIしかないようなのでアイソクロナス転送使ってのリアルタイムビューはできないっぽい。

そして終了はCloseCamera()関数、usbNativeWriteBulk()で終了コマンドかなんか送信した後にusbNativeStopWriteBulk()→usbNativeStopReadBulk()→usbNativeClose()で切断かな。

終了と開始だけでもうめんどくさくなってきたゾ…まずはバッテリ充電めんどいからDCアダプターを入手するところからだナ…

2019/4/20(Sat)

[プログラミング減誤C] リバースエンジニアリングの道具

買ってもいない宝クジが当たるか居もしない親戚の遺産を相続するかワム!と達郎を超えるクリスマスソング作ってその印税が入ってきたら、買うものリストの中に Hex-Rays IDA Pro + Decompilerが入ってるんだけどまぁおいそれ買える値段じゃありませんわね、いまどきだと貧乏人は黙ってフリー(自由より無料の方が重要だ) Avast RetDec使えばええという話もあるけど。

ただRetDecでCソース吐かすと

ので、ぱっとみCコードになっててアセンブラそのまま読むよりかはマシなのだけど、可読性高いかというとそれほどでもねーよなという気はする。

これがIDA Decompilerだと既知のAPIの呼び出しを元に強力な型推論をやってるんだろうけど、戻り値や引数そして変数の型や構造体のメンバへのアクセスも復元できてるっぽいのよね。 ただこれは試用版が無いのでリバースされたCコードみての感想なので夢見すぎかもしれない、デバッグビルドならここまで復元できますとかいうハハハナイスジョークかもしれん。

まぁ老人には贅沢抜かすな機械語読めとかいわれそうだけれども、こっちも老人なのでいまさら原始時代に戻って石器で暮らすほど人生に時間は残っていないのだ。

2019/4/21(Sun)

[プログラミング眩誤C] 続・リバースエンジニアリングの道具

昨日の記事IDA Pro + Decompilerはさすがに買えないけど Avast RetDecも微妙だなという話を書いたんだが、ちょうど先月に一般社団法人日本サーフィン連盟ではない方の N・S・A(駄パンプの例のリズムで)が Ghidraというリバースエンジニアリングツールを無償かつオープンソースで公開したというニュースをいまさら知ったゾ、アンテナ低過ぎですね。

軽く使ってみたけどRetDecに感じた不満はだいぶ解消されてて、これならIDA Pro + Decompiler買う必要ないのではという気になった、実際に持ってる人はぜひ比較記事書いてくれねぇかな~頼むよ~。

まぁあの 水を吐くフグことOpenBSDにバックドアを仕込もうと画策する悪の組織が作ったツールを動かすの怖いというパラノイアでも患ってなければこれでいいんじゃねぇかな…

とはいえGhidraはなんでいまさらJavaで書いてしまったんですかという気がしないでもないけど、LLVMが真のWrite Once, Run Anywhereを実現するまでJVMもいまだ価値があるのかもしれない(てきとう)。

[写真] Minolta DiMAGE Capture SDKで遊ぶ(その2)

続き、とりまUSBDevIF.dllの仕様解析した結果を随時メモっとく。

全くやる気なかったんだが昨日インストールしたGhidraにだいぶ助けられたことで解析が進んでしまったので、これならSDK(MDSCRC.dll)の再実装ではなくUSBDevIF.dllだけの再実装(WinDriverからWinUSB or LibUSB化)で工数はぐっと減りそうでどうしようかなという感じ、世界で3人くらいが嬉しいプログラムコード書いても何もいいことは無いと学んだはずなんだが。

ちなみに評価版インストールしたJungo WinDriverのドキュメントにはWDAPI.dllというのがあるのだが、それ呼んでないよなと思ったら、この時代のWinDriverはまだAPIというよりOSの差異のほとんどをwindrvr.hに定義されたマクロで埋めて、あとは僅かにイベント管理用のCコードをコピーして組込むいうものだったようだ、なので解析にはWinDriverそのものの知識はあまり必要なさげ。 まぁマクロが展開された結果ひたすらCreateFileしてDeviceIoControlしてるというコードになってるので、それを読む退屈さに耐えられる性格かどうかなんやな…

それとSDK V1のUSBDevIF.dllはextern "C"し忘れたのかC++ ABIになっとるので(SDK V2のUSBDevID2.dllでは直ってる)、再実装してDLLを置換するにはMSVC7つまりVisual Studio .Net 2002というとても微妙なバージョンをいまさら入手しないとならないかもしれん、MSDN加入してる富豪でももう無理な気がするんだけどな。

手元に用意できるのVC++2005 Expressが最古だけどMSVCRT 7.0向けのビルドって対応してるんかな、まぁインタフェースみる限りメモリ管理はDLL内で閉じてるっぽいし例外も使ってないし、名前マングリングだけ合わせりゃ大丈夫とは思うんだけどね…

そんでGhidraの不満点いっこ発見、型推論できない未知の構造体で、メンバへのアクセスが先頭ポインタからのアドレス演算になるのはいいんだが、その先頭アドレスをILP32のコードはintとしてコード吐きやがるのでLP64環境には移植性のないコードになるのが気になる。せめてここってlongかchar *にできひんのかなこいつ。

2019/4/22(Mon)

[リバースエンジニアリング] Ghidraたのしい

それにしても Ghidraは素晴らしいね、まじでIDA Pro + Decompilerの販売元のHex-Raysをアレする公的機関による民業圧迫なのでは…

まぁでも一般論としてクラウドによる定額制が進むソフトウェア業界って所得に対する累進性の問題について低所得者層の存在をまるっと無視してるわけで(アカデミックライセンスはあってなぜ年金ライセンスとか生活保護ライセンスが無いのか)、殿様商売しかできん業界相手にはどんどん民業圧迫していけという気はしないでもない、なおその原資たる税の累進性は考慮しないこととする(消費税10%絶対に許さないよ派)。

いくつか感動した点を挙げるとすると、たとえば解析結果で未知の構造体のポインタがint(32bit arch)やlong(64bit arch)に化けてたら

するとあっという間に先頭アドレス+オフセットだったDecompile結果が構造体メンバへのアクセスに解析結果がリアルタイムで更新されるとこかな。 しかも型名の上で右クリック→Auto Create Structureを実行すると、いちいち構造体を登録しなくてもオフセット計算を元に各メンバの型を推測してくれたりもする(さすがに限界はあるけど)。

ただ惜しいのは構造体の登録方法、ダイアログ開いてそこのグリッドにひとつひとつメンバの型と名前を入力していくのはとてもつらい作業なので、ヘッダファイル読込なりスニペットにCコード形式で入力しての登録ができて欲しい。

そしてenumなんかも登録してRetype Variableしてやると解析結果を更新してただの数値でなくenum名に変換してくれたりもするので、Cソースの可読性がモリモリ上昇するのであれC/C++ってJavaとか.Net並みに透明性の高い言語だったっけという気分になる。

重箱の隅つつくなら関数の戻り値だけどまとめて一括でRetypeできる機能なんかも欲しいわね。いま解析してるDiMAGE Capture SDKとかAPIは共通仕様でエラー値としてenumを返すんだけど、60近い関数群をいっこいっこ修正してくのはおつらい。 つーかやっぱりDLL解析する時にヘッダファイルがあればそれも指定できるオプションが欲しいのである。

あとXRefsというウインドウを開けば、変数(アドレス)がどこの関数(ラベル)内から読み書きされるのかR/Wで表示されるのも便利、開かなくてもアセンブラのコメントとしても表示されてるしワンクリックでジャンプできるの素晴らしい。

さすがにmemsetみたいなコードが最適化の結果ぜんぶインライン展開されて可読性落とすのについてはさすがに対策願うのは贅沢ですかね、もっと贅沢言うならマクロも登録するとまとめてくれたりすると最高なんですが、さすがに厳しいか。

しかしやっぱりなんでJavaで実装しちまったんだろうなぁ、JavaのSwingのLook & Feelの違和感はおいといてもクリップボードとかショートカットとかページアップダウンとかスクロールバーの動作が変なのはみんなJavaのせいだと思う(偏見)。

というかバイナリに強い老人たちにはこういう世界が見えてたのかーと、超視力を得る眼鏡を手に入れたとかそういう気分ですはい。

[Java] Amazon Corretto

ということでGhidraの為にこの令和になろうかという時代にJavaなんぞ入れる必要が生まれてしまったのだ。

相変わらずOracleは完全に腐り果てたSunの死体をいまだ切り刻んでは錬金の術に勤しんでるようで、Javaにもバージョン番号インフレ戦法とOracle JDKの商用利用有償化でいエンプラですらオワコンはじまってるJavaの息の根を完全に止めにかかって相変わらずやなーってとこまでは把握していたんだがね。 ワイは最初の仕事がJavaだったという汚点だけでその後のプルグラマ人生このクソ言語につきまとわれ続けて炎上案件ばっかに放り込まれたからむしろ滅んで欲しかったんですけどね…

したらいつのまにかゴスリングおじさんがAmazonに入社してOpenJDKベースの独自ビルドであるCorrettoなんて出してたとは知りませんでしたわ…

もしOpenSolarisがCDDLでないライセンスで公開されてたらAmazon Solarisがあったかもしれない並行世界、それならPrime会員大幅値上げも許せるぞ。

つーかRHELに対してAmazon LinuxとかCentOSもScientific LinuxそしてOracle Linuxもあるのにあっちの人たちって386BSDより混乱してない大丈夫?

2019/4/23(Tue)

[リバースエンジニアリング] Ghidraたのしい(その2)

そういえばIDA Proと違ってでGhindaはデバッグ実行の機能は無いのね、実行ボタンみたいなのがあるから押したらScript Managerといかいうマクロ管理のダイアログが出てきた。

マルウェア解析とかがお仕事のセキュリティおじさんは統合環境下でステップ実行できたら便利かもしれないけど、ただの趣味コードおじさんはあらかたの挙動を掴むだけでいいし、なんならIDA Free併用するから別に問題ないやな。

もういっちょ気づいたGhidraクセのある逆コンパイル結果について。

typedef struct {
	HANDLE handle;
	int value;
	…
} *device_t;

という構造体があった時に、先頭のメンバを変数に代入する時に

void foo(device_t param_1)
{
	HANDLE local_1;
	int local_2;

	local_1 = param_1->handle;
	local_2 = param_1->value;
}

として欲しいところなんだけれど

void
foo(device_t param_1)
{
	HANDLE local_1;
	int local_2;

	local_1 = *(HANDLE *)param_1;
	local_2 = param_1->value;
}

と無理矢理配列にキャストして先頭を取り出すというコードになる、まぁアセンブラなら同じことだけどさ!

もちろん配列も

void
foo(int param_1, int param_2)

{
	int *local_1;

	*local_1 = param_1;
	local_1[1] = param_2;
}

みたいになるのが若干気になりますね。

あとC++の解析が非常に弱いね、シンボルツリーにClassってあるからC++のクラスも解釈してくれるかと思ったんだけどね。

void __thiscall FUN_11451481093(void *this)

{
  undefined4 *puVar1;
  
  puVar1 = (undefined4 *)((int)this + 4);
  *puVar1 = 0;
  *(undefined4 *)((int)this + 0xc) = 0;
  *(undefined4 *)((int)this + 0x10) = 0;
  ...
  return;
}

これをthisに対してAuto Class Structureを実行すると

struct AutoClass1 { /* PlaceHolder Class Structure */
    undefined4 field_0x0;
    undefined4 field_0x4;
    undefined4 field_0x8;
    undefined4 field_0xc;
    undefined4 field_0x10;
    ...
};

void __thiscall FUN_11451481093(AutoClass1 *this)

{
  undefined4 *puVar1;
  
  puVar1 = &this->field_0x4;
  *puVar1 = 0;
  this->field_0xc = 0;
  this->field_0x10 = 0;
  ...
  return;
}

いやー(白目)、ワイはC++で出力されるよりCで出力してくれる方がありがたい老人ですが、C++完全に理解してる勢は脳の血管切れませんかね大丈夫?

そもそもC++についてはエクスポートされてるシンボルの名前まんぐり返し程度の事もしてくれんっぽいし、あまり優先度高くないんですかね。

[宗教] ThinkPad X201用のウルトラベース壊れた

こないだThinkPad X201を落下させてしまいその相変わらずの頑丈さを証明したとこなんだが、完全に無傷とはいかず電源プラグ周りに衝撃が集中したようで、ウルトラベースの電源コネクタが接触不良気味になってしまった。 バッテリーあるから電源落ちることはないしいいやで放置してたんだけど、結局ショートおこして中の基板が焦げてしまった。

くっさ → 基板焦げてるやんけ!となる前、むかし撮影した写真をスキャンしてて1枚だけなぜ撮影したのかわからないブルーシートの写真があってこれ何だっけ?と頭ひねってたのよね。 そんで焦げ臭さを嗅ぎ取った瞬間に撮影した理由を思い出したんですわ、これ当時近所でおきた火災の現場だ!

そういうとこで写真を撮ると悪霊というかグレムリンというか得体の知れぬ何かを連れて帰ってしまうんですな、その結果ウルトラベースが燃えたという事だ(失敗事例データベースより)。 それでは今からスティービー・ワンダー「迷信」とかアルバート・キング「悪い星の下」ロバジョンの「地獄の猟犬がつきまとう」あたりを聴いて悪霊祓いの儀式をしようと思います。

最近はなにか事故がおきるとスマホで撮影すぐにSNSへ放流しそれに報道が飛びついてお茶の間に流れる時代だけど、とんだ何かを連れて帰らないように撮影は慎もう。

ウルトラベースを買い直すと中古でも送料込で3000円くらいはかかるのでまた出費に嘆いてたのだけど、たまたま近所のリサイクル屋でセキュリティロック外れませんなジャンクが108円で売ってたので助かった。 あれゼムクリップとマイナスドライバーでかんたんに開錠できるのでな *1

あとどうでもいいけど関東電気保安協会と関西電気保安協会は日本語では1文字しか違わないけど、英語だと

でけっこう違うという学びを得た、本当にどうでもいい。

*1:なので盗難防止用のセキュリティワイヤーはウルトラベース側だけでなく本体側にもつけないと簡単に盗まれるので注意。

2019/4/24(Wed)

[Windows] Windows 10のパスワードリセット方法に追加された「セキュリティの質問」

Windowsでは長いこと(XPからだっけ?)パスワード忘れた場合は「パスワードリセットディスク」なるものでリセットしたんだけど、Windows 10 1803からは「セキュリティの質問」というセキュリティ的にガバガバなものに答えてもリセットできるように変更されたのよね、Vistaの頃からあった「パスワードのヒント」ですら安全性が問題視されてたというのに何考えてるんだこいつら。

しかも質問の内容が固定で自由入力できない上に「最初のペットの名前は?」とか何十年前のセキュリティ意識なんですかね、もしかするとMicrosoftアカウント登録させるためにわざと安全性下げている?(陰謀論)

まぁリモートデスクトップ(RDP)経由なら秘密の質問を使ったパスワードのリセット要求はできないしセーフです!セーフ!とアクロバット擁護してもいいんだが、実はリモートデスクトップでも画面のロックは可能なのでその状態からならパスワードリセットを試行できちゃうのよな。 離席する時はリモートマシンでなくローカルマシンの方に画面ロックかけるとはいえ、全画面表示で使ってたりするとどっちにロックかけたか判んなくなるよね特にトイレ行きたいときは焦ったりするわけで。

なのでどう考えても百害しかないから無効にしたいところなんだけど、インストールの最終段階であるミニセットアップ画面(正式にはOut-Of-Box-Experience略してOOBEという)において、パスワードを設定するとセキュリティの質問も同時に設定しないと先に進めなくなってしまう。

これの回避策としてはパスワードを入力せずにセットアップを終了させ、後からパスワードの設定を行えばよい(これは「パスワードのヒント」も同様だった)。

ただし「設定→アカウント→サインインオプション」からパスワードの作成を行うと、旧来の「パスワードのヒント」の入力が必須になってしまうのでこれも使えない。 なので「コンピューターの管理→ローカルユーザーの管理→ユーザー」でアカウントを選択し右クリックメニューから「パスワードの設定」で実施する。

もっと手軽な方法もあって管理者権限あるならコマンドプロンプトを開いて

C:\Windows\system32> net user ユーザー名 パスワード

と叩くでもいいんだけど、UNIXのpasswd(1)なんかと違ってパスワードの再確認とか無しに強制上書きなので入力ミスあったりするとそれこそ「セキュリティの質問」でリセットしたくなる状況になるのだ。

そんでだ、ミニセットアップ画面で「セキュリティの質問」をもう設定しちゃったよ!というあわてんぼさん(長崎ハウステンボスの亜種)は、自身のアカウントで二度と復活することのないよう消去しておきたいと思うわけだけど、困ったことにオフィシャルに方法が用意されてないのよね、やはり秘密の質問はセキュリティ高めると勘違いしてるのかあいつら。

非公式なものでも何かねーかなと探したんだけど Update-AllUsersQAというPowerShellスクリプトがあってわりとひろく宣伝されてるようなのだけど、どうもこれ

という対症療法スクリプトでしかないっぽいんだよな、逆に無能な管理者の入力しそうな値(1145148101919とか)を推測できたらまずいんじゃないですかねこれ…

まぁ世の中の高給取りのシスアド貴族様ってそんな道端落ちてたPowerShellスクリプトなんて拾い喰いしてこれで安心とか言わないから大丈夫でしょ(適当)。

ということで根本的にはユーザーを作り直すしか方法はなさそうね、環境を壊したくない人には大変おつらいだろうけど再インストールほどの手間じゃないからまあええでしょ。

ちなみにWindows 10からは「システムのプロパティ→詳細設定→ユーザー プロファイル」からプロファイルのコピー/移動もできないようになったので、AppDataの下にある有象無象の謎ファイルを安全に引継ごうと思ったら

くらいしか方法しか無さそうなのがクソクソアンクソ、企業だとグループポリシーで「アカウント:Microsoftアカウントをブロックする」は100万回設定するポイントだと思うんですけどね。

管理者権限もっててローカルコンピューターのユーザー全員に対策してもいいなら、「セキュリティの質問」そのものを表示されないように

として無効にしておく方法もあるようね、我が家ではカスタムインストールイメージにこの値追加しておくかという。

[Windows] Windows 10に.Net Framework 3.5 をインストールする

とあるアプリが2.0で書かれとって更新される気配が無いので、Windows 10で動かそうと「Windowsの機能の有効化または無効化」から「.Net Framework 3.5 (2.0 および 3.0 を含む)」を実行したんだが、エラーでインストールできねぇのな。

同じ症状の人は多いようで

で成功したという情報が散見される、うちの環境では全部試してダメだったけどな!

あらかじめインストールイメージに.Net Frameworkの累積パッチをDISMコマンドで統合するとWinSxS以下が不整合発生で壊れるっぽい、なので

という順序にせんとアカンようだ。

この適用する順番が重要っての、Windows NT4の頃にまだQFE(Quick Fix Engineereing)って呼ばれてた時代のパッチが、適用する順番間違えると古いDLLなんかに置き換えられて死ぬって20年前に先祖返りした趣がある。

まぁWindows 10って式年遷宮みたいに定期的に再実装することで技術力を維持しようとかブラックボックス化してる部分を廃したかったんだろうけど、例のフレスコ画修復みたいになってない大丈夫?

2019/4/25(Thu)

[Windows] Windows 64bit OSのドライバに必要なコード署名についていろいろ

@「ドライバー署名の強制を無効にする」は本当に必要?

先日の古いSCSIカードを使う件なんかでWindows 64bit OSのドライバ署名まわりの挙動を調べてたんだけど

  • ドライバインストール時の署名検証はセキュリティカタログ(.cat)で行なわれる
  • セキュリティカタログとカーネルモードドライバ以外のファイルは署名されず、セキュリティカタログにハッシュ値だけが記録されている
  • インストール時は
    • セキュリティカタログの署名の真正性と信頼性
    • それぞれのファイルのハッシュ値が一致するか
    だけが検証され、この時点ではカーネルモードドライバの署名は検証のしようがない(infにカーネルモードドライバか否かの情報無いしね)
  • セキュリティカタログの署名チェックは基本ザルで、オレオレ署名でも「信頼されたルート証明書」に追加されてれば回避できるのでインストール可能
  • なんなら回復コンソール(Windows RE)で起動し、DISM /Add-Driverコマンドを使ってDriverStoreにインストールしてしまえばセキュリティカタログ要らない
  • ただしオレオレ署名だと(?)デバイスマネージャ上は「デジタル署名されていません」表示のままになる(原因不明)
  • カーネルモードドライバにされてる署名の真正性はカーネルにロードされる時にようやっと検証される
  • カーネルモードドライバの署名だけはMicrosoftによる署名でないとダメ*1
  • セキュアブートを無効にすれば(あるいは元々その機能が無ければ)上の条件は緩和され、認証局から購入したMicrosoftとのクロスルート証明書で署名されてればおk
  • テストモード(bcdedit /set testsigning on)で起動すればオレオレ署名なカーネルモードドライバでもロードされる
  • それでもドライバに絶対に署名したくないでござるであれば、起動オプションで「ドライバー署名の強制を無効にする」を選択

ってとこかな。

これ公式文書にも当たらず自分で検証もせず他人の書いた文章を鵜呑みにして最終手段のはずの「ドライバー署名の強制を無効にする」を設定してくださいなどと製品サポートに書いてしまう法人が多数あるのはヤバさ可視化されていいっすね、やっぱりこの施策って失敗だったんじゃないですかね…

@コード署名って本当に有用?

それにコード署名って結局のところ配布物が改変されてないことを証明することが精一杯で

  • コードに悪意が無いかの証明 → たかが認証局にコードの安全性の審査なんてできるわけがない、そもそも悪意ないヤツが書いたコードでも大災害は起きるのだ
  • EV証明書なら責任の所在が明確 → 責任取れといわれて取るのは実は世間の少数派、会社畳んで夜逃げドロンのケースがどんだけ多いことか

であってスーパーの野菜に生産者表示にある顔写真のものではないのよな。

なのになぜコード署名にMicrosoftが信頼する認証局のEV証明書が必要になるのか、これは事務的な問題でしかなくPGPのキーサインパーティーでは鍵指紋と身分証明書を持ちあって本人確認を行うけど、そのプロセスを認証局が代行するだけなんよな(どーせ帝国データバンクとか東京商工リサーチなんかの足元にも及ばないザル調査だと思うんだけどね)。

その結果として失われたものは多くて

  • 本人確認プロセスは認証局の特権となり、非常に高価なものとなっってしまった上に、信頼の連鎖モデルは失われてしまった
  • EV証明書とその署名自体に価値があると勘違いする連中が増え、セキュリティ的にはむしろモラルが下がった

ってのは大問題よね、署名されてればオッケーならWindowsのエラー番号やKB番号そしてハードの名前で検索すると雲霞の如くヒットするWindows修復ツールを騙るマルウェアのインストーラーだって署名されとるわけでさ。

とはいえだ、Microsoftがそんなにコード署名ごときを重視するのであれば、こっちもオレオレ証明書いっこ作っておいた方が運用面で楽になるよね、そもそもOffice製品のVBAマクロやPowerShellなんかもコード署名しといた方がいいケースも多いしな。

ということで次回はopenssl(1)?知らないですねそんな子のためのオレオレ認証局の建て方とコード署名証明書の作り方でも書くか…

*1:例外もあって、アップグレードインストールあるいは署名の日付がWindows 10のリリースより前という条件ならセキュアブート無効と同じ条件に緩和されるようだ

2019/4/26(Fri)

[Hardware] Tekram DC-390とIO-DATA SC-UPCIなSCSIカードはWindows 10 64bitでも小細工不要で使える

先日ジャンク屋で ThinkPad X200/201用のウルトラベースを108円で買った時ついでに

も買ってきたよ。

そんで驚いたことに両カードともにWindows Updateで勝手にドライバが降ってきて認識しやがったぞこいつ!

どういうカラクリかというと、いまだにSCSIカードの販売と保守をやってる酔狂なドイツ(あっ…察し)の会社Dawicontrol社の話を 先日の記事で書いたけど、そこの製品のDC-2974というのがAMD 53C974、DC-2975U/DC-2976UWはLSI Logic 5C875と同じコントローラでなんと自社でWHQL取得してWindows Update対応までしてくれてるのだ、はえーすっごい。

ちなみにLSI Logic 53C875はVistaからぶっこ抜いてきたsimc8xxドライバ(4.16.06)でも動くんだけど、DC2976ドライバはより新しいバージョン(5.11.0.0)なので勝手に更新されるのね。

そんでこいつってIO-DATA SC-PCIのような53C815採用のカードでも動かねえかなと思ったんだけど、古いコントローラーのサポートを切り捨てたのか初期化できませんでした(エラー10)で死ぬもよう、ということでSC-PCIはVistaのドライバー使えってことで。

ということでオレオレ署名とかオフラインインストールとかめんどくさいことせずともWindows 10 64bitでも現役で使えるSCSIカードは思ったより多かったということ。

それにTekramもまだ生きてて DC-315UというSCSIカードまだ売ってるのな…

[Hardware] Windows 10 64bitでASPIを使う(その2)

続き、AdaptecのカードとAdaptecのASPIドライバしか使ったこと無かったので(典型的信者スタイル)その存在を知らなかったんだけど、 FrogASPIというwnaspi32.dll実装が存在してて、こいつは本来はカーネルモードドライバ(aspi{32,64}.sys)が必要なASPIをNT kernel標準のSPTIに変換するエミュレーター・トランスレーターとして実装されてるのね。 ということDLL入換えてしまえばいいだけなんやな、NeroASPIってやつも同様っぽい。

なんかどちらも元々のプアー過ぎるASPIを拡張したオレオレ便利関数が実装されてるのね、Neroに至っては使ってないASPIの関数未実装だったりもする。まあそういうのに頼ってるなら最初からアプリに添付されてるはずだしどうでもいいな…

とはいえnative 64bitなwnaspi64.dllとなるとAdaptecの署名なしドライバ必要なやつあるいはラトックの有償版ドライバ同梱なやつしか無さそうだけど、そもそもASPIで書かれた64bitアプリがこの世に存在するとは思えんし、その上いまなお使おうとう奇人は世界で0人だと思うので問題ないかな。

動作確認しようにも今更ASPI使うアプリなんて思いつかねぇよなと思ったけど、Nikon Scan 3がそうであった。 つかNikon Scan 3はUSBあるいはIEEE1394になったCOOLSCAN IV ED/4000 ED/8000 EDの標準ソフトでもあるので、 Windows Image Acquisition(WIA)を使ってインタフェースに依存しないよう実装されてると思ったんだが…SCSIだけ盲腸のようにASPIで動いてんだろうか。 Nikon Scan 4ではSCSIな機種切り捨てたのだけど、inf書いてSCSIな機種もscsiscan.sys使えばいいだけなんやな。というかIEEE1394もscsiscan.sysで動いてるんだから動かないはずがないのだ。

2019/4/27(Sat)

[Windows] オレオレ証明書によるコード署名の手順 (その1 - makecert編)

先日の記事の続き、Windowsではオレオレ認証局(CA)を建ててオレオレ証明書を発行するには3つの方法がある *1

基本的に3以外はobsolete扱いの上、1と2は不足する機能が多いのであまりお勧めできないが、何が問題か説明してる文書をみかけない気がするので、何回かに分けて書いていこう。

@makecertを使った作成法

まずはオレオレ認証局(CA)の鍵ペアを作る、すでに別件で作成済ならそれ使ってもいいし新規に作っても誰も気にしない、なんせオレオレだからな!

makecert ^
	-r ^
	-n "CN=Example CA,O=Example Corp.,OU=Example Div.,C=JP,DC=com,DC=example" ^
	-a sha256 ^
	-len 4096 ^
	-sky signature ^
	-cy authority ^
	-b 05/01/2019 ^
	-e 12/31/2039 ^
	-sv root.pvk root.cer

ポイントは

  • 自己署名証明書となるので-rオプション指定しろ
  • 証明書の名前は-nで指定する、どーせオレオレなのでCNとか好きにしろ
  • ハッシュアルゴリズムのデフォルトがいまどきは非推奨のSHA1なので、明示的に-aオプション指定してSHA256にしておけ
  • 暗号方式は-syオプションで変えられるけど、デフォルトのRSAから変えられるのはDSAのみっぽいのでそのままで
  • 鍵長がもはや時代遅れの1024bitなので、-lenオプションでせめて2048bit以上に変更しておけ
  • 鍵用途に-sky signatureをして署名(AT_SIGNATURE)に限定
  • 基本制限に-cy authorityを指定しCAとしての利用に限定しておけ
  • 証明書の期限は-b(開始)と-e(終了)をmm/dd/yyyyとかいうメリケンの田舎者形式で指定する(指定しない場合現在からGMTで2039年12月31日23時59分59秒まで)
  • -svで秘密鍵と公開鍵の名前を指定する
  • 秘密鍵に設定するパスフレーズの入力と確認を求められる、コマンドラインツールなのに入力はダイアログなので他の窓の裏に隠れてないか注意
  • 公開鍵の出力に秘密鍵のパスワードを聞かれる、やはりダイアログ以下略

くらいかな。

次にコード署名用の鍵ペアを作成する

makecert ^
	-iv root.pvk -ic root.spc ^
	-n "CN=Example Apps,O=Example Corp.,OU=Example Div.,C=JP,DC=com,DC=example" ^
	-a sha256 ^
	-len 4096 ^
	-sky signature ^
	-cy end ^
	-b 05/01/2019 ^
	-e 12/31/2039 ^
	-eku 1.3.6.1.5.5.7.3.3 ^
	-sv apps.pvk apps.cer
  • 自己署名ではないので-rオプションでなく-ivと-icで発行者となるCAの鍵ペア(さっき作ったやつ)を指定する
  • -nで指定する名前は同じにすると運用上紛らわしくて事故の元だからさっきのとは別にしておけ
  • 基本制限に新たな証明書を発行できないよう-cy endで末代(エンドエンティティ)指定して中間証明書として使えないようにしろ
  • 使用目的はコード署名のみに限定し-ekuオプションでOIDに「1.3.6.1.5.5.7.3.3」を指定しておけ
  • パスフレーズ設定はさっきと同じ手順、漏洩リスクを考えて認証局に設定したものとは別のものにしとけ
  • 公開鍵への署名にさっき作成した認証局の秘密鍵のパスフレーズを求められるので入力する

ちゅーとこ。

ファイルに出力せず証明書ストアを利用することも可能で

  • 出力先は「-sv 鍵ペア」でなく「-ss ストア名」
  • 署名用の鍵ペア指定は「-iv 秘密鍵 -ic 公開鍵」ではなく「-ir ストアの場所 -is ストア名 -in 名前」
  • ストアの場所およびストア名は証明書マネージャーに表示される日本語は認識しないので(l10n/i18nの敗北)、英語名はググるかレジストリ値探せ

と適宜読み替えてどうぞ、ただし試行錯誤した結果が全て証明書ストアに蓄積され後で削除めんどくさくなるしでお勧めしない。

そんでmakecertを使う上での問題点は

  • キー使用法(key usage)の指定ができない(なぜか拡張キー使用法はできる)ので厳密な運用を求める人には向いてない
  • いまどき楕円曲線暗号が指定できないので、署名だけならいいけど鍵交換用だとRSA/DSAで安全と思われる鍵長を指定するとオーバーヘッドが生じる
  • 有効期間に時刻の指定ができない(GMTで00:00:00固定)
  • フレンドリ名が指定できない
  • 失効証明書(CRL)の情報を指定できない

あたりか、オレオレ用途ならまぁ及第点ってとこだな…

問題なく作成できたと確信できたらようやっと証明書ストアにインポートする。ただし暗号鍵はMicrosoft独自形式の上で自分らも直接の証明書ストア取込に対応していないのが謎過ぎる。 なので公開鍵と一緒にPFX(Personal inFormation eXchange)形式に変換をする、これはpvk2pfxコマンドで行う。

まず認証局の鍵ペアの変換。

pvk2pfx -pvk root.pvk -spc root.cer -pfx root.pfx -pi 最初につけたパスワード -po 新たにつけなおすパスワード

ポイントは-poを指定し忘れるとパスワード無しの.pfxが出来あがるので危険というとこやね。

そしてコード署名の鍵ペアだけど、認証局の公開鍵とコード署名の公開鍵を証明書チェーンとするためにcert2spcというコマンドを使ってソフトウェア発行元証明書(.spc)というものを作る必要がある。

cert2spc root.cer apps.cer apps.spc

そんでpvk2pfxの-spcオプションの引数にapps.cerではなく証明書チェーンのapps.spcを指定してやる。

pvk2pfx -pvk apps.pvk -spc apps.spc -pfx apps.pfx -pi 最初につけたパスワード -po 新たにつけなおすパスワード

あーもうめんどくせぇ…すぞ(血管ブチ切れ)。

ちなみに本来はここでMicrosoftのクロスルート証明書チェーンにしてやる必要があるんだろう、 先日書いたオレオレ署名がデバイスマネージャで「デジタル認証されていません」の表示のままである原因はこれかな多分。

そして後はpfxをダブルクリックすれば証明書ストアへのインストールウィザードがはじまる、今後認証局として他の証明書の発行を行う端末にはroot.pfxを、ドライバなどのコード署名を行う端末にはapps.pfxをインポートしてやればいい。味噌とよく似た何かを一緒にしてはならない権限分離は大事だよ(戒め)、 なおコード署名するだけならpfxをインポートする必要も無いので後回しでいいです。

実際のコード署名の手順はまた最終回にでも。

@次回

certreqを使った作成法を説明する予定、いつになるかは知らない。

*1:openssl(1)とか知らない子ですね(すっとぼけ)

2019/4/28(Sun)

[旅行] NAF(Naval Air Facility) Spring Festival 2019

4年ぶりに行ってきたよ、生憎の大雨で滑走路辿り着く前に帰ろうかとすら思ったんだけど、雨の中静かに羽根を休める哨戒機P-1とかよかったっすね。

過去記事には身分証明書確認と手荷物検査の待機列に最悪3時間くらい並ぶし、最後尾は基地を半周した光陵運動公園あたりになるので最初からそこ目指した方がいいと書いたんだけど、待機列として基地内の駐車場を開放するようになったのと雨模様で来場者も少なかった事の相乗効果で、身分証明書確認のゲートの前には待機列なく手荷物検査も20分も待たずという状態。 なもんで前回と同様に長後→さがみ野行のバスのって上深谷で下車したら誰もいなくてゲートまで長時間歩く羽目になった、晴れてたとしても観音入口まですら伸びなかったかもね。

自分が子供の頃はまだミッドウェイにキティホークの時代で、戦闘機はF-4、F-8、F-14、F/A-18Cそして攻撃機ならA-4、A-6、A-7とバリエーションに富んで(F-8とA-6、A-7の区別がつくとはいっていない)しかもド派手な塗装のベトナム戦争時代の機体ばかりだったものだけど、4年前にEA-6Bが退役していまや海軍はF/A-18ベースの機体しか運用してないのでとても地味なのだ、おのれストレンジ・マクナマラ。はよワイの生きてる間にF-35Cの配備を…

それでも4年前は基地祭にはかつての海軍を思い出す特別塗装がなされた司令機が展示されてたんだけど、ここ数年で大部分が岩国の海兵隊のところに移転したりでロービジ塗装の機体ばかりであった。 例外が今年創立40周年を迎えるVAQ-132所属のEA-18Gと、一昨年VAW-115のE-2Cと入れ替りで来たVAW-125のE-2Dくらい。

そいえばEA-18Gって以前は電子戦装備に近寄れないよう兵隊さんが座ってガードしてたんだが今年はフリーアクセスだったな。 もうRQ-4グローバルホークのような無人機の時代だから機密指定解かれたんですかねあれ。

2019/4/30(Tue)

[Windows] 新元号対応更新プログラム

そいやまだWindowsって改元対応の更新プログラムってWindows Updateには来てないのね、Cygwinのnl_langinfo(3)とそれを呼びだすlocale(1)はWindowsのAPIから元号情報ひっぱるはずだけど

$ LANG=ja_JP.UTF-8 locale -k era
era="+:2:1990/01/01:+*:平成:%EC%Ey年";"+:1:1989/01/08:1989/12/31:平成:%EC元年";
"+:2:1927/01/01:1989/01/07:昭和:%EC%Ey年";"+:1:1926/12/25:1926/12/31:昭和:%EC元年";
"+:2:1913/01/01:1926/12/24:大正:%EC%Ey年";"+:1:1912/07/30:1912/12/31:大正:%EC元年";
"+:6:1873/01/01:1912/07/29:明治:%EC%Ey年";
"+:1:0001/01/01:1872/12/31:西暦:%EC%Ey年";"+:1:-0001/12/31:-*:紀元前:%EC%Ey年"

でまだ平成は続くよどこまでも状態なんやな、オレオレN6だとこうなっとる。

$ LANG=ja_JP.eucJP locale -k era
era="+:2:2020/01/01:+*:令和:%EC%Ey年;+:1:2019/05/01:2019/12/31:令和:%EC元年;
+:2:1990/01/01:2019/04/30:平成:%EC%Ey年;+:1:1989/01/08:1989/12/31:平成:%EC元年;
+:2:1927/01/01:1989/01/07:昭和:%EC%Ey年;+:1:1926/12/25:1926/12/31:昭和:%EC元年;
+:2:1913/01/01:1926/12/24:大正:%EC%Ey年;+:2:1912/07/30:1912/12/31:大正:%EC元年;
+:6:1873/01/01:1912/07/29:明治:%EC%Ey年;"

あ、長いので適宜改行してるけど実際は1行ね。

Windowsのカレンダーをコントロールパネルから和暦表示に変更してもダメっぽい。

あと「令和」の合字がユニコード(U+32FF)に追加されたのもフォント更新されてないっぽ。 それと確認するのめんどいからやらんが文字コード変換まわりもウンコード正規化もまだなんだろうな。 こんな合字が必要になるシステムなんてJISで動いとるだろうしそっちには追加されんから外字対応だろうしどうでもいいか…

どうせGB18030にはUnicode12.1対応すりゃ勝手に入るだろうけどCNS11643とかどうなるんかな、ああどうでもいい…

むー 公式の文書読んでもWindows Update自動にしてればもう降ってきてるはずと書かれてるんだがはて?

検索したら KB4469068がヒットして、マンスリーアップデートには間に合わなかったからオプションにある累積パッチプレビュー版入れるか手動で単体パッチ適用しろだと。 まぁAppleなんかもまだベータでしか対応されてないし、どこも間に合わねえということやな。

ちなみに7用の単体パッチの 機能追加および修正を読むと定数とか境界値でバグりまくってたようなので、いちおうテストはしとるんやな。

ということで単体パッチ適用して再起動した結果。

できてへんやんけーッ!!基本的なことが~~~!!(例の画像略)、令和元年になるところが令和1年になっとるし平成も元年でなく1年表示。 ということはCygwinってもしかして自前でlocale database持ってるんかな。

それと

と無意味にややこしい動作をするよう実装されてるっぽい、法の施行を以てと厳密に解釈した結果かねえ。 政府から出てる原則は施行日より前であっても改元日以降の日付を和暦で表現すんなら「令和」使え、ただし「平成」って書いちゃったものにはめくじらたてんなって扱いだと読んだ記憶があるのだが…

おそらくOfficeの方は自前実装でもっと奇怪な動きをしそうだけどチェックめんどくさい、誰か記事書くやろ(鼻ホジ)。

社会に混乱なきよう生前退位で半年以上前からスケジュール決まってて元号発表からですら1月の猶予あったのに、まさしく「誰も消防車を呼んでいないのである」のインターネットミームになったという気分である。

結局こうなるとOSのlocaleやら使うよりも自前でデータベースを抱えるというクソアプリの方が正義になってしまうので、自分を含めて国際化プログラミングに関わってた連中のやってたことは無意味でしたーwという烙印がまたひとつ押された気分やでホンマ、ワイなんて無意味の何乗になることやら。

[pなんとかsrc] pなんとかsrc

pなんとかsrcの要求するmake(1)のバージョンが上がったようで、オレオレN6のbaseモノだと動かなくなったので、mergeするのもめんどくさいのでbootstrap-pなんとかsrcを導入して誤魔化した。

以下費やした無駄な労力

そいえばPREFER.openssl=pkgsrcしたいのにlibresslとconflictするから依存パッケージで困るから放置してる件も直る気配すらないので自分でやらんとならんかな…