RS232Cとクロスケーブル
2023.11.19
PC/AT機のDsub9ピンRS232C端子(厳密にはRS232Cではないとかは置いておくとして)同士を直結するときの結線はどうあるべきか。
例えばlinuxのシリアルコンソールにHWフロー制御ありで接続するときはどういう結線であるべきなのかということ。
というのは、調べたところ、クロス(リバース)ケーブルと呼ばれるものにいくつか種類があるようだ。
基本的にはTXD/RXDがクロスしてて、GNDがつながっていればフロー制御とかしなければどれでもいいわけだが。
まずDsub9のピンアサインと機能について。
※IOは本体基準
・インターリンクケーブル
サンワサプライだとインタリンク用シリアルクロスとパッケージ表記。
https://www.sanwa.co.jp/product/syohin?code=KR-LK2
エレコムだとシリアルリバースとパッケージ表記。
https://www.elecom.co.jp/products/C232R-915.html
なんの変哲もない完全なクロス。
・家に転がってた謎のクロス
基本的には上記インターリンクとほぼ同様。DTR出力がDCDにも接続されている点がことなる。
つまり、対向の電源が入っていれば、キャリア検出状態(≒有効なデータが送られてくる)として認識する。
RTS/CTSは互いの状態を見て制御。
というわけで、上記インターリンク接続に加え、DCDを見ているソフトでもきちんと動いてくれると思われる。ちょっと親切。
・サンワサプライクロス
サンワサプライにはインターリンククロスではないクロスケーブルが存在する。
リバースとパッケージ表記。
https://www.sanwa.co.jp/product/syohin?code=KRS-403XF-07K2
自身のRTS出力が対向のCTSと対向のDCDに入力されている。
RTS/CTS制御は自身の状態で決まる。自身が受信できないとき(つまり受信FIFOが埋まっているときなど)は自身は送信もできない。対向の状態は気にしない。
対向が受信できないとき、キャリア非検出状態として認識する。
対向がRTS/CTS制御しておらず、自身がCTSを見ているときに有効。それって対向と自身の設定があってないだけのような気がするので、用途としては謎。
というわけで、とりあえずPCのRS232C直結するならインターリンク接続でいいんじゃないの、と思われる。
本物のモデムでDCDが"0"のときでもATコマンド送っていいと思われるし、応答も返ってくるはずなので、送受信時にDCDをチェックする必要もないはず。
例えばlinuxのシリアルコンソールにHWフロー制御ありで接続するときはどういう結線であるべきなのかということ。
というのは、調べたところ、クロス(リバース)ケーブルと呼ばれるものにいくつか種類があるようだ。
基本的にはTXD/RXDがクロスしてて、GNDがつながっていればフロー制御とかしなければどれでもいいわけだが。
まずDsub9のピンアサインと機能について。
| No | IO | 名称 | 機能 |
| 1 | in | DCD | Data Carrier Detect。モデムが回線からキャリア(いわゆるピー音)を検出したら"1" |
| 2 | in | RXD | Recieve Data。受信データ。 |
| 3 | out | TXD | Transmit Data。送信データ。 |
| 4 | out | DTR | Data Terminal Ready。電源が入っていれば"1" |
| 5 | - | GND | Ground。試される大地 |
| 6 | in | DSR | Data Set Ready。対向側の電源が入っていれば"1" |
| 7 | out | RTS | Request To Send。対向からこちらにデータを送って欲しいという要求。すなわちこちらが受信できるという状態なら"1" |
| 8 | in | CTS | Clear To Send。送信許可。対向がデータを受け入れられるときに"1" |
| 9 | in | RI | Ring Indicator。電話の呼出ベルが鳴っている状態。 |
・インターリンクケーブル
サンワサプライだとインタリンク用シリアルクロスとパッケージ表記。
https://www.sanwa.co.jp/product/syohin?code=KR-LK2
エレコムだとシリアルリバースとパッケージ表記。
https://www.elecom.co.jp/products/C232R-915.html
なんの変哲もない完全なクロス。
・家に転がってた謎のクロス
基本的には上記インターリンクとほぼ同様。DTR出力がDCDにも接続されている点がことなる。
つまり、対向の電源が入っていれば、キャリア検出状態(≒有効なデータが送られてくる)として認識する。
RTS/CTSは互いの状態を見て制御。
というわけで、上記インターリンク接続に加え、DCDを見ているソフトでもきちんと動いてくれると思われる。ちょっと親切。
・サンワサプライクロス
サンワサプライにはインターリンククロスではないクロスケーブルが存在する。
リバースとパッケージ表記。
https://www.sanwa.co.jp/product/syohin?code=KRS-403XF-07K2
自身のRTS出力が対向のCTSと対向のDCDに入力されている。
RTS/CTS制御は自身の状態で決まる。自身が受信できないとき(つまり受信FIFOが埋まっているときなど)は自身は送信もできない。対向の状態は気にしない。
対向が受信できないとき、キャリア非検出状態として認識する。
対向がRTS/CTS制御しておらず、自身がCTSを見ているときに有効。それって対向と自身の設定があってないだけのような気がするので、用途としては謎。
というわけで、とりあえずPCのRS232C直結するならインターリンク接続でいいんじゃないの、と思われる。
本物のモデムでDCDが"0"のときでもATコマンド送っていいと思われるし、応答も返ってくるはずなので、送受信時にDCDをチェックする必要もないはず。
2023.11.19 18:05
| 
BitLockerのお話
2019.03.30
なんというかNuに限った話では全然ないのだが、この辺興味ある人が多いようで。
基本的にはコールドブートアタックといわれる技法。
既にセキュリティホールとして報告も上がっている話。
https://www.itmedia.co.jp/enterprise/articles/0802/22/news094.html
ディスク暗号化技術にセキュリティホール、研究者が指摘
さらに詳細はリンク先の論文読むべし。英語わかんないからちらっとしか読んでないけど。
結局のところ、稼働している状態のメモリの中身を覗ければ、そこからFVEKは導き出せるという話。
※というのが脆弱性。この脆弱性って回避できんの？って話は後で。
じゃあどうやって稼働してる状態のメモリの中身を見ようかというところ。
MSX2とか酷使したことある人なら(っていきなりそこか)、メインRAMにROMイメージを読み込んで、ハードリセットしてもイメージが起動するとか、電源を切っても数分は残ってるとか経験はあるはず。
ほら、そういう経験が役に立つわけですよ。
まあつまりリセットしただけではメモリ内容はほとんど失われない訳ですよ。
起動シーケンスで使われる部分は上書きされるけど、それはごく一部。
なので、起動中にSSDを差し替えてリセットすると、メモリ内にFVEKが残った状態で、メモリダンプツールとか起動できる。
この時点でSSDの変更が検出されてTPMのデータが消えて、次回以降正規のSSDは起動出来なくなるので一発勝負。
ちなみに、世の中にそんなツールがあるのかは知らない。
ただ、一つ言えることは、再起動後にOS(特にWindows)を起動した場合、デバイスドライバが読み込まれるメモリ上の場所というのは、ほぼ毎回変わらない。よって、OSを起動してしまうと高確率でFVEKは上書きされて消えてしまう。
なので、MBRにダンプツールを仕組むとかしないとまず無理。
あとはメモリダンプからどうやってFVEKを探し当てるかという話。
この辺も論文にわりと書いてあるけど、仮に実装メモリが1ギガだとすると、総当たりしても(FVEKは全バイト連続して格納されてると仮定して)たったの1ギガ個＝10億個のキーを試すだけ。256bit鍵=2の256乗(10進数で78桁)個とは比較にならないくらい少ない。
さらに、検証機で事前にBitLockerの動きとかを解析しておけば、どのあたりが怪しいかってのも見当を付けられるから、実際に試行するキーの数はもっと絞れる。たとえば00が連続してる場所とか明らかにキーじゃないでしょ。
ただこれはおそらく経験と勘。バイナリデータを眺めてなんか目印になりそうなものが見つけられるかどうか。
昔のROMカセット時代とかのファイルシステムの無いゲーム機とかのダンプを見て、ここはプログラムっぽいとかここはデータっぽいとか、そういうのを見分けられる経験と勘。
ほら、やっぱそういうどうでもよさそうな経験って役に立つわけですよ。
とまあ、そんな感じで稼働機からFVEKは取得できます。はい、論文から情報が1㍉も増えてない気もしますがわざとです。
FVEKの取得に関してはこれ以上深いことを書くつもりはありませんし、ツール公開もしません。
さて、ではこれを踏まえた上で、どうすることで安全にセキュリティを確保することができるか。
まず、現状のようにメモリ上に平文でキーが置かれること、これは確実にNGです。
少し難易度を上げると、メモリ上にも平文でキーを置かないこと、もしくは連続で置かないことです。
ただ、これもデバイスドライバの解析でアルゴリズムが解ってしまうので、手間増えるくらいで解析不可能ではありません。
きちんと対応するなら、ハードウェア対応でしょう。
鍵の生成自体をTPMチップで行って、SATA制御チップに暗号解除アルゴリズムを搭載するとか。
もしくは、SSD自体に高度な暗号機能を搭載するとか。
ちなみに、現状でもSSDに暗号化機能はATAの仕様としてありますが(RINGEDGEで採用されている奴です)、バス上にキーが平文で流れるので、ATAのプロトコルアナライザを使うと簡単に解除できます。
これをDH鍵交換みたいな手順でホストと交換したりするようになるとどうしようもないですね。
ハードウェアとしては仕様が決まればそんなにコストがかかる物では無いでしょうから、いずれはこんな感じになるんでしょうか。
もしかしたら最新に仕様を知らないだけで、すでにそういう物があるのかもしれませんが。
ところで仕事先のノートPCが最近Windows10にリプレイスされたときに、TPM+BitLocker(PIN無し)になったんですが、盗まれたりすると全然安心できないってことですね！！！
Windows7のときはサードパーティーの暗号化ソフトでかつ解除キーは毎回手入力だったんですが・・・。
いいのかこれ？
基本的にはコールドブートアタックといわれる技法。
既にセキュリティホールとして報告も上がっている話。
https://www.itmedia.co.jp/enterprise/articles/0802/22/news094.html
ディスク暗号化技術にセキュリティホール、研究者が指摘
さらに詳細はリンク先の論文読むべし。英語わかんないからちらっとしか読んでないけど。
結局のところ、稼働している状態のメモリの中身を覗ければ、そこからFVEKは導き出せるという話。
※というのが脆弱性。この脆弱性って回避できんの？って話は後で。
じゃあどうやって稼働してる状態のメモリの中身を見ようかというところ。
MSX2とか酷使したことある人なら(っていきなりそこか)、メインRAMにROMイメージを読み込んで、ハードリセットしてもイメージが起動するとか、電源を切っても数分は残ってるとか経験はあるはず。
ほら、そういう経験が役に立つわけですよ。
まあつまりリセットしただけではメモリ内容はほとんど失われない訳ですよ。
起動シーケンスで使われる部分は上書きされるけど、それはごく一部。
なので、起動中にSSDを差し替えてリセットすると、メモリ内にFVEKが残った状態で、メモリダンプツールとか起動できる。
この時点でSSDの変更が検出されてTPMのデータが消えて、次回以降正規のSSDは起動出来なくなるので一発勝負。
ちなみに、世の中にそんなツールがあるのかは知らない。
ただ、一つ言えることは、再起動後にOS(特にWindows)を起動した場合、デバイスドライバが読み込まれるメモリ上の場所というのは、ほぼ毎回変わらない。よって、OSを起動してしまうと高確率でFVEKは上書きされて消えてしまう。
なので、MBRにダンプツールを仕組むとかしないとまず無理。
あとはメモリダンプからどうやってFVEKを探し当てるかという話。
この辺も論文にわりと書いてあるけど、仮に実装メモリが1ギガだとすると、総当たりしても(FVEKは全バイト連続して格納されてると仮定して)たったの1ギガ個＝10億個のキーを試すだけ。256bit鍵=2の256乗(10進数で78桁)個とは比較にならないくらい少ない。
さらに、検証機で事前にBitLockerの動きとかを解析しておけば、どのあたりが怪しいかってのも見当を付けられるから、実際に試行するキーの数はもっと絞れる。たとえば00が連続してる場所とか明らかにキーじゃないでしょ。
ただこれはおそらく経験と勘。バイナリデータを眺めてなんか目印になりそうなものが見つけられるかどうか。
昔のROMカセット時代とかのファイルシステムの無いゲーム機とかのダンプを見て、ここはプログラムっぽいとかここはデータっぽいとか、そういうのを見分けられる経験と勘。
ほら、やっぱそういうどうでもよさそうな経験って役に立つわけですよ。
とまあ、そんな感じで稼働機からFVEKは取得できます。はい、論文から情報が1㍉も増えてない気もしますがわざとです。
FVEKの取得に関してはこれ以上深いことを書くつもりはありませんし、ツール公開もしません。
さて、ではこれを踏まえた上で、どうすることで安全にセキュリティを確保することができるか。
まず、現状のようにメモリ上に平文でキーが置かれること、これは確実にNGです。
少し難易度を上げると、メモリ上にも平文でキーを置かないこと、もしくは連続で置かないことです。
ただ、これもデバイスドライバの解析でアルゴリズムが解ってしまうので、手間増えるくらいで解析不可能ではありません。
きちんと対応するなら、ハードウェア対応でしょう。
鍵の生成自体をTPMチップで行って、SATA制御チップに暗号解除アルゴリズムを搭載するとか。
もしくは、SSD自体に高度な暗号機能を搭載するとか。
ちなみに、現状でもSSDに暗号化機能はATAの仕様としてありますが(RINGEDGEで採用されている奴です)、バス上にキーが平文で流れるので、ATAのプロトコルアナライザを使うと簡単に解除できます。
これをDH鍵交換みたいな手順でホストと交換したりするようになるとどうしようもないですね。
ハードウェアとしては仕様が決まればそんなにコストがかかる物では無いでしょうから、いずれはこんな感じになるんでしょうか。
もしかしたら最新に仕様を知らないだけで、すでにそういう物があるのかもしれませんが。
ところで仕事先のノートPCが最近Windows10にリプレイスされたときに、TPM+BitLocker(PIN無し)になったんですが、盗まれたりすると全然安心できないってことですね！！！
Windows7のときはサードパーティーの暗号化ソフトでかつ解除キーは毎回手入力だったんですが・・・。
いいのかこれ？
続続 SEGA nu
2019.01.14
さてさて、文鎮化したとおもわれたNuですが、FVEKは取得できてますね。
OSパーティションの他にBitlockerがかかっているパーティションは2つ(つまり計3つ)あるんですが、
オートアンロック機能でブート時にOS以外も自動で解除されるんですね。
というわけで、必要な分のFVEKはすべて入手できました。
とすると、別に文鎮化したわけでは無く、起動しないだけで必要なデータはすべて残っていてアクセス可能なわけですね。
なので、特に新たなNuを仕入れてくる必要なないわけでした。
が、まあしかし、キーチップが消されるってのは怖いので。。。
なんか大量に出回ってるキー付きのNu SXを仕入れてみました。
まあこれもたぶんセキュリティ的には同じ構成のようで、SX用のキーチップをNuに刺しても普通に認識しますね。当然ゲームは起動しませんが。
で、Nuのセキュリティ関連の構造なんですが、
OSと一部データがBitLockerで暗号化されています。
ゲーム自体はBitLockerが掛かってないパーティションに、HDDイメージとして独自暗号化されたファイルがおいてあります。
NuのインストールDVDに入ってるアレです。
なので、NuSXから暗号化されてるゲームイメージを引き抜いてくることは誰でも簡単にできます。
そうなると、これをNu(SXではないほう)で起動できないかって話ですよ。
これが出来ればキーチップから解除キーを読み出して、ゲームイメージを復号する一連の流れに安心してデバッガとかかけれるわけですね。
・・・・がんばりました。
NuSXのゲームイメージの展開までは成功しました。
日本語のコメントがあるっていいですよね・・・。
まだ解析できてない部分が多々あるので、本命キーチップでやろうという気はまだしませんが、
これでキーチップのダンプとHDDイメージの復号処理の解析はかなり進みそうです。
OSパーティションの他にBitlockerがかかっているパーティションは2つ(つまり計3つ)あるんですが、
オートアンロック機能でブート時にOS以外も自動で解除されるんですね。
というわけで、必要な分のFVEKはすべて入手できました。
とすると、別に文鎮化したわけでは無く、起動しないだけで必要なデータはすべて残っていてアクセス可能なわけですね。
なので、特に新たなNuを仕入れてくる必要なないわけでした。
が、まあしかし、キーチップが消されるってのは怖いので。。。
なんか大量に出回ってるキー付きのNu SXを仕入れてみました。
まあこれもたぶんセキュリティ的には同じ構成のようで、SX用のキーチップをNuに刺しても普通に認識しますね。当然ゲームは起動しませんが。
で、Nuのセキュリティ関連の構造なんですが、
OSと一部データがBitLockerで暗号化されています。
ゲーム自体はBitLockerが掛かってないパーティションに、HDDイメージとして独自暗号化されたファイルがおいてあります。
NuのインストールDVDに入ってるアレです。
なので、NuSXから暗号化されてるゲームイメージを引き抜いてくることは誰でも簡単にできます。
そうなると、これをNu(SXではないほう)で起動できないかって話ですよ。
これが出来ればキーチップから解除キーを読み出して、ゲームイメージを復号する一連の流れに安心してデバッガとかかけれるわけですね。
・・・・がんばりました。
NuSXのゲームイメージの展開までは成功しました。
日本語のコメントがあるっていいですよね・・・。
まだ解析できてない部分が多々あるので、本命キーチップでやろうという気はまだしませんが、
これでキーチップのダンプとHDDイメージの復号処理の解析はかなり進みそうです。
続 Sega nu
2018.10.12
はーい。OSのパーティションのFVEKと引き替えにNu死にました。
OSパーティションは見れるようになったので、
一応TPM保護は破ったことにはなる。
だがそれだけ。それだけでしかない。
次回はもっと注意を払ってやろう。
なにせ、「つぶしてもいいNu]が手に入ったんだから。
でも、手を入れた状態でキーチップ刺すのすげー怖いんだよな－。
自己書き換えチェックとかにひっかかったらキーチップ消されそうな気がする。
RingEdgeみたいにそのうちインストールDVDと対応するキーチップ大量に出回ってこないかな。
SEGA Nu
2018.08.05
今更SEGAのNu基板仕入れてきました。
IOこんな感じです。
※クリックで拡大します
中身こんな感じです。
SSD(64GB)とHDD(500GB)の2台構成。
※クリックで拡大します
SSDとか外すとこんな感じ。
※クリック(ry
M/Bの品番はDAC-BJ05と記載ありますが、Advantech AIMB-582のカスタム品と思われます。
あと特記することといえば、オプション扱いのTPMが載っていることでしょうか。
ちなみに、SSD/HDD共にブートドライブからBitLockerで暗号化されているので、TPMは使用されていると思われます。
キーチップはこんな感じです。
単なるUSBドングルっぽいんですが、中身はこんな感じです。
普通のPCに刺した瞬間にデータ消えたりするといやなので、どう認識するかとかは不明です。
※クリック(ry
起動ドライブはMBRなので、TPMでBIOSに守られてるってことは無いと思うんだけど、
この辺の挙動は正直詳しく知らないのです。
起動はしてるんだから暗号化キーを抜けないことは無いと思うんだけど、BIOSが隠してたら超面倒だなあ。
IOこんな感じです。
※クリックで拡大します
中身こんな感じです。
SSD(64GB)とHDD(500GB)の2台構成。
※クリックで拡大します
SSDとか外すとこんな感じ。
※クリック(ry
M/Bの品番はDAC-BJ05と記載ありますが、Advantech AIMB-582のカスタム品と思われます。
あと特記することといえば、オプション扱いのTPMが載っていることでしょうか。
ちなみに、SSD/HDD共にブートドライブからBitLockerで暗号化されているので、TPMは使用されていると思われます。
キーチップはこんな感じです。
単なるUSBドングルっぽいんですが、中身はこんな感じです。
普通のPCに刺した瞬間にデータ消えたりするといやなので、どう認識するかとかは不明です。
※クリック(ry
起動ドライブはMBRなので、TPMでBIOSに守られてるってことは無いと思うんだけど、
この辺の挙動は正直詳しく知らないのです。
起動はしてるんだから暗号化キーを抜けないことは無いと思うんだけど、BIOSが隠してたら超面倒だなあ。