Tag: binary

跑 ldd 有可能會執行裡面的程式碼

在 Daily Lobsters 上看到「ldd(1) and untrusted binaries」這篇，這次的重點在 ldd 的 manpage ldd(1) 裡提到可能會執行裡面的程式碼，所以不適合拿來處理 untrusted binary：

Be aware, however, that in some circumstances, some versions of ldd may attempt to obtain the dependency information by directly executing the program. Thus, you should never employ ldd on an untrusted executable, since this may result in the execution of arbitrary code.

另外在原文裡面的 comment 有人提到 macOS 上面沒有 ldd，而是用其他工具給出類似的資訊，看起來是避開了這種實作方式：

macOS and other Darwin-based systems, which use Mach-O rather than ELF, and have an 4.x/SVR4-inspired dynamic linking mechanism (not surprising, given that the person who did a lot of the work on the 4.x system left Sun to go to NeXT), but don't have an "ldd" program. Instead, there's "otool -L", which produces output such as [...]

而 FreeBSD 上的 ldd(1) manpage 上沒有提到安全問題，但從他的實作描述看起來也不太妙：

ldd lists the dependencies of an executable by setting rtld(1) environment variables and running the executable in a child process.

回到原來主題，Linux manpage 裡面提到的 objdump 跟 ldd 的功能還是差蠻多的啊？不知道合理的替代品到底是什麼...

拿 fq 看一些二進位檔案的 metadata

前幾天的 Hacker News Daily 上看到「Fq: Jq for Binary Formats (github.com/wader)」這個工具 fq，可以對二進位檔案操作：

Tool, language and decoders for working with binary data.

Ubuntu 22.04 以後的版本有套件可以直接裝 (就 apt install fq)，不過 22.04 內的版本比較舊，可以考慮抓 binary 下來丟到 ~/bin 之類的地方用，不過目前應該是先丟著，等明年 24.04 的時候就會自己換新了？

官方範例的 fq . file 可以看 metadata，這樣還算是好用，不用自己 hexdump 對半天；另外「Supported formats」這邊有每種格式對應的 column name 可以讓你操作，參考 fq --help 的說明就可以拉一些欄位出來用...

用 fpm 這個工具包 .deb 安裝

先前在「Using Cloudflare R2 as an apt/yum repository」這邊看到的工具，其中一個是 fpm，可以快速包裝成各種套件格式 (符不符合 community standard 就是另外一回事晴了)。

在「deb - Debian package format」這邊就有提到像是之前 HashiCorp 都只有丟 binary 出來時，要怎麼打包。

先抓 binary zip 檔下來，然後直接用 fpm 指定版號與要丟的 prefix，他就幫你包起來：

$ wget https://releases.hashicorp.com/terraform/1.0.10/terraform_1.0.10_linux_amd64.zip
$ fpm -s zip -t deb --prefix /usr/bin -n terraform -v 1.0.10 terraform_1.0.10_linux_amd64.zip

生出來的 terraform_1.0.10_amd64.deb 就可以直接 apt install 或是 dpkg -i 裝進去。

看起來可以是個快速先解決問題的工具，之後遇到沒有提供 apt repository 的套件可以用這個方式先打包起來裝，後續移除也比較簡單，不用靠文件來記錄一堆細節...

Decompile to C 的工具

昨天在 Hacker News 上看到「Decompiler Explorer (dogbolt.org)」這篇，裡面列出了很多 Decompile to C 的工具 (就不用直接硬看 assembly)，包括了 open source 與商用軟體：

網站本身則是提供界面可以交叉比較，不過各家的結果看起來還是有侷限...

從 Mozilla 官網下載的 Firefox 帶有追蹤用的標籤

前天看到「Each Firefox download has a unique identifier」這篇報導，就順手貼到 Hacker News 上面了：「Each Firefox download has a unique identifier (ghacks.net)」。

簡單的說就是 Mozilla 在 Firefox 的 binary 裡面加上 download token，後續就可以追蹤使用者：「[meta] Support download token」。

依照報導所提到的，每次下載 binary 都會有不同的 token：

在「Attached file dltoken_data_review.md — Details」裡面有回答更多細節，像是跟 Google Analytics 綁定：

5) List all proposed measurements and indicate the category of data collection for each measurement, using the [Firefox data collection categories](https://wiki.mozilla.org/Firefox/Data_Collection) found on the Mozilla wiki.   

<table>
  <tr>
    <td>Measurement Description</td>
    <td>Data Collection Category</td>
    <td>Tracking Bug #</td>
  </tr>
  <tr>
    <td>A download token that uniquely corresponds to a Google Analytics ID</td>
    <td>Category 4 "Highly sensitive or clearly identifiable personal data"</td>
    <td>Bug 1677497</td>
  </tr>
</table>

我自己重製不出來 (都是被導去 CloudFront)，但留言區裡面的 Yuliya 透過 Tor 有重製出來：

I have tried some TOR exit nodes:

Name: Firefox Setup 98.0.1_germany.exe
Size: 55528896 bytes (52 MiB)
SHA256: 2d8164d547d8a0b02f2677c05e21a027dc625c0c1375fd34667b7d039746d400
SHA1: 71302acbee6895b84cf0dfae99050926f2db59ef

Name: Firefox Setup 98.0.1_austria.exe
Size: 55528896 bytes (52 MiB)
SHA256: a139a45dd5737ab981068ca2596b7fdfde15e5d4bc8541e0a2f07a65defd3e4e
SHA1: 28630a0aababa162ca9e7cbca51e50b76b9c3cff

I have labeled the file for the corresponding country of the exit node.

如果不願意換到 Chromium-based 的方案，目前在討論裡看到的替代方案是 LibreWolf，昨天裝起來後發現還行，應該也可以測試看看...

在電腦上計算二進制圓周率 π 的公式

在 Hacker News 的最新列表上面看到的演算法，用來計算圓周率 π 的公式：「Bellard's formula」。

\pi = \frac1{2^6} \sum_{n=0}^\infty \frac{(-1)^n}{2^{10n}} \, ( -\frac{2^5}{4n+1} - \frac1{4n+3} + \frac{2^8}{10n+1} - \frac{2^6}{10n+3} - \frac{2^2}{10n+5} - \frac{2^2}{10n+7} + \frac1{10n+9} )

這個公式特別的地方在於 \frac{1}{2^{10n}} 的部份，這使得整個公式可以很迅速的算出某個二進制位置上的值 (要做一些條件判斷，相較於十進制轉二進制的方式快多了)，而且可以馬上想到一些平行運算的方式...

另外一個讓我注意到的點是，這居然是 Fabrice Bellard 丟出來的公式，真的是到處看到他的蹤跡耶...

HashiCorp 家的軟體看起來都支援 APT repository 了

以前 HashiCorp 家的軟體大多都是自己下載 binary 後放到 /usr/bin 或是 /usr/local/bin 下使用，剛剛翻了一下 Nomad 與 Vault，看起來都支援 APT repository 了：「https://apt.releases.hashicorp.com」；另外也有 RPM repository：「https://rpm.releases.hashicorp.com」。

這樣下個禮拜分享會的投影片也要改一改了...

另外看了一下架構，從錯誤訊息觀察，看起來後面是 Amazon S3，前面是 Fastly 的 CDN。

用 Exodus 打包 Linux ELF 檔案到其他機器上

前幾天在 Hacker News Daily 上看到的工具：「Exodus」，官方的說明是這樣：

Painless relocation of Linux binaries–and all of their dependencies–without containers.

技術上是把 Linux ELF 檔案搬到其他機器上以外，也幫你把對應的 dynamic library 都一起包進去：

  • Finding and bundling all of a binary's dependencies.
  • Launching the binary in such a way that the proper dependencies are used without any potential interaction from system libraries on the destination machine.

而 Linux 的 Kernel 因為有儘量維持 ABI compatibility，應該是不會有太大的問題，除非剛好用到新的 API...

看起來是個除了用 static compile 以外的解法，好像可以來弄弄看 FFmpeg？

生一個 static 版本的 ffmpeg

目前有丟出來的 FFmpeg 執行包都會因為軟體授權不相容的問題，沒辦法把想要的東西都包進去 (或者無視授權丟出來 XD)，但反正看一看沒看到適合的，所以弄了一天包了一包出來。另外也是因為同樣理由，這邊也只能提供步驟讓大家自己編...

我的主力放在 AV1 與 VP9 的支援上，步驟就寫在「FFmpeg」這邊了，裡面是先開了一個 Docker container 再去裝環境，接著再把會用到的 source code 用 git clone 拉下來再固定版本，所以應該是不會有太大的意外。

另外可以看到 libfdk-aac 與 libx264 兩包我就直接拉系統的套件來包，主要是查了一下版本還算堪用，而且也不是主力要處理的東西，就不想要再自己拉下來編了。

這邊就是整理一下感想...

首先是 Rust 一直在推新功能，然後各家的軟體也幾乎就是馬上跳進去用這些新功能，所以只能用 rustup 跟到最新版的 Rustc 去編 rav1e。

然後 x265 搞不定 static compile 的問題，卡在沒有 libgcc_s.a 可以用，如果還要搞 GCC 的話就太累了...

這樣在 AV1 與 VP9 的支援度就比較完整了，另外內建 libvmaf 也可以拿來分析...

2019 年 Percona 對 UUID 當作 Primary Key 的看法

前陣子的「為資料庫提案新的 UUID 格式」這邊提到了有人提案要增加新的 UUID 格式，Percona 的老大 Peter Zaitsev 在 Twitter 上貼了「UUIDs are Popular, but Bad for Performance — Let’s Discuss」這篇在 2019 年時他們家的文章，題到了 MySQL 使用 UUID 當作 Primary Key 的事情：

要注意的是這篇文章沒有要從頭解釋 UUID 對於 Primary Key 的壞處，如果你想要先了解的話，在這篇文章的開頭給了一堆其他文章的連結，裡面就有討論過了。

這篇主要是在討論，如果硬要用 UUID 當 Primary Key 時，可以有什麼方法降低對 InnoDB 的衝擊，剛好回應最近的提案。

開頭還是先花了一些篇幅大概講一下 UUID 的種類，然後在「What is so Wrong with UUID Values?」這邊提到了字串比較的差異，如果 UUID 是到最後一碼才不同的話 (這邊是跑 df878007-80da-11e9-93dd-00163e000002 與 df878007-80da-11e9-93dd-00163e000003 與比較一億次)：

1 row in set (27.67 sec)

但如果是一開始就不同的話 (這邊是選擇 df878007-80da-11e9-93dd-00163e000002 與 ef878007-80da-11e9-93dd-00163e000003) 會快很多：

1 row in set (2.45 sec)

但如果與數字相比的話 (這邊是 2=3 這樣的條件去比)：

1 row in set (0.96 sec)

可以看數字在這邊的優勢，另外也是在說明，如果你用的是 time-based ordering 的 UUID，要考慮會遇到這個可能會發生的效能問題。

再來是玩 UUID 的三種不同的儲存方式對於寫入效能的差異，分別是 CHAR(36) (32 bytes 的 hex 加上四個 -)、base64 (用 CHAR(22) 存) 與 BINARY(16)，可以看出來 BINARY(16) 因為佔用空間比較小的關係，是可以高速寫入持續最久的，再來是 base64，最差的是 CHAR(36)：

後面給了兩個 workaround，第一個算是定義了另外一種產生 128 bits 的方式，第二個則是想辦法把 UUID 對應到數字。

這在 MySQL 的環境裡面算是被討論的很久的主題了。(我猜在 PostgreSQL 應該也是，不過 PostgreSQL 的社群沒跟那麼久...)