[pso] [Tema 1 win] - problema la setarea parametrilor syscall-ului pe stiva

[Cristi Lazea]

Salut.

Dimensiunea parametrilor corespunde, pentru ca am verificat-o (si asta
pentru mai multe syscall-uri, ca sa nu fie coincidenta). Ce nu inteleg eu, e
de ce la acea adresa "new_stack" (pentru cazul in care am 3 parametrii), se
gasesc 3 int-uri total diferite fata de ce s-a generat in do_monitor().


PS: Cum se da un reply pe lista de discutii (eu sunt subscriber doar cu un
daily digest mail in care primesc continutul a mai multor mailuri) ?


Salut,
>
> poate nu ai copiat corect dimensiunea parametrilor in noua tabela?
>
> 2008/4/3 Cristi Lazea <cricotanierea at gmail.com <http://cursuri.cs.pub.ro/cgi-bin/mailman/listinfo/pso>>:
>
> >* Salut.
> *>*
> *>* Am o problema in momentul in care in metoda de interceptare incarc in
> *>* stiva parametrii pe care
> *>* trebuie sa-i ia apelul original: dupa ce apelez codul in asm (cel din
> *>* curs), care se ocupa cu
> *>* incarcarea parametrilor in stiva, la adresa "new_stack" am niste valori
> *>* care difera total
> *>* fata de cele care sunt data in test.exe, in metoda do_monitor() (cele
> *>* generate aleator).
> *>* Teoretic ar trebui sa imi apara aceleasi valori ->si in userspace in
> *>* metoda do_monitor(),
> *>* si in driver, in metoda mea care apeleaza syscall-ul original.
> *>* Insa nu apar. Si de aici, la testearea apelurilor, se intampla
> *>* numai chestii ciudate (e si normal, avand in vedere ca se apeleaza cu
> *>* parametrii gresiti).
> *>*
> *>* De asemenea, am verificat codul pe care il intoarce syscall-ul original,
> *>* iar acesta este
> *>* STATUS_ACCESS_VIOLATION (0xC0000005) -> presupun ca din cauza parametrilor
> *>* gresiti
> *>* care sunt pusi pe stiva.
> *>*
> *>* Intrebarea mea este urmatoarea: e vreun amanunt ce-mi scapa mie atunci
> *>* cand am scris codul in
> *>* asm din curs, care salveaza in stiva parametrii respectivi ?
> *>*
> *>* Mentionez ca bucata de salvare in stiva e incadrata de un spinlock, asta
> *>* ca sa nu mai umble cineva
> *>* pe acolo in momentul in care fac eu modificari (am incercat si fara
> *>* spinlock, si rezultatul
> *>* e identic). De asemenea, syscall-no e preluat cum trebuie din eax
> *>* (intructiunea corespunzatoare e
> *>* din metoda mea, caci altfel, se altereaza eax-ul).
> *>*
> *>* Multumesc frumos,
> *>* Cristi Lazea*
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://cursuri.cs.pub.ro/pipermail/pso/attachments/20080403/dff5c60a/attachment.htm