はてなキーワード: iOS 7とは
昨日iOS向けにもリリースされた「オライリーコレクション」というゲーム。
仕事(ボタンを乱打するだけ)をして金を稼ぎ、オライリーの本データ(概要のみ!)が出るガチャを回すだけの、ゲームとは言いがたいアプリである。
でもこういうネタは好きなので有料オプション(放置時にも妖精さんが勝手に金を稼いでくれる。100円)も速攻追加した。
一日にしてオライリーコレクションの廃人となった俺は、種類の少ないガチャから次々とコンプリートしていった。
んで、今日、iOS 7.1.1のアプデが来てたので、早速アプデしたら、本のデータ全部消えてた。
今までの思い出がすべて消えてしまったし、もう続ける理由など無い。
open /var/mobile/Library/Preferences/com.apple.restrictionspassword.plist
you can find this kinds:
<key>RestrictionsPasswordKey</key> <data> xxxxxxxxxxxxxxxxxxxxxxxxxxx= </data> <key>RestrictionsPasswordSalt</key> <data> XXXXXX== </data>
$ key=```echo "key" | base64 -d | xxd -p``` $ salt=```echo "salt" | base64 -d | xxd -p```
finally try matching hashed 0000~9999(PBKDF2-HMAC-SHA1, salt=salt, iterations=1000) and the given key
more info: http://hashcat.net/forum/archive/index.php?thread-2892.html
例のAppleのSSL/TLSのバグの件、日本語情報がなかったので意訳しました。
Adam Langleyさんによって書かれた原文はこちら。要所要所に親切なリンクがついているので、ぜひ原文も見てみてください。
Apple's SSL/TLS bug (22 Feb 2014)
https://www.imperialviolet.org/2014/02/22/applebug.html
(Hi Adam Langley, Than you for your blog! We really appreciate you.)
-----
昨日、AppleはばかばかしいiOS向けのセキュリティアップデートを発行した。 それは詳しく明かされていないが、SSL/TSLについてとんでもなく恐ろしい間違いを示すものだった。 その答えは既にハッカーニュースのトップにタレこまれている(https://news.ycombinator.com/item?id=7281378)し、アップルが隠したい秘密はもうバレてしまっていると思う。 そして現在、俺たちはその誤った情報を正すステージに来ているんだ。 ほらここに、Appleのbugがあるんだ。:
static OSStatus SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer signedParams, uint8_t *signature, UInt16 signatureLen) { OSStatus err; ... if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0) goto fail; if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0) goto fail; goto fail; if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0) goto fail; ... fail: SSLFreeBuffer(&signedHashes); SSLFreeBuffer(&hashCtx); return err; }(Quoted from Apple's published source code.)
(訳者注:(Quoted from Apple's published source code)→sslKeyExchange.c) 2行のgotoがあるだろ。 2行目のgotoは、見て分かる通り常に発動する。 変数[err]にはエラーを示す値が入らず、正常を示す値のままfailに飛ぶってことだ。 それって成功したのと同じなんだよね! この署名検証処理は(訳者注:SSL/TLSハンドシェイクのやりとりのうちの一つである)ServerKeyExchangeメッセージの署名を検証するものだ。 このServerKeyExchangeでは、"the ephemeral key"(通信のための一時的な鍵)を交換するためのDHE や ECDHE という暗号スイートが使われる。 そのサーバーは言うんだ。 「ここに"the ephemeral key"と署名があるよ、ほら、これが証明書だ。君はこれが僕からのものだってわかってくれるよね!」 今、もし"the ephemeral key"と証明書の関係が破たんしているならば、すべては無意味なんだ。 これってつまり、正規の証明書チェーンをクライアントに送信したけど、ハンドシェイクへの署名には正しくない間違った(つまり適当にその辺で作った)鍵を使ったり、そもそもハンドシェイクに署名しなかったりってことができるってことなんだよ! そこには、今君が通信しているサーバーが、サーバー証明書に含まれる公開鍵の秘密鍵を持っているってことの証明が、何もないんだ。 これはSecureTransport(というライブラリ)に入っていて、以下に影響する。 ・iOS 7.0.6より前(俺は7.0.4で確認した) ・OS X 10.9.2より前(10.9.1で確認した) (訳者注:つまりiOS 7.0.6、OS X 10.9.2で解決した) これはSecureTransportを使っているすべてに影響するけど、ChromeとFirefoxはそうじゃない。 ChromeとFirefoxはSSL/TLSのためにNSSを使っている。 でも、それはあんまり君のマシンがSecureTransportを使っていないってことを意味しないよ。(ソフトって更新されるしね) 超特急でテストサイトを作ってみたよ。https://www.imperialviolet.org:1266 ポート番号に気を付けてね。(テストサイトはCVE番号になってるよ) 443は通常通りに動いているからね。 ポート1266のサーバーと443のサーバーは同じ証明書を送っているけど、完全に異なるキーで署名しているんだ。 君がもしポート1266のHTTPSサイトにアクセスできたんだったら、君のマシンはこのイケてるバグを抱えてるってことだね。:) それってつまり、証明書チェーンは正しいってことで、そしてハンドシェイクと証明書チェーンの関係は壊れたってことで、もう俺はどんな証明書も信じないよ。 またこれは、DHE または ECDHE 暗号スイートを使っているサイトに影響を及ぼすだけじゃないんだ。 攻撃者は、この暗号スイートを使うサーバーを自分で建てるようになるだろう。 また、これはTLS 1.2には影響しない。このバグを含まないTLS 1.2の別の関数があったから。 でも攻撃者は使うプロトコルをある程度選ぶことができるから、安心できないよ。 (訳者注:サーバー側がTLS1.2を使えないことにしていたら、それ以外の例えばSSL3.0とかTLS1.0とか1.1で通信が始まっちゃうから。) でもでも、クライアント側でTLS1.2だけを使えるようにしておけば、それは今回の問題の回避策になる。。 同じく、クライアント側でRSA暗号スイートだけを許可するということも、ServerKeyExchangeが発生しなくなるので今回の問題の回避策になる。 (2つのうち、1つ目のほうがだいぶ好ましい。) 俺のテストサイトでは、iOS 7.0.6 と OS X 10.9.2で問題は解決していた。 (更新:このバグはOS X 10.9 のときに入ったように見えたけど、iOS6にもっあったぽい。iOS 6.1.6は昨日リリースされたよ。) こんなような微妙なバグって、悪夢だ。 俺はこれは単なるミスだと思うし、なんかもうほんと最悪って思う。 ここに、今回の問題を明らかにするコードがある。:
extern int f(); int g() { int ret = 1; goto out; ret = f(); out: return ret; }
もし俺が"-Wall "を付けてコンパイルしたとしても、XcodeのGCC 4.8.2 や Clang 3.3は死んでるコード(the dead code)について警告をしないんだ。 本当にビックリだよ!!! ここで警告が出ていたらこの問題は止められたのに。でもたぶん、現実には死んでるコードが多すぎて無視することにしてるんだろうね。 (ピーター・ネルソンが教えてくれたけど、Clangはこれを警告するための"-Wunreachable-code"を持ってる。でもこれ、なんと"-Wall "には含まれてない!) if文に{}をつけないことを許すコーディングスタイルはこの問題を誘発したかもしれない。 でも、人は{}を付けたとしても間違ったプログラムを書くことがあるから、これは俺はあんまり関係ないように思う。 テストケースはこれを見つけることができたはずだけど、今回のはいろいろ条件が複雑なやつだったから難しかったと思う。 TLSのめちゃめちゃ多くのオプションを試さなきゃいけなかったからね。しかも正常系じゃないやつも。 俺、TLSLiteでちゃんとテストしてるか思い出せないもん。(月曜日怖いかも) コードレビューはこの種類のバグについて効果的でありえる。 ただし単なる審査じゃなく、それぞれの変更に対してしっかりとレビューすることだ。 Appleのコードレビューカルチャーがどんなもんか知らないけど、もし俺が同じようなことをやっちゃったとしたら、同僚のWan-Teh や Ryan Sleevi がばっちり見つけてくれたと、固く信じてる。 でも、誰もがそんなにいい仲間を持てるわけじゃないよね。 最後に。昨日、Appleが証明書のホスト名をちゃんとチェックしていなかったことについて多くの議論があったんだけど、 それは OS X のコマンドラインでcurlを使うと、IPじゃない証明書でもIPでHTTPSにつながっちゃうってだけだったよ。変だけど。 Safariはこの問題には関係なかったよ。
「iOS 7にすると防水になるよ!」――悪質なデマ&偽広告が海外で広がる: http://nlab.itmedia.co.jp/nl/articles/1309/26/news065.html
読んだ。
ほとんどの人はネタとして受け止められるけど、たぶんごく少数の人は真に受けると思う。
Googleアカウントにログイン→Gmail開く→添付ZIPファイル落とす→ZIP解凍っていう作業が1人でできない。
Wi-FiとBluetoothとインターネットの区別も分からない。
以前、講演会に参加したら、主催者のおじいちゃんがカセットテープで講演を録音してた。
コンビニにもTSUTAYAにも、未だにカセットテープやビデオテープやMDが置いてある。
iOSをアップデートして、この何もかもフラットになってしまった世界の中で
当増田にとってミニスカートが最強という結論に達しましたのでお知らせいたします。
まず、通販サイトなどで、ミニスカートの商品詳細写真の中から使えそうなものを選びます。
モデルさんが着ている状態を後ろから大きく写したものが実用的で良いです。
布地の織のパターンがわかるくらい高精細なものがあればハッピーの入り口になります。
ホーム画面の背景に設定する時は、思い切ってスカートの生地がほぼ全画面をおおうようにしましょう。
下部に少しだけ脚(ふともも)が写りこむくらいがベストな配分です。
こうすると傍目からは特にスカートとは決してわからない、シンプルな布地系の背景画像となります。
ミニスカートの拡大画像を背景に設定するには通常ちょっとした覚悟が必要ですが、これなら大丈夫です。
カラーや素材で季節感を楽しむことができますし、柄によってはオシャレな背景になります。
スカートやふとももをどんなに凝視しても、iPad/iPhoneを手に考え込んでいるようにしか見えないはずです。
また、画面ごしとはいえ、スカートの上からお尻をさわさわタッチしてスワイプしてピンチインしているのを
見られたらセクハラで訴えられる恐れもありますが、これなら大丈夫です。
スカートの陰影の変化やパターンの乱れがお尻のふくらみだとわかるのは設定した本人だけです。
傾き検知機能で立体的に見えるのも楽しみましょう。
サンプルとして、話題の記事を引き合いに出そう。
iOS 7: ここ10年で最大の悪夢 | Ticking Point
こう書かれている。
(中略)
しかし、そこで「ユーザビリティの低下」の根拠として挙げられているのは“Slide to Unlock”の問題だけだ。
いちおう線が多いだとかフォントが嫌いだとか書かれているが具体性に欠けている。
曰く「オシャレなだけ」「流行を追いかけただけ」「目新しさだけ」。
やはり具体性に欠ける。
フラットデザインには実用性がある(「メリットを上回るデメリットがあるのだ」というなら分かる)。
「オシャレなだけ」「流行を追いかけただけ」「目新しさだけ」といった批判はまったくの的外れだ。
そもそも、シンプルなデザインの代名詞とさえ言えるサー・ジョナサン・アイヴが、ソフトウェアをシンプルにデザインすることは「流行の後追い」なのか?
あるいは、Appleは目新しさのためだけに功臣スコット・フォーストールを追放したとでも言うのか?
まったく馬鹿げたことだ。
個別の使いづらさについては批判されるべきだ。
フラットデザインというだけで使いやすいわけではないのは当然だ。
“Slide to Unlock”への批判については確かに一理ある。
iOS 7でとうとうAppleもフラットデザインに舵を切った。
今までのAppleのデザインはメモ帳やカレンダーといった現実世界に既にあるものをソフトウェア上で表現するものだった。
このスキューモーフィックと言われるデザインは、ユーザが画面を見た瞬間に、現実世界の事前知識から「そのソフトウェアが何であるか」をすぐに理解できるメリットがあった。
iPhoneによってあらゆる人にコンピュータが広まる過程において、ソフトウェアの概念をスムーズに理解させるには、このような現実世界のメタファを利用することが有効な方法だった。
ただ、この方法では、メタファにこだわればこだわるほど、「ページをめくる」「ゴミ箱に丸めて捨てる」というような現実世界で対応する動作が無いと機能を追加しづらくなるデメリットがあった。
そして、iPhone発売から6年経ち、スマートフォンを活用して生活するのが当たり前になりつつある状況になった今、Appleは新しいデザインコンセプトへとシフトした。
新しいデザインをAndroidやWindows Phoneと同様の「フラットデザイン」と呼ぶべきか否か議論はあるかもしれないが、便宜上ここではフラットデザインと呼ぶ。
フラットデザインの一番本質的な違いは質感や影のあるなしではなく、ソフトウェアをソフトウェアそのものとしてデザインしているところにある。
ソフトウェアは現実世界にある道具と同様の機能を果たす面もあるが、それだけには収まらない様々な機能を提供可能な新しい「モノ」である。
Appleは今まで「カレンダーを画面上で再現したもの」という存在だったソフトウェアを、「日付を知るという機能を物理的制約のない画面上で最適な形で表現したモノ」へと変化させたのである。
これは既存のメタファに一切頼らないという意味で、直感的な理解が難しくなる危険性をはらんだ変更である。
中にはこの変更についていけない人も出てくるだろうが、それでもソフトウェア本来の能力を引き出すためにはどこかで現実世界のメタファから卒業する必要があったのである。
Appleは人類全体の中の十分な割合の人が、ソフトウェアというモノをメタファに頼らずとも理解できる段階まで来たと判断して、今回の変更に踏み切ったのだろう。