Author: NamCr
Bài viết này nhằm giới thiệu với anh em 1 Protecter rất nổi tiếng: Armadillo, các kĩ thuật bảo vệ được sử dụng, điểm mạnh cũng như điểm yếu của chương trình này.
Pro thì chẳng lạ gì, chinh chiến sa trường không ít thì nhiều cũng đã đụng độ, thậm chí unpack ầm ầm, nhưng cũng có những Pro nhìn thấy em này là ngao ngán sự đời, lôi tool ra unpack cho khỏe. Nói như vậy là để cảnh báo anh em newbie mới vào chưa biết, tưởng Armadillo là ngôn ngữ lập trình nữa thì tiêu, nói các lão newbie đừng buồn chứ peid scan ra mà đã báo Armadillo thì các bác lên mạng tìm tool đi là vừa, tool mà bó tay nữa thì các bác quăng nó đi cho rảnh nợ, arm không phải là mục tiêu dùng để bắt đầu sự nghiệp cho các newbie.
Giới thiệu em này 1 chút cho anh em:
Armadillo là 1 trình Protecter, kiêm 2 nhiệm vụ:
NV1. Cái này là nhiệm vụ của packer: nén file (nhằm thu nhỏ dung lượng), cũng như Winrar hay Winzip chương trình cũng có các mức nén khác nhau từ thấp cho đến cao.
NV2. Đây mới là nhiệm vụ chính: bảo vệ file trước sự dòm ngó của cracker, với đủ kiểu kĩ thuật tà đạo, Arm đã khiến không ít cao thủ dừng chân ngay từ bước scan bằng Peid.
Armadillo có thể thao tác trên các định dạng file EXE, SCR, DLL, OCX
Các kiểu bảo vệ của Arm:
Standard protections (hoặc Minimum protections)
Bản chất 2 kiểu bảo vệ này không khác nhau là mấy, kĩ thuật duy nhất mà chương trình sử dụng trong kiểu bảo vệ này là Magic Call (ngày xưa là Magic Jump). Với kĩ thuật này 1 số hàm API sẽ được di dời nhà ở khỏi file được bảo vệ, bỏ lại 1 bảng IAT thủng lỗ chỗ, không cần nói thì các lão cũng tưởng tượng ra, với 1 IAT thiếu sót như vậy và arm là người duy nhất biết địa chỉ di dời (để khi soft cần đến thì còn gọi API ra mà làm việc chớ) thì tiêu diệt arm đồng thời cũng là tiêu diệt soft luôn, arm xuống mồ thì nó cũng mang theo bí mật về hững hàm API còn thiếu, còn chúng ta thì chỉ biết ngậm ngùi đứng khóc.
Tuy nhiên kĩ thuật này tỏ vẻ vô dụng đối với các Unpackme, đơn giản là vì Unpackme sử dụng quá ít các hàm API, Unpacker sẽ không mất quá nhiều thời gian để vá lại các chỗ còn thiếu. Còn đối với Soft sử dụng hàm trăm API thì vá bằng tay những gì còn thiếu không điên thì cũng quá là dư sức.
Phương pháp xử lí kiểu Protect này rất đơn giản: Diệt Magic Call là xong
Standard protections là kiểu bảo vệ mặc định cho các dự án mới khi khởi tạo bảo vệ.
Lưu ý: Dù sử dụng kiểu Protect nào đi nữa thì Magic call luôn được dử dụng (có 1 vài ngoại lệ không nhiều lắm)
Debugger-Blocker:
Kĩ thuật này tạo ra 2 Process trong bộ nhớ (1 cha và 1 con), nếu bạn bật Task Manager lên và thấy soft đang chạy với 2 Process có cùng tên mặc dù không đảm bảo 100% nhưng Arm chính là thứ cần nghi ngờ đầu tiên.
Với kĩ thuật này Process cha sẽ tạo ra, chăm nom và bảo vệ thằng con khỏi các Debugger tấn công (và chỉ lo có ngần đó việc mà thôi), trong khi đó thằng con sẽ thi hành chức năng của soft như bình thường. Kĩ thuật này hạn chế Debugger ở chỗ không thể nào can thiệp vào quá trình hoạt động của thằng con khi mà 2 "cha con" vẫn còn liên hệ với nhau.
Phương pháp tiêu diệt: rất đơn giản, xài tools, bạn có thể dùng tay nếu thích, tuy nhiên dùng tay mất rất nhiều thời gian và hay hư hỏng, không an toàn như dùng soft. Tuy nhiên dùng tay hay dùng soft cũng có nguyên lý làm việc như nhau: Patch thằng con tại EP (lệnh EB FE) để nó "chạy tại chỗ", trong khi đó thì ngắt kết nối cha-con, sau khi ngắt thì thằng con không còn được bảo kê nữa, ta có thể mần thịt.
Strategic Code Splicing: Chiêu này gọi là chiêu ăn trộm, Armadillo sẽ chôm chỉa 1 vài đoạn code của chương trình, đá văng đoạn code này sang 1 vùng nhớ bất trì trong bộ nhớ, sau đó thay vào vị trí đoạn code bị chôm 1 lệnh nhảy hoặc hàm call gọi đến đoạn code đã bị di dời. Chiêu này có 2 lợi thế, 1 là chương trình vẫn hoặt động bình thường (do đoạn lệnh di dời vẫn được thực thi qua lệnh Jump hoặc hàm call gọi tới), thứ 2 là nó chống được việc chúng ta dump. Khi dump file như bình thường thì chúng ta chỉ dump được hàm call hay lệnh jump nhảy tới mà thôi, đoạn code đã nằm ở 1 vùng nhớ khác và không được dump xuống --> như vậy là soft thiếu code sẽ không chạy bình thường được
Fix: có 2 cách xử lý em này
Cách 1: tìm vùng nhớ nơi mà đám code lạc đàn đang cư ngụ, dump thêm chúng xuống, nối nó vào file dump của soft, Fix IAT sau đó vá lại các hàm call và lệnh jump cho khớp nữa là xong.
Cách 2: Xài tool, chúng ta cung cấp các thông tin cần thiết và tool sẽ mang những đoạn code trở về chỗ cũ, như vậy chương trình sẽ quay về dạng ban đầu trước khi được bảo vệ, cách làm này thường nhanh và ít thiếu sót hơn.
Import Table Elimination:
Có tác dụng tương tự như Strategic Code Splicing, nhưng thằng này thao tác với API thay vì code. Cách hoạt động cũng tương tự, đá văng các hàm API đi khắp nơi khiến chúng ta không tìm được bản IAT đầy đủ, không fix được file dump. Tuy nhiên không như Strategic Code Splicing chỉ đưa các đoạn code vào 1 vùng nhớ, Import Table Elimination đưa các API đi khắp nơi trong bộ nhớ, số lượng các API cũng quá nhiều, do vậy cách fix như cách 1 của Strategic Code Splicing không thể áp dụng ở đây, chỉ còn cách 2 đó là đưa các API trở về chỗ cũ, với lượng API quá lớn xài tool là điều không tránh khỏi.
Công nghệ Anti-dumping protections: Không phải chống chúng ta Dump xuống đâu, nó vẫn cho ta dump, nhưng dump xuống 1 đống ....rác
Bao gồm các kiểu bảo vệ sau:
CopyMem-II:
Chỉ có thể áp dụng khi có Debug Blocker, dường như nhận thấy Debug Blocker hơi sơ sài, Arm tăng cường thêm công nghệ
CopyMem II, thằng này trang bị cho Process cha, nó sẽ phá nát OEP của Process con, thay vào đó 1 đống code chẳng đâu vào đâu nhằm tránh việc Dump file, và dĩ nhiên chỉ có Process cha mới biết cách mã hóa trở lại như cũ, điều này thực sự khó chịu vì cho dù có mò được đến OEP của Process con thì nó cũng đã bị phá nát, dump xuống cũng chỉ là 1 đống rác mà thôi.
Tiêu diệt: cái này có rắc rối hơn 1 chút, căn bản là thế này:
[B]Bước 1:/[B] dùng tool để loại bỏ CopyMem (dùng tay cũng được tuy nhiên khá vất vả), chúng ta sẽ đứng ngay tại OEP của process con, 1 OEP nguyên vẹn, nhưng IAT đã bị phá nát (do Magic call và có thể kèm theo các kĩ thuật sắp nói bên dưới)
Bước 2: vẫn dùng tool, nhưng chỉ tiêu diệt Debug Blocker,sau đí lần lượt xử lí Magic call, kill các kĩ thuật khác nếu có, lần tới OEP, dĩ nhiên OEP đã tòe loe dưới tác dụng của Copymem, tuy nhiên chúng ta lại có bảng IAT nguyên vẹn.
Bước 3: Vá IAT nguyên vẹn ở bước 2 vào OEP nguyên vẹn ở bước 1, chúng ta có 1 chương trình ngon lành. hehe
Nanomites:Vẫn phải đi kèm Debug Blocker tuy nhiên CopyMem có hay không gì cũng được, được hãng dùng dưới cái tên: Enable Selected Code Encryption (Nanomites), trong tài liệu đi kèm không thấy nhắc nhỏm gì nhiều tới em này (chắc là muốn giấu ). Theo tui được biết Nano là tuyến phòng ngự cuối cùng của Armadillo, bất chấp các kiểu kĩ thuật khác đã bị vô hiệu hóa, file được Nano bảo kê cho dù đã được fix IAT và OEP ngon lành vẫn không tài nào chạy được, nếu load trong Olly sẽ nhìn thấy rất nhiều các lệnh ngắt INT3 khiến soft chết đứng ngay tại những câu lệnh đầu tiên( có hàng ngàn cái INT3 như vậy rải rác khắp nơi trong chương trình).
Phần tiêu diệt: Tui chưa thấy ai vá Nano bằng tay hết, thường là xài tool. Lý thuyết khá lằng nhằng, bản thân tui cũng không biết phải dịch ra sao cho đúng ý nữa.
Các kiểu bảo vệ đi kèm:
Memory-Patching Protections: chống patch trong bộ nhớ, Loader mà gặp em này coi như tiêu
Random PE Section Names: cái tên nói lên tất cả rồi, kĩ thuật này gây khó chịu trong Unpack nhiều hơn là có chức năng bảo vệ
SoftICE Detection: phát hiện SoftIce, chúng ta xài olly không cần sợ
Nhược điểm cơ bản của Armadillo:
Đầu tiên, nếu tui là giám đốc công ty này tui sẽ đuổi hết mấy thằng cha lo vụ antidebug, arm có cơ chế antidebugger quá đơn giản, chỉ cần 1 bản mod olly, 1 vài plugin là qua mặt ngon lành. Két sắt có tốt tới mấy mà cứ mở rộng cửa cho trộm thử phá thì kiểu gì cũng thua, vấn đề là bao lâu thôi.
Thứ 2: Arm có các kiểu bảo vệ rất tốt, nhưng cái giá phải trả chính là tốc độ thực thi của chương trình, Debug Blocker, copymem, Strategic Code Splicing, Import Table Elimination, Nanomites đều là những sát thủ tốc độ cực tốt, soft được bảo vệ với tất cả tùy chọncủa Arm sẽ "bò" chứ không chạy, quá trình khởi động rất lâu, quá trình hoạt động cũng rất chậm, vì vậy mà các hãng phần mềm chẳng ai dại mà chọn hết kiểu bảo vệ cho soft của mình cả, điều này làm arm mạnh nhưng không phát huy hết được sức mạnh của mình
Thứ 3: File được pack có dung lượng quá lớn, nhiều khi còn lớn hơn cả file gốc, điều này là do mức nén thấp trong khi đó arm lại thêm khá nhiều mã lệnh vào soft để thực hiện chức năng Protect của mình
Link:http://cin1team.biz/showthread.php?t=123
