Kami menembus perlindungan dari bot

Baru-baru ini, incapsula telah mulai muncul di banyak situs asing - sebuah sistem yang meningkatkan keamanan situs, kecepatan kerja dan pada saat yang sama sangat menyulitkan kehidupan pengembang perangkat lunak. Inti dari sistem ini adalah perlindungan komprehensif menggunakan JavaScript, yang, omong-omong, banyak bot DDOS telah belajar untuk mengeksekusi dan bahkan mem-bypass CloudFlare. Hari ini kita akan mempelajari incapsula, menulis deobfuscator skrip JS dan mengajar bot DDOS kita untuk mengatasinya!

Situs dalam tangkapan layar di bawah ini diambil sebagai contoh yang baik untuk sebuah artikel, tidak berbeda dari yang lain, di forum subyek yang meragukan, banyak yang mencari kekerasan untuk itu, tapi saya punya tugas lain - perangkat lunak untuk mengotomatisasi berbagai tindakan dengan situs.

Mari kita mulai dengan memeriksa pertanyaan, karena hanya ada 2, dan di sini adalah yang pertama:



Permintaan ini memuat skrip yang dikaburkan secara alami:



Mengubah eval ke document.write () memberikan kode yang sedikit lebih mudah dibaca:



Saya tidak tahu mengapa, tetapi alat otomatis untuk memformat kode keluaran mematahkan kode ini, jadi saya harus memformatnya dengan tangan saya dan memberikan variabel nama normal. Untuk semua manipulasi ini saya menggunakan notepad sederhana ++ dan fungsi penggantian teks, sebagai hasilnya kita dapat melanjutkan dan memeriksa baris pertama:

var _0x3a59=['wpgXPQ==','cVjDjw==','Tk/DrFl/','GMOMd8K2w4jCpw==','wpkwwpE=','w6zDmmrClMKVHA==', ... ,'w4w+w5MGBQI=','w6TDr8Obw6TDlTJQaQ==']; 

Ini adalah array yang berisi nama fungsi terenkripsi dan string lainnya, jadi kita perlu mencari fungsi yang mendekripsi array ini, tidak perlu melangkah jauh:


Jika kami menyebutnya secara terpisah:

 ParamDecryptor('0x0', '0Et]') 

Hasil itu akan jauh dari yang kami harapkan. Dan semuanya harus disalahkan untuk fungsi lain:

 var shift_array=function(number_of_shifts){ while(--number_of_shifts){ EncodedParams['push'](EncodedParams['shift']()); } }; 

Yang ada di tempat yang sangat tidak terduga - dalam fungsi yang disebut di bagian paling awal dan memeriksa cookie. Rupanya, para pengembang dengan demikian “melindungi” cek cookie dari pemotongan. Seperti yang Anda lihat - tidak ada yang rumit, loop hanya menggeser array dengan jumlah elemen yang ditentukan, dalam kasus kami 223 elemen. Dari mana datangnya angka ajaib 223 ini? Saya mengambil nomor ini dari panggilan ke fungsi verifikasi cookie, sepertinya 0xdf di sana dan mengikuti rute ini:

 //  function(EncodedParams,EncodedParamsShifts); //  (AllParams,0xdf); //0xdf => 223 //    var _0x5e622e=function(_0x486a40,_0x1de600){_0x486a40(++_0x1de600);}; _0x5e622e(shift_array,EncodedParamsShifts); //     : shift_array(++EncodedParamsShifts); 

Secara alami, itu berubah setiap saat, siapa yang akan ragu ...

Sekarang yang tersisa adalah mengganti semua panggilan

 var _0x85e545=this[ParamDecryptor('0x0', '0Et]')]; 

pada

 var _0x85e545=this['window']; 

Atau, lebih baik lagi, terus

 var ThisWindow=this.window; 

Saya menjadikan konversi terakhir sebagai reguler biasa. Oh ya, mereka benar-benar lupa untuk memberikan baris berikut:

\x77\x6f\x4a\x33\x58\x68\x6b\x59\x77\x34\x44\x44\x6e\x78\x64\x70

Untuk tampilan normal. Tidak ada yang rumit, ini adalah UrlEncode biasa, ubah \ x menjadi% dan dekode untuk mendapatkan baris berikut:

woJ3XhkYw4DDnxdp

Kemudian saya mulai mengganti semua panggilan ala

 ParamDecryptor('0x0', '0Et]') 

ke baris yang sudah didekripsi menggunakan fungsi yang ditulis sendiri dari modul saya. Ya, kodenya tidak bersinar dengan indah, tenggat waktu terbakar (seperti yang biasanya diperlukan kemarin) dan saya terlalu malas untuk berpikir karena saya dulu memprogram dengan mouse , namun, ia bekerja dengan baik:



Saya menulis ulang kode dari sumbernya hampir 1v1.

Selanjutnya, metode lain untuk mengaburkan kode menarik perhatian saya. Saya harus menulis fungsi yang cukup besar yang mencari panggilan seperti itu:

 case'7':while(_0x30fe16["XNg"](_0x13d8ee,_0x5a370d)) 

Dan menggantinya dengan analog sederhana:


Untuk mendapatkan:

 case'7':while(_0x13d8ee < _0x5a370d){ 

Algoritma kerja sangat sederhana, pada kenyataannya, kami hanya mengganti variabel:

1. Kami menemukan nama array, dalam kasus kami: _0x30fe16
2. Parameter input parsim: _0x425e3c, _0x481cd6
3. Badan fungsi parsim: _0x425e3c <_0x481cd6
4. Ganti _0x425e3c dengan _0x13d8ee
5. Ganti _0x481cd6 dengan _0x5a370d
6. Kami mendapatkan : _0x13d8ee <_0x5a370d
7. Ganti _0x30fe16.XNg (_0x13d8ee, _0x5a370d) dengan kode di atas
8. Ulangi sampai fungsi berakhir

Parsing nama, parameter dan isi fungsi dilakukan oleh satu biasa. Tentu saja, dalam versi final modul metode ini tidak terlalu diperlukan, hanya ada 1 panggilan yang sedikit lebih dikaburkan, tetapi pelanggan mengatakan untuk melakukan segalanya dan karena itu melakukannya, selain itu, fungsi-fungsi lain juga menjadi lebih jelas. Di situs lain ada juga desain seperti:


Seperti yang Anda lihat di sini, parameter dari satu array merujuk ke yang lain. Saya memecahkan masalah ini hanya:

1. Parsim semua array
2. Kami membersihkannya dari kode
3. Salin semua elemen ke dalam array asosiatif (nama, nilai)
4. Dalam satu lingkaran oleh pencarian rekursif, kami mencari semua fungsi bersarang
5. Ganti fungsi bersarang dengan tindakan yang mereka lakukan
6. Rentangkan semua tautan ke string dengan cara yang sama

Setelah menerapkan metode deobfuscation ini, kode menjadi sedikit kurang membingungkan. Anda dapat segera melihat fungsi base64 dengan dua cara. Yang pertama:

 CharArray="ABCDE...XYZabcde...xyz0123456789+/"; 

Dan yang kedua:

 if(!window["btoa"])window["btoa"]=_0x386a89; 

Anda tidak lagi dapat membalikkan dan beralih ke fungsi lain yang lebih penting, atau lebih tepatnya, ke fungsi yang bekerja dengan cookie. Saya menemukannya di baris incap_ses_ dan melihat fitur kebingungan lainnya - kode kebingungan menggunakan loop:


Semuanya sangat sederhana di sini: kami mengatur ulang baris sesuai dengan urutan eksekusi: 4 | 2 | 5 | 0 | 3 | 1 dan mendapatkan fungsi aslinya. Metode deobfusasi ini juga tidak diperlukan dalam versi final, tetapi tidak menyebabkan masalah besar, semuanya diurai dengan cara dasar, hal utama yang perlu dipertimbangkan adalah bahwa bisa ada loop bersarang dan oleh karena itu saya hanya melakukan pencarian rekursif.


Itu hanya menyimpan nilai - nilai semua cookie yang dimulai dengan incap_ses_ dalam array dan kemudian metode lain menghitung checksum mereka hanya dengan menjumlahkan kode ASCII:


Kita akan membutuhkan checksum sedikit lebih jauh, dan sekarang mari kita mencari tahu seperti apa fungsi _0x4d5690 ini yang dipanggil dari tempat yang berbeda. Untuk melakukan ini, lihat saja metode yang dipanggil dan berikan mereka nama yang sesuai:

 function CheckDebugger(){ if(new this.window.Date()["getTime"]() - RunTime) > 0x1f4){ FuckDebugger(); } } 

Penulis skrip ini sangat naif :)

Poin penting lainnya:

 ParamDecryptor('0x65', '\x55\xa9\xf9\x1c\x1a\xd5\xfc\x60') //result = "ca3XP6zjTSB3w3gEwMl6lqgsdEVDTV9aF4rEDQ=="; 

Dari sini kita membutuhkan 5 huruf pertama: ca3XP , saya akan memberitahu Anda mengapa di bawah ini. Dan ingat, kami menghitung checksum dari nilai cookie? Sekarang kita membutuhkan mereka untuk mendapatkan apa yang disebut hash.


Bandingkan:



Hebat! Langkah terakhir tetap - menerima cookie untuk respons:

 ResCooka=((((ParamDecryptor(btoa(PluginsInfo),"ca3XP")+",digest=")+DigestArray)+",s=")+AllDigestHash); Set_Cookies("___utmvc",btoa(ResCooka),0x14); 

Kode asli di awal menambahkan parameter browser yang disandikan di base64 ke akhir array AllParams yang digeser, "mengenkripsi" mereka dengan fungsi ParamDecryptor dengan kunci ca3XP dan kemudian menghapus elemen yang ditambahkan sebelumnya. Saya dapat berasumsi bahwa kruk ini dibuat karena fitur kecil: fungsi ParamDecryptor menerima indeks elemen dalam array dan kunci, yang berarti bahwa Anda dapat mentransfer string di sana hanya melalui array. Kenapa tidak melakukannya dengan benar? Programmer, tuan.

Well, sebenarnya semuanya, cookie sudah siap, tetap untuk menginstalnya dan mengirim permintaan. Benar, Anda tidak akan menerimanya karena satu detail kecil yang saya lebih suka diam.

Optimasi

Potongan-potongan kode dalam Delphi hanyalah sebuah prototipe. Semua kode deobfuscator ditulis ulang dalam assembler karena persyaratan pelanggan dan kecepatan eksekusi meningkat beberapa kali. Berikut ini juga memiliki efek positif pada kecepatan:

1. Memotong kelebihan potongan kode dan array dalam satu iterasi dari loop. Ini diperlukan untuk secara signifikan mengurangi jumlah kode dan mempercepat pencarian di masa depan.
2. Karena fungsi dalam kode tidak tercampur, kami tahu perkiraan lokasinya, oleh karena itu, jika fungsi pemasangan cookie di bagian paling akhir, maka Anda harus mencarinya setidaknya dari tengah.
3. Cari fitur-fitur utama sebelumnya. Algoritma assembler mencari mereka bahkan pada saat membersihkan kode dari sampah yang tidak perlu.
4. Dalam versi final, saya menyingkirkan sekitar setengah fungsi deobfuscator yang diperlukan untuk memahami kode dan tidak diperlukan untuk bot karena parameter yang diperlukan didapat tanpa masalah

Kesimpulan

Ketika saya mengunjungi situs, saya ingin itu bekerja dengan cepat, dan mengacaukan skrip JS menggunakan metode ini tidak sopan kepada pengguna. Apakah ini membantu melindungi dari bot? Tidak, tentu saja, seperti yang Anda lihat, harganya benar-benar melebihi malam, dan hanya beberapa sandwich dan beberapa cangkir teh adalah biayanya.

Tujuan artikel ini adalah untuk berbicara tentang prinsip pengoperasian solusi ini dan untuk menunjukkan betapa tidak bergunanya solusi ini. Untuk alasan yang jelas, modul yang sudah jadi untuk menghindari perlindungan ini tidak akan dipublikasikan (setelah bocor, game-stop yang buruk beralih ke akamai), yang perlu melakukannya sendiri berdasarkan studi ini (yang dilakukan sekitar setahun yang lalu dan masih relevan), dan anak sekolah yang ingin untuk menggerakkan akun orang lain pergi ke hutan. Jika Anda memiliki pertanyaan, saya selalu siap untuk menjawabnya di komentar.