カテゴリー
バグ

Apple製品でだけ違う表示にできる PNG ファイル

PNG Parser Differential では、Apple のデバイスでだけ異なって表示される不思議な PNG ファイルが公開されています。

Windows + Chrome で見た同ページ

iPad + Safari で見た全く同じページ (Chrome でも同じ)

PNG の表示結果がまったく違い、”Hello World” が “Hello Apple” になっています。不思議ですね。

デビット・ブキャナン氏(David Buchanan)は、マルチスレッド対応のPNGデコーダを自作しようとしている時に、自分が作りこんだバグに気づいたということ。それは、一つのPNGファイルを分割してそれぞれを個別にzlibでデコードしたものを単純に結合しても、必ずしも元の画像に戻らないことに起因するバグだでした。リンク先には PoC のコードがあります。

もし分割の前半部分が非圧縮ブロックの途中であった場合に、単純結合では本来の画像が復元されないという問題が起こるそうなのですが、そうすると PNG を小分けにしてデコードしようとしない限りこのバグを作りこむことはなさそうです。

そして、この問題をさらに調べたブキャナン氏は Apple のデコーダーにも同じバグがあるらしいと気づいたわけですね。Apple のデコーダはマルチスレッドで PNG データを分割デコードしているようです。おそらくパフォーマンスを稼ぐため。そこには iDOT というApple 独自のチャンクタイプも絡んでくるらしいのですが、とにかく、前記のような条件を満たす PNG を人工的に作ることで、Apple デバイス上のレンダリングでは違う解釈をさせることができるというのが、冒頭の不思議な PNG ファイルというわけです。

そのうち修正されるのだろうとは思いますが、これまでもバグを指摘していた人たちはいるようです。このバグをわざと使って何かする人とかでてきますかね。

via Hacker News

カテゴリー
技術

Confusables – 紛らわしい文字を含めて検索できるPythonライブラリ

Unicode コンソーシアムが提供している見た目そっくりな文字リストにある文字が紛れていても文字列マッチする小さなライブラリが Confusables です。

このクラスは最新の Confusables.txt を Unicode.org から取得し、紛らわしい文字を含んだマッチする正規表現を生成してくれます。

たとえば、”Hello” に対しては次のようなパターンができます。

Regexp pattern: [HHℋℌℍ𝐇𝐻𝑯𝓗𝕳𝖧𝗛𝘏𝙃𝙷Η𝚮𝛨𝜢𝝜𝞖ⲎНᎻᕼꓧ𐋏ⱧҢĦӉӇ][e℮eℯⅇ𝐞𝑒𝒆𝓮𝔢𝕖𝖊𝖾𝗲𝘦𝙚𝚎ꬲеҽɇҿ][l‎\|∣⏽│1‎۱𐌠‎𝟏𝟙𝟣𝟭�
IIIⅠℐℑ𝐈𝐼𝑰𝓘𝕀𝕴𝖨𝗜𝘐𝙄𝙸Ɩlⅼℓ𝐥𝑙𝒍𝓁𝓵𝔩𝕝𝖑𝗅𝗹𝘭𝙡𝚕ǀΙ𝚰𝛪𝜤𝝞𝞘ⲒІӀ‎‎‎‎‎‎‎‎ⵏᛁꓲ𖼨𐊊𐌉‎‎łɭƗƚɫ‎‎‎‎ŀĿᒷ🄂⒈‎⒓㏫㋋㍤⒔㏬㍥⒕㏭㍦
⒖㏮㍧⒗㏯㍨⒘㏰㍩⒙㏱㍪⒚㏲㍫ljIJ‖∥Ⅱǁ‎𐆙⒒Ⅲ𐆘㏪㋊㍣Ю⒑㏩㋉㍢ʪ₶ⅣⅨɮʫ㏠㋀㍙][l‎\|∣⏽│1‎۱𐌠‎𝟏𝟙𝟣𝟭𝟷IIⅠℐℑ𝐈𝐼𝑰𝓘𝕀𝕴𝖨𝗜𝘐𝙄𝙸Ɩlⅼℓ𝐥𝑙�
𝓁𝓵𝔩𝕝𝖑𝗅𝗹𝘭𝙡𝚕ǀǀΙ𝚰𝛪𝜤𝝞𝞘ⲒІӀ‎‎‎‎‎‎‎‎ⵏᛁꓲ𖼨𐊊𐌉‎‎łɭƗƚɫ‎‎‎‎ŀĿᒷ🄂⒈‎⒓㏫㋋㍤⒔㏬㍥⒕㏭㍦⒖㏮㍧⒗㏯㍨⒘㏰㍩⒙㏱㍪⒚㏲㍫ljIJ‖∥Ⅱǁ‎𐆙⒒Ⅲ𐆘
㏪㋊㍣Ю⒑㏩㋉㍢ʪ₶ⅣⅨɮʫ㏠㋀㍙][oంಂംං०੦૦௦౦೦൦๐໐၀‎۵oℴ𝐨𝑜𝒐𝓸𝔬𝕠𝖔𝗈𝗼𝘰𝙤𝚘ᴏᴑꬽο𝛐𝜊𝝄𝝾𝞸σ𝛔𝜎𝝈𝞂𝞼ⲟоჿօ‎‎‎‎‎‎‎‎‎‎‎‎‎‎‎‎‎‎‎‎ഠဝ𐓪𑣈
𑣗𐐬‎øꬾɵꝋөѳꮎꮻꭴ‎ơœɶ∞ꝏꚙൟတ]

あとはこれに対して入力された文字列がマッチするかをチェックすれば、紛らわしい文字列かどうかの判定ができるというわけです。

テストコードでは “𝓗℮𝐥1೦” が “Hello” にマッチすることが確認できます。紛らわしい文字列として真で、元の”Hello”と同値ではないなら、誤認することを狙った”Hello”のニセモノだ、というわけですね。

Confusables のリスト中には日本語の紛らわしい文字(ハと八とかニと二とか)もあります。『カタカナの「ノ」はスラッシュと似ている』という定義もあり、”and/or” に間違うパターンを出してみるとこんな風になりました。カタカナの「ノ」だけじゃなく斜め線に見える文字もたくさんUnicodeにあるんですね。

Regexp pattern: [a⍺a𝐚𝑎𝒂𝒶𝓪𝔞𝕒𝖆𝖺𝗮𝘢𝙖𝚊ɑα𝛂𝛼𝜶𝝰𝞪а⍶℀℁ꜳæӕꜵꜷꜹꜻꜽ][n𝐧𝑛𝒏𝓃𝓷𝔫𝕟𝖓𝗇𝗻𝘯𝙣𝚗ոռɳƞη𝛈𝜂𝜼𝝶𝞰ᵰnj][dⅾⅆ𝐝𝑑�
𝒹𝓭𝔡𝕕𝖉𝖽𝗱𝘥𝙙𝚍ԁԁᏧᑯꓒɗɖƌđ₫ᑻᒇʤdzʣdžʥ][/᜵⁁∕⁄╱⟋⧸𝈺㇓〳Ⳇノ丿⼃⧶⫽⫻][oంಂംං०੦૦௦౦೦൦๐໐၀‎۵oℴ𝐨𝑜𝒐𝓸𝔬𝕠𝖔𝗈𝗼𝘰𝙤𝚘ᴏᴑꬽο𝛐𝜊𝝄𝝾𝞸σ𝛔�
𝝈𝞂𝞼ⲟⲟоჿօ‎‎‎‎‎‎‎‎‎‎‎‎‎‎‎‎‎‎‎‎ഠဝ𐓪𑣈𑣗𐐬‎øꬾɵꝋөѳꮎꮻꭴ‎ơœɶ∞ꝏꚙൟတ][r𝐫𝑟𝒓𝓇𝓻𝔯𝕣𝖗𝗋𝗿𝘳𝙧𝚛ꭇꭈᴦⲅгꮁɽɼɍғᵲґ𑣣mⅿ𝐦𝑚𝒎𝓂𝓶𝔪𝕞𝖒𝗆𝗺𝘮
𝙢𝚖𑜀₥ɱᵯ]

“andノor” と入れると、”Matched” となるわけです。

日本語ドメインもあまり普及していないし、日本語に紛らわしい文字を混ぜた文字列で何かをすり抜けられるというユースケースもそんなにないかもしれませんが、まあそういう必要があればこういったチェックをつけるのでしょう。

カテゴリー
技術

Debian の perf を高速化するパッチと、そのGPL的な背景

Cargo の flamegraph ツールがDebian の perf のせいでとても遅いという話。

Cargo flamegraph sample

perf コマンドがプロファイルデータを解析する際に libbfd をリンクすればずっと高速になるのですが、Debian のポリシーでライセンスに違反するため libbfd をリンクすることはできないそうです。

[修正] コメントでの指摘を受け修正しました

perf のライセンスが GPL バージョン2、libbfd のライセンスが GPL バージョン3+ であり、これら二つのプロジェクトを合法的にリンクさせる方法がないそう。

Debian の Makefile では、わざわざ生成された perf コマンドが libbfd をリンクして「いない」ことをチェックするようになっているのですね。

そんな訳で、Debian の perf は dso 一つごとに addr2line コマンドをパイプで呼び出す(そして、毎回サブプロセスは終了する)方式となっています。

しかし、大量の perf 呼び出しを行う flamegraph を作ろうとした @leastfixedpoint さんは、いつまでも帰ってこない perf コマンドに業を煮やし、libbfd をリンクさせない範囲での高速化を考えました。

このパッチでは、addr2line を別プロセスとして起動させたままにしておき、dso をデータとして送り付け結果を受け取っても、addr2line プロセスを終了させないことで、とあるデータ量に対して68倍速く処理が終わるようにできたそうです。

対象のデータ量によっては気にならない程度の速度差なのかもしれませんが、同じようにここの処理速度で困ってる人もいるんじゃないでしょうかね。

via Hacker News