找出並聯絡 AirPods 的失主

從「Did you lose your AirPods? (alexyancey.com)」這邊看到的,原文是「Did you lose your AirPods?」。

如同標題提到的,作者朋友撿到 AirPods,接上 iPhone 後能得到的資訊除了序號以外只有失主的電話末四碼了,不知道怎麼聯絡失主。

接下來作者開始想辦法,先假設失主是在同一個州,這樣電話的區碼 (前三碼) 就會一樣了,中間三碼的排列組合就只剩下 1000 組 (作者寫 999):

I started with the assumption that the owner lived near me in the Portland metropolitan area. With that, I restricted the search to our local area code*. Sure, they could be from out of town, but hey, let's give it a shot.

接著是透過公開的資料庫查有哪些電話號碼是有效,而且屬於行動網路的,這樣就降到 232 組:

Next, I narrowed it down by central office code (commonly called prefix) (those three digits after the area code). Most of Portland’s are assigned, but only 26% to wireless carriers. Also, 000-199 are reserved codes that aren't available for telcos. I lied earlier, sorry.

再接著,既然是 Apple 生態系的,作者決定用 iMessage Lookup API 去掃,這樣就剩下 84 組:

It's a safe bet that the owner has an iPhone with iMessage turned on. We can use this assumption to narrow down the list further by filtering out any non-iMessage phone numbers. I ran a check using this API. (The API is probably used for shady stuff, but my intentions were pure.)

最後是透過 MacBook 直接打 iMessage 出去問,就不用花錢透過簡訊聯絡:

With the list whittled down, I avoided Twilio entirely by using a script on my MacBook to send iMessages in bulk. Now we wait.

最後真的找到失主並且順利還給對方了:

回頭看裡面用到的兩個小技巧 (公開資料庫的查詢與 iMessage 的查詢),有蠻濃厚的 OSINT 味道,還蠻有趣的...

CSS 的 feature detection:@support

在「Conditional CSS」這篇裡面在講很多 CSS 條件過濾的方式,裡面看到有 @support 這個規格,可以透過 feature detection 的方式來過濾:「CSS at-rule: @supports: selector()」。

文章作者給的範例是這樣:

@supports selector(:has(p)) {
  .card-thumb {
    aspect-ratio: 1;
  }
}

在瀏覽器支援 :has(p) 的情況下才指定裡面的 CSS。

翻了一下 @support 在各家瀏覽器上實做的情況:在 Firefox 上是 69 開始支援,推出的日期是 2019/09/03。在 Chrome 上是 83 開始支援,推出的日期是 2020/05/19。在 Safari 上是 14.1 開始支援 (對應到 iOS 版本是 14.5),推出的日期是 2021/04/26。

從日期可以看出來算是比較新的功能,但主要幾個大的瀏覽器都支援了。

這個讓我想起來早期利用各家瀏覽器的 bug 產生出的各種 hack:「Browser Specific Hacks」。

修正 Curl 的 TLS handshake,避開 bot 偵測機制

利用 TLS handshake 的 pattern 可以當作是某種 fingerprint,就可以知道你是用 Curl,這個方式在蠻多 CDN 都會用在 anti-bot 機制 (像是 Cloudflare),而剛剛看到有人投稿自己的 patch,試著將 Curl 修改成 Firefox 的 pattern:「curl-impersonate」,Hacker News 上的討論在這邊可以看到:「Show HN: Curl modified to impersonate Firefox and mimic its TLS handshake (github.com/lwthiker)」。

作者有提到這次的 patch 偏 hack,不太可能整進上游,但希望未來改的乾淨一點,然後整進上游:

I hope to do so in the future, for now the implementation is extremely hacky so I doubt it can get accepted into curl.

另外有人提出來說應該要用 Firefox ESR 版本的 pattern 而非 stable channel,也有人提出來說用 Google Chrome 的更好,不過我覺得有人開始做就已經很棒了 XD

Shell Script 裡面 [ "x$var" = "xval" ] 的歷史

看到「What exactly was the point of [ “x$var” = “xval” ]?」這篇,在講為什麼不直接寫 [ "$var" = "val" ] 而是會加上 x 而寫成 [ "x$var" = "xval" ],被稱為 x-hack 的 workaround... (其實已經變成 best practice 了)

最常被拿出來講的是 - 開頭的字串,不過文章作者找到更多奇怪的 bug report,像是 () 之類的問題 XD

雖然作者提到大概在 2010 (或是 2015) 都修完了,但我應該還是會繼續這樣寫 (算是 best practice 了),可以避免在遇到老系統上遇到問題...

Terminal 的 Dark Theme

在「Automatic dark mode for terminal applications」這邊看到讓 terminal 的一些程式支援 Dark Theme 的方式,裡面引用的是「Automatic dark mode for terminal applications」這篇。

可以看到因為 terminal 下沒有標準,所以得 hack 事件發生時要送出的指令,文章裡面給出了 Vim (以及 Tmux)、Alacritty 這幾套程式的 hack。

不過這些 hack 過程算詳細 (而且有說明整個原理),如果有其他 terminal 下的程式有支援 Dark Theme 的話也可以用類似的邏輯套進去。

三不五時被提到的 LackRack

又在 Hacker News Daily 上看到 LackRack 了,這是 IKEA 的 LACK 系列家具,因為尺寸很剛好,有人就 hack 這個邊桌拿來當作機櫃用,甚至還有仿 IKEA 的組裝文件:「Manual」。

另外還可以疊 (不過要注意重量,畢竟這還是木頭):

這張邊桌在台灣也有賣,有四種不同的外觀可以選:「LACK 邊桌, 白色」、「LACK 邊桌, 黑色」、「LACK 邊桌, 高亮面 白色」與「LACK 邊桌, 黑棕色」,尺寸都是 55cmx55cmx45cm。

繞過 Screensaver Lock 的有趣話題...

Hacker News Daily 上看到「Screensaver lock by-pass via the virtual keyboard」這篇,裡面這邊題到了 screensaver lock 的有趣話題。

先講嚴肅一點的,這個 bug 被編號為 CVE-2020-25712,問題出在 xorg-x11-server 上:

A flaw was found in xorg-x11-server before 1.20.10. A heap-buffer overflow in XkbSetDeviceInfo may lead to a privilege escalation vulnerability. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.

比較有趣的事情是,這個 bug 是小朋友在亂玩時拉出 virtual keyboard 觸發的:

A few weeks ago, my kids wanted to hack my linux desktop, so they typed and clicked everywhere, while I was standing behind them looking at them play... when the screensaver core dumped and they actually hacked their way in! wow, those little hackers...

然後他說他自己搞不出來:

I tried to recreate the crash on my own with no success, maybe because it required more than 4 little hands typing and using the mouse on the virtual keyboard.

另外一個人也說他家小朋友也弄出 segfault 了:

My kids came upon a similar cinnamon-screensaver segfault! I've emailed details of how to reproduce the problem to root@linuxmint.com.

小朋友超強 XDDD

Firefox 試著透過預載 Intermediate CA 降低連線錯誤發生的機率?

在「Preloading Intermediate CA Certificates into Firefox」這邊看到 Mozilla 的人打算在 Firefox 上預載所有的 Intermediate CA,以降低 HTTPS 連線發生錯誤的作法。這點在 Mozilla 的 Wiki 上也有記錄:「Security/CryptoEngineering/Intermediate Preloading」。

的確如文章裡說的,沒有正確放入 Intermediate CA 是個 server 設定上很常見的錯誤。像是前幾天看到「【茶包射手日記】網站憑證無效案例分析」這篇講的摩斯 https://www.mos.com.tw/ 其實就是這個案例,用 SSL Labs 的工具就可以掃出來問題:「SSL Report: www.mos.com.tw (210.59.225.242)」。

問題出在於沒有送出正確的 Intermediate CA(s),所以在 Android 上找不到一條完整的 trust chain:

不過在 Windows 系統內的 CA store 是可以建立出一條完整的 trust chain,所以 Windows 上的 Microsoft EdgeGoogle Chrome 是不會有問題的 (這兩個都吃系統的 CA store):

Linux 上的 Google Chrome 就會出問題 (這邊會吃 Google 自家的 CA store 資料,就是 Android 那包)。

交叉比對中華電信自家的網站,像是「SSL Report: www.cht.com.tw (2001:b000:1a4:d000:203:75:129:111)」這組,可以看到同樣都叫做「Chunghwa Telecom Co., Ltd. / Public Certification Authority - G2」的 Intermediate CA,但有兩種不同的 SHA256,可以翻到是:「609930eb807ad420afda2a8aa61b67483039168cd766e09942a48bfe7f3bdc10」與「f5fb67c8453eda34dbec8a766574f07a03548c084af2f5e6455ea769608d9ad5」,點入裡面的「Trust」tab 中可以看到中華自己的 CA 與 ePKI 的 CA 都有交叉簽,但卻不是每一個 CA 都有被所有瀏覽器認可,所以在設定的時候就得注意...

話說回來,現在因為 CA/B Forum 的標準有強制要送 CT (Certificate Transparency),的確是有辦法抓出所有的 Intermediate CA 沒錯,但瀏覽器幫使用者預載感覺好像怪怪的?

In essence, Firefox pre-downloads all trusted Web Public Key Infrastructure (PKI) intermediate CA certificates into Firefox via Mozilla’s Remote Settings infrastructure. This way, Firefox users avoid seeing an error page for one of the most common server configuration problems: not specifying proper intermediate CA certificates.

目前大約有 2000 筆資料:

Given this information, we periodically synthesize a list of these intermediate CA certificates and place them into Remote Settings. Currently the list contains over two thousand entries.

這個比較像是 client 端的 hack?

打穿蘋果的企業網路

上個禮拜丟出來很轟動的一篇「side project」,三個月不斷的打穿蘋果的企業網路:「We Hacked Apple for 3 Months: Here’s What We Found」,對應的 Hacker News 討論可以在「We Hacked Apple for 3 Months (samcurry.net)」這邊看到。

在最後面有提到這本來是打好玩的,但後來就投入愈來愈多時間進去:

This was originally meant to be a side project that we'd work on every once in a while, but with all of the extra free time with the pandemic we each ended up putting a few hundred hours into it.

這是五個人通力合作打了三個月出來的成果,依照他們的回報數字,共打出了 55 個「洞」,考慮到週休的情況,幾乎是天天打洞出來玩:

There were a total of 55 vulnerabilities discovered with 11 critical severity, 29 high severity, 13 medium severity, and 2 low severity reports. These severities were assessed by us for summarization purposes and are dependent on a mix of CVSS and our understanding of the business related impact.

文章裡沒有對每個安裝漏洞都描述,但有針對一些比較「有趣」的漏洞說明,雖然看了以後知道是怎麼一回事,但對這些手法沒這麼熟,你叫我打我還是不會打啊 XDDD 反而是當作表演藝術來看...

用 ESP8266 模擬 PC-XT...

看到拿 ESP8266 模擬 PC-XT,是個懷古時間:「IBM PC-XT Emulator on an ESP8266」。

現在小板子的 CPU 跟記憶體都比三十年前的桌機還要大了,直接在上面跑模擬器就算慢一點也已經不是問題了... 直接上麵包板接起來跑:

然後也可以跑 Windows 3.0:

純粹 hacking 的專案 XD