  |
はてなキーワード: 初期化とは
http://www.alexkyte.me/2016/10/how-textsecure-protocol-signal-whatsapp.html これエキサイト翻訳か？主語が全部theyという支離滅裂な英語なんだが。
----
TextSecureの目標は「経路末端までのセキュリティ、否認性、前方秘匿性、将来の秘匿性のすべて」を提供することである。具体的には、可能な限り短い時間だけ鍵情報を保持するメッセージストリームを二者の間に構築するということを目指す。将来に鍵の危殆化があっても、現在観測されたトラフィックを復号化できなくするのだ。
以下にSignal Protocolの批評的分析を羅列してある。実装の構造を研究し、発見した欠陥を記述し、上述の目標がどれほど実現されているかを評価するものである。まず仕組みの説明をしてから、より詳細な分析を続けることにする。
TextSecureは、今ではSignalと呼ばれているアプリに与えられた名の一つだ。コードも文書も一貫してTextSecureという名を使っている。一貫性を保つため、システム全体をTextSecureと呼ぶことにする。
TextSecureは、非同期整合性に焦点を当ててOff-The-Recordというチャットプロトコルを改造したものだ。OTRが対話的ハンドシェイクを必要とする一方、TextSecureは不確定な遅延を認めない。メッセージを送れるようになるまでアプリを表示したままにしてハンドシェイクを遂行しなければならないというのであれば、ユーザ体験はひどいことになる。
そうではなく、通常の鍵交換においてサーバが果たす役割の部分だけ、将来のクライアントが取得しに来るよう中央サーバに格納される。このサーバは、すべてを復号化できる鍵情報は預けておかない、信用なし経路となる。すべての暗号化は末端どうしだ。
TextSecureは暗号学の基礎のほんの一部を使うものである。公開鍵暗号は楕円Diffie-Hellmanを通し、Curve25519を用いて実行される。AESがパディングなしカウンター(CTR)モードとサイファーブロックチェーン(CBC)モードの双方で対称暗号に使われる。HMAC-SHA256がメッセージ認証に使われる。これらが信頼の基礎(TCB)である。
TextSecureの暗号化エンジンの中心部はAxolotlダブルラチェット・アルゴリズムである。大まかに言うと、一方向にだけ回ることのできるラチェットが二つあり、一つは受信ラチェット、もう一つは送信ラチェットである。この構造により、鍵交換の前半を保管しておいて、後から非同期的に再生し完全なハンドシェイクを得ることが可能になっている。
受信ラチェットはメッセージが受信されるときに使われるが、そこには次の鍵交換のための新しい材料が含まれていなければならない。この材料が後ほど暗号化やメッセージ認証に使う対称鍵の生成に用いられる。
送信ハッシュラチェットは前回の整合性ある共有秘密から生成された鍵ストリームを使って新たな鍵セットを生成する。このラチェットは、受信ラチェットが進んで共有秘密が変化するとリセットされる。
ここで注目すべきは、メッセージを送信するために送信者が待つ必要は一切ないということだ。いつでも送信の第一歩を踏み出すことができ、その一歩は必ず有限の時間で終わる。メッセージはすべて異なる対称鍵で暗号化されるが、これにより、ある時点の鍵は、どちら側のデバイス上のものであっても、過去に送信されたメッセージを復号化するためには使えないことになる。(ただし後で一つ警告がある。)
登録は、クライアントに言って、連絡用の電話番号をサーバに教えてもらうことから始まる。また同時に、トークンを通話とSMSどちらで受け取りたいかの希望も登録してもらう。このトークンが持ち主の証明となり、TextSecureで情報を登録できるようにしてくれる。
クライアントはメッセージ認証と暗号化の対称鍵('signaling'鍵)、および長期公開鍵を送る。
また、複数のプレ鍵も送信する。これはクライアントが受信者になる時の鍵交換の半分、クライアント側部分の使い捨てコピーである。こうして保管されているプレ鍵のおかげで、将来の送信者はクライアントの応答を待つ必要もなく鍵交換を完了でき、こうして遅延を劇的に減らすことができる。クライアントは「最後の手段のプレ鍵」もアップロードするが、これは最後に使われ、受信者が新しいプレ鍵を追加するまでのセッションでずっと共有され続ける。
他のクライアントからも使われるプレ鍵に頼ることについてSignalが警告をしないというのは、筆者の意見では、理想と程遠い。
クライアントは次にGoogle Cloud Messagingに登録して、登録IDをTextSecureに出す。このTextSecureへの登録には、クライアントがSMSを受け取りたいかデータだけにしたいかの情報も含まれる。
TextSecureはクライアントどうしがお互いの長期鍵のフィンガープリントを比較して本人確認できるようになっている。鍵をQRコードとして表示して便利に検証できるようにする機能も含まれている。
送信者は、まず相手のプレ鍵を要求し、プレ鍵インデックス、プレ鍵、登録ID、長期公開鍵をもらう。これらを使い、HKDFという鍵派生アルゴリズムを通して共有秘密を取り決める。この秘密情報をルート鍵と呼ぶ。
このメッセージだけの一時鍵ペアが生成される。ルート鍵を使ってHKDFで新しいルート鍵とつなぎ鍵を派生させる。このつなぎ鍵は、暗号化とMACの鍵を生成するのに使われる。
最後にAESカウンターが初期化される。カウンターは二つある: ctrとpctrだ。ctrカウンターはメッセージ送信ごとに増える一方で、pctrカウンターは、最後の既読メッセージの番号を保持する。これにより、受信者側にバラバラの順番で届いたメッセージを正しく並べ直すことができる。
これらを使って相手にメッセージを暗号化し、それをSignalサーバに送る。このメッセージには、相手が鍵交換ハンドシェイクを完了できるだけの必要情報が含められている。
SignalサーバはGoogle Cloud Messenger登録IDが件の電話番号に合っているかチェックし、メッセージを'signaling'鍵で暗号化してからクラウドサーバに送る。この遠回しな方法により、Google Cloud Messengerがメッセージの送信元を知らずにいることが保障される。
受信者はプレ鍵インデックスを受け取り、送信者がどのプレ鍵を使ったかをそれで調べる。そして送られてきた情報を使ってハンドシェイクを完了したり送信者と同じルート鍵を持ったりする。送られてきたメッセージを復号化するために使う鍵は、このルート鍵が生成する。
相手が返信する前に、もとの送信者から続きのメッセージを送りたい場合は、新しいつなぎ鍵を生成して、これを使って新しい暗号化およびメッセージ認証の鍵を得る。
受信者が返事を出したい時は、まず新しい一時鍵ペアを選ぶ。送信者の一時公開鍵と自分の一時秘密鍵を使って、新しい共有秘密を生成する。これを使って新しいつなぎ鍵を得て、そこから新しい暗号化と認証の鍵を得る。これを使ってメッセージを暗号化し、さきほどの新しい一時公開鍵と一緒に送信する。
TextSecureは、サーバとクライアント間の共有秘密、いわば機械生成パスワードを使って、新しいプレ鍵のアップロードを認証する。これは送信メッセージの認証にも使われる。このパスワードを漏らしてしまうと、それだけでメッセージの送信も鍵アップもそのユーザになりすましてできてしまうことになる。エキスポート機能があった頃はTextSecureクライアントを別のスマホに移行することができたが、この機能は削除された。エキスポート情報には機械生成パスワードが含まれていたからだ。この平文バックアップはデバイスのSDカードに置かれていたので、他のアプリから読むことができたのだ。
この機能はそれ以来削除されたままだ。なくて困る人がいるとしても、これはユーザビリティの問題ではなく、現実の問題であり、それに対する後ろ向きな対策なのである。
この攻撃は偽配送の一種だ。攻撃者がUKS攻撃を実行すると、ある送信者が攻撃者に向けて送ったつもりのメッセージが、攻撃者から別の人(標的)へのメッセージとして送信される。
これは能力のある攻撃者にとっては簡単にできる。TextSecureサーバ上にある自分の公開鍵を、標的の公開鍵に変えればいい。これは自分の電話番号を再登録すればできる。送信者はQRコードを使って、相手のフィンガープリントが合っていることを検証できるが、これが本当に標的の鍵のフィンガープリントになるのである。
それから、今度は送信者のアカウントを再登録して、その検証SMSか確認通話が送信者に到達しないよう横取りしなければならない。これは太っ腹に権限を与えられた人には造作もないことだ。こうして、送信者として認証し、既知の署名つきメッセージを送信できるようになる。
この攻撃はTextSecureでは解決されていない。プレ鍵の署名は追加したが、まだ暗号学的にIDと関連付けられているわけではないので、奪われて再生される危険がある。
できることがあるとすれば、送信者と受信者の双方がメッセージの暗号化された本文内で言及されるようにすることなどだ。
TextSecureはその構造のおかげで前方秘匿性を獲得している。前方秘匿性(forward secrecy)は、もし長期公開鍵が安全なままであれば、ある時点の対称鍵が漏れても、そのセキュリティ突破は限定的な時間範囲にしか有効でないとする。新しいラチェットのそれぞれに公開鍵が必要であることから、これは達成されている。
完全前方秘匿性(perfect forward secrecy)は、クライアントの持つある時点の鍵が奪取されても、それ以前に送信したメッセージの復号化が不可能である性質と定義されている。このことはTextSecureのwire protocolにより施行されるが、少々ことば遊びに入ってくる。というのも鍵はデバイス上にのみ格納されているので、アプリ上の他の鍵にアクセスすることなく鍵が暴露されることはありそうにない。長期鍵だけではメッセージを復号化できず、ラチェットのステートに対応する一時鍵が必要になるが、これはそのスマホから引き出すことができるので、送信したものの返信されていない(前回のラチェットを使用した)メッセージを復号化できる。これは技術的に言えば「以前の」メッセージの暴露である。
否認性(アリバイ)はさらにあやふやだ。ある特定のメッセージについて、それはだれにでも作成できたのだと言うことは可能だが、その一方で、プレ鍵は公開されているので、TextSecureの中央集中構造が脅威をもたらす。TextSecureサーバは認証とメッセージ転送をするものだが、それを記録することもできる。内容は末端どうしで暗号化されているとはいえ、メタデータは違う。
Analysis Whitepaper:
http://ieeexplore.ieee.org/document/7467371/
Marlinspike, Moxie (30 March 2016). "Signal on the outside, Signal on the inside". Open Whisper Systems. Retrieved 31 March 2016. https://whispersystems.org/blog/signal-inside-and-out/
ハイスペックなWindowsのPCが必要になったので、ドスパラで見繕って1台注文した。
数日後、PCが届いたので開封して電源を入れると...なんとWindowsが起動しない。
BIOSの画面で止まったまま。
社内のエンジニアと一緒にあれこれいじってみたが、
どうやらWindowsがインストールされていないのでは？という結論に至った。
OEMでプリインストールされる方式なので、ディスクやプロダクトキーも付いておらず、お手上げなのでサポートに電話してみる。
自動応答で「混み合っています...」を繰り返すばかりで、数分待ってもつながらず。
諦めて時間をおいてかけなおすこと数回、やっと繋がった。
症状を伝えると、受け付けた人は技術的なことがわからないのか、分かるものから折り返すとのこと。
さらに折り返してくるのを待つはめに。ここまで半日くらいかかっている。
数分で電話がかかってきて、BIOSの画面見つつ設定の初期化などを試みる。がやはりダメ。
そして次に言ってきた対処法が衝撃。
ディスプレイ、マウス、キーボードと、本体につながっている電源を抜き差ししてくださいと。
さらに電源はマルチタップ経由ではなく、直接さすように言われた。
電話やネットが同時に止まってしまうので、厳しい旨伝えると、できるだけ外して電源だけの状態に近づけてくださいと。
これに一体何の意味があるのか。
すると次はさらに内部の電気を放電させるために、電源外して一晩おいてください、それでもダメなら修理になるので、また連絡してくださいと。
しびれを切らしてこちらから「Boot Optionに何も表示されていないし、そういう問題ではないのでは？」と指摘すると、
担当者は若干イラっとした口調で今度は内部のケーブルの抜き差しをしてみてくださいと言われてしまい、開いた口が塞がらなかった。
そしていずれにせよ配送での修理しか受け付けていないようで、送り返す以外に解決方法がないようだ。
翌朝もう一度電話をかけようとして問題のPCを起動した時に、とあることに気づいた。
このPCはHDDとSSDが内蔵されているはずが、HDDしかBIOS画面上に表示されていなかった。
もしや、と思ってフタを開けるとビンゴ、SSDも入っていた。ケーブルの配線を変えてみたらWindowsの画面が表示された。
そもそも一度電源を押して起動確認をすればものの数秒で検知できる問題なのに、それすらなされていないことも衝撃だった。
そのくせ本体には堂々とWindowsのラベルが貼られている...
世の中のPCトラブルはそれで解決されるケースが多くてそういう対応になっているのかもしれないが、
問題解決のサポートをしてくれる窓口としては著しく技術レベルに不安があるので、もうドスパラで買うことはないと思う。
ちなみに仮に送り返すことになった場合は、よりによって佐川指定なので、何から何まで行き届いてダメだということを学んだ。
パチンカスとか言われそうだけど、遊びでパチスロ打つのが趣味です。
今日仕事だったんで、帰りにちょっと新大○保駅前のチェーンに寄りまして。
色々見てると偽物語のaタイプで、それなりに確率がいけてるのがありまして。
高設定なんて信じてないけど、回ってない台には座りたくないので、この台に座りたいなーとよくよく見ると、
つきひフェニックスで画面止まって、あぁ要するにチャンスね。下皿にはフリスクとメダル数枚。
明らかに嫌がらせの放置なんだけど、10分タイマー動いてたみたいなので、ぼけーと待つことに。
ただすぐ待ち飽きたので別の台ペシペシしてると、店員が放置した台でゴソゴソ。
まぁ意地で待つかなと他の台で待って10分。
別に打ちたいわけでもなくなったんだけど、ものすごくモヤっとした話。
またしばらく行かなくていいかな。
Snapdragon820に4GBのRAMをお載せして250ドルちょっとということでお強いと一部で噂のLeMAX2にCyanogenMod13をお載せしたので手順を書く。
購入時のファームウェアはS16であった。
あくまで私の場合はこれで出来たというだけなのでやるときには自己責任で。
失敗して文鎮化しても私は知らん。
http://forum.xda-developers.com/showthread.php?t=2588979 をダウンロードする。
実行すると何か聞かれるのでYYY。
c:\直下にadbというフォルダが出来ていることを確認する。
http://forum.xda-developers.com/le-max-2/development/recovery-twrp-3-0-2-0-unofficial-t3443611
と
http://forum.xda-developers.com/le-max-2/development/cm13-max2-s19-umbrellateam-spainteam-t3471863
zipは展開しない。
You've enterd Fastboot mode. とか書いてある黒背景に青い歯車の画面になったらPCに接続する。
c:\adb\を開き、Shiftを押しながら何もないところで右クリック→コマンドウィンドウをここで開く
＞fastboot oem unlock
＞fastboot flash recovery twrp-X.X.X-1-x2.img
両方ともOkayと書かれていることを確認する。
twrp-X.X.X-1-x2.imgはさっきダウンロードした2つのうち前者のほう。
今度は電源ボタンと音量ボタンの上を両方同時に長押ししつづけて再起動するとtwrpのロゴが出たあと、
下のほうに左から右にスワイプするっぽいものとボタンが2個ある画面になる。
Select Languageで日本語を選び、下のスワイプを左から右になぞってロック解除。
中国語で表記されていて読めない場合には2個あるボタンのうち右側。
警告されるのでyesと打ち込んで実行する。
完全削除後、マイコンピュータ直下にx2というデバイスがいるはずなので、それを開く。
準備のときに後者でダウンロードした++CM13 UmBreLLaTeaM S19_UNofficial XX-XX-201X++.zipを、そのx2の中に転送する。
LeMAX2の戻るボタンを押してトップメニューに戻り、インストールボタンを押す。
インストールするzipを選ぶ画面になるので++CM13 UmBreLLaTeaM S19_UNofficial XX-XX-201X++.zipを選択する。
「インストール後に再起動する」にチェックを入れ、最下段のスワイプをなぞる。
CyanogenModの初回起動は少し遅いので待つ。
CyanogenModが正常に起動してくると最初にセットアップ画面になるのでセットアップする。
以上。
IIJmioのタイプA(データ+SMS)のSIMを挿してAPN設定をしたところ問題なく通信をすることが出来た。
とはいっても、LeMAX2は技適を取得していないデバイスなので通信できることの確認までしか行っていない。
普段はIIJmio直販のZenFone Goをルータ役としてテザリング運用している。
ZenFone Goに載っているCPUはSnapdragon400と貧弱極まりないが、どうせルータとしてしか使わないのでどうでもいい。
CyanogenModはデフォルトでRoot化されているので、RootチェックにひっかかりポケモンGOをプレイすることが出来ない。
設定→端末情報→ビルド番号を連打し、開発者向けオプションを有効にする。
設定→開発者向けオプション→ルートアクセス にて「アプリのみ」を選択し、
おそらくsuバイナリのアップデートが必要とか言われるのでアップデートし、
再起動後SuperSUを開き、設定から「root権限を放棄する」を選択するとRoot化が解除されポケモンGOを起動できるようになる。
おわり。
JavaScriptで、配列を各要素がユニークな新規オブジェクトになるよう初期化したい。
Rubyの
ary = Array.new(8) { Hash.new }
単純な実装としては
const ary = []; for(let i; i < 8; i++){ ary[i] = {}; }
みたいな感じだけれどもこれはなんとも微妙である。ワンライナーで書きたい。
ちょっとかっこつけると
const ary = Array.call(null, ...Array(8)).map(() => { return {}; } );
とか
const ary = [...Array(8)].map(() => new Object() );
とかできなくもないけど、これらもどうにも不格好である。
何かもっとシンプルでクレバーでスマートなやり方はないものであろうか。
const ary = Array(3).map(()=> new Object());
とかできたらよかったのだけれども、残念ながら空要素はスキップされるらしく、これでは空配列が返ってくるから
一旦展開させてundefinedで埋めた配列を生成してからmapしなければいけないらしい。最終的に得たい配列が1つなのに、その前に別の配列を2つも生成するのが気持ち悪い。
http://bbs.kakaku.com/bbs/K0000781884/#19907238
「イベントビューアーに何かないか」とか「リソースモニターで何か変な動きをしている奴はいないか」とか具体的な助言を何一つ与えてやらず、「通話中に勝手に通話アプリの新しいインスタンスが立ち上がる」というような（Windows Phone horrorとでも言うべき）怪奇現象が起きているにもかかわらず、それが「対処」可能で当然であるかのようなことを言っている。要は「俺は起きてないからお前のも起きないはずだ」と言っているだけで、ただの荒らしと何ら変わりない。それとも自分の考えをうまくまとめることのできない、ちょっと足りない奴なのか？
通話中に通話アプリの別のインスタンスが立ち上がるとか、どんなプラットフォームでも対策して当たり前のことだし、もし同じことやろうと思ったらどうすればいいかと考えた時、OPが提供している情報と自分の浅知恵からは想像のしようがあまりない。強いて挙げるとすれば画面が顔に当たって何かの操作が行われてしまっていることだろうが、「電話中に電話をかける」という言い方がまだまだ曖昧なので、いまいち疑わしい（通話アプリ自身が新しいインスタンスを立ち上げるということはないはずだ）。
初期化後インストールしてきたアプリを全部列挙して、そういう怪しいことをしそうなアプリが一つもなければ、あとは知り合いの詳しい人か店員のところに持っていって再現性を確かめるか、一部始終を動画撮影して公開するしかなさそうだ。
と、自分にできることを全部挙げてみるのは簡単なことなので、それをしない奴は荒らしと決めつけても差し支えないだろう。
Windows 10にアップデートできなかったら、それこそ何のためのWindows Phoneなのか…。8.1はもうサポート終わってるんだから…。そもそも10にアップデートできないという問題に遷移するだけじゃないか、8.1に戻して直ったとしても…。やっぱり自分の言っていることが非論理的だってことに気づかないで言っているに違いない。
要は誰にも対処しようがないと言ってもらって安心したいだけなのに、自分が見当もつかないことを言いたくないのか、あるいはそういう心理に対する妙な反発や嫌悪でもあるのか、全部OPのせいにすることに終始している。こういうガジェットを使いこなして全能感と多幸感に浸っているのかもしれない。人間心理に機械ほどの不可解さはなさそうだ。
newしてから渡せば良いと思うよ。
いちいちクラスに分ける理由は、こういう感じで、クラス内の変数にアクセスすれば、画面事の表示とかが簡単に出来る的な？
// Javaの書き方しらん、インターフェースを実装することを定義したい
public class EventHoge : View.OnClickListener {
//画面事の名称
// Javaの書き方しらん、インターフェースのメソッドを実装することを定義したい
public void View.OnClickListener.onClick(View v) {
AlertDialog.Builder dlg;
dlg = new AlertDialog.Builder(MainActivity.this);
dlg.setTitle("画面の名前：" + ViewName); // 画面名称が表示されるイメージ
dlg.setMessage("Hello, サンプル!");
dlg.show();
//＜ーー
}
}
// Androidなにも知らんけど、元増田がボタンにイベントを書く処理が書いてあるクラスのことが言いたい
// そのメソッド
final Button button = new Button(this);
button.setText("ダイアログの表示");
View.OnClickListener ocl = new EventHoge();
ocl.ViewName = "画面その一";
button.setOnClickListener(ocl);
}
}
こんな感じにすれば、画面が二つあって、
その画面の名称を表示するようなボタンを、二つメソッドをコピペして作らなくていい的な？
サンプルは、出来るだけとっちらかさないよう、匿名クラスとか使って、サンプルで紹介したいところ「だけ」を書くんだよね。
だから、そのサンプルがどういう意味かをちゃんと読み取って、自分ならこう書くとか、こう書けるか？ とかを考えてこそ勉強だと思うよ？
今回のレイだと「View.OnClickListener」っていうインターフェイスを実装したクラスを、setOnClickListenerすればいいってことさえわかれば、
匿名クラス？（っていうのかな？ ちょっと用語はよくしらん、クラス定義を使い回さず、その場だけのクラス定義を書く書き方）とかを使わずに、
どういうふうに応用ができるか？ とか頑張れ！
頑張れ！
頑張れ！
はああああああ。
おれはビールを飲む！
うーん？
いや、なんか、通じてないな。
もうちょいサンプル詳しく書くから、サンプルのどこがわからないか言ってくれ。
// Javaの書き方しらん、インターフェースを実装することを定義したい
public class EventHoge : View.OnClickListener {
// Javaの書き方しらん、インターフェースのメソッドを実装することを定義したい
public void View.OnClickListener.onClick(View v) {
AlertDialog.Builder dlg;
dlg = new AlertDialog.Builder(MainActivity.this);
dlg.setTitle("サンプル");
dlg.setMessage("Hello, サンプル!");
dlg.show();
//＜ーー
}
}
// Androidなにも知らんけど、元増田がボタンにイベントを書く処理が書いてあるクラスのことが言いたい
// そのメソッド
final Button button = new Button(this);
button.setText("ダイアログの表示");
button.setOnClickListener(new EventHoge());
}
}
こうやって、クラス分けて書けば、外とか中とか、全く関係なくなるじゃん。
元増田のサンプルだと、メインの中でインターフェースを実装したクラスの実装を書いてるから、中とか外とかがあるんじゃないのか？
自分でクラスとして定義して、そっちで実装すれば、メインは紐づけるだけでよくなって、仮引数？の中で実装しなくてもすむじゃん。
お疲れさまです。
まず全体的に、インデントがおかしいのと「}」が不足しています。
プログラム仕様書とはいえ「}」や「；」は書く必要がないため、もう少し日本語として通じる文章にしてください。
下記の
俺 ＝ 彼女いない歴 = 年齢；
「もし」ではなく、繰り返しを意味する「諦めない」でしょうか？
また「彼女＝フリー;」setupメソッドで「なんかモテそう」を代入していますが、フリーで上書きして問題ありませんか？ その場合「なんかモテそう」の代入処理は必要なのでしょうか？
変数彼女のフォーカスが不明のため、このクラス内だけでは考慮できません。
次に「俺頑張る＋＋」は、人間型の変数俺の頑張るプロパティをインクリメントするという意味でしょうか？
上記のループが回っているときに、このメソッドではない別のメソッドで、変数彼女と俺の友達の値が変更されるため、上記のループの中に条件式があるのでしょうか？
もし、そのためであれば、非同期処理を本当に使う必要があるのか、もう一度設計を見直してください。
そのためでないのなら、ループが始まるまえに、条件式を記載してください。
return 今夜も童貞;
voidなので、値を返すことはできません。
また、条件式の結果によっては、値を返さないケースがあります。
その場合は初期値を返すのか、エラーを投げるのか明記してください。
以上、指摘事項を受けて、修正箇所があれば修正を行い、レビュー結果ドキュメントに修正箇所を明記してください。
また、質問箇所については、レビュー結果ドキュメントに回答もセットで記載してください。
文章でわかりにくいところがありましたら、遠慮なく私のところまで聞きにきてください。
Device Protection（端末保護）ってどれ位認知あるんだろう？
店頭では、「初期化済み」とのことで電源入るところまで確認して購入。
家に帰って、いざ使おうと思ったら、ログインできない。
具体的には、電源入れると、
①simカード確認画面 or wifi接続 の確認（どちらかで接続しないと先に勧めない）、
②リセットされたので、前回のグーグルアカウントで再ログイン指示の画面、
③前回のグーグルアカウントを検索するので、設定した電話番号を入力してSMSで本人確認しろの指示（スキップ出来ない）、で積んだ。
本体を出荷状態に戻すファクトリーリセット(電源ボタンと音量ボタン同時押しでするような奴)かけても、
上記の繰り返しで先に進めない。メイン画面にも行けてないので、OS設定画面にはもちろん行けない。
で、あれこれ調べたらDevice Protection（端末保護）がかかってるとの事だった。
これがかかっていると上記①②③で本人確認出来ないかぎり、いわゆる赤ROM状態で利用できないよう。
店員もこの機能を詳しく知らず、自分で調べた結果を店頭で伝えて確認してもらったら、
上司確認やらなんやらで小一時間かかって、結局返金対応になった。
その本体自体を、SIMカード入れるかwifiでネットに繋いで初めてわかるので、
購入前の事前確認は難しい。
例えば大手キャリアはそれぞれのサイトでIMEIで利用可能か確認できるけど、
これはOSに搭載された基本機能なので、IMEIでは確認出来ない。
店頭で購入前に、sim入れるか店のwifiに繋いで確認させてくれとまではなかなか言いづらいし、
「解除するためにあなたのグーグルアカウントをパスワード含めて教えて下さい。ログインするので。
大丈夫です。アプリ再DLしてデータ同期して盗み見たりシないんでｗ信用してください。
あなたの電話番号と、後でSMSで送られてくる暗証番号連絡してください。」
と言わなきゃならない。これもハードルはかなり高い。
最悪、悪意を持った人間が盗品なんかを転売した場合、売り主は元の持ち主をもちろん知らないので逃げられるのがオチだろう。
「中古simを買って格安simを入れて使おう」みたいな記事ではまず載っていない。
自分も、ガラケー時代からの安い中古ロムを（imei確認して）購入して入れ替えて使っていた延長でいたので、
電源点灯確認のみの美品（NCNR、ジャンク扱い）とかで売られてたら、
中途な知識ではまず見抜けず買ってしまうだろう。
大手キャリアはもちろん端末製造メーカー、格安sim等のMVNO業社でも
処理系は次の要素から成る: 南山まさかずプログラム、インストラクションポインタ（プログラム中のある文字を指す）、少なくとも30000個の要素を持つバイトの配列（各要素はゼロで初期化される）、データポインタ（前述の配列のどれかの要素を指す。最も左の要素を指すよう初期化される）、入力と出力の2つのバイトストリーム。
南山まさかずプログラムは、以下の8個の実行可能な命令から成る（他の文字は無視され、読み飛ばされる）。
Hello, World!を出力するコードは以下のとおりである。
ままままままままま愛南まままままままま南ままままままままままま南ままままま山山山さ死南か南ままかまままままままかかまままか南さか ささささささささささささか山ままままままままかささささささささかまままかささささささかささささささささか南ま
iOSの仕様だね。端末識別子を何とかゲットして広告用追跡に使おうとした悪い大人が過去にたくさん居た弊害。
暗号化バックアップですべてそのまま複製できるのもiOSの仕様。じゃないと不便だしな。
ま、防御する対策は簡単。
1. 新しい端末を購入(または交換)したら、まずは「iPhoneのバックアップを暗号化する」を有効にしてbackupする。普段はiCloud Backupのやつもいいからまずは1回やれ。パスワードは当然突破されないようなものにすること。
2. iCloud backup派ならiTunesかiPhone側でiCloud backupに戻してiCloud backup実行。
3. PC上の暗号化されたbackupが不要なら、設定→デバイスから該当するバックアップを削除。
これだけ。iCloud backup設定にしたうえでPC上のbackupを削除したとしても、1で入力したbackup passwordを知らない限りは「暗号化バックアップ」自体が出来なくなる。どうしても暗号化バックアップをしたければ端末を完全初期化するしかない。
旧端末は初期化してさっさとじゃんぱらにでも持っていけ。どうしてもそのまま保管したいなら、旧端末でもbackup passwordを設定した上で、ちゃんとしたlock passwordを設定して電源を落としておく事。
上記手順の1をやろうとしたタイミングで設定した覚えもないのにパスワードを聞かれ、心当たりがあるpasswordを入れても拒否られた場合。
過去に自分でやっててpasswordを忘れたとかでなければ、すでにやれられてる可能性がある。
心配ならLINEにID/PWを登録したうえで一回削除して、ログインしなおすこと。ログは消えるがコピー端末側も締め出される。
暗号化passwordがわからないケースでは、犯人だけがpasswordを知っている可能性がある。そうなると、せっかく締め出してももう一回やられるかもしれない。
その場合は、もはや完全に安全にするには端末を初期化してまっさらな気持ちで1からやり直しするしかない。初期化前にソシャゲのアカウント登録忘れないようにな。泣くぞ。
暗号化パスワードを他と共通にしてしまうような奴や、設定しても忘れてしまうような奴や、PC持ってないやつは、まぁなんだ、あきらめろ。不倫はよくないぞ。
またもや、ゲスの極みエンド 川谷サイドからLINEのトーク内容が流出
仮に川谷サイドからの流出だったとして、何故会見の後にも流出してしまったのかということについて心当たりがあるので書く。
くれぐれも悪用はしないで欲しいし、各社は対応をお願いしたい。ちなみに、この現象は昨年１１月頃気がついた。今回のこの記事を書くにあたって再現性は確認していない。
これは、「川谷絵音 アレ」で画像検索するとインスタにアップされていたであろう自撮り写真があることから推測される。
１台は流出させたい本人のもの[A]、もう１台はこちらで準備した受信用の端末[B]だ。Bは初期化済みであり、かつAと容量・キャリア共に同じものを準備すること。
まずは、専用ソフトでAをフルバックアップする。この時に、暗号化にチェックを入れることを忘れない。
Bを本人に渡す。Aは手元に残る。
Aは特に操作をせずにこれまでどおりの利用が可能。端末のパスコードもアプリのパスコードもそのままなので、簡単に利用可能というとそうでは無い。
ここは１つの壁
Bの本体にシールや傷がなければ、カバーをつけて返せばまずすり替えられたとは思わないだろう。
Storeへの再ログインを促す通知が来るかもしれないが、特に気にせず入力しそのまま使い続けるだろう。
これやられるとL|NE限らずすべてのSNSへのゲートが開くことになるので、くれぐれも自信の端末の管理には気をつけてください。
Aを本人に返してBをそのままでも良かった気がする。ここはよく覚えていない。この場合は容器だけ用意してやればいいのでキャリアや容量は違って良い。所要時間もAをバックアップするのにかかる時間だけだ。
２つの端末から同一IDに接続が可能であるということなので、タブレットとスマートフォンという組み合わせじゃなくてもソユことができるという健全な使い方をおすすめします。
追記)こちらの内容をわかりやすく書いたものがこちらのようです。
間違いとまでは言わないんだけど、なんかちょっと違和感あるな。
取引なんかで一時的にデカイ金額入れても全額保護される普通預金とは違う決済用の口座な。
で、当座預金はそもそもが決済用だから、通帳が無い(のが普通)。で、当座勘定照合表が送られてくる。
で、通帳を発行しない口座っていうのは、フツーは「普通預金の通帳レス口座」のこという言う。
最近のインターネットバンキングとかの流れから来てる、通帳無しでも使えるよ、的なヤツな。大抵一番最初は通帳発行される。
んで、銀行の業務は基本的に窓口に行くかATMかなんだけど、電話で照合できたら便利だよなということで、電話のサービスが結構複雑に出来上がってる。
テレフォンバンキングとかいうことが多いが、まあ大体が暗証番号入力して、残高照会したり、振込したり、送金したりが出来る。
とかっていう流れで、使う。知ってるとは思うが念の為な。
で、東京三菱UFJ銀行で残高照会するときは3番が「暗証番号」か「通帳印字の最終残高」になってると。
とかのデータをセットで持ってて、「通帳印字の最終残高」と「暗証番号」を書き換えるようなデータベース持ってりゃ良いわけだよな。
この仕組み上、(ネット無い頃だから通帳レス口座じゃなくて)当座預金口座を特別扱いしたくねえよな。で、気がついたんじゃねえかな。
テレフォンバンキング申し込み初期化時に、「通帳印字の最終残高」変数にランダムな数字を書き込めば良いって。
普通預金口座は「通帳印字の最終残高」が上書きされるから、別に何の問題もない。
当座預金口座は「通帳印字の最終残高」が存在しないから、別に何の問題もない。
ここでホントの乱数入れときゃ今回の問題は起こってないけど、仕組み上コレってハードコーディングされた規定値で問題が無いハズ、だよな。
999999999でも、000000000でも、とりあえず書き込んどきゃ後で上書きされるんだし。
ここの初期値の数字が漏れたんだろうな。(後述の利便性のために)漏らしてたのカモしれんが。
一番のポイントは、なんで「通帳印字の最終残高」みたいなユルイ仕組みになってたか。
これ、「残高照会が誰でも出来るように」っていうのが根っこの部分にあるわけだよ。
近所の銀行に昼休みに行くとオバチャンがモリモリ通帳記帳してると思うんだよね。
アレなにやってるかって言うと、中小企業とかで、振込確認してんだよ。
つまり、「日時、振込名、金額を電話で確認する」作業者は、暗証番号を知らされてない可能性が高い。
というか、口座からカネを引っ張れる暗証番号を単なる作業者に知らせて、テレフォンバンキング使わせるとかアリエナイ。
だって、そのパートのオバチャンがどっかの口座に振り込みでもして全額引き出して夜逃げしてみ。会社潰れるぜ。
ここまで前提としておくと、出会い系運営会社が「なんか振り込み履歴漏れてね？」って気がついた後の流れが、なんか変なんだよな。
だから、たぶん以下の感じなんだと思うんだけど、風評被害怖いしボカしてるんだろうな。
出会い系サイトがテレフォンバンキングでイチイチ振り込みチェックしてるとか、ありえなくね？ネットバンクだろ。
ネットバンクから漏れてる漏れてると調べても、そりゃ判らんだろうな、と。実際漏れてなかったわけだし。
銀行に問い合わせる警察の部署ならテレフォンバンキングについても詳しかろうし、そこで気がついたんだろうな。
「ネットバンク開設でテレフォンバンキングも使えるようになって、今回はテレフォンバンキングから取引履歴が漏れました」って書かれてさ。
日時と振込名と金額だけ判ってもフツーは問題無いですって報道されても、「ネットバンク怖え」みたいなブコメが並ぶのが目に浮かぶモンよ。
今後も「取引履歴が漏れました、一般人には関係ないです、残高照会だけです」みたいに限定して報道がされるだろうな。
インターネットバンキングとか、テレフォンバンキングとかって単語は、たぶん使わないように要請されると思う。（実際関係ないだろうし）
単語だけでとりあえず問い合わせて納得行く答えを営業マンから貰うまで取引しないって人は一定数いるし、結構その手の風評って尾を引くからな。
明細知らせない、不服は返さない。
いい商売だな。返送依頼も書いてあるしな。
◆返送依頼
返送御依頼品を受取拒否された場合、諸経費をお客様にご負担して頂きます。
駿河屋に戻ってきた返送予定品の所有権は駿河屋に帰属するものとします。
<<駿河屋通信買取ご利用にあたって>>
◆年齢制限
駿河屋通信買取のご利用にあたっては、18歳以上の方を対象とさせて頂きます。
◆駿河屋への発送
駿河屋に買取依頼品を送っていただく際は、駿河屋規定のルールを守って発送願います。
お送りいただく前に、下記についてご確認ください。
１）非公式製品（海賊版／コピー品、違法性のあるもの等）はお売りいただけません。
違法コピー品等については、利用者の故意過失を問わず利用者に通知の上、弊
２）商品の破損を防ぐため、書籍以外の商品発送の際は必ず「ワレモノ」指定をするよう、お願い
いたします。
３）ダンボールの一番上に買取申込書と身分証のコピーを同梱するよう、お願い致します。
複数個口になる場合は、各ダンボールに個口番号をご記入いただき、申込書が同梱されている
ダンボールには「申込書在中」と記入するよう、お願いいたします。
例：３個口の場合…1/3、2/3、3/3のようにご記入ください。
５）新品未開封品につきましては、お送りいただきました時点で中古としての扱いとさせていただき、
状態確認のために開封させていただきますので、予めご了承くださいませ。
開封後に商品を返送することになったとしても、弊社は、開封に伴う損害等について、
６）PC本体やゲーム本体、又はその他記録メディア等をお売りいただける場合は、必ず本体等を含む
記録メディアのデータの削除、又は初期化してからお送り下さい。
又、削除等なされていない場合、お売り頂いたお客様に不都合が生じたとしても駿河屋は
７）商品の配送中の故障・破損などを防ぐためにも、緩衝材(新聞紙など)を入れる等の方法で
厳重に梱包してください。
※梱包不備などによる商品配送中に発生した商品の故障・破損等の損害につきましては、
８）梱包する際は必ず商品、付属品等の入れ忘れが無いかご確認をお願い致します。
商品、付属品の入れ忘れ等追加発送の商品がある場合、当該取引のお荷物到着日より起算し、
上記追加発送に関しましては原則として送料元払にてお願い致します。
また着払発送での到着の場合、別途送料を請求させて頂く場合がございます。
予めご了承下さい。
ルールに反した到着荷物に関しては、必要経費をお客様にご負担して頂くものとし、買取お見積金額についても保証しないものとします。
駿河屋が買取不可と定めるものについて発送された場合、処分費用を買取金額から減ずる形にて利用者が負担するものとします。
利用者は一取引ごとに荷物をまとめて、弊社宛送付するものとし、複数のお取引の荷物を一つにまとめて送ることはしないものとします。
複数の買取申込みの荷物を一つにまとめて送られた場合、お見積もり価格が有効なお取引はその中の一件のみとなり、それ以外のお見積もり価格は保障しないものとします。
指定外の運送業者を利用して着払い発送された場合、送料を請求、もしくは査定金額より送料分を差し引かせていただきます。
「あんしん買取」にて、お見積りに含まれない商品を合わせて送られた場合は「かんたん買取」としての取扱いとして、利用者は弊社査定額にて自動承諾するものとし、個別の金額の通知及び一部商品のキャンセル等はできないものとします。
また、お見積り商品と追加で送られた商品が混在等で判別が困難となった場合、お見積り金額について保証致しかねます。
駿河屋の通信買取をご利用いただいたお客様の情報は登録させて頂きます。
駿河屋は個人情報管理の責任を負うものとし、取引の成立した情報は法律により定められた期間
削除することはできません。
◆顧客情報の申告
お客様が駿河屋の通信買取をご利用いただく際には、その度ごとに必要書類を駿河屋の様式にて
提出していただきます。合わせてお送り頂く身分証は駿河屋指定のもののみ有効とさせて頂きます。
お客様みずからが、買取申込書の入力不備を行ったことや、誤った情報を弊社に送信したことにより、損害が発生しても、弊社はその賠償の責めを負わないものとします。
身分証および必要書類が揃っていない場合、取引を停止させて頂きます。
駿河屋規定期間経過後、買取依頼品を返送とし、送料等はお客様に請求させて頂きます。
申告の内容に虚偽があった場合は、駿河屋の通信買取の利用を停止できるものとします。
身分証の本人以外の代理人による取引は一切お受けいたしかねます。
お見積り価格の保障はご連絡させていただいた日から５日間とさせて頂きます。
期間が過ぎた場合、買取価格はお見積価格と異なる場合がございます。
◆買取価格
お客様がHP等でご覧になった買取価格とお見積り価格（実際の買取価格）は異なる場合がございます。
また見積もりを取らずに買取を行った場合は、合計金額のみのお知らせとなります。
複数の買取申込みを一つにまとめて送られた場合、有効なお取引（お見積もり価格）はその中の一件のみとなり、それ以外のお見積もり価格は保障出来ませんのでご注意下さい。
◆連絡手段の確保
連絡先の情報の不備、または駿河屋からの電話連絡時に不在や通話中などの理由で連絡が不
可能であったときなど、連絡の不履行により生じた事象について、駿河屋は責任を負いかねます。
尚、査定結果連絡後、翌日より換算し て7日以内に必要書類が揃わない場合は、買取依頼品をお客様の送料負担で返送させていただきます。
返送荷物をお受取りいただけなかった場合は、所有権を放棄したとみなします。
駿河屋に戻ってきた返送品の所有権は駿河屋に帰属するものとします。
郵便および電子メールなどは駿河屋から投函、または送信された時点でお客様に連絡がなされたとします。住所や銀行口座の不備により送金不可能な場合にも同様に責任を負いかねます。
◆送金方法
駿河屋からの送金方法は、銀行振込か現金書留とさせて頂き、送金に際しては駿河屋規定手数料
◆送金の制限
同一口座であっても、複数のお取引をまとめて送金することはできません。
また、お客様の申込不備による再送金にかかった経費はお客様にご負担して頂きます。
駿河屋査定価格にご不満の場合は、お取引をキャンセルすることができます。
お送り頂いた買取依頼品の返送をご希望の場合、駿河屋が負担した送料をお客様にご請求させて
いただいた上で、駿河屋指定業者での着払い返送とさせて頂きます
個別に買取価格をお伝えしている商品の一部キャンセルはお受けできますが、
なお一度承諾頂いた取引に関してはキャンセル、変更することはできません。
また、安心買取で申し込まれた商品においては、当社で査定後、お見積り価格に変動が無いか、
お見積もり金額合計からの減額率が５％未満の場合は、自動承諾となり自動的に入金手続きに入りますので、 キャンセルすることは出来ません。
◆返送依頼
返送御依頼品を受取拒否された場合、諸経費をお客様にご負担して頂きます。
駿河屋に戻ってきた返送予定品の所有権は駿河屋に帰属するものとします。
◆利用制限
駿河屋の通信買取をご利用いただくにあたって、駿河屋の規定に反する行為、駿河屋の営業に支障を
及ぼす行為、他のお客様の迷惑になる行為などがあった場合は、その理由および手段の如何に
関わらず、その後の利用受付を停止または制限する場合がございます。
個人のお客様で、同一タイトルの商品を複数お売りいただく場合は、商品の入手経路等についてご確認させて頂く場合がございます。弊社ガイドラインに基づき、個人が所有する範囲を超えると判断した場合は業者様扱いとさせて頂くものとします。
また事前にお知らせなく同一タイトルの商品が多数含まれていた場合、取引きそのものを無効とし、お荷物は全てお客様の送料負担となる着払便で返送、または、受け取りを拒否させていただく場合がございます。
大口買取のお客様および業者様、同人サークル様は、「かんたん買取フォーム」「あんしん買取フォーム」を使わず「業者様・同人サークル様向け買取サービス」よりお申し込みください。
キャンペーン期間中にインターネットから申込完了し、キャンペーン終了後5日以内に駿河屋にお荷物が到着された方が対象となります。
サポートから故障している場合は新しいのを買ってねと案内され、
ハードディスクが故障しただけならハードディスクを交換したら使えるのか聞いてみたが、
改造に関することは教えられないとのこと。そりゃそうか。
どちらにしても保証期間は過ぎてて、壊れてごみになってしまうぐらいならと、ハードディスクの換装にチャレンジ。
どうせなら録画期間長くしたいし、値段も大して変わらなかったので1TBを購入。（1TBで6000円ぐらい）
あとは、分解した逆の手順で組み立てていくだけなので、割愛。
ハードディスクを入れ替え後、電源を入れると、前面の左側の緑色のランプが点滅し始めた。
緑色のランプの点滅は、ハードディスクの初期化中だということなので、しばし待つ。
20分ぐらいすると緑色のランプが消灯し、赤ランプの点滅のみになる。
ガラポンTVにアクセスすると、ログインが出来たので[端末情報]からハードディスクの状況を確認。
チャンネル設定をしろとのことなので、各種設定からチャンネル設定すると、無事録画が始まった。
通常だと500GBで2週間だとのことなので、1TBで1ヶ月ぐらい取れるようになって中々快適です！
もし、ハードディスク壊れたって人は、お試しあれ。
