Tasarım kararları
Bir Struct alanının veya CFunction çağrısının, taşınma mekanizmasına göre farklı API'lere bölünmesi kolay görünür; ancak bu, her üst katmanın...
Neden accessor soyutlaması?
Bir Struct alanının veya CFunction çağrısının, taşınma mekanizmasına göre farklı API'lere bölünmesi kolay görünür; ancak bu, her üst katmanın yerel/uzak ayrımı yapmasına yol açar. Accessor modeli taşıma ayrıntısını altta bırakır ve bileşenleri yeniden kullanılabilir kılar.
Neden mevcut sistem stub'ları?
NThread, thread'i yönlendirmek için yüklü sistem modüllerinde küçük talimat dizilerini arar: EB FE (spin), push reg; ret, jmp reg, ret ve add rsp, 0x28; ret. Bu, yönlendirme için büyük bir sabit payload yerleştirme ihtiyacını azaltır; ancak tüm NThread/accessor işlemlerinin hedefte hiç tahsis yapmadığı anlamına gelmez. Örneğin stack argümanları için küçük temizleme stub'ı, accessor middleware'leri için çalışma belleği gerekebilir.
Neden iki hook yaklaşımı var?
nhook, fonksiyonun ilk iki byte'ını EB FE ile değiştirir; giren thread park edilir ve taşınan prologue host tarafında simüle edilir. Uzaktaki trampoline tahsisini önler fakat polling, instruction simülasyonu ve eşzamanlı thread'ler açısından hassastır.
minhook ise beş byte'lık göreli jmp ve taşınmış talimatlardan oluşan gerçek trampoline kullanır. Daha geleneksel kontrol akışı sağlar; RIP-relative talimatların taşınması ve ±2 GB erişim sınırının relay ile aşılması gerekir.
Bu seçenekler birbirinin genel amaçlı yerine geçeni değildir; hedef fonksiyonun prologue'u, erişim yolu ve kabul edilen risk belirleyicidir.
Mimari genel bakış
Exoproc katmanlıdır. exoproc-utils ortak yardımcılar dışında, sistemin işlevsel tabanı bun-xffi'dir: adındaki **x**, cross-process'i; **ffi** ise...
Accessor zinciri
Accessor, Exoproc'un en önemli soyutlamalarından biridir. Aynı işlem kümesi — read, write, alloc, free, protect, scan ve call — farklı bellek...