14/11/29 08:34:59.39 5y3gKMVX
将来の4ｋ、8ｋ用のカードの研究の可否をどうするかだが。
3:名無しさん＠編集中
14/11/29 09:02:27.59 qGsVmWdQ
M003 CA35ってカードがあるんだが
これってツールでいけるの？
ググっても情報がないよ
4:名無しさん＠編集中
14/11/29 09:23:08.98 w7+nK9CJ
>>2
4K解像度放送でもBS/CS110にはB-CASがそのまま使われるのでは？
>>3
M003は多分ハズレ
ついでにTRMPの解析や研究もしていいと思う
5:名無しさん＠編集中
14/11/29 09:58:21.60 vN+MV32r
>>ｽﾚﾘﾝｸ(avi板:992番)n-
とりあえず、N_MAXを増減させてみたのですが、
増やしすぎると逆に悪影響が出るっぽいです。
URLﾘﾝｸ(i.imgur.com)
乱数の取り込みはこれからやってみます。
6:名無しさん＠編集中
14/11/30 10:25:23.40 gQxqcNr/
前スレ
ｽﾚﾘﾝｸ(avi板)
7:名無しさん＠編集中
14/11/30 18:12:52.39 gQxqcNr/
SpeedyBCAS0XReverseKeyScheduler 1.1
URLﾘﾝｸ(www.unkom.info)
i7 965定格で20秒弱です
8:名無しさん＠編集中
14/11/30 19:46:28.06 gQxqcNr/
前スレ981の
> ・c3はBFでなく正規の手順で取得する
がよくわからなかった
9:名無しさん＠編集中
14/11/30 21:18:53.74 dkqjOv3C
いちいちコンパイルしなくてよいように改造してみました。
r0～r1 → r0123 に一本化
usage: r0123 [subkey1 [subkey2 [subkey3]]]
e0 → fp2sk
標準入力から0or1のみ取り出してfpとして解釈します。
OpenMP対応。
URLﾘﾝｸ(pastebin.com)
解パスはLv2
10:名無しさん＠編集中
14/11/30 21:27:25.28 v5aU5ZWb
>>4
BS、110度CSの4ｋ、8kのスクランブル方式はAESやCamelliaになるみたいですよ
11:名無しさん＠編集中
14/11/30 23:28:43.37 eR6ubOG8
>>5
N_MAX増やすのは、EMMを送信する回数を増やしてサンプルとなるデータを増やしているだけなので、
増やし過ぎて悪影響が出る理由は…うーん、何でしょうね
>>8
先にc1を取得すればc3はそれと既知情報から計算できるので、BFする必要は無いと言う意味です
12:名無しさん＠編集中
14/12/01 00:37:28.91 EbZ6ehdR
SpeedyBCAS0XReverseKeyScheduler 1.2
URLﾘﾝｸ(www.unkom.info)
i7 965定格で8秒強です
13:名無しさん＠編集中
14/12/01 00:38:28.23 EbZ6ehdR
>>11
ありがとうございます
おかげさまで最大限の高速化ができました
14:名無しさん＠編集中
14/12/01 02:05:02.39 mk/bsQIQ
逆関数の存在も忘れないであげて！
とりあえず、最後の回転とXORのところはただの32元連立方程式だから
がんばって32x32の逆行列を作るだけだよー
15:名無しさん＠編集中
14/12/01 15:13:42.89 EbZ6ehdR
まだ試していないけど
WorkKeyが既知(逆鍵スケジュール等)の場合は
Round0Xの逆処理のようなことはできるかもしれない
私の頭が悪いのか>>14は理解できない
16:名無しさん＠編集中
14/12/01 22:32:21.24 m9elal/F
逆行列はGF(2)上で普通どおりに計算すればいいんですか
17:名無しさん＠編集中
14/12/02 00:24:29.24 ICKxV0zI
そだよー
知らない人向けに書くと
Y = X ^ rot8(X) ^ rot1(X)
みたいなのをXについて解くには、とにかくビットごとに方程式を書いて、
y0 = x0 ^ x24 ^ x31
y1 = x1 ^ x25 ^ x0
y2 = x2 ^ x26 ^ x1
...
y31 = x31 ^ x23 ^ x30
を頑張ってといて
y? ^ … ^ y? = x0
y? ^ … ^ y? = x1
に変形すればいいじゃよ。中学のときみたいに式を足したり引いたりすればいんだけど
ここでは足し算のかわりにxorするとよい
18:名無しさん＠編集中
14/12/02 03:29:48.49 WuXhVPPy
IsOddParity()の部分はやっぱりとりあえず計算しちゃって検算かな
あんまりきれいじゃないけど・・・
19:名無しさん＠編集中
14/12/02 09:23:50.60 J/FkdOJN
SpeedyBCAS0XReverseKeyScheduler 1.3
URLﾘﾝｸ(www.unkom.info)
結果チェックを追加しました
速度はあまり変わっていません
20:名無しさん＠編集中
14/12/02 21:50:21.91 gMrbY8o2
>>19
>>17で懇切丁寧に説明してもらっても理解できなくて
BFAするしかないか…
うんコムは低学歴/子供オーラが出てるんだよな
普通の理系大学でてたら>>17見たら「あーそうすりゃいいのか」っていう
感想になるとおもうんだよな
21:名無しさん＠編集中
14/12/02 22:41:26.36 J/FkdOJN
低学歴低能キモデブで悪かったな
22:名無しさん＠編集中
14/12/02 22:47:26.79 J/FkdOJN
それっぽいところまで行った
URLﾘﾝｸ(pastebin.com)
23:名無しさん＠編集中
14/12/03 01:47:14.01 P+O+m426
>>11
助言、ありがとうございます。
現状、こんな感じで、USBカードリーダではデータ収集が非常に厳しい環境だという事がわかりました。
URLﾘﾝｸ(i.imgur.com)
使用カード:T422CA23(BackDoor有)すべて同一カード使用にて計測。
PCMCIAでこれだけきれいなデータが取れれば、"found"が来てもおかしくないのでは？と考え、
過去スレを読み直したところ.....ありました！
ｽﾚﾘﾝｸ(avi板:836番)
『hoge++が必要と言う意味です』これ！やってませんでした。ごめんなさい。
って事で"found"が来るようになりました。
結果が出たらまたご報告させていただきます。
24:名無しさん＠編集中
14/12/03 04:58:50.58 GVd/qfwo
>>22
＞それっぽいところまで行った
どこがだｗ
まだ何もしてないのと同じじゃねーかｗ
25:名無しさん＠編集中
14/12/03 06:30:47.13 acY3H+ob
確かに
c = round00(p, k, 0);
に対して、
p == rround00(c, k, 0);
となる関数がつくれる事を確認しました
連立方程式は適当にコード書いて解きましたが、最終的に
x0 = y4 ^ y11 ^ y12 ^ y18 ^ y20 ^ y25 ^ y26 ^ y27 ^ y28
みたいになるのをシコシコ手で解くよりは、その方が正解なんでしょうね…
しかし言われてみればなるほどで、結構単純な話なんですねー
勉強になりました
26:名無しさん＠編集中
14/12/03 06:34:58.45 acY3H+ob
>>23
おお、PCMCIAのは十分行けそうな感じですね
(なるべく正確な測定をする事を含め)閾値を正しく設定するのが最大かつ唯一のハードルだと思いますが、
画像のデータを見る限りそこは大丈夫そうな感じなので、後は特に詰まる部分は無いかと思います
ちなみに、バックドア有りカードなら、先にKmからサブキーを計算しておいて、
eでの検出結果と実際のサブキーが正しいか確認しながら進むと確実ですよ
そう言う事せずにやる方が達成感有って楽しいかもしれませんけどねー
27:名無しさん＠編集中
14/12/03 11:29:26.29 h4PvSMPl
>>22
ここから進めずに困ってるんよ
28:名無しさん＠編集中
14/12/04 07:19:09.75 a0e5T/cN
>>27
まずその方程式解いて、後は特に何も考えずに処理を逆に辿るだけでしたよ
当方は方程式はこう言う感じで解きましたが、適当に思いついたのをコードにしただけなので、
方法として正しいかどうかはわかりません
＃一応、答えはあってる様です
URLﾘﾝｸ(pastebin.com)
29:名無しさん＠編集中
14/12/04 10:38:27.04 9mCd1qEd
>>28
割とシンプルなんですね
32元あるので難しく考えすぎてました
ありがとうございます
30:名無しさん＠編集中
14/12/04 14:54:11.32 9mCd1qEd
BCASProtocol0XReverseKeyScheduler 1.0
URLﾘﾝｸ(www.unkom.info)
逆関数を実装
31:名無しさん＠編集中
14/12/04 20:40:46.96 a0e5T/cN
ちなみに回転とxorの組み合わせで、同じ様なパターン(=入力に対して出力が重複していないパターン)なら、
64元でも128元でも同じ仕組みで解けると思いますよ
＃そのソース内の固定値32を必要ビット数に変えるだけです
xorの回数が増えても、変換前の式設定時点でのフラグ立てる数を増やすだけなので、そこそこ汎用的な部品に
なってる気はしますね
もっとも、それが必要な状況になんて殆ど遭遇しなさそうですが
32:名無しさん＠編集中
14/12/05 08:33:54.30 qNxgN5qV
>>30
ソースはよ
33:名無しさん＠編集中
14/12/05 09:25:51.13 6tsI1X0f
逆関数の部分が汚い気がするけどええんかな
34:名無しさん＠編集中
14/12/05 11:44:44.71 7+UHvJqU
というわけで、逆関数が分かれば逆スケが速くなるので、
もう一段2^32のループを行うことができて、そうすれば全部のサブキーを使わなくてもいいような気がしてる。
んだけども、全然試せてないので君たちにまかせた！
35:名無しさん＠編集中
14/12/05 12:37:55.00 6tsI1X0f
BCASProtocol0XReverseKeyScheduler 1.0のソースコード
URLﾘﾝｸ(www.unkom.info)
36:名無しさん＠編集中
14/12/05 16:13:32.61 3x5hQhvB
それ何のソフト？
37:名無しさん＠編集中
14/12/05 16:32:26.81 6DduKXKJ
残り6ファイル
★Oishii.rar: 10631CCAD0061038
├files.txt(ファイルリスト)
└★Treasure.rar: 67.228.212.146
├★NetCasAdmin.rar: f-cas.com
└★Level2.rar: Oishii Slurper
├★BCAS Server.rar: yakisoba sousu
├★BCASEMU.rar: 同上
└★Level3.rar: 0000-3100-0596-4944-2958
├☆AE330-TechReMain.rar:
├☆BCASEMU.rar:
├☆BCAS-for-AT9028515FUNCARD.rar:
├☆bcas-km-database.rar:
├☆IDtoKM-Converter.rar:
└☆T002CA20-ae330.rar:
38:名無しさん＠編集中
14/12/05 17:31:04.21 P1iqeArc
C言語版
URLﾘﾝｸ(pastebin.com)
39:名無しさん＠編集中
14/12/05 18:30:56.68 P1iqeArc
動作確認用
URLﾘﾝｸ(codepad.org)
40:名無しさん＠編集中
14/12/05 19:31:02.83 gTcSpfmn
>>34
拡大鍵の前半8バイトがわかっているなら話は簡単ですが、拡大鍵は後ろから判明して行くので、
前半だけがわかっていると言う仮定はあんまり意味無いですよね
なので、拡大鍵の一部が判明している状態と言うのは、拡大鍵の後半の4、8、あるいは12バイトだけが
わかっている状態とほぼ同義かと思います
その上で、BlockCipher()(当然その逆処理も)は、キーが決まっていれば入力/出力が1対1になるのは
わかったのですが、入力と出力だけが判明している場合のキーの一意性は保証されていないですよね？
入力と出力からキーをBFして、1つしか見つからなかった場合は問題無いと思いますが、複数見つかった
場合はそのどれが正しいのかを知る手段は無い気がするのですが、間違っているでしょうか？
＃一応、見つかったキー候補全部から有り得るパターンの全Kmを候補として取得し、そのKm候補
＃それぞれでEMMを作成して実機に食わせてみると言うローテクな手段なら存在しますが…
41:名無しさん＠編集中
14/12/05 22:57:15.30 7+UHvJqU
12バイトあればKm候補はほぼ確実に1つしか見つからないはず。
だめな確率は1/2^32だからありえない。
8バイトだと確率の計算が複雑になりそうだけど、数個しか見つからないはず・・・たぶん
4バイトだけだと情報量的に無理
やっぱり気になってきたから自分で試したくなってきたぞ
42:9
14/12/06 00:49:30.54 u81getUm
URLﾘﾝｸ(www1.axfc.net)
全EMMコマンドの事前生成と一括転送
エンディアン依存性の排除
環境変数によるパラメータ設定
windows/linux対応
fp確認に便利なしょぼいグラフ表示 URLﾘﾝｸ(imgs.link)
解パスは定期的に貼られてる中のどれか
例によってbc.cppだけは実装を伏せてあります。
ここの住人なら自前でやっちゃうレベルの改造ですがよかったらドウゾ。
43:名無しさん＠編集中
14/12/06 01:02:53.23 u81getUm
rの出力fp行だけ標準出力になってますのでeにパイプして使えます。
$ ./r | ./e
44:名無しさん＠編集中
14/12/06 02:51:43.28 u81getUm
URLﾘﾝｸ(pastebin.com) 修正パッチです(；´Д｀)
45:名無しさん＠編集中
14/12/07 03:53:53.58 baUQaleD
ソースファイル全てのreverse32を取っ払って
store_leをsotre_beとすれば、eを少し速く回せますね。
46:名無しさん＠編集中
14/12/07 16:25:23.58 zQRLbbV+
かなり遅れたけどC-CASのATR
3B F0 12 00 FF 91 81 B1 EF 45 1F 03 0A
47:名無しさん＠編集中
14/12/07 17:42:45.69 baUQaleD
速くて無理かと思えていたM002CA20(バックドア有り)ですがPCでfp採れました。
linuxでpcscd以外起動していないシングルユーザーモードにて採取。
マシンは普通のノートPCです。
URLﾘﾝｸ(pastebin.com)
# 差もはっきり出ていますし、既知のKmから作ったｆｐとも一致。
あと、linux64bit環境だとr.cpp:teeprintfでsegfaultしたので
以下の様に修正たところ大丈夫でした。
@@ -136,6 +136,8 @@
va_list ap;
va_start(ap, fmt);
std::vfprintf(stderr, fmt, ap);
+ va_end(ap);
+ va_start(ap, fmt);
std::vfprintf(fp, fmt, ap);
va_end(ap);
48:名無しさん＠編集中
14/12/07 20:54:45.18 LbbUkcrZ
>>26
r0は何回やってもきれいなグラフになるので問題無いと思うのですが、
r1をやるとTHRESHOLDラインの前後を行ったり来たりのヘロヘログラフになっちゃうんですよ。
たぶん、BlockCipher()の修正を間違えていてe0でSUBKEY_1が正常に出せていないのではないかと...
なにぶん頭が悪いのでサブキーの計算方法もわからないからSUBKEY_1が正しいのかさえわからない状態です。
49:名無しさん＠編集中
14/12/07 21:57:06.36 baUQaleD
>>48
Kmが既知ならサブキーの計算は>>39のmain関数をよく見れば判ると思うよ
50:名無しさん＠編集中
14/12/07 22:42:13.58 baUQaleD
0,1,0,1,0,1,1,0,0,1,1,0,0,1,0,1,0,0,1,1,0,1,0,0,0,1,0,1,1,0,0,0
このfpで50e1bddbともう一つが出てくればBlockCipherは合ってるはずだよ
ちょっとコーヒーでも飲んでくるわ
51:名無しさん＠編集中
14/12/08 02:43:49.69 a0OW4C3h
なんにしましょう ＞(´∀｀)
( ´_ゝ｀)＜ フレーバーコーヒー16くれ
3つで十分ですよ ＞(´Ａ｀;)
( ´_ゝ｀)＜ いや16だ、8と8で16だ
3つで十分ですよ ＞(´Ａ｀;;)
( ´_ゝ｀)＜ ドーナツもくれ
解ってくださいよ ＞(´Ａ｀ )
52:名無しさん＠編集中
14/12/08 07:27:55.80 Ynxpe70Z
>>49-50
遅レス、大変申し訳ない。
main関数の『int i;』が理解できたところで睡魔に襲われてしまい、
激闘の末！さっき、撃退しましたのでご安心ください。
0,1,0,1,0,1,1,0,0,1,1,0,0,1,0,1,0,0,1,1,0,1,0,0,0,1,0,1,1,0,0,0 -> found: 506135d3
なんじゃこりゃ！？やっぱBlockCipher()だ！！
同じミスをしない為にも恥を忍んで原因を記載しておきます。
原因:Cipher.Short[0]と[1]の行をコメントアウトしてました(爆)
理由:コンパイル時にエラーになったのでコメントアウトして忘れてた。
結果:
found: 50e1bddb
もうひとつは、これですかね？
found: badcaffe
>>51もヒントだったわけですね。ありがとうございます。
サブキーの計算についてはこれから勉強させていただきます。
53:名無しさん＠編集中
14/12/08 12:21:43.52 UwtcgnuV
当方もブレードランナーは好きな映画ですが、話自体は原作の方が好きです(´ー｀)
>>47
おお、これだけきれいに差が拾えるなら行けそうですね
カウンタの解像度が1GHzあるのもさることながら、シングルユーザモードも効いてそう
ここまで来ると穴なしカードでどうなるのか知りたいところ…
54:名無しさん＠編集中
14/12/08 20:03:02.06 d9xs7NlA
BCASProtocol0XReverseKeyScheduler 1.0.1
URLﾘﾝｸ(www.unkom.info)
主な変更
・逆鍵スケジュールの関数化
・ビットインデックステーブル処理修正
・日本語化
55:47
14/12/09 02:31:51.59 Ko1FuCQq
>>53
恥ずかしながら原作はまだ読んでないですねぇ。
そういえば、イラストを来年の干支に差し替えて年賀状を刷るよう
親から言付かっていたのを思い出しました…(；´∀｀)
まぁそんな事はどうでもよくて、先のMカードについてです。
r1以降は試していませんでしたので改めて試してみたのですが、
ちょっとだけ手間取りました。
一見良好なｆｐに見えても正解じゃない場合が有りました。
正解fpと比較して１ビット違いのｆｐが出てくるという現象です。
しかも割りと安定的に出てくるのでタチガワルイ。
違いは最初の１ビットだけで、1が来てほしいのに0。
現象はr1でのみ発生。少なくとも手持ちのTでは無かった事ですね。
最終的には、
N_MAXを大幅に増やすこと(BLOCK_NUM*512)で正解を得ることは出来ました。
＃L値ランダムのアリ、ナシ両方で正解を得られました。
以上のような事が有りましたので、
Mに挑戦する方は気に留めておくと良いかもしれません。
56:名無しさん＠編集中
14/12/09 15:23:13.29 7coCRu3A
初段のサブキーのビットパターンがなんだかうまい形に偏ってると、
連番でやってるLの生成とうまく相関しちゃって、初段の速度が偏るんじゃないかな？
二段目をやるときは、初段はランダムに動いてくれるのが理想なので、
Lの生成を乱数でやればよくなるのかも？
57:名無しさん＠編集中
14/12/10 19:48:38.74 YKiMDlMR
よく見たらランダムありって書いてあったすまそ。
しかし、これは理屈がよくわからないぞ