hashcat v3.00

hashcat 是個用暴力法拿來計算各種 reverse hash 的的工具,也就是對於 HASH(key) = value 時,給 value 的值,要求得出 key 的值 (被稱為 Preimage attack)。

雖然是暴力法,但還是花了很多力氣加速,尤其在這個 GPU 已經很常見的年代,這套軟體也支援透過 GPU 加速運算。

先前的版本是 CPU 與 GPU 分開兩個版本可以用 (CPU 版本的叫 hashcat,GPU 版本的叫做 oclHashcat),而 GPU 的版本只支援 nVidiaAMD 兩家大廠的顯卡。

而在 v3.00 版,透過 OpenCL 的界面將這些全部都合而為一了:「hashcat v3.00」,所以不只是支援 CPU 與 nVidia + AMD 的 GPU,還包括了:

  • GPU
  • CPU
  • APU
  • DSP
  • FPGA
  • Coprocessor
  • Anything else which comes with an OpenCL runtime

也特別提到,Intel CPU 上內建的 GPU 部份也可以拿來用了:

For example, Intel CPUs will now instantly pop up as an available OpenCL device after you've installed the Intel OpenCL runtime.

也因為透過 OpenCL,如果有多種不同類型的加速方式,新版 hashcat 也可以同時使用。

另外這次效能評估 (與舊版比較) 也做出來了:「hashcat 2.01 / 3.00 performance comparison」,可以看到比較新一點的卡整體都有進步,而舊的卡有可能是對 OpenCL 的最佳化或是 overhead 比較敏感,慢了不少...

解譯機械碼的 Panopticon

Panopticon 看起來頗不錯,可以直接解機械碼轉成 assembly,再把 flow 畫出來讓人理解:

不過還不知道遇到 dynamic self-decoding 的程式會怎麼處理,另外我記得好像有些商用的 solution 已經有提供了,不知道相比起來如何。

用 curl 測試 Reserve Proxy 是否正確運作

架好 reverse proxy 後要測試可以用 curl--resolve 的功能來確認。

curl -v --resolve i.kfs.io:443:68.232.45.191 https://i.kfs.io/article5/global/364,324,6v1/original.png > /dev/null

其中 --resolve 的第三個參數一定要用 IP address,你可以看到他的運作原理:

* Added i.kfs.io:443:68.232.45.191 to DNS cache

HAProxy 1.6 的兩個大功能:Quote 以及 Lua

HAProxy 1.6.0 出版的公告文章:「[ANNOUNCE] HAProxy 1.6.0 released」。

兩個大功能,第一個是「It’s 2015, let’s use QUOTE in configuration file」,可以用引號了... 另外一個是「Lua Scripting」,需要 Lua 5.3+。

還有提到一些改進,像是支援 SNI,以及對 HTTP/2 的計畫。

Varnish 的 Super Fast Purger...

Reverse Proxy 的 Cache Infrastructure 在遇到 cache invalidate 都是很討厭的問題,不是不能做,而是效能不太好... 常見的作法是設計成不用 purge 的形式,只要是需要更新,就產生不同的 url,而舊的 url 在沒人 access 後會透過各種 Cache algorithms 自動回收掉,像是 LRU (Least Recently Used) 之類的演算法。

發展久了之後也因此衍伸出很多不同的架構,像是 groupcache 就是假設在同一個 address 的內容永遠不會變的前提。

Varnish Cache 這次發表的東西則是打算從根本問題解決,也就是想辦法讓 purge (cache invalidate) 的成本降低:「Simple scales better and faster in the real world」、「VAC 2.0.3 with high performance cache invalidation API (aka the Super Fast Purger)」。

官方的說法,在大台機器上可以到 60k reqs/sec:

Kristian nonchalantly mentioned that the Super Fast Purger did 60,000 requests per second, on a 6 core Xeon with 36GB memory, traffic over a gigabit network to a single Varnish Cache server, with httperf as test client. But we believe the Super Fast Purger can do a lot more with a little love and tuning.

Squid 效能不好,ATS 的文件很傷,是該找時間來測試看看...