Symbolic execution: Solving a Crack Me by lazy way

Symbolic execution

Symbolic execution là một chủ đề gần đây rất ồn ào. Symbolic execution là một hình thức mở rộng hơn của dynamic binary analysis (nếu bạn chưa hiểu về nó thì có thể đọc thêm một bài cũ ở đây). Thay vì chỉ đi một luồng thực thi với một input tương ứng như dynamic, symbolic với từng nhánh rẽ (branch) có thể quyết định đi nhánh nào với input đầu vào tương ứng như thế nào.

Nguồn: http://slideplayer.com/slide/3238789/

Nguồn: http://slideplayer.com/slide/3238789/

Ví dụ:

Trong đoạn code này, giá trị input là giá trị đầu vào.
Đoạn rẽ nhánh là toán tử != trong hàm if.
Chỉ cần dùng một phép tính, ta có thể dễ dàng tính được với giá trị nào của input để nhánh rẽ và TRUE và ngược lại.

Nhiệm vụ của symbolic execution, cũng như vậy tại vị trí rẽ nhánh này, nó sẽ giải toán biết với giá trị input nào thì luồng chạy sẽ đi vào nhánh TRUE / FALSE.

Để làm được điều này, ta cần làm 2 việc:

  1. Theo dõi luồng làm việc của một input đầu vào: + – ~ / and or xor not … các loại, từ đó tới branch tương ứng thì suy ra được một biểu thức toán cho biến symbolic đầu vào
  2. Một công cụ để giải toán. Việc này không đơn giản, phép toán thì nhiều, dạng toán cũng lắm mà tay người thì hơi bé. Cũng may mà có lý thuyết và công cụ để giải giúp, chủ đề này gọi là Satisfiability modulo theories

CrackMe by lazy way

Trong phần này, ta sử dụng symbolic execution trong việc giải quyết một bài CrackMe khá chua nếu làm bằng tay.

Đề bài: Đầu tiên ta đọc cái đề đã

Đoạn code hơi khoai, mình dùng để compile TCC đoạn code trên.
Quan sát control flow graph một tý, ta thấy điều kiện if

Sẽ được compile ra dạng như sau:

 if ((pass_val2 - pass_val4) == 0)

if ((pass_val2 – pass_val4) == 0)

Nhánh TRUE mang theo màu xanh hi vọng, và nhánh đỏ là nhánh FALSE. Tương tự như vậy cho gần một chục cái rẽ nhánh khác.

a. Rẽ nhánh thủ công

Đầu tiên, ta xem cách giải quyết của bài viết: Solving a Crack Me with Triton and Pin (a.k.a the lazy way).

Đoạn code này cho ra flag như sau:

Ta có flag: Tr!t0NRock5

Ở cách này, mỗi nhánh rẽ người code sẽ xác định xem nó sẽ phải đi theo nhánh nào để đạt đi tới khối code Good password!!!!, engine sẽ lo phần giải để tìm giá trị tương ứng của từng nhánh rẽ này.

Cách này ổn, nhưng việc thủ công xác định hơn chục điểm rẽ nhánh hơi mất sức. Chưa kể nếu nhìn code, chúng ta thấy có thể có nhiều hơn chỉ một flag trong bài này.

Symbolic cho phép chúng ta xác định được có thể đi nhánh TRUE/FALSE, vậy nếu có một cách nào đó tự cover tất cả các branch đi thì mọi thứ sẽ được giải quyết, ta chỉ cần xác định 2 vị trí:

  1. Vị trí nhập input đầu vào để set giá trị symbolic tại đó
  2. Vị trí xuất ra dòng  Good password!!!!, do engine symbolic travel qua tất cả các nhánh, đồng nghĩa với việc chúng ta chỉ cần đặt “break-point” tại vị trí xuất này, lấy ra giá trị symbolic hiện thời ở nhánh đó cũng chính là flag.

Để tìm hiểu vấn đề cover này bạn có thể đọc ở đây: Code coverage using a dynamic symbolic execution

b. Code coverage

Phần này mình sử dụng một engine đang phát triển đã giới thiệu ở bài viết trước.

Code tương tác như sau:

Chạy một vài giây, ta có giá trị:

Bạn sẽ thắc mắc flag này tại sao không giống tiếp cận trước. Do xét nhiều branch, nên có thể sinh nhiều flag, ta tạm tắt log branch đi, chỉ xem các dòng flag. Ta sẽ có vài chục flag trong đó có chứa flag như tiếp cận trên, sau vài chục giây chạy:

Kiểm tra lại 1 flag ngẫu nhiên trong này ra xem có đúng thiệt không:

Recheck

Binary và code để giải theo tiếp cận này các bạn có thể xem ở đây: https://github.com/zunc/First-hands-with-Triton 

Về symbolic execution engine sử dụng trong bài viết

Hiện nhóm dev đang cố gắng để ổn định và xây dựng engine dễ dùng hơn (hiện tại còn khó dùng quá). Khi mọi thứ dễ sử dụng hơn, mình hi vọng sự đóng góp ý kiến và coding của mọi người cho engine này.

Tham khảo

  1. Bài viết và tiêu đề này lấy ý tưởng từ bài viết gốc: Solving a Crack Me with Triton and Pin (a.k.a the lazy way)
  2. Introducing Ponce: One click symbolic execution
  3. The Art of War: Offensive Techniques in Binary Analysis

Malware analysis: Emdivi for lazy man

Lại là Emdivi, nhưng lần này chúng ta sẽ tìm hiểu một cách đỡ mất sức hơn so với cách dùng debugger phân tích.
Bài này sẽ sử dụng cách phân tích động tương tự debugger, nhưng tiếp cận khác tự động hóa hơn, tương tự như trong một bài viết cách đây 2 năm đã đề cập.

Công cụ sử dụng:

  1. BE-PUM: Công cụ chính sử dụng, là một engine dynamic analysis vẫn đang trong quá trình phát triển của một team Việt tự phát triển trên nền Jakstack. Engine gồm một emulator để thực hiện các lệnh assembler và cơ chế sandbox khi gọi Windows API ra ngoài.  Engine có Java API để tương tác trong quá trình phân tích.
  2. IDA: Tất nhiên rồi, IDA đi muôn nơi.

1. Chuẩn bị

Toàn bộ quá trình phân tích mình sẽ sử dụng các API mở bởi engine trên.

Ban đầu phải nhắc lại là engine phân tích chính sử dụng ở đây vẫn còn đang phát triển, vẫn còn rất nhiều thứ phải làm để hoàn chỉnh dần. Trong bài sử dụng một một chút workaround để phân tích được các mục tiêu mong muốn. Thao tác này thực tế hơi mất sức, chịu khó tý vậy, engine đang còn dev mà.

Việc workaround cụ thể ở đây là bypass một số đoạn gây lặp bất tử cho emulator. Mình sử dụng API onInstruction của engine để làm chuyện này:

Các đoạn comment là các đoạn mình mình sử dụng IDA, kết hợp với theo dõi quá trình emulator của engine này.

2. Xác định nơi sử dụng C&C server

Bởi vì công cụ này hỗ trợ log lại tất cả các mã assembler và Windows API được gọi, nên trước tiên ta cứ chạy và xem kết quả sao đã. Sau tầm 40 phút cắm máy chạy, engine báo hoàn thành phân tích,

API monitor

API monitor

Bởi vì nó sử dụng dynamic, nên không có gì lạ khi các API lần lượt phơi mình ra. Ta xem chi tiết hơn log, nếu engine chạy đúng thì tương tự như ở bài phân tích trước, hàm Internet nào đó sẽ được sử dụng, ta search text ‘Internet‘ trong log file.

Địa chỉ gọi và C&C domain

Địa chỉ gọi và C&C domain

Vậy ta có kết quả:

Có thể làm bạn thất vọng vì độ ngắn ngủn nhưng như tiêu đề đã nói đây là bài phân tích cho người lười nhác, thực sự là mục tiêu đã hoàn thành và bài viết có thể kết thúc ở đây.

Nhưng nếu dừng lại vậy thì ngắn quá, mà ít keyword thì không hút được khách. Nên mình viết thêm 1 đoạn nữa.

3. Monitor HeapFree API

Tại sao lại là HeapFree ?

Cái này đơn giản là do quá trình theo dõi API được gọi, mình thấy HeapFree được gọi rất nhiều. Với suy nghĩ đơn giản, do đây là một malware sử dụng làm rối chuỗi trên hầu hết chương trình, khi giải mã string xong nếu nó để nguyên string ấy rồi free thì bên dưới cũng sẽ gọi hàm HeapFree này.

BE-PUM hỗ trợ api onAPI để theo dõi các hàm API được gọi. Nhưng như đã phân tích ở trên, nếu ta chỉ chặn địa chỉ gọi HeapFree thì thật ra nó là địa chỉ cố định thuộc hàm free của C/C++.

Ta có thể kiểm chứng điều trên qua hình sau:

HeapFree nằm bên trong free

HeapFree nằm bên trong free

Như vậy, nơi thật sự dùng các string này sẽ là địa chỉ của hàm mẹ gọi hàm free này mới. Nói vắn tắt thì ta cần biết thông tin stack gọi của hàm free này.

Call stack trong IDA

Call stack trong IDA

Sử dụng onInstruction để tự cài đặt quá trình này, ta giả lập một cái stack vào ra với các hàm call và dạng hàm ret.

Vậy là ta đã có khối theo dõi Call stack của chính chúng ta. Giờ là việc theo dõi các string vào ra, ở đây chỉ quan tâm các string có thể in được:

Kết quả chúng ta thu thập được:

Nếu muốn, ta có thể dò ngược lên tìm các đoạn code làm gì với string này. Hoặc Google với một vài string coi người ta nói gì về tụi nó.

Malware analysis: Blue Termite APT aka Emdivi

Emdivi  là một malware trong một chiến dịch APT tấn công vào Nhật Bản vào cuối năm 2014.
Do duyên số đưa đẩy kiểu gì ấy nên mình vô tình có mẫu và tiến hành phân tích theo một số mục tiêu nhất định. Trong bài viết này là note lại các bước thực hiện phân tích.

I. Mục tiêu

  • Xác định vị trí hàm giải mã các string bị làm rối
  • Xác định C&C server và hàm sử dụng

II. Tiến hành

Trong bài phân tích này sử dụng công cụ IDA 6.8 (bao gồm Hexrays) để disassembler và debug, phần sau trình bày cách sử dụng Olly.

1. Nhìn tổng quan

Với mục tiêu là tìm ra C&C server, ta cần xác định malware gọi các API về mạng ở đâu. Ở trong bước nhìn tổng quan, ta cần xác định malware sử dụng kỹ thuật gì để gọi API.
Có 2 phương pháp gọi API cơ bản:
- Import table: phương pháp gọi thông thường, địa chỉ các hàm này nằm tĩnh trong PE header.
- Dynamic API load: thường là sử dụng cụm hàm: LoadLibrary(A/W), GetProcAddress để gọi động các API.

a. Import table
Bản import table chỉ có vài hàm, chưa thấy các API ấn tượng gì lắm.

Hình 1: Import table

Hình 1: Import table

Coi sơ qua code, ta dễ dàng nhận ra nhiều chỗ dùng các hàm: LoadLibraryA, GetProcAddress

Hình 2: Call dynamic API

Hình 2: Call dynamic API

Nhìn lên một chút để tìm xem coi có string của các API không, thấy chỉ toàn chuỗi đã base64.

Hình 3: String bị làm rối

Hình 3: String bị làm rối

Thử decode base64 thì ra toàn binary, như vậy còn có thuật toán mã hóa bên dưới lớp base64 này.

Nguyên tắc khi gọi các Windows API là các giá trị truyền vào kể cả string thì cũng phải xuất hiện là tham số đầu vào. Nên ta chỉ cần tìm cách chặn đầu vào gọi hàm là sẽ biết được các giá trị, có 2 hướng tiếp cận:

  1. Dùng hook: Cách này nhanh gọn nhẹ, nhưng không đảm bảo nắm tường tận hành vi, chưa kể các trick nhận dạng VM, bị hook …
  2. Debug: Theo như mục tiêu thì phải xác định được vị trí code thực hiện các thao tác, nên ta chọn hướng tiếp cận này.

Cũng theo nguyên tắc trên, ta biết là string phải được giải mã và push địa chỉ vào stack trước khi gọi API, nên ta chỉ việc debug các vị trí gọi API là đủ. Ta có thể xem các hàm giải mã này như các black box.
Với các đoạn code gọi API động có string làm rối, logic làm việc thông thường như sau:

  1. Lấy giá trị string đang bị encrypt ra từ đâu đó trên bộ nhớ đặt vào biến v1
  2. v2 = decrypt(v1); // giá trị sau giải mã
  3. hModule = LoadLibrary(szLib); // load lib lên bộ nhớ
  4. func = GetProcAddress(hModule, szAPI); // lấy địa chỉ API từ library. Từ bước này ta có một con trỏ hàm.
  5. Thực thi API bằng con trỏ hàm bằng thao tác với các thông số truyền qua stack.
  6. func(param1, …, paramN);

Xuyên suốt quá trình phân tích ta sẽ sử dụng logic làm việc này.

III. Tiến hành

1. Hàm giải mã string

Bằng logic như phân tích phần trên. Ta sử dụng thêm hexray để đọc mã giả C để dễ dàng tìm ra hàm giải mã string.
Tập trung quan sát một đoạn cụ thể gọi hàm GetProcAddress.
Với logic làm việc trên, ta truy ngược từ hàm GetProcAddress để xác định hàm nào là giải mã string.

Hình 4: Nhận dạng hàm giải mã string

Hình 4: Nhận dạng hàm giải mã string

Ta đã xác định được hàm giải mã từ các biến liên quan, trong đoạn code này cũng thấy được việc giải mã một string thông qua 2 hàm xử lý như sau:

Trong các case khác, ta thấy một số đoạn giải mã string chỉ dùng 1 hàm procStrDecrypt để giải mã string, còn param string ra còn lại được hard-code vào.

Hình 4: Decrypt string một bước

Hình 5: Decrypt string một bước

Như vậy ta có vị trí các hàm chính để mã hóa:

2. Xác định C&C server

Như đã phân tích, việc gọi các API chắc chắn sẽ thông qua việc xác định địa chỉ bằng hàm GetProcAddress.
Do các string đã mã hóa, nên ta chưa xác định được API cụ thể nào và đoạn code nào sẽ làm việc đó. Tốt nhất là đặt breakpoint tại tất cả các nơi API GetProcAddress được gọi.
Ta dùng chức năng Jump to xref to operand… của IDA để xác định các nơi dùng hàm này.

Hình 5: Các địa chỉ gọi hàm GetProcAddress

Hình 6: Các địa chỉ gọi hàm GetProcAddress

Chú ý là trên hình này, có tên các API cụ thể gọi là do người viết bài tự comment, chứ gốc không có. Ở đây sẽ tự debug để xác định vị trí đó gọi cụ thể hàm nào.
Vì mã giả C của Hexray rất mạnh, ta cũng nên tận dụng nó để vừa debug assembly vừa xem mã C cho dễ hình dung cách code làm việc.

Hơi thủ công một tý, đặt breakpoint tại tất cả các điểm trên:

Hình 6: Debugger dừng tại một breakpoint, ta thấy mã giả C bên trái

Hình 7: Debugger dừng tại một breakpoint, ta thấy mã giả C bên trái

Bằng cách nhìn lệnh push, ta có các giá trị string thật của các API.
String sẽ hiện các char rời, để dễ nhìn ta có thể dùng chức năng xem dạng string của IDA.

Hình 8: Merge char string

Hình 8: Merge char string

Sau khi merge ta sẽ có dạng dễ nhìn như sau:

Hình 9: Merge string

Hình 9: Merge string

Ta tiếp tục debug như vậy để hoàn thành dần các vị trí API chưa biết cụ thể.
Sau 1 lúc debug sẽ thấy các hàm liên quan về mạng.
Do hàm GetProcAddress sẽ lấy vị trí API nên chưa gọi ngay, ta cần xác định thêm vị trí gọi hàm này, tốt nhất là nhìn qua tab Pseudocode cho dễ tìm ra vị trí này, rồi đặt thêm breakpoint ở phần code assembly.
Khi vừa thực hiện thường để ý đổi tên biến cho dễ nhìn:

Hình 10: Gán lại tên biến cho con trỏ hàm

Hình 10: Gán lại tên biến cho con trỏ hàm

Hình 11: Vị trí gọi hàm API

Hình 11: Vị trí gọi hàm API

Cùng với việc xem memory khi debug, ta dò xác định được C&C server thông qua hàm InternetConnectW.

IV. Xác định C&C server bằng Olly

Load mẫu malware vào Olly.
Mục tiêu là chặn lại các nơi gọi hàm GetProcAddress và các hàm Sleep. Ta sử dụng chức năng Search All Intermodular calls để tìm các hàm này.

Hình 12: Tìm các API sử dụng

Hình 12: Tìm các API sử dụng

Ta sẽ có danh sách API sử dụng như sau. Đặt breakpoint tất cả các vị trí gọi 2 hàm GetProcAddress, Sleep.

Hình 13: Danh sách các API sử dụng

Hình 13: Danh sách các API sử dụng

Sau khi đặt breakpoint, ta tiến hành run bình thường (F9). Breakpoint khi dừng tại các chỗ gọi hàm GetProcAddress ta có thể xem các lệnh push để xem API gọi lấy địa chỉ thực của nó là gì.

Hình 14: Tên của API qua hàm push

Hình 14: Tên của API qua hàm push

Để dễ nhớ cho các lần debug sau thì nên comment lại các hàm API này.
Ta sẽ chạy như vậy để hoàn chỉnh các vị trí gọi hàm GetProcAddress còn trống.
Sau một vài lần gọi vào GetProcAddress thì các breakpoint sẽ nhảy vào hàm Sleep.
Để tiện chỉnh sửa giá trị của Sleep thì ta nên đặt breakpoint tại vị trí push ngay trên hàm Sleep để chỉnh giá trị tại đây luôn cho tiện

Hình 15: Breakpoint tại lệnh push tham số cho Sleep

Hình 15: Breakpoint tại lệnh push tham số cho Sleep

Người phân tích đã thử hướng NOP cả 2 lệnh PUSHCALL này nhưng kết quả mẫu chạy không còn đúng logic. Nên sẽ tiến hành như sau:

  1. Đổi giá trị EDX về giá trị 0 để hàm Sleep khỏi sleep.
  2. NOP dòng 41C0FB JNZ SHORT 0041C0D0: mục đích của việc này là nhanh chóng thoát khỏi khối lặp gọi hàm Sleep.
Hình 16: Sau khi tiến hành NOP

Hình 16: Sau khi tiến hành NOP

Sau đó tiếp tục chạy, nếu lại gọi vào hàm Sleep trong khối code này thì lại set giá trị EDX về 0 tiếp.

Cứ chạy như vậy ta sẽ tới các vị trí gọi hàm GetProcAddress tiếp theo. Sau một vài thao tác chạy ta sẽ tới 2 vị trí lấy giá trị hàm InternetConnectW.

Hình 17: Hai vị trí lấy giá trị hàm InternetConnectW

Hình 17: Hai vị trí lấy giá trị hàm InternetConnectW

Đây là vị trí lấy giá trị của API chứ chưa phải nơi gọi, nên ta cũng cần tìm chỗ gọi các hàm này.
Để xác định vị trí này ta có 2 cách:

1. Olly thuần
Do đoạn lấy địa chỉ thường nằm gần chỗ gọi, ta có thể debug để tiếp tục tìm kiếm nơi gọi.

2. Dùng kết quả bên trên phân tích từ IDA cho lẹ: Đoạn này đang nhác nên vậy cho lẹ :3
Hoặc ở đây đơn giản là dùng lại giá trị như đã phân tích từ IDA.
Ta chủ động đặt breakpoint tại: 004105B3

Sau vài bước tiếp tục run qua một vài chỗ gọi GetProcAddress, ta tới được nơi gọi hàm này tại 004105B3.

Hình 18: Xác định được C&C domain

Hình 18: Xác định được C&C domain

[Trekking] Ma Thiên Lãnh – Bà Đen for dummy

Nhân một dịp ngẫu hứng, muốn đổi gió, tránh bụi Sài Gòn, botbie team quyết định làm một chuyến đi chơi Ma Thiên Lãnh – Bà Đen mà đến tận bây giờ, sau khi đi về mình vẫn chưa biết tại sao mình biết chỗ này ( hình như từ fb một bạn trẻ đẹp số nào đó ).

Để chuẩn bị cho chuyến đi này mình đã phải mò hết internet mà không tìm ra được một cái review nào chi tiết, nên mình quyết định làm một cái review cho những ai có ý định chinh phục cung đường này :*

Chuẩn bị:

Những thứ cá nhân cần mang theo:
1. Nước (2 đến 4 lít tùy thể lực mỗi người) (require)
2. Giày có độ bám tốt, vừa chân (require)
3. Balo có trợ lực hoặc tự chế (require)
4. Dụng cụ, giấy vệ sinh cá nhân (require)
5. Áo giữ ấm (recommend)
6. Mang 1 triệu phòng thân (recommend)
7. Bọc nilông đựng đồ dơ, rác… (recommend)
8. Nón tránh nắng (option)
9. Dép mang buổi cắm trại và khi về (option)
10. Kem, thuốc…. chống nắng, côn trùng, muỗi… (option)

Những thứ mua chung:
1. găng tay cao su: để bám vào đá lúc leo núi, rất cần thiết
2. áo mưa và ống chân bọc giày: theo porter thì không cần thiết vì mang áo mưa khó leo và nóng, có mưa thì tắm mưa luôn
3. 2kg trái cây (quýt, táo, lê…) : trái cây có nhiều nước ăn lúc leo núi rất ngon
4. 1 kg khoai nướng: để nướng đêm lửa trại
5. 2kg than nướng khoai
6. 2 con gà đã luộc
7. 2 Bánh mì sandwich nhỏ, 9 dưa leo và 1 patê
8. 9 bánh chưng, 9 bánh tét, 9 bánh ít (loại nhỏ).
9. 9 lon Ken
10. 9 chai Pocari sweat: bổ sung muối, khoáng, ion…
11. 10 lon bò húc
11. Cồn, bông, gạc, băng cá nhân, thuốc đau bụng, thuốc hạ sốt, Salonpas
12. Một ít sả, tỏi
13. 2 lều trại
14. Cồn cục đốt lửa trại
15. Bật lửa

Hành trình:

- 2h chiều thứ 7 (9/7): Cả team tập họp chia đồ và bắt đầu đi

- 17h: Có mặt tại khu du lịch núi bà đen, rẻ vào một đường nhỏ ngay bên trái trước cổng chào của khu du lịch núi Bà Đen, qua khúc cua trước cổng chùa là quán cô Năm sơ ri, tại đây bọn mình có hẹn với porter là anh Bé (sđt: 0948505984) để dẫn đoàn đến nơi cắm trại, hoặc bạn có thể liên lạc với vợ anh Bé (sđt: 0975124757) vì anh Bé hay dẫn đoàn leo núi nên thường xuyên không liên lạc được, các bạn có thể gọi đặt trước với vợ anh Bé. (map)

 - 18h: Đoàn đến hồ đá Ma Thiên Lãnh bắt đầu dựng trại, và dạo chơi, tại đây có quan bác Tư là anh em của anh Bé nên an ninh khá tốt, các bạn có thể mua nước đá, đồ ăn vặt, xin tắm nhờ, vệ sinh tại đây.

Hồ Ma Thiên Lãnh

Hồ Ma Thiên Lãnh

- 5h: Sáng bọn mình tổng vệ sinh, ăn sáng, dọn lều, phân chia đồ cần mang và những thứ không cần mang.

- 6h: Bắt đầu đến thung lũng Ma Thiên Lãnh, tại đây bọn mình có hẹn vơi anh Bé tại nhà bác Sáu – nhà có hoa giấy trước cổng , bên trái, ngay trước khi lên dốc vào thung lũng, bác Sáu chuyên cho nhiều đoàn gửi xe trekking Ma Thiên Lãnh, tại đây bọn mình đã hay tin một đoàn bị lạc một ngày từ hôm qua chưa ra khỏi núi, từng có đoàn bị rắn cắn, và số đoàn có bánh bèo phải cõng giữa núi là rất nhiều… nên chuyến đi này các bạn cần chuẩn bị thể lực thật tốt. Bọn mình gửi xe, lều và các thứ không cần thiết phải mang theo ở đây. (map: https://goo.gl/xrexli)

- 7h: Anh Bé đến và cả đoàn bắt đầu đi bộ vào thung lũng Ma Thiên Lãnh. Ngay từ những con dốc đầu tiên các bạn sẻ thấy được sự khó khăn của cung đường này, sau tầm 10 phút leo lên những tảng đá to, dường như đây là bài test thể lực của anh Bé, một thành viên đoàn mình đã không qua được bài test thể lực và buộc phải quay lại đi tham quan chùa Bà Đen, đây là một sự việc đáng tiếc ngoài sự chuẩn bị cẩn thận các bạn cần khởi động thật kỹ và có sự phân công mang vác theo thể lực hợp lý. Trên đường đi team mình đã gặp đoàn bị lạc từ hôm trước nhưng may mắn không có gì xảy ra, team này cũng có porter nhưng vẫn lạc và nếu bạn chưa đi lần nào thì thuê porter là điều rất cần thiết, ngay cả team mình đã đi qua vẫn khó có thể nhớ lại đường đi. Anh Bé quyết định dẫn team mình lên đỉnh trước và sẽ quay lại dẫn đoàn bị lạc sau, vì team mình thể lực tốt hơn team bị lạc.

P1230534

- 12h30: Team mình lên đến đỉnh, thời tiết đã ủng hộ team mình hết toàn bộ chuyến đi, trời mát, không có nắng hay mưa. Tại đỉnh núi team mình may mắn gặp được biển mây, từng đợt mây quấn lấy bọn mình với cái se se lạnh sẽ làm bất kỳ ai xao xuyến muốn trở lại nơi này và team mình sẽ trở lại với cung đường này hoặc cung đường khó hơn để lên đỉnh, và cả team sẽ chuẩn bị thể lực tốt hơn để cuộc vui được trọn vẹn. Team mình chia tay anh Bé tại đỉnh, anh Bé quay lại đón đoàn bị lạc còn bọn mình nghĩ ngơi và ăn trưa tại đây.

P1230844

P1230805

- 1h15: Team mình băt đầu leo xuống theo đường Chùa, đoạn này dể đi, có lối mòn nhưng vẫn dốc, đeo bám nhiều và đi xuống luôn khó khăn hơn đi lên.

- 3h30: Team mình xuống đến chùa, nghĩ ngơi sau đó định mua vé trượt máng xuống nhưng đã ngưng bán vé đành mua vé cáp treo xuống.

- 4h: Team mình xuống đến cổng khu du lịch, đón một chiếc taxi 7 chổ quay trở lại nơi gửi xe tại nhà bác Sáu, vệ sinh và chuẩn bị cho chuyến quay về.

- 5h: Bắt đầu về, trên đường về bọn mình ghé Củ chi làm cái lẩu cho bửa tối.

- 9h30: Về đến nhà, kết thúc chuyến đi thú vị và êm đẹp. và bọn mình sẽ quay lại lần nữa với cung đường khó nhất Núi Phụng – Bà Đen.

Malware núp lùm PowerShell

Chúng ta đã quen với những con virus “lồ lộ” cục binary như diễn viên, người mẫu trên mấy tờ báo. Cái gì lộ quá thì nó không có vui, trong bài viết này mình đề cập đến một dạng malware lạ mình mới gặp, những kỹ thuật rất khéo để luẩn trốn dưới sự che chở của PowerShell .

A. Gặp mặt:

Để nhận ra con hàng này không có gì phức tạp, với cách thông thường xem: process, startup key là đủ.

1. Process đang làm việc

Thông thường PowerShell ít làm việc, nhưng một process với một đám tham số lạ -> Dễ dàng nhận ra có vấn đề.

pwvx01

2. Key khởi động

Một key đã quá quen thuộc: Software\Microsoft\Windows\CurrentVersion\Run

pwvx02

Quan sát kỹ hơn một chút giá trị tại: HKCU\Software\Classes

pwvx03

Ta có 3 key, dễ nhận ra là 1 key encode base64, 2 key có giá trị là binary.

B. Bên trong

1. PowerShell Script: Packer

Decode base64 giá trị từ file giá trị key thứ 3 trong regedit, ta có đoạn code sau:

Đoạn code có giá trị biến _varScript_ rất dài, nên mình tạm viết gọn lại vậy.
Không mất quá nhiều thời gian để nhận ra một hàm mã hóa RC4, một hàm giải nén Gzip. Đoạn code sau hiệu chỉnh và comment lại cho dễ đọc hơn như sau:

Script có logic làm việc như sau:
1. Giải mã giá trị ‘_varScript_
Key của mã hóa RC4: ‘YQ1MBJ2MZSNVXGZYC

2. Đọc giá trị trong 2 regedit key còn lại, sẽ có một bản binary cho 32bit và một cho 64bit.
Nhận biết OS hiện tại là bản 32 bit hay 64 bit để chọn bản binary thích hợp (rất chu đáo).

3. Giải mã cục binary với RC4, key vẫn như bên trên

4. Sử dụng đoạn code varExecute như một loader, load và execute binary tương ứng.

Có thể hiểu, cả đoạn code này đóng vai trò như một packer viết bằng PowerShell Script, thành phần loader cũng được đóng gói rất cẩn thận.
Để chuẩn bị phân tích sau hơn, chúng ta giải mã 3 giá trị nêu trên.

2. Loader: Invoke-ReflectivePEInjection
Biến _varScript_ bên trên sau giải mã sẽ là một đoạn code từ Invoke-ReflectivePEInjection.

3. Binary file

Hai binary file mình đưa lên quét thử trên virustotal. bản 32bit, bản 64bit
Nếu so độ phức tạp của các thành phần trên thì cục binary lại đơn giản hơn rất nhiều.
Đây là các dll, có export ra hàm VoidFunc để Invoke-ReflectivePEInjection bên trên gọi.
VoidFunc tạo ra 2 thread với các công việc:

  • Downloader: Gọi thêm chiến hữu về
  • Ghi key khởi động

Selection_047

Code rất sơ xài, xài các API dễ bị AV bắt.

C. Kết
Sơ đồ làm việc của malware như sau

Untitled

Malware hay ho ở một số điểm sau:

  • Mã hóa các PowerShell script rất cẩn thận
  • Obfuscation code luôn script trên
  • Cơ chế load dll chạy bên trong PowerShell rất khéo

một lá thư

Ross Ulbricht bị bắt năm 2013 vì tội điều hành chợ đen khét tiếng Silk Road, đối mặt với bản án ít nhất là 20 năm tù giam, có thể phải sống hầu hết cuộc đời trong tù. Các công tố viên đã yêu cầu bỏ tù ông ta lâu nhất có thể, để cảnh cáo những người khác khi hoạt động kinh doanh bất hợp pháp. Đây là bức thư được share trên reddit, được cho là của Ross gửi cho thẩm phán Katherine Forrest xin tha tù chung thân.

Gửi thẩm phán Forrest,
Tôi viết cho bà lá thư này trong lúc mường tượng về bản án sắp tới của tôi. Thật là khó khăn khi nghĩ về hình phạt đó, cố gắng viết những từ ngữ có thể gợi lên chút khoan dung nơi bà. Nhưng tôi đã cố gắng viết chân thật nhất, như bà sẽ thấy dưới đây.
Lần bị bắt một năm rưỡi trước đã mang tới cho tôi khá nhiều thời gian rảnh rỗi, để nhìn lại những hành động mà tôi đã làm, những hành động đã dẫn tôi tới cảnh tù tội, và những động cơ của nó. Thời điểm tạo nên Silk Road, tôi chưa hề hướng tới mục tiêu lợi nhuận. Thực sự lúc đó tôi đã có một lý tưởng đẹp cho nó. Trước đó tôi đã làm chủ một công ty khởi nghiệp, Good Wagon Books, và nó đang phát triển tích cực. Tôi có hai bằng cấp có thể giúp tôi có được một công việc tốt khi công ty thất bại. Tôi đã tạo nên Silk Road vì tôi nghĩ đó là một ý tưởng giá trị, và hiện thực nó là điều đúng đắn. Tôi đã tin rằng người ta có quyền mua và bán mọi thứ nếu điều đó không làm hại người khác. Tuy nhiên, tôi đã nhận ra việc tin tưởng một điều gì đó và hành động ngay lập tức, không suy nghĩ chín chắn có thể gây ra những hậu quả tai hại không ngờ. Silk Road hóa ra lại là một ý tưởng rất ngây thơ và tốn kém.
Silk Road đã được tạo ra như một nơi mà người ta có thể tự do lựa chọn, theo đuổi những hạnh phúc của chính họ, cho dù họ đã tìm thấy gì ở nó, ví như một nơi để thỏa mãn cơn nghiện. Cá nhân tôi không bao giờ ủng hộ việc lạm dụng ma túy. Tôi đã học được từ Silk Road rằng khi bạn trao tự do cho con người, bạn không thể đoán được họ sẽ làm gì với nó. Khi tôi vẫn không nghĩ rằng người ta nên bị cấm đoán thực hiện một số lựa chọn, tôi đã không nghĩ tới cảnh mình tạo ra một trang web cho phép kẻ khác thỏa mãn cơn nghiện ngập của mình. Nếu tôi chín chắn hơn, hay kiên nhẫn hơn, hoặc có được cả hai, tôi đã làm mọi thứ khác đi.

Tôi đã ngây thơ theo một cách nào đó. Trước lần này, tôi chưa bao giờ bị bắt giữ hay bỏ tù. Giam cầm là một khái niệm khá trừu tượng với tôi. Tôi biết nó là một cái gì đó khó chịu, nhưng không rõ ràng nó thực sự như thế nào. Bây giờ tôi đã được biết tình trạng tồi tệ này, khi bạn bị chia cắt khỏi gia đình và những người thân yêu cùng với sự đau khổ mà nó mang lại. Nếu tôi biết trước được những ảnh hưởng mà Silk Road đã mang đến cho những người tôi quan tâm, tôi đã không bao giờ tạo ra nó. Tôi tạo ra Silk Road với một mục đích vô tư mà tôi đã từng tin, nhưng cuối cùng nó đã biến thành một thứ vô cùng ích kỷ.

Bằng việc tạo ra Silk Road, tôi đã hủy hoại cuộc đời tôi, tương lai tôi, lãng phí sự giáo dục mà gia đình tôi đã cho tôi, tất cả những cơ hội tôi từng được ban tặng, tài năng của tôi, cũng như những gì tôi đã kiếm được bằng cách làm việc chân chính. Lẽ ra tôi phải làm tốt hơn với cuộc đời của tôi. Bây giờ tôi đã thấy rõ, nhưng nó đã quá muộn. Bản án tôi sẽ nhận được ít nhất là 20 năm. 20 năm không thể đóng góp cho cộng đồng, 20 năm lẽ ra để xây dựng một gia đình, bên cạnh cha mẹ, anh em trong những sự kiện quan trọng của cuộc đời của họ. Tôi nói với bà những điều này vì tôi muốn bà biết rằng, khi tôi mất đi những tiện nghi và thú vui của sự tự do, nỗi đau lớn nhất của tôi là mất đi khả năng giúp đỡ những người mà tôi yêu quý, là không thể trở thành một phần cuộc sống hàng ngày của họ, một thành viên của xã hội. Vì những lẽ trên, nếu bà nhận thấy rằng tôi đáng được khoan dung, tôi sẽ không mất đi tình yêu của tôi với nhân loại trong những năm tù tội, và khi được phóng thích, tôi sẽ làm những thứ tôi có thể để không làm phụ lòng những người thân yêu, góp phần xây dựng một thế giới tốt đẹp hơn trong khuôn khổ của pháp luật.

Với tôi, án tù chung thân cũng như một án tử hình có kỳ hạn. Cả hai đều khiến người ta phải chết trong tù, và án tù chỉ kéo dài cái chết ra. Nếu tôi có thể ra tù sau vài chục năm giam cầm, tôi không còn là người đàn ông lúc vào tù nữa, mà thế giới cũng không còn là thế giới lúc tôi bị bắt. Tôi rõ ràng không phải là một mối nguy hiểm cho xã hội như khi tôi tạo ra Silk Road. Thực sự, tôi sẽ là một lão già, ngoài ngũ tuần với những tàn phá của nhà tù. Tôi đã biết những hậu quả của việc vi phạm pháp luật và hơn ai hết, tôi biết rõ chúng không đáng giá. Tôi biết tôi đã có một sai lầm kinh khủng. Tôi đã phung phí tuổi trẻ của mình, và tôi biết ngài sẽ lấy đi của tôi tuổi trung niên, nhưng xin bà hãy để lại cho tôi tuổi già, xin hãy cho tôi một chút ánh sáng cuối đường hầm, cho tôi một lý do để giữ gìn sức khỏe, một lý do để hy vọng, và một cơ hội để chuộc lại lỗi lầm của tôi trong thế giới tự do trước khi trình diện trước chúa trời.

Kính thư,
WV
035 Ulbricht

A/B test

Kiểm thử A/B là một kỹ thuật phổ biến trong tiếp thị trực tuyến, khi bạn đưa ra một thử nghiệm với hai biến ngẫu nhiên A và B, thống kê các hoạt động của khách hàng trong hai biến số này để đưa ra bước hành động kế tiếp. Nó được ưa chuộng do thực hiện đơn giản mà hiệu quả mang lại cực cao. Một ví dụ của kiểm thử A/B như sau:

Trong chiến dịch tranh cử năm 2008 của Obama, các cố vấn của ông ban đầu đã làm một trang web quảng bá như sau:

Obama_Homepage_original

Thực hiện kiểm thử A/B trên trang web, họ đã thay lần lượt ba video và ba ảnh vào khung giữa, thử 4 nút đăng ký khác nhau (Sign Up, Sign Up Now, Join Us Now, Learn More), và nhận ra mẫu thu hút nhiều khách đăng ký nhất: trang web với bức ảnh gia đình và nút đăng ký với dòng chữ “Learn More”

Obama_winner

Như vậy, bằng việc đưa ra hai hoặc nhiều biến thể của một trang web/ sản phẩm chỉ với một điểm khác biệt, ta có thể phát hiện và lựa chọn phương án tốt nhất để thu hút người dùng, phần kiểm thử có thể là tiêu đề, màu sắc, kích thước, vị trí, bố cục, hình ảnh… của trang web hoặc sản phẩm. Tổng quát hơn, với bất kỳ phần nào của trang web mà bạn muốn/ cần cải thiện, bạn có thể thực hiện phép kiểm thử A/B trên nó để tìm ra phương án tốt nhất, so với các phương pháp đánh giá dựa trên cảm giác hay kinh nghiệm, điểm ưu việt của phép thử là “bản thân nó là thực tiễn”.

Các bước để thực hiện một kiểm thử A/B đơn giản trên trang web:

- Xác định mục tiêu: bạn có một trang web và muốn tăng tỉ lệ đăng ký/ mua hàng hay thời gian hoạt động của người dùng?

- Xác định phần của trang web cần kiểm thử: tiêu đề/ nút bấm/ phông nền …

- Kiểm thử: lập trình trang web để bộ phận đã chọn có thể hiển thị trong hai biến thể cũng như theo dõi hoạt động của khách hàng

- Chờ đợi khách hàng đến và theo dõi kết quả, bạn cần thu thập dữ liệu từ một/ vài ngàn khách hàng, quá trình này có thể mất vài tuần.

- Chọn ra phương án tốt nhất từ kết quả kiểm thử và sử dụng nó cho trang web

- Trở lại bước 1, 2 với một bộ phận/ chi tiết khác của trang web

Refs:

https://en.wikipedia.org/wiki/A/B_testing

https://blog.optimizely.com/2010/11/29/how-obama-raised-60-million-by-running-a-simple-experiment/

bash shell unittest with shunit2

shUnit2 – unit test cho Unix shell scripts

Link: http://code.google.com/p/shunit2/

shunit là một tiện ích dùng để thực hiện unit test cho shell script, cách làm việc tương tự như Junit hay PyUnit…

ví dụ:

chạy thử

Các hàm setup và clear unit test: oneTimeSetUp(), oneTimeTearDown(), setUp(), tearDown()
ví dụ:

RUN:

để đưa thêm thông tin về lỗi, ta truyền thêm option [message] vào lệnh assert***:

## test suite:
để tạo suite, ta có hàm suite() và lệnh suite_addTest <function>

vd: thêm vào test.sh

RUN TEST:

[NoConName] Explicit – 500

pwn this game, 88.87.208.163:7070

Filehttps://www.dropbox.com/s/ixd37aerxw6jajd/explicit?dl=0

Game gì khó quá, chơi vài giây về nước rồi :)

… Kidding! Đại khái là game random 1 số từ 0->20 rồi bắt người ta phải đoán số đó.

Continue Reading

Binary analysis: Next chapter of the game

Tiêu đề ?

Người viết tính đặt tiêu đề là Phân tích mã: Chương tiếp theo của trò chơi, nhưng nghe gượng gượng nên cuối cùng người viết bài chọn tên này, 1 cái tên Tây cho một bài viết Tiếng Việt, một sự kết hợp không đẹp lắm :”>

Mở

Trò chơi phân tích mã bắt đầu từ những ngày đầu ngành điện tử – tin học xuất hiện, từ vụ tháo mạch điện, chọc mũi hàn của các bạn làm điện tử, rồi sau này là các trình disassembler xuất hiện cho mảng tin học hí hoáy. Kéo dài từ các trình disassembler sơ khai cho đến IDA thần thánh thông dụng hiện tại.

Việc đọc mã thuần với các disassembler là chưa đủ, người ta muốn theo dõi chương trình đó chạy ra sao, làm cái gì. Vậy là các trình debugger ra đời để đáp ứng nhu cầu đó. Các debugger thật tuyệt vời, nó làm đơn giản hóa việc hiểu 1 đoạn mã làm cái gì thay vì chỉ ngồi tưởng tượng. Các tool debugger tiêu biểu: Ollydbg, gdb, Windbg

Nhưng việc ngồi mòn mông để ngồi dò từng dòng lệnh asm của 1 chương trình, nhất là với các chương trình lớn và mã rối rắm thì là cả một thảm họa. Phải có gì đó giúp tự động hóa, giúp cuộc  đời này tươi đẹp hơn, giúp người lười có nhiều thời gian để ăn ngủ hơn thay vì phải ngồi debug cả buổi.

Người ta chia việc phân tích mã thực thi (binary analysis) thành 2 mảng khác nhau như sau:

  • Phân tích tĩnh (Static code analysis): Ngồi nhìn một đoạn code đứng im ru, bạn cố tìm hiểu, khi làm việc nó sẽ làm cái gì, việc này khá giống với việc bạn nói chuyện với một cục đá -_-
  • Phân tích động (Dynamic program analysis): Thay vì chỉ ngồi nhìn ngắm dung nhan đoạn code, bạn có thể xem quá trình đoạn code đó làm việc, xem nó buồn vui thế nào, hiếu động ra sao… một nhánh của phương pháp này là phân tích hành vi

Tất nhiên mỗi phương pháp đều có thế mạnh, yếu riêng :

Phân tích tĩnh:

  • Đảm bảo phân tích trọn vẹn code, do suy cho cùng thì mọi hành vi của chương trình đều nằm cả trên 1 cục binary đó mà thôi, tất nhiên điều này là rất khó
  • Tốc độ nhanh
  • Nhưng phương pháp này sẽ phải rất mệt với đám làm rối code (obfuscation), pack … thậm chí theo quan điểm cá nhân của người viết thì với 1 bộ làm rối đủ tốt thì phân tích tĩnh là bất lực.

Phân tích động

  • Sẽ thấy được những điều mà phương pháp tĩnh không cho thấy được, như tụi pack chẳng hạn
  • Tuy nhiên do giả lập lại quá trình thực thi nên bị gặp vấp phải các vấn đề như không khó có thể thực thi đến mọi ngóc ngách của chương trình, các trick để loop vô cùng, các trick nhận dạng bị debug …
  • Tốc độ chậm hơn phân tích tĩnh

Trong quá khứ, việc phân tích mã tĩnh chiếm ưu thế, nhưng càng gần đây việc phân tích mã động ngày càng phát triển do:

  • Máy tính ngày càng mạnh, công nghệ ảo hóa ngày càng tốt, đảm bảo tốc  độ cho việc này
  • Tụi binary sau này ngày càng đông và hung hãn, chưa kể nhiều đứa còn rất khó hiểu nếu chỉ nhìn mặt chúng nó (phân tích tĩnh), thôi thì cứ thả cho nó chạy xem nó làm gì cho trực quan

Bài viết này, người viết sẽ nói về việc tự động hóa trong việc phân tích mã động. Bước đầu làm quen với vấn đề này.

Nhập

Có nhiều sự lựa chọn để phân tích động, các công cụ cho phép thực thi file binary, theo dõi quá trình thực thi chi tiết từng mã thực thi (asm), bạn có thể tưởng tượng đơn giản là bạn đang dùng một cái Ollydbg, nhưng khác cái là bạn sẽ làm việc đó tự động hóa (bằng code) thay vì ngồi gõ từng phím nóng để debug code.

Các công cụ tiêu biểu: pinValgrindDynamoRIO … nhưng mình thích nhất pin đơn giản do tên nó dễ nhớ và nhiều sample.

pin là một công cụ mạnh mẽ của Intel để phân tích động, với kho đồ chơi có sẵn gọi là pintools, một kho đồ chơi cực kỳ giá trị và rộng lớn, tìm hiểu cho hết công năng của mớ đồ cũng không phải dễ dàng.

Mỗi tool của pin là được lưu dưới dạng một tập tin liên kết động (dynamic library), mỗi thư viện này sẽ làm việc mà bạn lập trình cho nó (dựa trên framework của pin). Khi chương trình thực thi, bạn sẽ cần chọn thư viện tương ứng và nó sẽ tương tác với chương trình bạn cần phân tích trong quá trình thực thi.

Chúng ta sẽ quan sát 2 ứng dụng của pin

A. Binary Side channel attack

1 Sơ lược

“Tấn công qua kênh phụ không đòi hỏi bất cứ một sự xâm nhập trực tiếp nào vào thiết bị. Cụ thể là người tấn công sẽ tìm cách đo các tín hiệu như năng lượng tiêu thụ điện, cường độ của trường điện từ phát ra từ thiết bị. Sau đó các thông tin này sẽ được quan sát và xử lý để tìm ra thông tin bí mật.”

Nguồn: http://tudien.vntelecom.org/Side_Channel_Attack

2. Phương pháp

a. Lab

  • Với đoạn code sau:

Không xét tới độ phức tạp để reverse, pack hay cái gì ở đây, chúng ta nhìn nhận đoạn code này trên quan điểm brute-force. Đoạn code không quá khó để brute-force.
Chúng ta đều biết strcmp sẽ so sánh từng ký tự từ trái qua phải đến hết, do vậy với mỗi ký tự đúng bên trái thì ứng dụng này sẽ thay đổi một số thao tác so với khi sai.
Viết một đoạn code nhỏ để đếm số lệnh ứng dụng thi hành với từng input (một ký tự ‘a’ -> ‘z’) ta có bảng số liệu sau:

char

a

b

c

d

e

f

g

h

i

count

98340

98338

98342

98338

98338

98340

98338

98338

98339

char

j

k

l

m

n

o

p

q

r

count

98338

98342

98342

98340

98338

98340

98338

98338

98338

char

s

t

u

v

u

x

y

z

count

98338

98338

98342

98338

98340

98340

98338

98338

Không quá khó để nhận ra sự khác biệt của ký tự i. Thao tác này nên lặp lại vài lần để kiểm tra việc focus vào ký tự đó theo một rule nào đó là đúng hay sai.

b. Break game

Trong thực tế áp dụng, đã áp dụng phương pháp này để giải quyết bài SimpleVM ( http://reversing.kr/challenge.php ), một script nhỏ và phân tích các thông số thủ công trong vòng nửa giờ cho ra key: id3*nxx (phần xx dấu đi để bạn tự thực nghiệm)

Submit và kết quả chính xác.

3. Code

Script viết trên Python kết hợp với PINTool để thực thi SimpleVM tự động cùng với key brute-force, hiện trong mỗi bước tăng chiều dài key thực hiện thủ công (hardcode), phân tích rule bằng mắt (+ niềm tin) :”>

icount.so : là một thư viện nhỏ trong example code của pin, nó làm nhiệm vụ đếm số mã lệnh thực hiện của một chương trình.

B. Nhúng scripting trong pin

1. Sơ lược

Dù có thể code các dynamic library như ở ví dụ trên, tuy nhiên việc này tốn nhiều thời gian cho mỗi lần điều chỉnh code phân tích (code, compile, chạy lại …).
Phần này người viết giới thiệu một wrapper giúp đơn giản hóa việc này. Scripting nhúng ở đây là sử dụng ngôn ngữ Lua.
Link project: https://github.com/hexgolems/pint 
Mục tiêu cụ thể trong phần này khi sử dụng pintTìm kiếm tất cả string có thể in được (printable) trên bộ nhớ của chương trình khi thực thi

Các ứng dụng :

  • Một số bài CTF binary đơn giản dùng các hình thức so sánh input với flag để kiểm tra đúng sai, tất nhiên là chuỗi flag này thường được mã hóa cẩn thận. Nhưng khi so sánh thì nó cũng phải giải mã, sau đó thì đọc vùng memory đó để so sánh. Điển hình nhất là tụi dùng hàm strcmpmemcmp
  • Do mục tiêu code chỉ tìm string printable tại các address chương trình đọc đến, nên gần như toàn bộ string printable được chương trình đọc tới đều bị nhận dạng, nên các hàm compare string tự chế, hay printf, hay LoadLibrary, hay mọi API khác nếu có dùng string đều bị nhận dạng, việc này cũng giúp phân tích phân tích dễ dàng hơn các string đã obfuscate hay các dạng phân tích malware động. Nói kiểu này thì nghe rất hoành tráng :* nhưng thực ra thì không có gì cả :|

Nói nhiều vây thôi, chứ tóm lại code nó nằm tại đây (bạn nên custom tùy theo nhu cầu): https://github.com/hexgolems/pint/blob/master/tools/strings.lua

2. Sử dụng

a. Lab

Compile  tại: ./hook/hit

Command thực thi:

Ta có một file kết quả: out.log
Có một trong đó chứa vài dòng như sau:

b. Break game

Chúng ta sẽ cùng ngâm cứu lại một bài viết cũ: http://blog.botbie.com/2012/12/31/29c3-ctf-misc-300-funchive/ , bằng hướng tiếp cận mới này.

Một command nhỏ:

Và chúng ta cùng xem log và có những dòng sau:

:D , quá nhẹ nhàng cho 1 bài CTF 300 điểm :3