用統計方法反推 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

Go 的 self-boot 計畫

Go 的 self-boot 計畫,也就是用 Go compiler 編 Go compiler:「Russ Cox – porting the Go compiler from C to Go」。

其中提到:

The goal is to convert *their* C code (not all C code). They want generated code to be human-readable and maintainable. They want automatic conversion to handle 99+% of code.

第一波想要用機器轉換過去,而且要轉出可維護的程式碼。可以馬上想到的事情是,如果這件事情成功,代表現有軟體的 C code 也有機會轉移?

接下來了幾個版本會開始發展整套機制,有得瞧了 :p

FreeBSD 預設的 compiler 從 GCC 換成 clang

FreeBSD 預設的 compiler (/usr/bin/cc/usr/bin/c++/usr/bin/cpp) 從 GCC 4.2.1 換成 clang 了:「Revision 242624」。

目前只有 CURRENT 裡的 amd64 與 i386 版本換過去,如此一來,FreeBSD 10.0 會是第一個使用 clang 作為預設編輯器的正式版本 (看起來不像會 back port 回 FreeBSD 9)。接下來是 Ports 大混戰了,應該會有一卡車的 ports 用 USE_GCC=yes 來解?

從 2009 年的努力到現在三年多了 (參考「[ANNOUNCE]: clang/llvm can compile booting FreeBSD kernel on i386/amd64」這封公告信),離拔掉 GCC 4.2.1 又進了一大步...

clang 的進展...

OSnews 上看到 clang 2.8 與其他幾個 compiler 的比較:「Compiler Benchmarks of GCC, LLVM-GCC, DragonEgg, Clang」。

以測試結果來說,如果改用 Clang,有些會變得比較快,但也有些變得比較差。不過以 license 以及後勁來看,還蠻看好發展的。六月的時候在 FreeBSD 的 -HEAD 裡面變成 default compiler,預定 9.0-RELEASE 會是 FreeBSD 上第一個用 clang 的版本... (感謝 lwhsu 戳中)