[pso] [tema1][win]Interceptare NtClose...

[Maximilian Machedon]

        Incercati:

1. Sa verificati tot ce returneaza functiile (ca sa detectati erorile, de 
alocare de exemplu)
2. "Callers of IoAllocateErrorLogEntry must be running at IRQL <= 
DISPATCH_LEVEL" deci nu din spin-lock

On Fri, 18 Mar 2005 17:11:53 +0200, Octavian Purdila <pso at cursuri.cs.pub.ro> 
wrote:

> On Thursday 17 March 2005 08:52 am, Andrei Costin wrote:
>> OP> Era doar un exemplu. Atentie insa,  apelul de sistem original
>> poate face
>>
>> OP> sleep(), asa ca aveti grija la race-uri. Problema e ca in timp ce
>>
>> OP> apelul original face sleep, poate sa vina o cerere care sa
>>
>> OP> demonitorizez apelul de sistem, asa ca dupa apelul original nu
>> trebuie
>>
>> OP> sa mai folositi decat variabile de pe stiva (sau sa stiti ce
>> faceti).
>>
>>
>> Referitor la aceasta ultima remarca 2 intrebari:
>>
>> 1. ce inseamna/implica "asa ca dupa apelul original nu trebuie
>>  sa mai folositi decat variabile de pe stiva (sau sa stiti ce
>> faceti)"
>>
>
> Poate apare un race, in functie de modul in care ati implementat accesul
> la apelurile de sistem interceptate. Ideea de baza este sa tineti cont
> de faptul ca functia originala poate face sleep si intre timp poate sa
> vina cineva si sa opreasca monitorizarea/interceptarea.
>
>> 2. are vreo legatura cu NtClose()
>>
>> PS: 3. e NtClose() mai speciala - daca da, cum se rasfrange asta?
>> intreb asta pentru ca imi
>> moare/blocheaza testul doar la NtClose() si de pe lista de anul
>> trecut stiu ca si altii au avut
>> aceasta problema, dar egoisti au fost si nu ai zis care e treaba si
>> cum au rezolvat...
>>
>
> Dupa cum o sa mai vedem la celelalte teme, in Windows operatia de close
> se implementeaza din doua suboperatii: un clean   mai intati si abia
> apoi close-ul efectiv. Din cauza asta s-ar putea ca probabilitatea de
> sleep la NtClose sa fie mai mare.
>
>
> tavi