[pso] [Tema1][Win] interceptor test - Reply

[Cristi Lazea]

Salut Alex.

Aceeasi problema cu parametrii am avut-o si eu. In test.exe se generau niste
parametrii, iar in
metoda mea interceptor, la old_stack aveam cu totul altceva.
Mi-a sugerat Razvan sa ma uit in metoda in care faceam efectiv interceptarea
(unde marcam un syscall ca fiind interceptat), ca poate stricam ceva pe
acolo, si exact asa a fost.
Suprascriam dimensiunea parametrilor pentru syscall-ul interceptat, si de
aceea aveam problema
cu pricina.
(Pentru mai multe detalii, cu ce pateam eu - poate se potriveste cu ce ai
tu)
vezi mailurile trimise de mine acum 2 zile.

Cat despre partea cu find_log(), acolo imi ramanea si mie de rula la infinit
in bucla aia,
exact din cauza ca nu gasea aceeasi parametrii ai syscall-ului (vezi if-ul
cu memcmp(...))
in intrarea de log generata de mine in driver.

Ideea e ca daca nu generezi bine intrarea in log, sau daca e vreun parametru
ce nu
corespunde pe acolo, ruleaza pana la timeout, dupa cum ai vazut si tu, in
while-ul ala.

Numai bine,
Cristi Lazea

2008/4/5 Alex Drenea <alexdrenea at gmail.com>:

> Am intampinat o problema la partea de logare a apelurilor de sistem.
>  Deoarece test.exe se bloca la testul "interceptor", am inceput sa adaug
> printf's si DbgPrint's all over the place.
> Foarte curand am constatat ca parametrii care ii trimite test.exe apelului
> de sistem (cei generati random in do_monitor()),
> sunt diferiti de cei pe care ii primesc in handlerul meu de apel de sistem
> (pe care ii citesc din ebp).
> Mentionez ca rulez test.exe direct din masina virtuala si am comentat
> verificarile care implica UserAdmin().
>
> sci.c:
> NTSTATUS genericHandler()
> {
>  int* old_stack;
>  ...
>  _asm mov old_stack, ebp
>  _asm add old_stack, 8
>  ...
>  DbgPrint("old : %x %x %x",old_stack[0], old_stack[1], old_stack[2] );
>  ...
> }
>
> test.c:
> int do_monitor(const char *str)
> {
> ...
> for(i=0; i<sano; i++)
>   args[i]=rand();
>  printf("calling params : %x %x %x", args[0], args[1], args[2]);
> ...
> }
>
> Ceea ce ma intriga, este faptul ca functia originala a apelului de sistem
> returneaza OK, ba mai mult, daca interceptez sa zicem
> NtOpenFile sistemul functioneaza corect ( pot deschide fisiere ), ceea ce
> ma duce cu gandul ca, driverul functioneza corect.
> (Am incercat sa "stric" interceptorul in mod deliberat, spre exemplu sa nu
> adaug 8B la ebp si evident sistemul nu a mai functionat)
>
> Orice idee e binevenita.
>
> P.S Mai am o intrebare in legatura cu test.exe, in special la functia
> find_log(). Momentan pe masina virtuala test.exe se blocheaza
> la primul test interceptor, care am vazut ca duce in final la
> find_log(). Am remarcat ca find_log are un while(1) din care nu iese decat
> daca gaeste logul corect in event log si sunt curios daca acesta e
> comportamentul normal sau imi scapa mie ceva.
>  Pe site, tema da timeout si cred ca tot acolo se blocheaza.
>
> Multumesc,
> Alex
>
> _______________________________________________
> pso mailing list
> pso at cursuri.cs.pub.ro
> http://cursuri.cs.pub.ro/cgi-bin/mailman/listinfo/pso
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://cursuri.cs.pub.ro/pipermail/pso/attachments/20080405/7b4234c4/attachment-0001.htm