SoftBankの.hufで保護されたコンテンツについて
今後SHA-1端末でネットワーク自動調整できなくなる予定なので、
ネットワーク自動調整で復号化キーを取得できなくなり、
何かしらのタイミングで復号化キーが消失すると、
ネットワーク自動調整が表示されても今まで利用できていた。
.hufで暗号化されたピクチャーや着メロやFlashなども表示できなくなります。
特にS!アプリは復号化と動作手段がなくなるのでこれで携帯コンテンツはほぼ終了となります。
ご注意ください。 本日SoftBankの旧世代機からのネットワーク自動調整不可を確認しました。
長い歴史に幕が降りたようです。
携帯コンテンツに感謝。 hufの暗号化とネットワーク自動調整は無関係では? 長いこと調査した結果、解約後では必要な鍵が確認できず自力で復号は本当に不可能なのがわかったよマミー 俺も.hufの画像をどうにか復号化したいんだけど全然情報がない
データを捨てる踏ん切りが付かなくてガラケーが現役だよ
誰か復号化の方法を教えてください 復号できたという報告は個人のブログに一つあったぐらいかな?
本当に出来たのかどうかやや怪しい内容だったけど 使ってる鍵やアルゴリズムの特定に繋がらないか特許情報を見たけど
内容は暗号化してヘッダを付ける、ヘッダを見て復号するものだった その際に整合性を見るハッシュのようなものを付与してるみたいだったけど、
hufのヘッダにはそこまで多くの情報が載せられてるようには見えない 電話番号が鍵だと各所にあったので色々試したけどダメだったよ
usimの中も覗いてそれらしい値もあれこれ試したけど× んで移行先と移行元で常に同じ値を取るものを鍵と考えて、どれが共通するのか推理
しかし、端末の中にはそれが入っていない、usimの中にも入ってない 加えて電話番号の残ったusimでも復号できない
暗号化について調べていくと、鍵として11桁の数字は適当ではない 2003年頃の情報を追っていくと、J-SH51のインタビュー記事に答えっぽいものが書いてある
https://www.itmedia.co.jp/mobile/news/0111/16/super.html
> ユーザーごと振られるIDに基づいて暗号化が行われるためセキュリティも万全だ。 そしたらこんなものが
https://ja.wikipedia.org/wiki/契約者固有ID
16桁の大小英数からなる値なので暗号鍵としては適当
しかし解約後では確認できないので自分で試せないのが悔やまれる そんな記事があったのか
参考になります
こちらはアルゴリズムの推測もままならないんだけど、どうやって検証したのか差し支えなければ教えてほしい 0x08-0Aに元のサイズが格納されてて、元のファイルサイズが8の倍数の場合はヘッダ分しか増加しない
足りない場合は常に8の倍数に埋めて(パディング)暗号化しているので、64bitブロック暗号だと判る 暗号化のたびにまったく違うファイルになるので、CBCモードが使われている模様
0x0B-12の8バイトの値は、初期化ベクトル(IV)もしくはSaltだと考えられる 64bitブロック暗号はBlowfish、DES、3DES、DESX、RC5、RC2、IDEA、MISTY1、FEAL...
J2MEではBouncy Castleというライブラリが使われているようで、含まれる64bitブロック暗号のアルゴリズムは、
3DES、Blowfish、CAST5、IDEA、GOST >>13-14の存在に気づいて、自分の検証はここで頓挫しました
uidは契約地域の1文字目、常に数字をとる2文字目程度しかもうわからず、
スパコン使わないと破れない厖大な組み合わせなので・・・
契約中なら自分でuidを取得して試すことができそうです
x_jphone_uidで調べると詳しいことが出てきますので