Messages posted by: TQN

- Thiên hình vạn trạng cho các registry key.
- 2 quanghabk: bạn làm sao mà modify được các file này, khi:
1. nó đang luôn running khi bạn đã và đang logon,
2. Làm sao bypass được SFC của Windows.
- 2 kienmanowar: REA đang nâng cấp, nên tui post tại đây:
"ShellExecuteDll là 1 dạng rất nguy hiểm. Nó là 1 COM dll, implement IShellHookEx interface. Interface này chỉ có 1 hàm duy nhất là Excute. Và hàm này (trong dll) sẽ được gọi khi bất kỳ app trong Windows nào gọi hàm ShellExecute hay ShellExecuteEx, tức mở file, thực thi exe... Virus mà đã đăng ký và hook được key này thì hầu như kiểm soát toàn bộ Explorer.
Thông tin về nó các cậu xem thêm ở đây:
- http://www.codeguru.com/cpp/com-tech/shell/article.php/c4515__1
- http://msdn2.microsoft.com/en-us/library/ms632982.aspx"
Rì ga !!!

Trên Win32, pointer trong VB thực ra chỉ là 1 số Long thôi. Truyền cho hàm API thì cứ ByVal As Long.

Thế mà còn không biết dùng uharc.exe bung nó ra.

Viết gì cũng được, miển chạy trước userinit.exe và winlogon.exe là được.

GINA chỉ là một dll, được Winlogon.exe gọi khi đăng nhập. Thông tin chi tiết của nó mô tả đầy đủ trong MSDN, và source code của các GINA dll đầy trên internet. Cậu search sẽ thấy.

Cái trò userinit nhóm 29a đã dùng từ 3 đời 8 hoánh rồi, xưa như trái đất. Sau này các virus writter bắt chước theo ồ ạt.
Con fun.exe không gọi userinit.exe được, lấy tư cách gì mà gọi, nó chỉ append thôi. Winlogon.exe sau khi đăng nhập thành công, sẽ mở key này, parse và gọi tất cả exe trong đó. Cậu thử thêm cmd.exe vào sẽ thấy (nhớ là thêm, không xóa nha).
Đố cậu nào viết được virus chạy trước cả userinit nữa, tương tự như chkdsk.exe đấy. Khỏi sữa luôn, chỉ còn nước format.

Tui có 2 CD source code (1 phần) của Win 2000, không dùng 1 cái. Bạn cần không ?

Dùng API trong VB cực kỳ dở, khó chịu. Nếu có lỗi thì không debug được, không watch memory được, không stepin vào hàm API được, lại tốn thêm 12 bytes cho mỗi lệnh gọi DllFunctionCall, làm chậm thêm.
Ta cũng có thể dùng VC, WinDbg, OllyDbg... để debug exe của VB app, với điều kiện là build debug, chọn option create pdb file, build native code. Lúc này có thể vừa debug được code ASM, code VB.

- CDAC11BA.EXE là thằng nào mà lại nằm trong system32\drivers
- Trong Windows không có file taskmons.exe, mà lại nằm trong thư mục Windows. Thằng này chắc chắn là virus rồi.
Copy 2 file này ra máy nào có AV mới, update thường xuyên, quét thử xem sao.
Nếu vẫn không phát hiện ra, up lên host nào đó để LVH lấy về, add vào database.

Bạn có thể upload file virus SSVICHOSST.exe này lên đâu đó được không. Tui sẽ analyze thử và sẽ trả lời cách hoạt động của nó, cách diệt, mã giả của nó.

Đồ dỏm, kỹ thuật xưa rồi. Qua mấy tool rootkit detect thì lòi ra hết: IceSword, GMER, RootkitUnhooker....
Kỹ thuật này hồi xưa tui và Teerayoot đã dùng khi coding OllyInvisible.

Google với IdleUIGetLastInputTime, thấy ra một đống. Không lẽ Yahoo ăn cắp code hay ???
- http://www.microsoft.com/msj/0200/c/c0200.aspx
- www.vckbase.com/document/viewdoc/?id=567
- www.codeguru.com/forum/archive/index.php/t-193602.html
Và y chang như code của bạn thanhth2909. Bạn thanhth2909 RE ra code của idle.dll hay thiệt !!!

Manual unpack !!!

Không nhớ chính xác nữa, down về install thấy VB là uninstall liền.

Sợ cái bộ install của icafe quá, làm máy tui hư mất 1 ngày, uninstall ra nó xóa mất tiêu mấy cái olexxx.dll trên máy tui (toàn system dll không, mà tui tại tắt cái sfc nữa). Giờ mà còn làm bộ install dựa trên cái của VB à. Thôi không dám đụng nữa. I hate VB smilie

!!

Xin hỏi bác Mr.Ñººb (cái tên này gõ không được), các registry key đó để làm gì, có tác dụng gì trong Windows, liên quan gì đến ShellExecute, CreateProcess vậy, Exe nào của Windows dùng và kiểm tra các key đó. Chỉ modify key mà bypass được AV thì hơi nực cười.
Mình nói rõ với bạn luôn là Explorer.exe dùng các key này, nhưng để làm gì, làm ra sao thì mong bạn trả lời.
IE Protector của Hoàng hook rất nhiều APIs, nhưng lại bỏ sót các APIs của ntdll.dll như NtCreateProcess, NtOpenKey/ReadKey/WriteKey... nên vẫn có chổ hở. Xin lỗi đã RE sơ qua app của Hoàng.

MinGW và gcc tạo code ẹ lắm, phình to, chậm rì, Intel C/C++ và VC++ compiler tạo code trùm nhất, Borland C++ cũng không bằng.

Vậy là Hoàng detect dựa trên VersionInfo của exe phải không, vì cái này nằm trong resource section, nên ít khi được chọn option pack. Nếu thực vậy thì hơi nguy hiểm vì script kiddie có thể modify version info = các resource editor tool.
Đọc warning của IE Protector thấy nghiêm cấm RE nên sợ quá, không dám đụng vào.
Hoàng thử code 1 app nhỏ, run sau khi IE Protector đã chạy, gọi FreeLibraray until thành công handle của BlockerAPIs.dll chưa (chắc LoadLibrary("BlockerApis.dll") sẽ thành công). Nếu free được thì coi chừng không ổn, madCodeHook cũng bị bypass.

Tui có thắc mắc, muốn hỏi Hoàng: các app viết bằng AutoIt đều bị pack = UPX, thì làm sao Hoàng detect được, chả lẽ phải unpack trên memory rồi find AutoIt string à. Nguy hiểm thế.

Cậu chuong81 này tốt bụng ghê, bind thêm vào cái AntiSpyware của LVH thằng perfect keylogger ha. Mod đâu cảnh cáo cậu nhóc 81 này một phát cho chừa.

Hoàng detect AutoIt dựa vào signature gì, có chính xác không ?

Ừ, lung tung luôn, sao giờ lại lòi ra cái .lib. File .lib thì làm sao mà dùng cho C# được, hay quá vậy, hay tui hỗng biết.

Chỉ dùng Dll inject khi process B có dùng Critical Section, còn nếu process B dùng cái khác như mutex, event, semaphore thì khỏi cần dùng Dll inject. Wait for object đó trên A, rồi trên A read/write (ReadProcessMemory/WriteProcessMemory) thoả mái. Vấn đề quan trọng nhất không phải là kỹ thuật code, mà là kỹ thuật RE để hiểu rõ về cơ chế đọc, ghi của process B lên vùng nhớ đó.
Critical Section chỉ lock được các thread trong cùng 1 process. Nó là 1 user object. Còn các lock object còn lại là kernel object, có thể lock các thread trên các process khác nhau. Vd: process B khởi tạo 1 mutex với tên là :"ThangChaNo", có hai thread: main thread và 1 working thread. 2 thread này luân phiên read/write lên addr X, dùng mutex trên. Bên process A, open mutex cũng phải với tên "ThangChaNo" (bắt buộc), rồi wait trên mutex trả về, thì cuối cùng cả 3 thread: main thread của A, main thread của B và working thread của B đều có khả năng lock bởi mutex "ThangChaNo". Nếu 3 thread đều wait trên mutex này thì tại mọi thời điểm, chỉ có 1 thread được run, 2 thread còn lại bị wait.

Thế mà cũng hỏi, Explorer, F2, xoá .exe, gõ .jpg, Enter là xong. Hì hì.
Có đổi gì đi nữa thì Exe vẫn là Exe, PE trong Win hay ELF trong nix

Cậu phải có khả năng lập trình và lập trình hệ thống thật giỏi, đồng thời phải là 1 cracker nữa thì mới mong chuyện bảo vệ được phần mềm của mình bằng chính code của mình. Mấy cái đồ kia thì cracker vừa xem tivi, vừa alo với girl mà vẫ crack được "cái bụp". Lập trình thật giỏi đã, tìm các sách về RE, anticracking, virus, ASM về mà đọc.

Không phải là copy không được, tui thấy có nhiều ct defrag hay backup file SAM làm được chuyện này. Không có thời gian để RE xem nó làm việc ra sao, có thể là inject code copy vào chính 1 process nào đó của System để copy.

Ủa, sao không thấy 2 con virus "sừng sỏ" của VN ta: Gaikhongxinh va vlove nhỉ.

Kiểm tra save chưa, kiểm tra ngày tháng của máy local và VSS server.

Good, cách này hay dùng nhất, nhưng coi chừng trường hợp sau: trong vòng loop, người dùng close ct hay làm 1 tác vụ khác, do DoEvents nên ct vẫn có khả năng gọi và sẽ gọi các event handler #, nên bug sẽ xảy ra. Nhất là trong VB, đệ quy sẽ xảy ra khi chính event handler có vòng loop bị gọi lại nữa. Cái này hồi đó khi tui còn làm coder gặp "quài".

Tìm hoài mà không ra CanonicalizePathName là hàm API nào, lúc đầu cứ ngỡ là của ShlWAPI.dll.