用統計方法反推 JavaScript 壓縮程式的變數名稱

JavaScript 在正式提供服務時一般都會使用「YUI Compressor」、「UglifyJS」或是「Closure Compiler」壓縮後再拿到正式環境上使用,最主要的目的是為了降低網路傳輸量。

這些工具其中一個特點是,local function 與 local variable 會被較短的名字取代掉,這可以讓想要反組譯的人比較麻煩。

不過今天看到的這個工具可以解決「困擾」:「JSNice」。(在 Slashdot 上的「Machine Learning Used For JavaScript Code De-obfuscation」這篇看到的)

用統計方法去「猜測」這些 local function 與 local variable 應該叫什麼名字,讓人比較好理解。官方對準確度的說法是超過 60%:

In our experiments, we found JSNice to be effective for deobfuscating minified code. On average, more than 60% of the identifiers are recovered to the same name as before the minification process.

接下來會想辦法提供 UI 讓使用者可以選擇另外的名字:

Further, as JSNice computes multiple ranked suggestions, we provide a UI to navigate through these suggestions and select alternative identifier names.

先記錄起來,這網站很有趣,之後要 trace 別人的程式碼應該常常會用到 XDDD

node.js 版的 YUICompressor...

看「Fantastic front-end performance Part 1 – Concatenate, Compress & Cache – A Node.JS Holiday Season, part 4」的時候發現 node.js 版的 YUICompressor 比起 Perl 版本更早之前就 porting 完成了:「UglifyCSS」,甚至是官方版本的「yuicompressor / ports / js / cssmin.js」也都遠早於 Perl 版本...

npm 裝 uglifycss 就可以用了...

Perl 版本的 YUICompressor (CSS 的部份)

看到 Booking.comYUICompressor 移植到 Perl 上:「Efficient CSS Compression in Perl」。模組在 CSS::Compressor 這裡,看日期其實放出來蠻久的了?

開發的起因是因為 Java 啟動速度太慢,所以用 Perl 改寫... 雖然只能處理 CSS 的部份,但因為現在 JS 的主力應該是 UglifyJS2 或是 UglifyJS,理論上是可以把 Java 版本的 YUICompressor 了放到旁邊了?

據開發者自己的說法,因為 Java 啟動的 overhead 實在太重,就算是處理很大的 CSS 檔案,也可以省 40% 的時間,如果是小一點的檔案甚至可以省一半...