「iOS 7」を含む日記 RSS

はてなキーワード: iOS 7とは

2014-09-27

iOS 8.0.2でバッテリが異常消耗すると思ったらやってみたほうがいいこと

病院に行け。神経系の。

アップデート後たった数時間バッテリー持ちの違いが分かるわけがないだろ。

iOS 6の時もiOS 7の時もバッテリーガーとか言って大騒ぎしていた人は今すぐに。

2014-04-23

オライリーコレクションiOSのアプデしたらデータ全部消えた。

昨日iOS向けにもリリースされた「オライリーコレクション」というゲーム

仕事(ボタンを乱打するだけ)をして金を稼ぎ、オライリーの本データ(概要のみ!)が出るガチャを回すだけの、ゲームとは言いがたいアプリである

でもこういうネタは好きなので有料オプション(放置時にも妖精さん勝手に金を稼いでくれる。100円)も速攻追加した。

一日にしてオライリーコレクション廃人となった俺は、種類の少ないガチャから次々とコンプリートしていった。

んで、今日iOS 7.1.1のアプデが来てたので、早速アプデしたら、本のデータ全部消えてた。

今までの思い出がすべて消えてしまったし、もう続ける理由など無い。

涙を飲んでオライリーコレクションを消去した。

あ、オライリー電子書籍が半額のキャンペーンSinatraカンフーマック買いました。

PDFいらないからePubもっと増やしてつかぁさい!!!

2014-04-07

Restriction passcode attack on iOS 7

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>

convert it to hex digits

    $ 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

2014-02-27

Apple's SSL/TLS bug (22 Feb 2014)の意訳

例のAppleSSL/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)し、アップルが隠したい秘密はもうバレてしまっていると思う。
そして現在、俺たちはその誤った情報を正すステージに来ているんだ。

ほらここに、Applebugがあるんだ。:
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を使っているすべてに影響するけど、ChromeFirefoxはそうじゃない。
ChromeFirefoxSSL/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 "を付けてコンパイルしたとしても、XcodeGCC 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じゃない証明書でもIPHTTPSにつながっちゃうってだけだったよ。変だけど。
Safariはこの問題には関係なかったよ。

2013-09-26

情弱と煽って済む問題ではない

iOS 7にすると防水になるよ!」――悪質なデマ&偽広告海外で広がる: http://nlab.itmedia.co.jp/nl/articles/1309/26/news065.html

 読んだ。

 ほとんどの人はネタとして受け止められるけど、たぶんごく少数の人は真に受けると思う。

 だから、こういう冗談はやめてほしい。

 60代の私の両親、デジタルデバイスが全く使えない。

 GoogleアカウントログインGmail開く→添付ZIPファイル落とす→ZIP解凍っていう作業が1人でできない。

 Wi-FiBluetoothインターネット区別も分からない。

 私の両親だけが機械に弱いのではないと思う。

 以前、講演会に参加したら、主催者のおじいちゃんがカセットテープで講演を録音してた。

 コンビニにもTSUTAYAにも、未だにカセットテープビデオテープMDが置いてある。

 振り込め詐欺のように、情報産業でも誰かに騙されて大きな被害を被る人が現れると思う。

 もしかしたら、そういう被害者はもう相当数いるかもしれない。 

2013-09-25

iOS 7のホーム画面の背景をミニスカートにすると心が安らぐ

iOSアップデートして、この何もかもフラットになってしまった世界の中で

心安らぐ背景画像はないかと考えたところ、

増田にとってミニスカートが最強という結論に達しましたのでお知らせいたします。

まず、通販サイトなどで、ミニスカートの商品詳細写真の中から使えそうなものを選びます

モデルさんが着ている状態を後ろから大きく写したもの実用的で良いです。

布地の織のパターンがわかるくらい高精細なものがあればハッピー入り口になります

ホーム画面の背景に設定する時は、思い切ってスカート生地がほぼ全画面をおおうようにしましょう。

下部に少しだけ脚(ふともも)が写りこむくらいがベストな配分です。

こうすると傍目から特にスカートとは決してわからない、シンプルな布地系の背景画像となります

ミニスカートの拡大画像を背景に設定するには通常ちょっとした覚悟必要ですが、これなら大丈夫です。

カラーや素材で季節感を楽しむことができますし、柄によってはオシャレな背景になります

写りこんだ脚も、ドックのすりガラスが隠してくれます

スカートやふとももをどんなに凝視しても、iPad/iPhoneを手に考え込んでいるようにしか見えないはずです。

また、画面ごしとはいえ、スカートの上からお尻をさわさわタッチしてスワイプしてピンチインしているのを

見られたらセクハラで訴えられる恐れもありますが、これなら大丈夫です。

スカートの陰影の変化やパターンの乱れがお尻のふくらみだとわかるのは設定した本人だけです。

傾き検知機能で立体的に見えるのも楽しみましょう。

以上、増田がお送りいたしました。

変態メタモルフォーゼ)との批判はご褒美ですので悪しからず。

2013-06-25

iOS7 beta2

多少でもデザインをかじったことが有る者はiOS7の違和感に気づくと思う。

iOS 7 beta 2 includes iPad and iPad mini support [Full screenshot tour] | 9to5Macを見てアイコンとかフラットデザイン以外に違和感を感じない?

2013-06-19

なぜフラットデザインを嫌うのか

サンプルとして、話題の記事を引き合いに出そう。

iOS 7: ここ10年で最大の悪夢 | Ticking Point

こう書かれている。

結局のところ新しいデザインで何が改善される?

新しい「無意味な装飾」を生み出しただけじゃないか

しかも今回は深刻なユーザビリティの低下と一緒に。

(中略)

流行に取り残されない/ユーザを飽きさせないために行われた小手先デザイン変更だよ。

しかし、そこで「ユーザビリティの低下」の根拠として挙げられているのは“Slide to Unlock”の問題だけだ。

いちおう線が多いだとかフォントが嫌いだとか書かれているが具体性に欠けている。

ブックマークコメントを見ても、似たような批判が散見される。

曰く「オシャレなだけ」「流行を追いかけただけ」「目新しさだけ」。

やはり具体性に欠ける。

フラットデザインメリットについて見てみよう。

さらに言えば、オシャレなのは素晴らしいことだ。

フラットデザインには実用性がある(「メリットを上回るデメリットがあるのだ」というなら分かる)。

「オシャレなだけ」「流行を追いかけただけ」「目新しさだけ」といった批判はまったくの的外れだ。

汚い言葉で言えば「下衆の勘繰り」というやつでしかない。

そもそも、シンプルデザイン代名詞とさえ言えるサー・ジョナサン・アイヴが、ソフトウェアシンプルデザインすることは「流行の後追い」なのか?

あるいは、Appleは目新しさのためだけに功臣スコット・フォーストールを追放したとでも言うのか?

まったく馬鹿げたことだ。

個別の使いづらさについては批判されるべきだ。

フラットデザインというだけで使いやすいわけではないのは当然だ。

Slide to Unlock”への批判については確かに一理ある。

だが、その一事でフラットデザインのものを否定するのは、いかがなものだろうか。

妙な先入観は捨て、率直な気持ちでiOS7に触れたいものである

2013-06-12

AppleiOS 7の新デザインで成し遂げようとしていること

iOS 7でとうとうAppleフラットデザインに舵を切った。

今までのAppleデザインメモ帳カレンダーといった現実世界に既にあるものソフトウェア上で表現するものだった。

このスキューモーフィックと言われるデザインは、ユーザが画面を見た瞬間に、現実世界の事前知識から「そのソフトウェアが何であるか」をすぐに理解できるメリットがあった。

iPhoneによってあらゆる人にコンピュータが広まる過程において、ソフトウェア概念スムーズに理解させるには、このような現実世界メタファを利用することが有効方法だった。

ただ、この方法では、メタファにこだわればこだわるほど、「ページをめくる」「ゴミ箱丸めて捨てる」というような現実世界対応する動作が無いと機能を追加しづらくなるデメリットがあった。

そして、iPhone発売から6年経ち、スマートフォンを活用して生活するのが当たり前になりつつある状況になった今、Appleは新しいデザインコンセプトへとシフトした。

新しいデザインAndroidWindows Phoneと同様の「フラットデザイン」と呼ぶべきか否か議論はあるかもしれないが、便宜上ここではフラットデザインと呼ぶ。

フラットデザインの一番本質的な違いは質感や影のあるなしではなく、ソフトウェアソフトウェアのものとしてデザインしているところにある。

ソフトウェア現実世界にある道具と同様の機能を果たす面もあるが、それだけには収まらない様々な機能提供可能な新しい「モノ」である

Appleは今まで「カレンダーを画面上で再現したもの」という存在だったソフトウェアを、「日付を知るという機能物理的制約のない画面上で最適な形で表現したモノ」へと変化させたのである

これは既存メタファに一切頼らないという意味で、直感的な理解が難しくなる危険性をはらんだ変更である

中にはこの変更についていけない人も出てくるだろうが、それでもソフトウェア本来の能力を引き出すためにはどこかで現実世界メタファから卒業する必要があったのである

Apple人類全体の中の十分な割合の人が、ソフトウェアというモノをメタファに頼らずとも理解できる段階まで来たと判断して、今回の変更に踏み切ったのだろう。

 
アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん