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

[Alex Drenea]

Salut,
 In functia in care marchez apelul ca interceptat, nu modific decat campul
"st" al KeSDT si de aceea nu cred ca e o problema la dimensiunea
parametrilor. Am sa ma uit totusi inca o data desi, nu cred ca e de acolo.
 Am afisari si in functia find_log() inainte de acel memcmp si parametrii
care se asteapta el sa ii gaseasca sunt (evident) cei care i-a generat mai
devreme in do_monitor, iar parametrii care ii gaseste sunt chiar cei care ii
prind eu in genericHander()..




2008/4/5 Cristi Lazea <cricotanierea at gmail.com>:

> 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
> >
> >
>
> _______________________________________________
> 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/490d7bd6/attachment.htm