banner

[Rule] Rules  [Home] Main Forum  [Portal] Portal  
[Members] Member Listing  [Statistics] Statistics  [Search] Search  [Reading Room] Reading Room 
[Register] Register  
[Login] Loginhttp  | https  ]
 
Forum Index Thảo luận virus, trojan, spyware, worm... Bài viết cũ:Bài 3 Hướng dẫn lập trình Virus. Tác giả Spinx  XML
  [Question]   Bài viết cũ:Bài 3 Hướng dẫn lập trình Virus. Tác giả Spinx 08/01/2007 23:05:50 (+0700) | #1 | 35027
komodo01
Member

[Minus]    0    [Plus]
Joined: 08/01/2007 07:01:49
Messages: 24
Offline
[Profile] [PM]
BÀI 1: MỞ ĐẦU

/forum/index.php?showtopic=11259&st=0&hl=

BÀI 2: VR cơ bản
/forum/index.php?showtopic=9143&hl=

BÀI 3: VR trên windows
OK, không thấy có bạn nào thắc mắc gì nhiều về các VR trên DOS (chắc chẳng ma nào đọc) :rolleyes: đồng thời có nhiều bạn PM cho tôi yêu cầu được biết thêm về VR trên Win và Unix. Chính vì vậy tôi sẽ kết thúc các bài đào tạo cơ bản để chuyển sang VR for Win. Vì thời gian có hạn, tôi sẽ mặc định là các bạn đã biết cách lập VR trên DOS để tập trung phân tích những điểm khác biệt giữa 2 hệ điều hành tất nhiên ở khía cạnh VR programming. Có nhiều bạn (kể cả tôi) lập trình VR trên DOS khá suya cho đến một ngày win ra đời, mọi thứ đảo lộn tiếp cận VR trên win còn khó khăn nên nếu bác nào chưa làm VR mà đọc ngay đừng có choáng nhé. Tôi sở trường dùng ASM nên ngôn ngữ trình bày là Win32Asm.

VR có rất nhiều dạng, bản thân môi trường Win tính đa dạng và phức tạp cũng hơn DOS nhiều nên VR trên Win càng đa dạng và phong phú. Lập trình các loại VR “đơn nguyên” như VR macro hay trojan không quá phức tạp nên tôi sẽ để dành ở một bài khác. Chúng ta sẽ bắt đầu với VR .exe trên Win9x trước.

Như ta đã biết. Các bước cơ bản của VR tệp khả thi là tự copy chính đoạn mã VR vào các tệp khả thi của hệ điều hành như .exe, .com, .dll, .ocx... nhưng nạn nhân chủ yếu trên win là tệp .exe (thực tế có rất nhiều dạng khác nhưng ta tạm xét là ngoại lệ). Nguyên tắc này vẫn đúng trên các hệ điều hành Windows. Thật đáng tiếc là mức độ bảo mật và tự vệ của bản thân các HĐH windows cũng khác nhau nên nhiều VR chỉ có tính tương thích nhất định. Thao tác cần phân tích bao gồm:
- Cách thức lây lan
- Khả năng thường trú
- Khả năng kiểm soát hệ thống

Cách thức lây lan
Gần giống với VR .exe trên DOS, thao tác lây lan ở đây chỉ đơn giản là sửa lại header tệp PE trên win và attach đoạn code VR vào tệp gốc (host). Tất cả thứ chúng ta cần là cấu trúc header tệp PE của Windows. Điểm bắt đầu chương trình đặc biệt là con trỏ EIP (trên DOS là cs:ip). Tài liệu header PE có rất nhiều trên mạng, kể cả trong các tài liệu chính thức (các bạn có thể tự tìm). Trên HVA cũng có vài bài hình như của .... đề cập chi tiết nên tôi sẽ không đi sâu nữa mà chỉ nhắc lại vài điểm chính.

http://spinxspinx.bravepages.com/images/pefig01.gif

Đây là hình tôi cắt từ tài liệu msdn của microsoft (đã giới thiệu khá đầy đủ). Như vậy bản thân header của tệp PE đã bao gồm cả header của tệp .exe trên DOS. Thậm chí các chương trình for windows hầu như đều có 1 đoạn code chạy trên DOS để in ra thông báo dạng “This program cannot be run in DOS mode”. Như thế một chương trình có thể vừa for win vừa for dos được không? Câu trả lời là được và VR cũng vậy.
OK, vậy là ta đã có thể lây lan được tệp PE rồi phải không ạ? Chi tiết hơn một chút về kỹ thuật, ta dùng gì để ghi lên các tệp đây? Trên dos thông thường ta lợi dụng bản thân các ngắt của DOS để ghi, cụ thể là ngắt 21h. Tương tự nền tảng trên win là các API, hãy tận dụng tối đa. VR chỉ là một đoạn code. Vị trí của nó thay đổi theo kích thước host chính vì vậy các offset tuyệt đối bị di rời loạn xạ. Lưu ý với VXer là phải sử dụng địa chỉ tương đối cho các biến của mình. Đã từng làm VR trên DOS chắc các bạn đều rõ điều này. Kỹ thuật cổ xưa vẫn áp dụng được. Đấy là thao tác dùng delta:
call Delta
Delta:
pop ebp

Khi gọi ngắt trên dos, địa chỉ ngắt luôn được HĐH tự động xác định qua bảng vector ngắt. Cứ việc gọi int xxx (0CD/xxx) việc còn lại là của CPU. Với API lại khác. API thực chất chỉ là các hàm thư viện viết sẵn của HĐH và load lên bộ nhớ như một chương trình. Để gọi được nó cần có địa chỉ của nó trong tay. Đương nhiên câu hỏi được đặt ra là vậy các chương trình “hợp pháp” gọi API như thế nào? Ta quay trở lại với khái niệm cơ bản trên windows. Các chương trình sau khi biên dịch đều có một bảng import table. Các hàm API chương trình sẽ sử dụng đều được ghi trong import table. Khi chương trình chạy windows loader sẽ làm nhiệm vụ xây dụng một bảng địa chỉ IAT (import address table) cho các hàm này. Thật đáng tiếc ta không thể thay đổi bảng này vì windows đã để mắt đến nó. Vì vậy để goi API từ VR ta phải làm lại thao tác của loader và xây dựng bản địa chỉ riêng.

Khi đó lệnh gọi tương đối hàm API sẽ có dạng
call [ebp+_<api name>]

ebp+_<api name> ==> chứa địa chỉ hàm API

APIs nó nằm ở đâu bạn không hề biết, làm sao bây giờ. Đâu có đó, thịt chó còn có rau thơm. Windows cung cấp cho ta một hàm để lấy địa chỉ các làm API theo tên là hàm là GetProcAddress. Vấn đề là ở đây là GetProcAddress cũng là 1 hàm API. :ph34r: Vậy yêu cầu tối thiểu là phải có địa chỉ 1 hàm GetProcAddress trong Windows. Hàm này thuộc kernel của win nên bây giờ câu hỏi chỉ còn kernel của windows nằm ở đâu. Trả lời điều này dễ hơn nhiều. Ta có ngay một danh sách:

0BFF70000h = Win95 Kernel Addr
077F00000h = WinNT Kernel Addr
077e00000h = Win2k Kernel Addr

Ta có thể yên tâm sử dụng cho đến khi Microsoft thay đi mất. :huh: smilie Thực ra địa chỉ này có thể không hoàn toàn chính xác như vậy. Ta nên kiểm tra ký tự “MZ” (header của file kernel32.dll) để xác định chính xác vị trí kernel. Có kernel header đối chiếu export/import table của kernel để đọc địa chỉ hàm API theo tên. Oải quá phải không? Đáng tiếc là no way. Thực ra cũng không quá khó đâu vì tất cả đều có trong PE/NE HEADER. Các bạn đọc và nghiền ngẫm kỹ lại đi.

Thường trú
Thao tác thường trú thực chất nhằm tăng khả năng lây lan và kiểm soát hệ thống. DOS là hệ điều hành đơn nhiệm, tốc độ các máy thời xưa không nhanh lắm. Nếu thao tác lây lan chỉ thực hiện lúc đầu khi ta chưa khả quyền điều khiển về host sẽ làm chậm thao tác load của chương trình ngoài ra phạm vi tìm kiếm của chương trình tương đối hẹp nên nên lây lan không đa dạng và nhanh chóng. Với tốc độ máy hiện nay, và với khả năng đa nhiệm của Win điều này không còn quá quan trọng như xưa. Thực tế số lượng VR không thường trú trên Win nhiều hơn Dos rất nhiều. Tuy vậy ta đã quá quen với VR thường trú, khi VR không thường trú VXer có cảm giác mình chưa thực sự kiểm soát máy nạn nhân (tôi cũng vậy). Để có một VR không thường trú trên Win không khó lắm. Bất quá cũng chỉ là một chương trình đọc ghi tệp bằng API viết trên ASM. Bạn đã lập VR trên DOS, đọc qua header PE file -> done. Thường trú trên Win không đơn giản như vây. Cái khó của ta là gì? Protected mode!
Vây có cách nào vượt qua protected mode không? Có chứ nhiều là đằng khác. Sau khi suy nghĩ tôi quyết định chọn giới thiệu cho các bạn 2 cách đơn giản nhất và kỹ thuật cao nhất. Nhưng trước hết Protected mode là gì.

Chúa ơi, muộn quá rồi. Tôi phải đi ngủ vậy không ngày mai toi mất. Vì thời gian có hạn không thể trình bày chi tiết hơn được các bác thông cảm. Có gì thắc mắc cứ post lên tôi sẽ từ từ giải đáp sau.

Ta lại tiếp tục nhé. Lần trước tôi dừng ở đâu nhỉ? Protected Mode là gì. Windows làm việc trong một môi trường bảo vệ. Nhờ đó nó có thể kiểm soát được các thao tác truy nhập cấp thấp của các ứng dụng. Đến đây có sự phân hoá mức độ an toàn bảo vệ khá rõ giữa các windows. Ta phân tích với win9x để lấy khái niệm rồi các bài sau ta sẽ đưa ra các tips&tricks có thể lợi dụng của win2k/xp

Vector ngắt:
Lên windows thường có một câu hỏi ai cũng nghĩ đến là các vector ngắt đi đâu và liệu ta có sử dụng được các ngắt ngày xưa không? Xét một cách sâu xa, ngắt (interrupt) không phải chỉ là khái niêm của hệ điều hành. Đây là tính năng của bộ vi xử lý. Thực ra trên windows các ngắt vẫn có chứ không biến mất. Việc gọi các vector ngắt windows vẫn hỗ trợ nhưng kiểm soát và hạn chế hơn rất nhiều. Các thao tác “bá đạo” như VR hay một chương trình lập trình hệ thống hay làm sử dụng các ngắt truy nhập cấp thấp sẽ gây ra lỗi bảo vệ. Trước kia trên DOS các vector ngắt có thể thay đổi dễ dàng bằng cách thay đổi địa chỉ trong bảng vector ngắt IVT (Interrupt Vector Table), trong chế độ protected bảng IDT (Interrupt Descriptor Table) sẽ lưu giữ các vector ngắt này. Thay đổi IDT có thể tạo cho ta hiệu ứng tương đương như trên dos nhưng việc này chẳng dễ dàng tí nào cả.

Bộ nhớ:
Để có chế độ bảo vệ, windows không thể đạt được nếu chỉ dựa vào phần mềm. Đây là nhờ có sự trợ giúp kiểm soát của phần cứng đặc biệt là bộ vi xử lý. Các ứng dụng chạy trong chế độ bảo vệ của windows thường có bảng IDT/IVT và bộ nhớ riêng và chạy như một hệ thống khép kín đọc lập. Mọi thao tác trực tiếp đến vùng nhớ ngoài ứng dụng đều gây ra lỗi bảo vệ (truy nhập không hợp lệ).

Rings:
Vậy bản thân windows kiểm soát hệ thống ở cấp thấp như thế nào? Ta có khái niệm rings. Đây là các “đặc quyến” các ứng dụng trên win có thể có. Một chương trình thông thường chạy ở ring-3 (có ít sức mạnh nhất) và kernel hệ thống chạy ở ring-0 có đặc quyền tối thượng. Việc cướp ring-0 của win sẽ cho ta sức mạnh kiểm soát toàn bộ hệ thống. Bạn muốn xoá CMOS (cổng 70h) ư? Hay đơn giản là kêu trên PC một âm thanh qua port timer? Bạn phải có ring-0. Bạn muốn có bảng vector ngắt riêng? Lại là ring-0. Việc của win là nắm chắc ring-0 còn việc của ta là cướp nó. Có một số sơ hở của windows dẫn đến các VXer lợi dụng cướp được ring-0 (ví dụ như VR nổi tiếng CIH). Tôi đã thử một vài kỹ thuật như vậy và sẽ trình bày lại với các bạn nhưng thật đáng tiếc tôi chưa bao giờ thành công với winNT/2k/xp.

Các kiến thức nho nhỏ tôi vừa trình bày chung quy chỉ để giải quyết vấn đề thường trú và kiểm soát hệ thống. Thường trú trên DOS rất dễ, ta có thể thay đổi khối nhớ MCBs của DOS hay đơn giản là tìm khoảng nhớ nào ít người dùng thì điềm nhiên “chui vào”. Ở chế độ bảo vệ, ta không làm được như vậy. Tôi đã hứa đưa ra 2 cách, một là cách đơn giản nhất, 2 là cách sử dụng kỹ thuật cao. Các bạn có thể đoán được cách thứ 2 là rings.

hừmm.. thời gian trôi nhanh quá lúc nào tôi rảnh ta sẽ lại tiếp tục nhé. Bác nào trợ giảng hay có tài liệu gì hay giải thích thêm đều rất hoan nghênh. Hẹn gặp lại bài sau

Spinx


[Up] [Print Copy]
  [Question]   Bài viết cũ:Bài 3 Hướng dẫn lập trình Virus. Tác giả Spinx 24/01/2007 01:06:09 (+0700) | #2 | 37780
totocongsang
Member

[Minus]    0    [Plus]
Joined: 17/01/2007 18:10:26
Messages: 9
Offline
[Profile] [PM]
con vr đó đâu cứ giới thiệu suôn như thế thì chẳng ma nào góp ý đâu
[Up] [Print Copy]
  [Question]   Bài viết cũ:Bài 3 Hướng dẫn lập trình Virus. Tác giả Spinx 25/01/2007 04:04:07 (+0700) | #3 | 37982
haifcoor
Member

[Minus]    0    [Plus]
Joined: 24/01/2007 13:51:23
Messages: 6
Offline
[Profile] [PM]
Newbie em chào cacs liền anh liền chị trong rôm

Theo dõi chủ đề nầy mà kh thấy bác spinx viết tiếp nhỉ. Rõ chán
[Up] [Print Copy]
  [Question]   Re: Bài viết cũ:Bài 3 Hướng dẫn lập trình Virus. Tác giả Spinx 25/01/2007 04:54:27 (+0700) | #4 | 37989
nothing1610
Member

[Minus]    0    [Plus]
Joined: 24/01/2007 16:41:30
Messages: 11
Offline
[Profile] [PM]
Bác Spinx có thể cho tôi hỏi về cách diệt con virus 32... gì đó mà nó cứ tạo là tên thư mục có cái đuôi là .exe không? Tôi dùng Norton Anti virus mà chẳng quét được gì cả? -> có lẽ nó không nguy hiểm smilie) nhưng nó làm tôi khó chịu lắm và nó cũng vô hiệu hóa cả Task Manager của window nữa chứ, -> khó chịu chít đi được? smilie(
Không biết có cách nào diệt nó không? (Bằng tay càng tốt smilie , vì máy của tôi cấu hình yếu lắm, không dùng các chương trình anti khác được, BKV thì nó cũng bị chít luôn, không dùng được)
Cám ơn bác Spinx trước nha!
[Up] [Print Copy]
[digg] [delicious] [google] [yahoo] [technorati] [reddit] [stumbleupon]
Go to: 
 Users currently in here 
1 Anonymous

Powered by JForum - Extended by HVAOnline
 hvaonline.net  |  hvaforum.net  |  hvazone.net  |  hvanews.net  |  vnhacker.org
1999 - 2013 © v2012|0504|218|