Tak ada gading yang tak retak, kata-kata pepatah tersebut berlaku juga untuk yang satu ini. Berbagai trik dan tehnik dilakukan terutama untuk menyembunyikan atau menyamarkan proses/prgram yang dibuat dengan menggunakan kompiler Visual Basic, contoh trik tersebut adalah dengan meng-overwrite nama runtime VB dalam tubuh file program VB, seperti yang telah dipaparkan oleh Achmad Darmal pada artikel sebelumnya.
Memang dengan menggunakan trik tersebut beberapa program VB detector biasa akan terkecoh, terutama yang hanya menggunakan tehnik (sub)string compare pada nama runtime VB (MSVBVM). Dengan cukup mengubah nama runtime tersebut pada daerah import table yang berada di dalam tubuh file, tehnik deteksi tersebut sudah tidak akan lagi efektif. Semisal namanya dirubah menjadi “kacau32.dll”, maka tehnik (sub)string compare akan gagal mendeteksi program VB, walaupun dengan cara demikian program VB tersebut harus makan ati untuk tidak lagi menggunakan nama runtime standar “msvbvm*.dll” tetapi harus memiliki handle ke file VB runtime dengan nama yang sama.
Berikut akan saya tunjukkan cara yang paling efektif dan akurat untuk mendeteksi program yang dibuat menggunakan kompiler Visual Basic. Cara ini 100% manjur untuk mendeteksi proses VB dan saya menjamin tidak akan pernah meleset sedikitpun dengan catatan dalam keadaan dan situasi yang normal, maksudnya proses tidak diproteksi, baik melalui proteksi ring 3 (user mode) maupun ring 0 (kernel mode). Selain itu tehnik ini tidak hanya mampu mendeteksi untuk program VB lama seperti VB yang menggunakan runtime msvbvm50.dll tetapi kemungkinan juga akan mampu mendeteksi runtime VB yang akan datang (tercipta), selama library lama masih dipakai.
Ide dasar tehnik deteksi ini ada dua macam cara. Pertama, dengan memeriksa setiap nama fungsi pada export table di setiap module, karena hampir setiap fungsi runtime VB memiliki pattern “__vba” pada awal nama fungsinya, sehingga akan sangat mudah untuk mengenalinya. Sebagai contoh fungsi untuk membuka file, maka nama fungsi akan menjadi “__vbaOpenFile”. Kedua, dengan memeriksa section stub (opcode) pada section kedua, yang mana merupakan section basis engine VB. Section ini berisi fungsi-fungsi internal program VB untuk beroperasi dengan baik, sehingga apabila terjadi perubahan, maka bisa dipastikan program yang dibuat dengan VB tidak bisa berjalan dengan baik. Sehingga trik “overwrite” yang pernah diimplementasikan oleh mas Achmad Darmal tidak bisa diaplikasikan pada bagian inti ini (opcode).
Untuk menghindari trik dan tipuan, agar proses deteksi tetap akurat, saya juga memakai metode deteksi dalam dua cara, RVA mode dan RAW mode. RVA mode akan melakukan pemeriksaan pada memori module secara langsung, sehingga apabila module di-pack/kompres, tehnik ini tidak akan terpengaruh, sedangkan RAW mode akan melakukan pemeriksaan pada file asli-nya (image sebelum di-load di memori) secara utuh, sehingga apabila trik/tipuan (yang bermaksud untuk mengecoh detector) terjadi saat program running, tehnik ini juga tidak akan terpengaruh. Dengan cara ini, maka tidak ada jalan lain bagi program VB untuk bersembunyi atau setidaknya, carilah jalan lain menuju roma J.
Untuk lebih jelasnya, anda bisa mempelajari pada source code yang telah saya tulis dalam bahasa C++, kok C++? Karena tidak lucu membuat program VBkiller menggunakan Visual Basic.
Source code dan program AVBKiller sudah disertakan menjadi satu file ZIP, dan bisa di download di sini.
0 Komentar