Esiste un modo per ingannare il compilatore JIT .net nell'esecuzione di un altro metodo?

Question

Ok, supponiamo che la mia applicazione stia emettendo (x86) istruzioni in memoria, rendendo eseguibile la pagina, ecc. C'è un modo per alterare lo stub del metodo di un metodo non JITted per puntare al mio flusso di istruzioni emesso?

per esempio:.

Supponiamo di aver creato un flusso di istruzioni x86 in memoria, che fa qualcosa di arbitrario. Supponiamo ora di avere un metodo "int Target ()". Non l'ho ancora chiamato, quindi non è stato compilato. C'è un modo per:

1. Porta il puntatore allo stub di Target
2. Indica il mio flusso di istruzioni emesso.

Mi rendo conto che praticamente ogni singola funzionalità di sicurezza di .Net è progettata per prevenire il dirottamento in questo modo. Ma è possibile, ad esempio, l'API di hosting?

Answer 1

sì, puoi farlo!

Aggancia il metodo getJit di mscorjit. E ti verrà chiesto ogni volta che qualsiasi metodo richiede Jitting. puoi passare quello che vuoi. Alcuni protettori .net funzionano in questo modo.

Answer 2

Ciò è possibile tramite l'API di profilazione. Non l'ho mai usato, ma è usato per uno scopo simile in TypeMock.

Modifica: penso che ci sia stato un bel post sui blog MSDN, andrà a cercarlo.

Modifica 2: Doh, primo colpo !

Answer 3

Come dici tu, questo non è facile e potrebbe non essere nemmeno possibile. Se ricordo correttamente il codice includerà l'indirizzo del compilatore JIT per un metodo, che non è stato compilato. Quindi, quando si tenta di chiamare questo metodo, il compilatore JIT farà il suo lavoro e inserirà l'indirizzo nel metodo appena compilato. Se puoi modificare questo indirizzo, potresti essere in grado di inserire una chiamata al tuo codice. Come faresti questo inosservato è al di là di me. Spero sicuramente che il CLR rilevi questo tipo di manomissione.

Non credo che l'API di profilazione ti aiuterà in questo caso (come suggerito da Leppie), poiché non stai cercando di modificare MSIL. In caso contrario, questo articolo potrebbe essere utile poiché descrive cosa devi fare per implementare ciò che sta facendo TypeMock.

Answer 4

Oltre a poter utilizzare ICorProfiler e riscrivere il metodo prima di eseguire jits, è possibile utilizzare ICorDebug (MDBG è gestito interfacciato). Imposta un punto di interruzione, quando i punti di interruzione raggiungono l'impostazione successiva per il tuo codice di intercettazione. Tutto questo processo può essere fatto dal codice ma è davvero invadente e avrai bisogno di un "watcher" processo per coordinare questo.

Un'altra cosa che vale la pena guardare è il PostSharp che ti dà metodi di entrata e uscita se applichi gli attributi .

Answer 5

Non proverei a rovinare direttamente la memoria e non sono sicuro che sia possibile, invece puoi usare l'API del profiler - ci sono alcuni esempi là fuori ma nessuna vera documentazione. Dai un'occhiata all'articolo della rivista MSDN - Riscrivi il codice MSIL al volo con .NET API di profilazione del framework