Apakah ada kasus cerdas modifikasi kode runtime?

Dapatkah Anda memikirkan penggunaan yang sah (cerdas) untuk modifikasi kode runtime (program yang memodifikasi kode itu sendiri saat runtime)?

Sistem operasi modern tampaknya tidak menyukai program yang melakukan ini karena teknik ini telah digunakan oleh virus untuk menghindari deteksi.

Yang dapat saya pikirkan adalah beberapa jenis pengoptimalan runtime yang akan menghapus atau menambahkan beberapa kode dengan mengetahui sesuatu pada saat runtime yang tidak dapat diketahui pada waktu kompilasi.

Ada banyak kasus yang valid untuk modifikasi kode. Menghasilkan kode pada waktu proses dapat berguna untuk:

• Beberapa mesin virtual menggunakan kompilasi JIT untuk meningkatkan kinerja.
• Menghasilkan fungsi khusus dengan cepat telah lama menjadi hal biasa dalam grafik komputer. Lihat misalnya Rob Pike dan Bart Locanthi dan John Reiser Hardware Software Tradeoffs untuk Bitmap Graphics di Blit (1984) atau posting ini (2006) oleh Chris Lattner tentang penggunaan LLVM oleh Apple untuk spesialisasi kode runtime dalam tumpukan OpenGL mereka.
• Dalam beberapa kasus, perangkat lunak menggunakan teknik yang dikenal sebagai trampolin yang melibatkan pembuatan kode secara dinamis pada tumpukan (atau tempat lain). Contohnya adalah fungsi bersarang GCC dan mekanisme sinyal dari beberapa Unix.

Terkadang kode diterjemahkan ke dalam kode saat runtime (ini disebut terjemahan biner dinamis ):

• Emulator seperti Apple's Rosetta menggunakan teknik ini untuk mempercepat emulasi. Contoh lain adalah software morphing kode Transmeta .
• Debugger dan profiler yang canggih seperti Valgrind atau Pin menggunakannya untuk melengkapi kode Anda saat sedang dijalankan.
• Sebelum ekstensi dibuat ke set instruksi x86, perangkat lunak virtualisasi seperti VMWare tidak dapat langsung menjalankan kode x86 istimewa di dalam mesin virtual. Alih-alih itu harus menerjemahkan instruksi yang bermasalah dengan cepat menjadi kode khusus yang lebih sesuai.

Modifikasi kode dapat digunakan untuk mengatasi keterbatasan set instruksi:

• Ada suatu masa (dahulu kala, saya tahu), ketika komputer tidak memiliki instruksi untuk kembali dari subrutin atau ke alamat memori secara tidak langsung. Kode modifikasi diri adalah satu-satunya cara untuk mengimplementasikan subrutin, pointer dan array .

Lebih banyak kasus modifikasi kode:

• Banyak debugger mengganti instruksi untuk mengimplementasikan breakpoint .
• Beberapa linker dinamis mengubah kode pada saat runtime. Artikel ini memberikan beberapa latar belakang tentang relokasi runtime DLL Windows, yang secara efektif merupakan bentuk modifikasi kode.

Ini telah dilakukan dalam grafik komputer, khususnya perender perangkat lunak untuk tujuan pengoptimalan. Pada waktu proses, status banyak parameter diperiksa dan versi kode rasterizer yang dioptimalkan dihasilkan (berpotensi menghilangkan banyak persyaratan) yang memungkinkan seseorang untuk membuat grafik primitif misalnya segitiga jauh lebih cepat.

Salah satu alasan yang valid adalah karena set instruksi asm kekurangan beberapa instruksi yang diperlukan, yang dapat Anda buat sendiri. Contoh: Pada x86 tidak ada cara untuk membuat interupsi ke variabel dalam register (misalnya membuat interupsi dengan nomor interupsi di ax). Hanya nomor const yang dikodekan ke dalam opcode yang diizinkan. Dengan kode selfmodifying seseorang dapat meniru perilaku ini.

Beberapa kompiler menggunakannya untuk inisialisasi variabel statis, menghindari biaya bersyarat untuk akses selanjutnya. Dengan kata lain, mereka menerapkan "jalankan kode ini hanya sekali" dengan menimpa kode tersebut tanpa operasi saat pertama kali dijalankan.

Ada banyak kasus:

• Virus biasanya menggunakan kode modifikasi sendiri untuk "menyederhanakan" kode mereka sebelum dieksekusi, tetapi teknik tersebut juga dapat berguna dalam rekayasa balik yang membuat frustrasi, cracking, dan peretasan yang tidak diinginkan
• Dalam beberapa kasus, mungkin ada titik tertentu selama runtime (misalnya segera setelah membaca file konfigurasi) ketika diketahui bahwa - selama sisa masa proses - cabang tertentu akan selalu atau tidak pernah diambil: daripada tidak perlu memeriksa beberapa variabel untuk menentukan jalan ke cabang, instruksi cabang itu sendiri dapat dimodifikasi sesuai
  • Misalnya, dapat diketahui bahwa hanya satu dari kemungkinan tipe turunan yang akan ditangani, sehingga pengiriman virtual dapat diganti dengan panggilan tertentu.
  • Setelah mendeteksi perangkat keras mana yang tersedia, penggunaan kode yang cocok mungkin di-hardcode
• Kode yang tidak perlu dapat diganti dengan instruksi no-op atau lompatan di atasnya, atau bit kode berikutnya digeser langsung ke tempatnya (lebih mudah jika menggunakan opcode yang tidak tergantung posisi)
• Kode yang ditulis untuk memfasilitasi debuggingnya sendiri mungkin memasukkan instruksi jebakan / sinyal / interupsi yang diharapkan oleh debugger di lokasi yang strategis.
• Beberapa ekspresi predikat berdasarkan input pengguna mungkin dikompilasi menjadi kode asli oleh perpustakaan
• Menyebariskan beberapa operasi sederhana yang tidak terlihat hingga runtime (misalnya dari pustaka yang dimuat secara dinamis) ...
• Menambahkan langkah-langkah instrumentasi / pembuatan profil mandiri secara bersyarat
• Crack dapat diimplementasikan sebagai pustaka yang mengubah kode yang memuatnya (bukan "sendiri" yang memodifikasi dengan tepat, tetapi membutuhkan teknik dan izin yang sama).
• ...

Beberapa model keamanan OS berarti kode modifikasi sendiri tidak dapat berjalan tanpa hak akses root / admin, sehingga tidak praktis untuk penggunaan tujuan umum.

Dari Wikipedia:

Perangkat lunak aplikasi yang berjalan di bawah sistem operasi dengan keamanan W ^ X yang ketat tidak dapat menjalankan instruksi di halaman yang diizinkan untuk menulis — hanya sistem operasi itu sendiri yang diizinkan untuk menulis instruksi ke memori dan kemudian menjalankan instruksi tersebut.

Pada OS tersebut, bahkan program seperti Java VM memerlukan hak akses root / admin untuk menjalankan kode JIT mereka. (Lihat http://en.wikipedia.org/wiki/W%5EX untuk lebih jelasnya)

The Sintesis OS pada dasarnya dievaluasi sebagian program anda sehubungan dengan panggilan API, dan diganti kode OS dengan hasilnya. Manfaat utamanya adalah banyak pengecekan kesalahan hilang (karena jika program Anda tidak akan meminta OS untuk melakukan sesuatu yang bodoh, itu tidak perlu diperiksa).

Ya, itu adalah contoh pengoptimalan waktu proses.

Bertahun-tahun yang lalu saya menghabiskan pagi mencoba untuk men-debug beberapa kode modifikasi diri, satu instruksi mengubah alamat target dari instruksi berikut, yaitu, saya sedang menghitung alamat cabang. Itu ditulis dalam bahasa assembly dan bekerja dengan sempurna ketika saya mengikuti instruksi program satu per satu. Tetapi ketika saya menjalankan program itu gagal. Akhirnya, saya menyadari bahwa mesin sedang mengambil 2 instruksi dari memori dan (seperti instruksi yang diletakkan dalam memori) instruksi yang saya modifikasi telah diambil dan dengan demikian mesin sedang menjalankan versi instruksi yang tidak dimodifikasi (salah). Tentu saja, ketika saya men-debug, itu hanya melakukan satu instruksi dalam satu waktu.

Maksud saya, kode yang mengubah diri sendiri bisa sangat buruk untuk diuji / debug dan sering kali memiliki asumsi tersembunyi mengenai perilaku mesin (baik itu perangkat keras atau virtual). Selain itu, sistem tidak pernah dapat membagikan halaman kode di antara berbagai thread / proses yang dijalankan pada mesin multi-core (sekarang). Ini mengalahkan banyak manfaat untuk memori virtual, dll. Ini juga akan membatalkan pengoptimalan cabang yang dilakukan di tingkat perangkat keras.

(Catatan - saya tidak memasukkan JIT dalam kategori kode modifikasi diri. JIT menerjemahkan dari satu representasi kode ke representasi alternatif, itu tidak mengubah kode)

Secara keseluruhan, itu hanya ide yang buruk - sangat rapi, sangat tidak jelas, tetapi sangat buruk.

tentu saja - jika yang Anda miliki hanyalah memori 8080 dan ~ 512 byte, Anda mungkin harus menggunakan praktik semacam itu.

Dari tampilan kernel sistem operasi, setiap Just In Time Compiler dan Linker Runtime melakukan modifikasi diri teks program. Contoh yang menonjol adalah Penerjemah Skrip ECMA V8 Google.

Alasan lain untuk mengubah kode sendiri (sebenarnya kode "yang dihasilkan sendiri") adalah untuk menerapkan mekanisme kompilasi Just-In-time untuk kinerja. Misalnya, program yang membaca ekspresi algebric dan menghitungnya pada berbagai parameter input dapat mengubah ekspresi tersebut dalam kode mesin sebelum menyatakan kalkulasi.

Anda tahu kastanye lama bahwa tidak ada perbedaan logis antara perangkat keras dan perangkat lunak ... orang juga dapat mengatakan bahwa tidak ada perbedaan logis antara kode dan data.

Apa itu kode modifikasi sendiri? Kode yang menempatkan nilai-nilai dalam aliran eksekusi sehingga dapat ditafsirkan bukan sebagai data tetapi sebagai perintah. Tentu ada sudut pandang teoritis dalam bahasa fungsional bahwa sebenarnya tidak ada perbedaan. Saya mengatakan bahwa e dapat melakukan ini secara langsung dalam bahasa imperatif dan penyusun / penafsir tanpa asumsi status yang sama.

Apa yang saya maksud adalah dalam arti praktis bahwa data dapat mengubah jalur eksekusi program (dalam beberapa hal ini sangat jelas). Saya memikirkan sesuatu seperti compiler-compiler yang membuat tabel (array data) yang dilintasi seseorang dalam parsing, berpindah dari satu negara bagian ke negara bagian (dan juga memodifikasi variabel lain), seperti bagaimana sebuah program bergerak dari perintah ke perintah , memodifikasi variabel dalam prosesnya.

Jadi, bahkan dalam contoh biasa di mana kompilator membuat ruang kode dan merujuk ke ruang data yang sepenuhnya terpisah (heap), seseorang masih dapat memodifikasi data untuk mengubah jalur eksekusi secara eksplisit.

Saya telah menerapkan program menggunakan evolusi untuk membuat algoritme terbaik. Ini menggunakan kode modifikasi diri untuk memodifikasi cetak biru DNA.

Salah satu kasus penggunaan adalah file tes EICAR yang merupakan file COM executable DOS yang sah untuk menguji program antivirus.

X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*

Itu harus menggunakan modifikasi kode sendiri karena file yang dapat dieksekusi harus berisi hanya karakter ASCII yang dapat dicetak / dapat diketik dalam rentang [21h-60h, 7Bh-7Dh] yang membatasi jumlah instruksi yang dapat dienkode secara signifikan

Detailnya dijelaskan di sini

Ini juga digunakan untuk operasi floating-point di DOS

Beberapa kompiler akan memancarkan CD xxdengan xx mulai dari 0x34-0x3B di tempat instruksi floating-point x87. Karena CDadalah opcode untuk intinstruksi, itu akan melompat ke interupsi 34h-3Bh dan meniru instruksi itu dalam perangkat lunak jika koprosesor x87 tidak tersedia. Jika tidak, penangan interupsi akan mengganti 2 byte tersebut dengan 9B Dxsehingga eksekusi selanjutnya akan ditangani secara langsung oleh x87 tanpa emulasi.

Apa protokol untuk emulasi floating point x87 di MS-DOS?

The Linux Kernel memiliki loadable Kernel Modul yang melakukan hal itu.

Emacs juga memiliki kemampuan ini dan saya menggunakannya setiap saat.

Apa pun yang mendukung arsitektur plugin dinamis pada dasarnya memodifikasi kodenya saat runtime.

Saya menjalankan analisis statistik terhadap database yang terus diperbarui. Model statistik saya ditulis dan ditulis ulang setiap kali kode dijalankan untuk mengakomodasi data baru yang tersedia.

Skenario di mana ini dapat digunakan adalah program pembelajaran. Menanggapi masukan pengguna, program mempelajari algoritme baru:

1. itu mencari basis kode yang ada untuk algoritma serupa
2. jika tidak ada algoritma serupa di basis kode, program hanya menambahkan algoritma baru
3. Jika ada algoritma serupa, program (mungkin dengan bantuan dari pengguna) memodifikasi algoritma yang ada agar dapat melayani tujuan lama dan tujuan baru

Ada pertanyaan bagaimana melakukan itu di Java: Apa saja kemungkinan modifikasi diri kode Java?

Versi terbaik dari ini mungkin Lisp Macros. Tidak seperti makro C yang hanya sebuah preprocessor Lisp memungkinkan Anda memiliki akses ke seluruh bahasa pemrograman setiap saat. Ini tentang fitur paling kuat di cadel dan tidak ada dalam bahasa lain.

Saya sama sekali bukan seorang ahli tetapi salah satu dari orang-orang cadel membicarakannya! Ada alasan mengapa mereka mengatakan bahwa Lisp adalah bahasa yang paling kuat di sekitar dan orang pintar tidak karena mereka mungkin benar.