Español | English
rss facebook linkedin Twitter

Protección del software (Parte VII)

Siguiendo con las técnicas antidebug, pensemos en qué más cosas podemos tratar de detectar.
  1. Si estamos siendo depurados
  2. Si se está ejecutando una aplicación no deseada
  3. Si se tiene instalada una aplicación no deseada
  4. Tratar de evitar el attach del proceso desde un depurador
Personalmente el uso de las técnicas comentadas en los puntos 2 y 3 no me parece ético en el ámbito del software comercial, ya que el ejecutar ciertas aplicaciones (y aún más el hecho de tener aplicaciones instaladas) no incumbe al creador de software, pero son técnicas muy utilizadas. Veamos algunos ejemplos:

Tratar de saber si estamos siendo depurados:
  • IsDebuggerPresent, CheckRemoteDebuggerPresent.

  • Consulta de ciertos valores dependientes de la presencia de un depurador, como NTGlobalFlag, valores devueltos por NtQueryInformationProcess, etc.


  • Protecciones de tiempo: Esta protección, menos técnica, trata de averiguar el tiempo que se tarda en ejecutar cierto código, ya que si el tiempo es muy elevado se puede suponer que se ha detenido la ejecución y, por tanto, está siendo depurado. Existen varias maneras de obtener el tiempo transcurrido, con GetTickCount, QueryPerformanceCounter, rdtsc o GetProcessTimes.

  • Excepciones. Si el programa levanta una excepción, el depurador por defecto detiene la ejecución y la maneja, de tal modo que la ejecución continúa en la instrucción siguiente. Por contra, si el propio programa instala un manejador de excepciones, podrá redigir el flujo a donde desee. Podemos utilizar SEH (Structured Exception Handler) o VEH (Vectored Exception Handler).


  • Comprobar que el proceso padre no sea un depurador (o esperar que sea explorer.exe)


Buscar aplicaciones no deseadas en ejecución:
  • Por ejemplo, mediante el título de las ventanas

  • Mediante el nombre del proceso

  • Mediante un patrón de bytes

Buscar aplicaciones no deseadas instaladas: Existen diveros métodos, como buscar ficheros conocidos en rutas concretas o entradas de registro conocidas. Cualquier característica que identifique el software nos puede servir pero, como hemos comentado al inicio, no es una actitud muy recomendable.

Tratar de evitar el attach del proceso desde un depurador:
  • Apertura exclusiva: Se realiza una apertura exclusiva del fichero.
  • Sobreescritura de API. Una manera poco elegante puede consistir en sobreescribir alguna API que sepamos que se va a ejecutar.

Existe además algún truco para intentar cazar al atacante cuando no se lo espera, como puede ser la introducción de código en callbacks TLS, tal y como se puede ver en alguno de los primeros retos publicados, de tal manera que este código se ejecuta antes que la supuesta primera instrucción del programa.

Recordad daros una vuelta por Securityfocus para ver alguno que se me haya escapado ;)

Mikel Gastesi
S21sec e-crime

6 comentarios:

number_binario@hispavista.com dijo...

Pero si estos trucos son más viejos que la polca!
Por Dios si esos trucos ya están super-trillados!

Sigo pensando que es una pérdida de tiempo el meter trucos "ANTI" lo que sea.

Lo que hay que hacer cuando uno hace una protección es hacer algo "diferente" y no "reinventar" la rueda una y otra vez.

O si "reinventas" la rueda no vuelvas a caer en los mismos errores de siempre o en los errores de diseño de siempre.

Además de que sirven los anti-dbg?
Si al final te puedes construir un un pequeño loader/debugger privado y por mucho anti-dbg que le metas no te servirá de nada.

Además que esos tricks de los que hablas con un debugger a nivel de kernel tipo Windbg no sirven absolutamente nada.

Por favor seamos serios!!

Iñaki dijo...

Cierto, number_binario tiene razón y por eso nos va a demostrar a que se refiere.

Deja de hacer demagogia y demuestra, number_binario, que aunque tu no sepas programar eres capaz de hacer una protección nueva, o dejanos mientras tanto a los demás disfrutar de la lectura, que aunque sean temas viejos no deja de ser útil recordarlos.

--Lo que hay que hacer cuando uno hace una protección es hacer algo "diferente" y no "reinventar" la rueda una y otra vez.--

Cuantas has hecho tu en tu vida? una o ninguna?

sin acritud..
:)

S21sec e-crime dijo...

Hola,

Como dices, no son trucos nuevos, y como comenté en la entrada anterior, me gusta llamarlo "trucos" porque hoy día no son de mucha utilidad.

Más sencillo que un loader-debugger puede ser añadir un plug-in al depurador (hablamos de Olly, ring3) y te calzas casi todas las comprobaciones.
Te recuerdo que esta serie de post no pretende ser una guía de protección, sino un repaso de lo que nos podemos encontrar.

El blog lo lee gente muy diferente, y estos post no están orientados a gente con mucha experiencia en el reversing, ya que seguramente no les aportarán nada nuevo, pero pretende aportar ideas para los que no lo son.

Saludos,

Mikel

number_binario@hispavista.com dijo...

Después de releer mi mensaje creo que si puede ser que me haya excedido un poco :) por lo cual pido perdón al creador de la serie de artículos ya que no era mi intención meterme con el trabajo de nadie.


Lo único que diré en mi defensa es que estoy un poco cansado de que la gente que supuestamente "trabaja" y "vive" de esto parece ser que son los que más saben como el amigo Iñaki que ya sea dicho de paso trabajará para alguna empresa AV.

Y sin ningún tipo de acritud por favor Etxebarria :) que en este mundo nos conocemos todos xD y varios hemos trabajado en el sector por eso sé de lo que hablo.

Y eso de que no sé programar si tú lo dices será verdad,no voy a entrar a discutir en este blog sobre ello.

Y ya por último lo del tema "ruedas" creo que no has captado el mensaje señor Etxebarria ya que mí "tirón de orejas" iba para los programadores de protección de software y no para el autor del artículo.

Y como siempre como he estado en el sector también de la protección de software sé de lo que hablo por lo que alguna rueda si que creo haber creado o por lo menos haber tapado varios parches :)

Y ya por último un buen ejemplo de "reinvento" de la rueda tienes a armadillo que desde hace años ya, no le pega un labado de cara a su protección.

Ahora que el autor ha explicado a quien iba destinado esta serie de artículos puedo entenderlo mejor.

Por lo tanto por mi parte queda todo aclarado


PD: Sobre los plugins que hablas es verdad (casi todos se basan en un pequeño driver)pero al ser públicos es fácil añadirles soporte.

number_binario@hispavista.com dijo...

Una cosa que se me olvidó comentar xD

Señor Iñaki Etxebarria
pregunta a un ex-programador de armadillo (Nicolas Brulez)a que se dedicaba casi todo el tiempo en su etapa anterior (Se cambió a detectar vulns y análisis de malware ya que dá mas dinero xD)

La respuesta es muy sencilla

Dar soporte de compatibilidad a sus clientes e insluo aun seguían dando soporte en Win 95.

Y la protección mejor no tocarla ya que si no luego las cosas no funcionan xD

En fin que vida más triste como el videoblo xD

number_binario@hispavista.com dijo...

Aunque lo mismo eres López y no Etxebarria xD por lo de "Técnicas anti-debugging"
I don't know


(+34 902 222 521)


24 horas / 7 días a la semana



© Copyright S21sec 2013 - Todos los derechos reservados


login