今日の出来事 (Feb, 2019)

デレステと ASUS ZenFone 5Z...

　引き続き「タイトル間違いではありません。」 (笑)

　昨年末から先週末に掛けて， ローエンド機の ASUS ZenFone Max (M1)， ミドルレンジ機の ASUS ZenFone 5Q， そして ASUS ZenFone 5 と 3 台のスマートフォンで「デレステ」や「ミリシタ」が どれくらい動作するのかを試しました。 その結果は， 「巷の評判どおりダメダメだった ZenFone Max M1」， 「要設定ながら意外と普通にプレーできた ZenFone 5Q」といった辺りまでは納得できるものだった一方， 「ZenFone 5Q よりも快適度が低いという期待外れの ZenFone 5」という「なんだかなぁ～」といったものもあったわけですが， まあ， 「Qualcomm Snapdragon 630 よりも性能が良い」と言われる Snapdragon 636 を搭載しているとはいえ， ZenFone 5Q の 630 が 2.2GHz なのに対して ZenFone 5 の 636 は 1.8GHz と 2 割近くもクロックが低いことから， 元々優位性の主張を懐疑的に思っていた自身としては， 逆に納得できる結果だったとも言えるでしょう…悲しいことですけれども。 (^^;)

ともあれ， Snapdragon 660 のクロックを下げるなどダウングレードしたものが Snapdragon 636 であるだけに， この調子では 660 にも期待できそうにありません。 もちろん， クロック差が ほぼなくなることもあって， 確実に ZenFone 5Q 辺りよりは良好な結果を得られるでしょう。 しかし， その差は恐らく期待したほどではないでしょうから， 言ってしまえば「大同小異」でしかありません。 そのためにハイ側ながらミドルレンジ機を もう 1 台追加投入しても得られるものは殆どなさそうなので， これ以上ミドルレンジ機を試すのは止めました。 どうやら「ゲームをするならハイエンド機を買え」という巷の評判は， 自身によるテストでも真だったようですね。

　「それならば， この際そのハイエンド機を試してみよう」というわけで， 19 日に発注して 20 日に届いたのが表題の ASUS ZenFone 5Z です。 ええ， 「3 月半ばに」買うとか下の記事で書いていたわけですが， 「後で買うなら今買っても同じ」と速攻で買っています。 (笑) 　大まかなスペックは Qualcomm Snapdragon 845， 6GB メモリー， 128GB ストレージ， そして 2246x1080 Super IPS+ 液晶…と， SoC やストレージを除けば ZenFone 5 と何も変わりません。

なので， 当然ながら見た目は ZenFone 5 と そっくりで筐体も全く同じです：

左上画像を見てのとおり そっくりです。 下の記事を読んだ方なら区別できると思いますが， ちなみに左の黒筐体なのが ZenFone 5Z で右のシルバー筐体は件の記事でネタにした ZenFone 5 です。 あとでも触れますが， ZenFone Max M1 と 5Q の ちょうど中間という大きさで， iPhone XS/X より一回り大きく， もはや音ゲー親指派には限界の域に達しています。 もちろん滑りまくる筐体も同じなので， 何らかのケースを使用しないと遠からず落っことして破壊することでしょう。 ええ， 当然ながら付属のケースはダメダメなので使えません。 (笑) 　ともあれ， 製品としては「Snapdragon 636 を 845 へ上げた ZenFone 5」といった趣ですね。

一方の右上画像ですが， インストールしたアプリは今回も同じで， アイコンの見えている Kindle， MX Player Pro とデレステ， ミリシタ， グラブル， そして Kaspersky といった面々です。 アプリやデーターを SD カードへ逃がせないクソ仕様は外と同じですが， Kindle がアプリ側の独自機能で SD カードへコンテンツを逃がせますし， 5Z は内蔵ストレージが 128GB なので多少ながら余裕はありそうです。

　それでは実験開始です。 四度 (よたび) デレステに御登場願います…いえ， 願ったのですが…：

ここで絶望する結果となりました。 見てのとおり， 一連のネタで買った ZenFone 4 台の中でフラグシップであるはずの 5Z が一番ゴミでした。 スクリーンショットさえまともに撮れないとか， 目が点になりました。 (爆) 　何のことはない， ZenFone 5Z の 2246x1080 といった画面サイズにシステムが対応できていないのです。 「ZenFone 5 では対応できている」にもかかわらずです。 実は ZenFone 5 と 5Z は同じ Android 8.0.0 ベースの OS でありながらも， その ZenUI としての版は割と大きく異なります。 その辺りもあって， どこかで別機種のコードが紛れ込んだのでしょうね。 それはともかく， 何を どう設定しようが横画面である限りはノッチ部分の欠けた 2159x1080 のサイズでしか撮れません。 縦画面では 1080x2246 で撮れるにもかかわらずです。

「よくぞ こんなバグを仕込めた!!」と感心するレベルなのは置いておいて， よもや発売当時からということはないと思いたいですが， 少なくとも今の版が登場したであろう 10 月下旬からの 4 ヶ月間は放置されているわけなので， スクリーンショットを ある程度でも重要視せざるを得ない使用法をするのであれば， ZenFone 5Z は「3000 円の最廉価中華スマホ未満のゴミ」と認定しても構わないでしょう。 (笑) 　それくらいアホなバグと放置具合ですから…。 アプリレベルで不具合が生じるのは仕方のないこととして， いくら問題の多い (らしい) 全画面モードとはいえ， システムレベルで不具合を出すのは怠慢でしかありません。

…と， ここに至り ZenFone 5Z への忠誠度は ほぼゼロとなり記事を書く気も殆ど失せてしまったのですが， この記事のためだけに買ったようなものなので， 仕方なく続けることにします。 (笑) 　というわけで， ここから先は Live 以外が標準モード， Live だけは全画面モードで撮ったものとなります。 前にも書きましたが， 標準モードで動画を撮ると周りの黒い額縁動画となってしまいますので…。

　さて， 気を取り直してデレステです：

要設定ながら意外と普通にゲームをプレーできたミドルレンジ機の ZenFone 5Q に対して， 「カタログスペックやベンチマーク結果では かなり向上するらしい Snapdragon 636 を搭載した ZenFone 5 で どれくらい変わるのか？」と試した前回の結果が上で書いたとおりでしたので， 「ハイエンド機が iPhone XS/X/8 に対して どれだけ善戦するのか？」といった辺りを確かめるのが今回の趣旨です。 ハイ側のミドルレンジ機が期待外れだったので， ハイエンド機へ方針転換したわけですね。 (笑) 　とはいうものの， XS に対しては 4 割強， 8 に対しても依然 6 割強の価格でしかない ZenFone 5Z ですから， 対等以上を望むのは無理というものでしょう。 そういった意味での「善戦」です。

まずは 2D 画面系の上画像ですが， 標準モードな表示のせいで ZenFone 5Q 未満の画面サイズとなってしまっています。 5Q が 2160x1080 なのに対して 5Z の標準モードは 2159x1080 と同等なのですが， エッジのカーブが緩い分大きく角は欠ける形となりますので， 得られる情報量が かなり少なくなってしまうのでした。 こと横画面で使用するアプリに限っては 5Q 未満の画面サイズとしてしか使えないわけで， スクリーンショットの大バグのせいで全画面を利用できないことによる大きなデメリットと言えるでしょう。

続いては Live の前のタイミング調整：

まずは左上画像ですが， 調整画面をクリアーした結果が 14 と， 値自体は ZenFone 5 と ほぼ同じになっています。 5 も そうでしたが， ノーツ側処理と音が完全に同期しますので， 言ってしまえば値自体は どうでも良いわけで気にする必要がないわけですけれども…。 (^^;) 　一方の右上画像， 今回はハイエンド機なので初期値として標準を勧められようが何だろうが 3D リッチ設定です。 そうしないと iPhone 勢との比較になりません。

それでは， 実際に Live を行ってみます：

ZenFone 5 と同じ筐体なので 6 インチクラスとはいえ親指プレーでも比較的フルコンボを狙いやすい訳なのですが， さすがに『咲いて Jewel』 1 回目即フルコンボとは行きませんでした。 ええ， 途中で筐体を持つ指が滑り， それで親指のタップ位置がずれて BAD 判定となってしまいました。 (笑) 　なので， 今回も大人しく MASTER 入門曲の『S(mile)ING!』を選択することにします。

というわけで， 『S(mile)ING!』の Live です：

今回も裏タスクでの動画キャプチャーを行うことから， 定番ソフトの「AZ Screen Recorder」を使用するわけですが， これまでの 1440x720 30 f/s 系ではなく， iPhone XS に合わせるべく 1922x924 60 f/s の設定となっています。 本来は 1920x923 なのですが， 件のアプリは偶数ピクセルしか指定できませんので。 …というわけで， かなり裏タスクの負担は高くなっているのですが， 特に表タスクへ影響することはなく快適にプレーすることが出来ます。 強いて言えば「30 フレームに対する 24 フレームのアニメ」といった感じで， 若干流れの悪いイメージがあるくらいですね。

それにしたところで iPhone XS/8 を持っているからこそ判る程度で， そうでなければ殆ど気にならないと思います。 巷では「ゲームをするなら iPhone」と言われたりもしますが， ことデレステやミリシタに限って言えば iPhone に拘る必要はなさそうです。 少なくとも ZenFone 5Z レベルで動作する Snapdragon 845 (以上) な機種であれば， 好みで選択すれば良いでしょう。

そのキャプチャーですが， さすがに高解像度な分負荷が高くなるのは避けられず， ZenFone 5 に比べると多少なりとも潰れる結果となっているようです。 とはいうものの， 上画像を見てのとおり遠景でも この程度で， それこそ動画で観る分には全く気にならない程度で収まっています。 音なしとはいえ， この点に関しては iPhone 勢は太刀打ちできていません。 あ， もちろん「自身の使用環境での話」ですけれどね。 こちらが音なしで 320MB なのに対して あちらは音ありで 100MB ですから， その分潰れまくるのは仕方のないところでしょう。

中景やウエストショットレベルになってくると より潰れなくなるのは必然なのですが， その一方で「2246x1080→1922x924」の変換によるものは避けられないらしく， それによるノイズの発生などは ZenFone 5 よりも多くなっています。 静止画で見れば…の話ですけれども。 それはともかく， 左上画像 117 コンボ目でのキャラの肌の色に凄く違和感を感じたのでした…これは記事の最後で触れます。

サイズ変換による影響は単体キャラなどウエストショットでも変わりません。 もっとも， キャラが大きい分潰れていることさえ気付かなかったりしますけれど…。 そして右上の動画…。 先にも書きましたが， 3D リッチ設定で さらに高解像度でキャプチャーしているにもかかわらず， ブロック化が殆ど気にならないものとなっています。 そして不思議なことに， 1922x924 60 f/s だろうが 1498x720 30 f/s だろうが音ありだろうが音なしだろうが， 出来上がる動画のサイズは 300MB 前後なのでした。

恐らくカスタム設定なサイズだと， 例えば 1920x1080 60 f/s だとか特殊ながら一定に近いデーターで記録されるのでしょうね。 カスタム設定ではない画面サイズどおりでキャプチャーしている ZenFone 5Q では 110MB と全く異なる結果になっていますから。 もっとも， その 5Q は iPhone XS と同じように潰れていますから， サイズを採るかブロック化の少なさを採るかですね。 個人的には「2 分半で 300MB 超えはちょっと…」といった感じです。 (^^;)

　というわけで， 両者を手元で比べれば差異はあるものの， ZenFone 5Z レベルの Snapdragon 845 機であれば ほぼ快適にデレステを 3D プレー可能と解りましたので， ご同様のアプリ…ということで今度は「ミリシタ」に御登場願います：

デレステ同様全画面設定なのでノッチ部分の欠けた画像しか撮れないわけなのですが， ミリシタはノッチやナビゲーションバー部分を避けて各アイテム類が配置されますので， 問題の発生することはありません。 見方を変えれば「限定した箇所しか使えない」ので一長一短なわけですが， ゲームだけに それで まともにキャプチャーできなくなるくらいなら， こちらのほうが遥かにマシ…以前に比較すること自体無意味でしょう。

メイン画面などの (キャラの) 3D 表示は， ZenFone 5Q や 5 と同じく頭から高解像度表示されます。 この辺りは大して負荷が掛かるわけではありませんから， 外との差は感じられません。 逆に ここで感じられるようでは困ります。

ZenFone 5 で多少慣れたとはいえ親指派に 6 インチクラスが厳しいのは変わらず， 6MIX までは楽勝でも， MILLION MIX でのフルコンボは やっぱり無理でしたので， ここでも AUTO PLAY の御世話になっています。 そして， デレステ同様綺麗めな動画キャプチャー結果となっています。 さすがに動きの激しい分， こちらでは それと気付く程度には潰れていますけれど…。 表タスクがリソースを奪うミリシタですから仕方のないところでしょう。

　…というわけで， Qualcomm Snapdragon 845 な ASUS ZenFone 5Z では， さすがにハイエンド機だけあって， デレステ・ミリシタ共々快適にプレーが可能でした。 それを目的とした記事なので ここでは比べていますが， 「iPhone が～， Android が～」とかは気にせず好みの機種を選択すれば良いと思います。 ただし， キャプチャー方面の大バグだけは大悪です。 これが存在する限り ZenFone 5Z はゴミです。 (笑)

　ここからは余談です。 ZenFone Max M1， ZenFone 5Q， ZenFone 5， そして ZenFone 5Z と 4 台続けての購入となりましたので， その 4 台を並べてみました：

左から ZenFone 5Q， 5Z， 5， そして Max M1 です。 4 台並べると一層小さく感じる Max M1 ですが， それでも iPhone XS より大きかったりします。 それはともかく， 5 や 5Z にもルージュレッドが欲しかった…。 いえ， たとえ出ても買いませんけれど。 (笑)

　そして上でも書いた色の違いですが…：

左上画像は ZenFone 5， 右上画像が ZenFone 5Z， 左下画像は iPhone XS， そして右下画像が その 3 つを 1/3 ずつ並べた合成画像となっています。 3D 軽量と 3D リッチという設定の違いでパネルの色が大きく異なっているのは別としても， 肌の色などが各デバイス…特に ZenFone 5 で大きく異なっているのでした。 右下の合成画像だと判りやすいのですが， iPhone XS， ZenFone 5Z， ZenFone 5 の順で彩度が低くなっているのですが， その一方で黄色掛かった色へ変化しています。

昔と異なり今の Android 機ではブルーカット等の設定が撮った画像に影響することはありませんので， 何故黄色くなるのかは謎です。 もっとも， iPhone XS と その他では使用ソフトが異なりますから， 結果が異なっても仕方がないわけですけれどね。

　さて， さすがに ZenFone 5Z くらいは何かに使わないと勿体ないですので， Win 10 な Miix 2 8 の代わりに職場用として暫く鞄にでも常駐させてみることにします。 筐体は小さいですが画面自体は 6.2 インチと昔使っていた Galaxy Note よりは大きく， その後使っていた 7 インチタブレットに近いノリで使えそうですから…。 あ～でも， それで可能なら「iPhone XS でも変わらない」となってしまいそう…。 (笑)

デレステと ASUS ZenFone 5...

　まず最初に…。 タイトル間違いではありません。 (笑)

　巷の評判どおりダメダメでゲームのプレーが出来なかったローエンド機の ASUS ZenFone Max (M1) に対して， 「んではミドルレンジ機はどうなのか？」と ASUS ZenFone 5Q を先週末に買って試してみた…といった辺りは下の記事で書きました。 その結果， 3D 軽量など ある程度設定を下げる必要はあったものの， 意外と普通にデレステやミリシタのプレーが可能だったわけですが…。 ZenFone 5Q の SoC は Qualcomm Snapdragon 630 です。 昨年の春モデルということで その頃のミドルレンジ機としては普通なわけですが， Snapdragon 636 が多くを占める秋冬モデルも登場した今となっては少々古くなってしまったと言わざるを得ません。

その Snapdragon 636 ですが， ミドルハイ機で良く使われている Snapdragon 660 のクロックを下げるなどダウングレードしたものだけあって， 「630 に比べて かなり性能が良い」という評判があったり， また それを示すかの如く「下手な 660 機より速い」といったベンチマーク結果も そこかしこで上がっています。 しかし， その一方でクロック自体は 630 の 2.2GHz + 1.8GHz に対して 1.8GHz + 1.6GHz と 2 割近くも下がってしまっているのでした。 「ゲームはクロックだよ， 兄貴っ!!」と言われることもあるだけに， この差による影響は意外と馬鹿に出来なさそうです。

　「ならば実際に試してみよう」というわけで， 12 日に発注して 14 日に届いたのが表題の ASUS ZenFone 5 なのでした。 ええ， 下の記事を公開した翌日に発注しています。 (笑) 　本当は 13 日に届くはずだったのですが， 不在通知攻撃を食らって 1 日遅くなりました。 大まかなスペックは， Qualcomm Snapdragon 636， 6GB メモリー， 64GB ストレージ， そして 2246x1080 Super IPS+ 液晶…と， 2 SIM + SD カードの両立は不可なのとカメラが…といった点を除けば， ZenFone 5Q に対してアドバンテージがあるといった内容になっています。

この ZenFone 5…。 6.2 インチと ZenFone 5Q より大きい画面なのに対して， 逆に筐体は小さかったりします：

左上画像を見てのとおり ZenFone 5Q より少々小さく， 実を言うと ZenFone Max M1 と 5Q の ちょうど中間の大きさだったりします。 音ゲー親指派にとって この差は大きく， 5Q では無理だった曲でも 5 ではフルコンボ出来たりするのでした。 重さも 165g と 3g だけ 5Q より軽くなっています。 さすがに差が感じられるほどではありませんけれども…。 そして筐体は 5Q 以上に滑りまくります。 もう落とさないほうが不思議なくらいです。 (笑) 　ちなみに， 付属のケースは やっぱりダメダメでした。 まともなものを付属しろよ!! (^^;) ＞ASUS 　それはともかく， 製品としては「Snapdragon 845 を 636 へ落とした ZenFone 5Z」といった趣ですね。

一方の右上画像ですが， インストールしたアプリは ZenFone 5Q と同じで， アイコンの見えている Kindle， MX Player Pro とデレステ， ミリシタ， グラブル， ATOK， そして Kaspersky といった面々です。 やっぱりアプリやデーターを SD カードへ逃がせないクソ仕様なわけですが， Kindle がアプリ側の独自機能で SD カードへコンテンツを逃がせますので， 個人的には内蔵が 64GB でも何とかなりそうです。

　というわけで， またまたデレステに御登場願うのでした (笑)：

前回試したミドルレンジ機の ZenFone 5Q では要設定ながら意外と普通にゲームをプレーできたわけですが， それに対して「カタログスペックやベンチマーク結果では かなり向上するらしい Snapdragon 636 を搭載した ZenFone 5 で どれくらい変わるのか？」というのが今回の趣旨です。 クロック差による影響が意外と馬鹿にならないゲーム界隈ですから， 630 より 2 割もクロックの下がる 636 で「本当に向上するのぉ？」という疑惑が個人的に拭えませんので…。 もちろん， 上がるに越したわけではありませんから， それならそれで何も問題はありません。 (笑)

上画像を見てもらう前に画面設定なのですが， 今回は全画面設定を手動指定しています。 というのも， デフォルトや標準設定では左端 (ノッチ部分) が大きく欠けてしまい， 5Q より狭い画像や動画しか撮れなくなってしまうのでした。 さらに その変則的な画面サイズが (特に) 動画キャプチャーの処理へ負荷を掛けてしまったりと， 少々使用に耐えないレベルだったりします。 それでの全画面だったわけですが， デレステ・ミリシタ共に不具合が出なかったのは僥倖でした。 (意外と不具合が発生するらしい。)

さて， その上画像ですが…。 見てのとおり背景の左右が欠けてしまっています。 なんと， iOS 版と異なり， 高解像度ワイド画面への対応が行われていないのでした。 ZenFone 5Q の 2160x1080 を超えると拡大表示されなくなるわけですね。 そのくせ その枠を超えてアイテム配置されたりと， 相当見栄えは落ちてしまっています。 アイテムが画面サイズに対応している以上， 単なるプログラムの手抜きでしょうね。 (笑)

続いては Live の前のタイミング調整：

まずは左上画像ですが， 調整画面をクリアーした結果がこれで， まだまだ大きな調整幅ながら 5Q の 18 よりは小さい結果となっています。 5Q 同様， ノーツ側処理と音が完全に同期しますので， 値自体を気にする必要はないでしょう。 一方の右上画像， やはりといいますか 3D 標準以上がカクカクでしたので， ここでも 3D 軽量を選択しています。 この時点で何となく結果が判ってしまうのは秘密です。 (^^;)

それでは， 実際に Live を行ってみます：

画像を見てのとおり ZenFone 5Q より筐体が小さいのと 6 インチクラスへの慣れもあって， 『咲いて Jewel』のフルコンボは可能になりました。 が， 全連結フリックが辛いのは相変わらずで毎回フルコンボを出すのは無理がありますので， ここは やっぱり大人しく MASTER 入門曲の『S(mile)ING!』を選択することにします。 (^^;)

というわけで， 『S(mile)ING!』の Live です：

今回も裏タスクでの動画キャプチャーを行っています。 使用ソフトはもちろん定番の「AZ Screen Recorder」で， 1440x720 30 f/s 設定へ落としてあるのも同じです。 ここでソフト等を変えたのでは比較の意味がありませんので…。 それはともかく， 潰れてしまうことの多い遠景ではありますが， その程度は 5Q より低く収まっています。 が， 肝心のデレステ自体が 5Q よりカクカク…いえ， 例えるなら「ノーツの流れるスピードが SIN 関数のような変位を見せる」のでした。 一定間隔で滑らかに速くなったり遅くなったりするわけですね。

幸い その差が大きくありませんのでプレー自体に影響は殆どないのですが， これのせいで体感の快適さは 5Q と比べて かなり落ちてしまっています。 これが標準設定などへ上げての結果であれば納得もしますが， 正直言ってガッカリでした。 (笑)

裏タスクへリソースが回っている (らしい) ので， 中景やウエストショットレベルになってくると殆ど潰れなくなってきます。 5Q よりキャラなどがガタガタなように見えるのは， 軽量設定で元々粗く描画されているだけで， むしろ これが滑らかだったなら， それは潰れた結果なのです。 …いえ， こちらは潰れても良いから表タスクが滑らかに動いて欲しかった。(^^;)

もちろん， 単体キャラなウエストショットだと さらに潰れなく…といいますか， 殆ど潰れていません。 (^^;) 　そして右上の動画…。 ZenFone 5Q と異なりブロック化は殆ど気にならないのでした。 動画キャプチャーで内蔵音源の録音を行えない Android なので音なしですから， それによる負荷の低下は大きく影響しているわけですが， 下手をすると iPhone XS に近いレベルかもしれません。

その一方で， 動画でもノーツの速さが こまめに変わっている…つまりデレステ側自体が安定していないと解るのでした。 「カクカクで引っ掛かりまくり」…というパターンでないのが救いかしら？ 　あと， ノーツ側と音が完全に同期している一方， キャラなど MV 側は 0.4 秒ほど先行しているのは， 5Q と同じです。 MV で ちゃんとキャラと音が同期するのも同じ。 他の理由があるのか 630 と 636 の能力差が小さいからなのかは不明です。 個人的には後者のような気がしますけれども…。 あ， ちなみに動画キャプチャーを行っていなくとも， デレステの不安定さは同じですので， 念のため。 (^^;)

　というわけで， 普通にデレステを 3D プレー可能ながら ZenFone 5Q より快適さが劣ると解りましたので， ご同様のアプリ…ということで今度は「ミリシタ」に御登場願います：

タイトル画面を含めた 2D 画面で何も問題ないのはデレステと同じです。 と言いますか， 基画像の解像度が高めなのか拡大処理のせいなのか， こちらでは背景が ちゃんと画面一杯に表示されます。 やっぱり こうでないとダメですね。 (^^;)

メイン画面などの (キャラの) 3D 表示も， ZenFone 5Q と同じく ちゃんと高解像度表示されます。 この辺りは大して負荷が掛かるわけではありませんから， 5Q との差は感じられません。 逆に ここで感じられるようではダメダメということになってしまいます。

ZenFone 5Q よりはマシとはいえ親指派に 6 インチクラスが厳しいのは変わらず， 6MIX までは楽勝でも， MILLION MIX は やっぱり無理でしたので， ここでも AUTO PLAY の御世話になっています。 そして， 「裏に より多くのリソース」らしい ZenFone 5 だけあって， デレステ同様綺麗めな動画キャプチャー結果となっています。 当然， その分ミリシタ自体が不安定なのも以下同文…。 ちなみに， MV 側， ノーツ側， そして音は もちろん完全に同期しています。 これがダメだと完全に 5Q 以下ということに…。 (^^;)

　…というわけで， Qualcomm Snapdragon 636 なミドルレンジ機の ASUS ZenFone 5 ではデレステ・ミリシタ共々普通にプレーが可能だったものの， 意外にも 5Q より体感的な快適さは下という結果になりました。 デレステ以上の重量級なゲームは 5Q より不安要素があると言わざるを得ないようです。 ゲーム目的での入手は黄色信号かしら？ 　15k 高くて これでは立つ瀬が…。

こんな調子では Snapdragon 660 も期待外れとなりそうですから， 来月以降に Snapdragon 845 な ZenFone 5Z を試してみたいと思います。 さすがに月末過ぎまでに もう 1 台買うのは無理なので， 来月といっても半ば以降となりそうです。 (笑)

デレステと ASUS ZenFone 5Q...

　iOS 用関数電卓アプリがきっかけで， それと同様の Android 用アプリを試すために ASUS ZenFone Max (M1) を買った辺りについては先日記事にしました。 その際「ローエンド機で無謀とされるゲームプレーが実際どれくらいダメダメなのか」と脱線しまくってデレステやミリシタを試してみたわけですが， 結果論としてはブラウザーゲーのグラブルすらカクカクという巷の評判どおりな結果が得られたところです。 あ， 件の電卓アプリ類も そうですが， 普通に使う分には殆ど問題ありませんので， 念のため。 「グラブルが～」で示唆されるように， 動画など動きがあるとブラウザーや Twitter などでも辛い場面に遭遇することもありますけれど…。 まぁ， ローエンド機ですから…。 (^^;)

さて， 「ゲームをしたいならハイエンド機を買え」という至極真っ当な結論だったわけですが， Android 機では多少安いケースがあるものの， 10 万を超えた Apple iPhone XS/X と同レベルの高額機なら それが出来て当たり前で何も面白いところはありません。 一方ミドルレンジ機については， その言葉の範疇で済まされる機種の幅が大きいこともあって， 「意外とゲームもプレー可能」「ゲームには使い物にならない」といったように相反する話が飛び交っています。 なので， 適当に選んだ機種を買って試してみることにしました。 毎度の悪い癖です。 (笑)

　というわけで， 8 日に発注して 9 日に届いたのが表題の ASUS ZenFone 5Q なのでした。 「適当な」と言ってもゲーム用途で使えない機種を選んだのでは記事のネタになりませんので (笑)， 「意外と可能だった」という意見を TL で見掛けた この機種を選定しています。 モバイル系 PC 方面で御世話になっている ASUS でもありますし…。 スペックですが， Qualcomm Snapdragon 630， 4GB メモリー， 64GB ストレージ， そして 2160x1080 IPS 液晶…と， 昨年春モデルらしい正しくミドルレンジな内容となっています。

年が明けた今なら Snapdragon 636 を載せた ZenFone Max Pro (M1) 辺りを買ったほうが良いのかもしれませんが， メモリー 3GB， 32GB ストレージ， カメラといった辺りが響いて微妙にスペックが下なので。 いえ， カメラは使わないわけですけれどね…。 それはともかく， 31k 辺りのブツもありましたが， 多少の安心感を採って安定の Amazon 販売なブツを買っています…38k と高額組でしたけれど…。 (笑) 　カラーはルージュレッドを選択。 赤筐体は HTC J butterfly HTL21 以来かしら？

この ZenFone 5Q…。 6 インチ機だけあってデカイです…本当にデカイです (笑)：

左上画像を見てのとおり iPhone XS より微妙に大きい ZenFone Max M1 を さらに一回り凌駕しています。 もはや音ゲーの親指プレーは不可能なレベルです。 (^^;) 　その割に重さが 168g と iPhone XS より軽いです。 それは良いのですが この筐体…とにかくツルツルすぎて滑りまくるのですよね。 何らかのケースを使用しないと落としまくりそうです。 が， 付属のケースは不良品過ぎて使い物になりませんでした。 作りが雑すぎてケースに収めるとボタン類が一切使用できなく…以前に収めるのさえ苦労します。 (笑) ＞位置がずれ放題

一方の右上画像ですが， インストールしたアプリは ZenFone Max M1 から電卓系を除いたもの…アイコンの見えている Kindle， MX Player Pro とデレステ， ミリシタ， グラブル， ATOK， そして Kaspersky といった面々です。 「何じゃそりゃ!?」と言われそうですが， 元々私は 2 台持ちのiPhone 使いで， Android 勢はアカウント管理 (のみ) 用な Max M1 と実験 (今回の記事) 用の 5Q なのですから， アプリの面々に意味はないのでした。 (^^;)

　というわけで， 今回も まずはデレステに御登場願うのでした (笑)：

前回試したローエンド機の ZenFone Max M1 では， さすがに無謀が過ぎて全くゲームになりませんでした。 それに対して「んではミドルレンジ機では どれだけ善戦できるのか？」というのが今回の趣旨です。 あ， iPhone XS は別として iPhone 8 でさえ辛い場面のあるデレステですから， 無茶は承知の上での話ですよ？ (^^;) 　それはともかく， トップ・メイン共々 2D 画面が全く問題なく表示されるのに対して， 多少マシとはいえ そこかしこでプチフリーズするのは Max M1 と同じでした。 どうやら この辺りは SoC 能力以外の何かが影響しているようです。

続いては Live の前のタイミング調整：

まずは左上画像ですが， 調整画面をクリアーした結果がこれで， Max M1 ほどではないにしろ相当大きな調整幅となっています。 が， 後でも言及しますが 5Q ではノーツ側処理と音が完全に同期しますので， 適切な値へ調節さえ行えばゲーム自体は普通にプレー可能でした。 調整しようがダメだった Max M1 とは ここが大きく異なります。 一方の右上画像， さすがに 3D 標準以上はカクカクでプレーに支障が出ますから， 3D 軽量を選択しておきます。

それでは， 実際に Live を行ってみます：

画像を見てのとおり外の記事と同じく『咲いて Jewel』と行きたかったのですが， 上でも書いたとおり 6 インチ機で親指プレーはダメでした。 全連結フリックが無理すぎます。 (笑) 　いえ， 慣れれば大丈夫なのかもしれませんが， こちらに適応した代わりに本家の iPhone 8 でプレーできなくなったのでは本末転倒ですので。 結果， ここは大人しく MASTER 入門曲の『S(mile)ING!』を選択することにします。 (^^;)

というわけで， 『S(mile)ING!』の Live です：

3D 軽量設定では全くと言って良いほどカクつかないので， 「これなら行けるのでは？」というわけで裏タスクでの動画キャプチャーも行ってみました。 使用ソフトは定番の「AZ Screen Recorder」です。 さすがに iPhone レベルは無理ですので， 1440x720 30 f/s 設定へ落としてありますけれど…。 そのせいもあって， 遠景では かなり潰れてしまっています。 もっとも， そもそも「プレーが可能かどうか？」という話なので， 表タスク…つまりデレステでのプレーに殆ど影響せず撮れているだけ立派と言えます。

なので中景でも同様に潰れていて， ウエストショットな右上画像でも動きがある分やっぱり潰れてしまっています。 この辺りは仕方がないですね。

同じウエストショットでも単体のキャラだと あまり潰れなくなってきます。 そして右上の動画…。 無理矢理撮っているので潰れまくっているのを気にしてはいけません。 そして動画キャプチャーで内蔵音源の録音を行えない Android なので音なしです。 それはともかく， 動画キャプチャーというハンデ付きにもかかわらず， 3D 軽量設定ながら意外と普通にプレーが可能でした。

ただ， その動画を観ても分かるのですが， ノーツ側と音が完全に同期している一方， キャラなど MV 側は 0.4 秒ほど先行していますので， 見栄えだけは確実に劣ってしまいます。 このずれは回避不可能です。 もっとも， Master 辺りで Live 中にキャラなどを眺めている暇はないでしょうから， ある意味小さな問題と言えるでしょう。 ちなみに， ここでは載せていませんが， MV では ちゃんとキャラと音が同期しますので御安心を。

あ， キャラがレア以下だったりスコアが悲惨だったりするのを気にしてはいけません。 インストール後チュートリアルを終えた程度の育成すら行っていない段階でのプレーなので， スコアの上げようがありません。 (笑)

　というわけで， 軽量設定ながらデレステが意外と普通に 3D プレー可能と解りましたので， ご同様のアプリ…ということで今度は「ミリシタ」に御登場願います：

タイトル画面を含めた 2D 画面で何も問題ないのはデレステと同じです。 と言いますか， 基画像の解像度が高めなのか拡大処理のせいなのか， こちらのほうが綺麗に表示されます。 もっとも PC などで原寸表示させて初めて解るレベルの話ですけれど…。 (^^;)

メイン画面などの (キャラの) 3D 表示は， ZenFone Max M1 と異なり 5Q では ちゃんと高解像度表示されます。 あちらは当該設定でも なぜか軽量表示だったのですよね…。 アプリの版が上がっていますから， 今なら向こうでも大丈夫なのかしら？ 　あとで試してみましょう。

デレステより自身にリソースを割くミリシタなので， 3D 標準設定のままで普通にプレーできました。 が， 親指派に 6 インチは やっぱり厳しく， 6MIX までは楽勝でも， 慣れていない段階での MILLION MIX は無理でしたので， 大人しく AUTO PLAY の御世話になっています。 (笑) 　そして， 「表に より多くのリソース」な分裏タスクには制限が掛かりますので， デレステ以上に悲惨な動画キャプチャー結果となっています。 まぁ， 今回はキャプチャーが目的ではありませんので…。 (^^;) 　あ， ミリシタでは MV 側， ノーツ側， そして音が完全に同期しますので， デレステと異なり全く問題なくプレーが可能でした。

　…というわけで， Qualcomm Snapdragon 630 なミドルレンジ機の ASUS ZenFone 5Q ではデレステ・ミリシタ共々意外と普通にプレーが可能でした。 重量級のデレステが可能なくらいなので， これならゲーム目的での入手でも大丈夫…かもしれません。 デレステの Live で発生した「キャラなどの表示と音のズレ」のような現象が「どこで発生するか？」が問題となりそうですね。 こればかりは博打で， 事前に情報をチェックするなどしか対策方法がなさそうです。

…しかしデカイ…やっぱりデカイ。 親指派には iPhone XS や ZenFone Max M1 が限界のようです。 (笑)

自己解凍書庫その他の脆弱性情報， 公開までの顛末...

　先月末の 31 日に， 拙作ソフトの脆弱性情報が JVN にて密かに一般公開されました。 (笑) 　いえ， 既に 1 年半以上前の 2017 年 5 月に修正版が公開されている案件ですから， 「普通に公開すると却って混乱をもたらしかねない」という JPCERT/CC と私双方の統一見解により， トップページでの公開が見送られただけです， 念のため。 (^^;) 　実際， 今のタイミングで公開すると「新版を改めてインストールする必要がある」と誤解されそうですから…。

結果， JVN や JPCERT/CC の新着リストなどトップページには載っていませんが， JVN の脆弱性レポート一覧で 2 件が公開されています。 まず 1 つ目が UNLHA32.DLL， UNARJ32.DLL， LHMelt + LMLzh32.DLL， そして UNLHA32.DLL が作成する Win32 版自己解凍書庫に関する脆弱性：

• JVN ： JVN#52168232　UNLHA32.DLL、UNARJ32.DLL、LHMelting および LMLzh32.DLL における DLL 読み込みに関する脆弱性

• MHSVI#20170515-01：UNLHA32.DLL で作成された自己解凍書庫における任意の DLL 読み込みに関する脆弱性
• MHSVI#20170515-02：UNLHA32.DLL における任意の DLL 読み込みに関する脆弱性
• MHSVI#20170515-03：UNARJ32.DLL における任意の DLL 読み込みに関する脆弱性
• MHSVI#20170515-04：LHMelt における任意の DLL 読み込みに関する脆弱性
• MHSVI#20170515-05：LMLzh32.DLL における任意の DLL 読み込みに関する脆弱性

もう 1 つが UNLHA32.DLL， UNARJ32.DLL， そして LHMelt の配布自己解凍書庫に関する脆弱性：

• JVN ： JVN#83826673　UNLHA32.DLL、UNARJ32.DLL および LHMelting のインストーラにおける DLL 読み込みに関する脆弱性

• MHSVI#20170515-01：UNLHA32.DLL で作成された自己解凍書庫における任意の DLL 読み込みに関する脆弱性

となっています。 2 つめの案件については， 各ソフトのダウンロードページへ飛ぶ必要があることから， JVN からは上の 1 件目各ソフトの当公開ページへのリンクを貼っていますが， ネタとしては上の自己解凍書庫の案件が該当します。

拙作ソフトが行っている当該脆弱性への対応内容については， 次のとおりです：

• MHVI#20170718：Windows アプリケーションにおける DLL 読み込みに関する脆弱性について
• 今日の出来事 (May, 2018)：LHMelt 等での DLL ハイジャック対策覚え書き

前者が DLL 読み込み方面の各種攻撃手法を脆弱性情報として一般化したもの， 後者は LHMelt を例として それら脆弱性への対策方法の詳細を纏めたもの…となっています。

というわけで， JPCERT/CC による通知を受けてから JVN で情報が一般公開されるまでの顛末を書こう…というのが今回の趣旨です。 当方の脆弱性情報ページや Twitter で あれこれ書いたりしていますが， 一連の流れを纏めたものは ありませんでしたし…。 書いておけば きっと未来の私への情報にもなるでしょう。 (^^;)

　さて， 話は今を去ること 8 年以上前の 2010 年 8 月まで遡ります。 この頃は今で言うところの「カレントディレクトリー型 DLL 読み込みの脆弱性」が巷を賑わせていた時期に当たり， 拙作においても「MHSVI#20100824：LHMelt における安全でないライブラリーのロードによりリモートでコードが実行される脆弱性」として LHMelt の対応版を公開しています。

実は その「カレントディレクトリー型 DLL 読み込みの脆弱性」と今回の「アプリケーションディレクトリー型 DLL 読み込みの脆弱性」は起源を同一としています。 が， 当時は後者が攻撃手法として使われ出す前だったため， 脆弱性とは見なされていなかったのでした。 それどころか， 所謂「バージョンヘル」問題の解決策として， その脆弱性をも生み出す仕様が利用されていたくらいだったのです。

　ところが， 2015 年も半ばを過ぎると その「アプリケーションディレクトリー型 DLL 読み込みの脆弱性」を利用した攻撃手法が使われ出します。 そして， それに少し遅れる形で当該脆弱性の情報が公開されるようにもなってきます。 JVN を例に挙げると， 2016 年半ばから公開され始め年末辺りから頻出するようになる…といった感じでしょうか？

そのような状況もあって， 実は 2016 年の 1 月にはソフトウェア作者筋の繋がりから「こんなネタで手入れが始まったよ～」と情報がもたらされていたのでした。 しかし， 元はといえば Windows の仕様バグですし， 脆弱性に対する完全な回避策をプログラム側で施すことは実は不可能だったりします。 結果， 「MS が修正すべき問題だよね～」「んだんだ」「んでは手入れがあるまでは様子見だね～」とスルーしたのでした。 (^^;)

　それから 1 年以上経った 2017 年 4 月 4 日。 ついに順番が回ってきたらしく， JPCERT/CC から自己解凍書庫に関する脆弱性発見の通知が届きます。 (笑) 　もっとも， この時は連絡先の確認だけで， 実際に通知が行われたのは 6 日だったわけですが…。 さてその内容は 2 件…上で挙げた JVN#52168232 と もう一つだったわけですが， 別案件として報告されたものの同一脆弱性のパターン違いだったことから， 後に件の 1 つの案件として扱われるに至っています。

実はその「もう一つ」のネタなのですが， 結果論としては自己解凍書庫の脆弱性ではなく「某ウイルス対策ソフト」の脆弱性によるものだったようです。 恐らく報告者が当該ソフトをインストールしていたのでしょうね。 それは何故か？ …拙作の自己解凍書庫では有り得ないタイミングで攻撃 DLL が読み込まれていたからです。 (^^;) 　ちなみに， その対策ソフトが抱えていた脆弱性も同じ件のネタだったりします。 そして監視ソフトが やらかしているだけあって， どのようなソフトかに因らず， そのソフトが どれだけ完璧に対策を施していたとしても， 常に等しく DLL ハイジャック可能な状態へ陥れてくれるのでした。 しかも， 当該ソフトが (たとえ間接的であったとしても) 使うことのない DLL であっても攻撃が成立するという絶大な威力で…。 (笑)

余談はともかく， とりあえず「各ソフト側での完璧な対策が不可能な以上 MS が修正すべき問題」とツッコミだけは入れつつ各ソフトの修正に取りかかり， ゴールデンウィーク中にβ版を， そして同月半ばに UNLHA32.DLL のみ先行して修正版を公開しています。 この段階では， UNARJ32.DLL など他ソフトの公開については， JPCERT/CC へ提出したβ版による検証結果待ちと， Symantec への検体提出結果待ちを兼ねて様子見です。 「出したわ， 脆弱性が残っていたわ， Norton 先生に削除されまくりだわ」…では悲惨ですので。 (^^;)

ちなみに， 脆弱性有りとして通知を受けたのは UNLHA32.DLL が作成する自己解凍書庫についてのみでしたが， JPCERT/CC へ その修正版を提出した時点で， UNLHA32.DLL 本体， UNARJ32.DLL， そして LHMelt と LMLzh32.DLL についても「同様の脆弱性有り」として JPCERT/CC へ報告しています。 これらは市販ソフトや巷で公開されている一般のアプリと状況が同じで「脆弱性有り」とは見なされないのですが， 同じ脆弱性が存在することに変わりはありませんので…。

　ちょっと脱線して少し詳細に踏み込むと， 市販ソフトなどではユーザーが別途指定しない限り通常は "C:/Program Files" の配下へソフトがインストールされます。 件のディレクトリーへの書き込みには管理者権限を要することから， 「攻撃用 DLL を仕込むことは簡単には行えない」ということで， 「たとえ今回の脆弱性が存在していたとしても安全」とされています。 が， ちょっと Web を検索すれば お判りのように「管理者権限への昇格」が可能なネタは巷に溢れていて， それによる被害の情報も同様に溢れています。 そういった意味では， 安全は安全でも「多少は安全」くらいでしかないのです。 (^^;) 　こう書くと「それならシステムディレクトリー上に存在するシステム DLL も同じじゃないか!!」と必ず言われるのですが， システム DLL はカタログにより管理されていて， 勝手な上書き等が行われれば次のシステム起動時に復元されますから， また事情は異なります。

ともあれ そういった状況なので， 修正を行い JPCERT/CC へも報告を行ったのでした。 受理されているということは， 先方としても「脆弱性には違いない」という判断なのでしょう…作者が自己申告する分には。 (^^;) 　そういうわけで， 同じ JVN#52168232 の案件に各ソフトが ずらっと並んでいるのでした。

　さて， 5 月 15 日に修正版を公開し， それを受けて 16 日には JPCERT/CC 側でも公開へ向けての作業が開始される…はずでした。 ええ， ゴールデンウィークを挟んでいたこともあって 45 日以内の範疇には収まらなかったものの， 本来は比較的あっさりと JVN で情報公開されるはずだったのです。 ところが…。 (笑)

ここで登場するのが「報告者側による放置」です。 通常， 作者が脆弱性に対応した修正版を JPCERT/CC へ提出すると， JPCERT/CC や IPA による確認が行われるのはもちろん， それが報告者へも送付され報告者による確認作業も行われます。 脆弱性の発生した当該環境で発生しないようになったことを確認するのは， どうしても必要ですから…。 というわけで， 拙作ソフトの修正版自己解凍書庫も (複数の) 報告者へ送付されたわけですが， 一部の報告者が全く反応を返さなかったことから， 処理が宙ぶらりんとなったまま長期間経過してしまったのです。

その間 JPCERT/CC からは 5 回以上件の報告者へ連絡を入れているのですが， 反応が返ってこない以上， さすがに JPCERT/CC としても諦めざるを得なかったのか， 最終的に 2018 年 2 月 23 日の時点で そのまま公開へ向けた準備を行う旨連絡がありました。 はっきり言って はた迷惑な話です。

　というわけで， 11 ヶ月前に公開へ向けて処理が開始されたわけですが， JPCERT/CC の手が足りていないことから 2019 年 1 月 31 日になって漸く JVN での一般公開が行われています。 ええ， さすがに長すぎますので昨年 11 月中旬に「どうなっているのかしらぁ？」と問い合わせたりもしています。 その際の返答は「手を着けていない」でした。 催促して初めて手を着けた可能性が 70% ほど有りそうです。 (笑) 　ちなみに， 公表案が送られてきたのは 2 ヶ月ほど経った 1 月 21 日でした。 (^^;)

ちなみに， 本来の公開予定日は 1 月 28 日だったのですが， 「JVN#52168232 と JVN#83826673 を同時に公開したほうが良さそう」という話になった関係上 3 日遅れの公開となっています。

　…と， 随分時間が掛かってしまいました。 うむ。 やっぱり順番が回ってくる前に自前で対応したほうが， ずっと早くて楽ですね。 なるべく そちらで済ませるようにしましょう。 (笑)