Mensajes

Lo último: perdonad si he sido hiriente o similar. No era esa mi intención.

Mi respeto sincero para todos. Un saludo.

No hace falta que me des más avisos. Me voy del foro, ya veo lo que hay aquí.

Si se me permite hacer dos últimos comentarios:

1.
Me dice burbu_1 que Panda de españoles lo justo.
Bueno, si tus opiniones sobre el tema virus-antivirus están tan fundadas como tu comentario... mejor no digo más.
Tan sólo esto: échale un vistazo, te vendrá bien actualizar tus conocimientos:
http://es.wikipedia.org/wiki/Panda_Security

2.
Karcrack: ¿utilizar la palabra virus para un código que no se replica? ¿virus para referirse a malware genérico? Pensé que aquí se hablaba con propiedad y conocimientos, dado que esto se supone es un sitio que se hace llamar "elhacker". Y segundo: ¿la complejidad del cifrado no es tan importante? Vale, vale... lo que tú digas. Aquí lo dejo.

Para 0xDani:

De los códigos que yo haya hecho no te voy a decir nombres concretos. Tú puedes pensar lo que quieras. Pero en general tan sólo te digo que he hecho motores polimórficos, EPO, anti-debugging, ..., y todo precisamente en el área de la programación de virus-antivirus.

No creo que sea yo precisamente quien me tenga que pasar por ninguna área de criptografía, cuando me están intentando colar una rutina xor con una "seed" (vaya novedad) y un PRNG (Pseudo Random Number Generator) (vaya otra gran novedad), como compleja rutina de cifrado.

Os di un link de un artículo (lo siento no estaba en español, era en inglés), sobre cifrado de virus, y además cifrado de la buena y compleja, empleada en algunos de los virus más complejos en cuanto a cifrado se refiere: W32.Magistr, W95.Perenast, W32.Efish, etcs : polimórficos todos, alguno incluso metamórfico.

http://www.thehackademy.net/madchat/vxdevl/papers/avers/x-raying.pdf

Si me queréis decir que vuestro nivel en criptografía y vuestras rutinas de cifrado superan el de ese artículo, os felicito y me como mis palabras.


Para APOKLIPTICO:

De lo último que un AV va a mirar son los strings que estés utilizando. Y lo primero que va a mirar es tu código binario. Y es en ese código binario donde primero compara patrones (cadenas de malware conocidas), y después (si lo considera) aplica emulación.

Te quiero decir con esto que cifrar tus strings es muy poca medida contra un AV.
Por mucho que cifres tus strings (por ejemplo las APIs de las DLLs que utilices), en la emulación serán descifrados (tu propio virus las descifra para utilizarlas, por mucho que estén en la pila o en Hong-Kong ¿lo pillas?, y todo en tiempo de emulación AV sin que se ejecute realmente tu virus), y si tu código binario es sospechoso: (abrir ficheros, que sean ejecutables, manipular la memoria, ...), el AV saltará.

Si intentas cifrar/cifrar algo, que sea todo tu código en todo caso, no tanto sólo unos strings que haya en él.

Por cierto, sigues hablando de tu "virus", estoy confundido, por eso te pregunté: ¿un virus en C? ¿o sea que tu programa infecta otros programas?

También podrías empezar por definir qué hace tu virus: si infecta qué infecta, cómo se propaga, si es residente o de acción directa, ... Porque si resulta que no hace ni la mitad de lo anterior, pues normal que tan sólo cifrando unos strings no sea detectado como programa sospechoso.

APOKLIPTICO: No lo pillas. Estás utilizando cifrado, simple no, muy simple. Aunque tú sigas diciendo que es compleja y hables de clave seed, PRNG, y etcs.

Estás muy equivocado cuando dices que los antivirus no son tan complejos. Por poner un ejemplo, los emuladores de código que usan los AV son de lo más complejo que te puedes echar a la cara.

Dices que no necesitas un virus que sea completamente indetectable para siempre. No desde luego que no. Porque no existen.

Y dices que uno simplemente que sea indetectable por heurística y emulación de código. Pues para eso empieza por estudiar polimorfismo y técnicas como EPO, etcs. Porque con tu rutina XOR no tienes ni para empezar.

Y si te da por pensar que digo estupideces, pues ¿por qué no demuestras lo que dices con hechos?: O sea puedes poner en el post el código ASM de cifrado que genera tu rutina de cifrado XOR, y ya veremos lo "compleja" que es. Y si no sabes ASM (por cierto mal si quieres hacer virus (serios) ), entonces pon al menos el código fuente de tu rutina C que realiza la cifrado.

Y ya para terminar, como estoy casi seguro que al final dirás "ya lo conseguí", pues puedes mandarme el EXE de tu virus, y yo le meto el debugger y veré el nivel de tu super rutina de cifrado XOR con su seed y su PRNG y sus etcs, además de comprobar que realmente es indetectable por los AVs.

Te digo que el nivel que aplicas de cifrado es pobre si lo que quieres hacer es un virus como dices que sea indetectable por heurística y emulación de código.
Pero bueno, tú sigue con tus planteamientos. Eso sí: seguro que ni pones en el post el código ASM de cifrado que genera tu rutina XOR, ni pones el código fuente C de la función con la que haces la cifrado, ni tampoco me mandarás el EXE si lo terminas y dices que ya nadie lo detecta. ¿Sí o no?

Sí significa detección segura, o más bien saltar alarma de código sospechoso.

Pero es que antes de llegar al delta offset, que eso está dentro de tu código del virus, el antivirus y sus módulos como el emulador, ya te han chequeado unas cuantas cosas antes: como por ejemplo en qué sección (primera, última, ...) (.text, .data, .rsrc, ...) del ejecutable (infectado) se está ejecutando tu código, qué atributos tiene esa sección, si hay alguna rutina de descifrado, ..., etcs.

O sea tu delta offset sería uno de los últimos datos que el antivirus vería para concluir que ahí en ese ejecutable hay algo muy sospechoso.

Despues de leer esto, voy a poner el punto newbie xD. Si nada mas empezar, hago algo como esto:

Código (asm) [Seleccionar] Expandir

call delta
delta:
pop ebp
sub ebp,delta
El clasico delta, significa deteccion segura no?

Gracias por tu respuesta y por los enlaces que me dabas. Parecen interesantes y parece que me pudieran servir.

Ahora no tengo tiempo para empezar a probarlos, etcs. Tengo exámenes de universidad en poco y estoy con ellos agobiado y hasta las narices.

Pero recojo lo que dices y cuando dentro de un tiempo (unos meses) les eche un vistazo, si llego a algo, os diré y comentaré.


Todo ha sido que desde hace un tiempo estoy buscando la manera de poder volver a tracear en RING0 como hacía hace años. Pero ahora el Windows 7, porque paso del ME, XP, NT, ... Quiero conocer lo nuevo y último.

En cuanto a expertos, yo no me considero experto.
Sino solo que algo hice en el pasado, y en el presente quiero retomarlo y hacer más. Eso es todo.

Gracias de nuevo por tus respuestas. Un saludo a todos.

Esa idea está muy bien. Yo mismo la pensé hace tiempo. Pero en mi opinión, para llevarla a la práctica, en primer lugar has de generar código polimórfico. Si es sólo cifrado=código fijo, entonces no tardarán nada en pillar tu rutina y se la saltarán de inmediato, incluso desde el primer momento en que hagas tus pruebas en tu casa con los AV probando en tu ordenador.

Y en segundo lugar, siendo polimórfica=variable=distinta cada vez, debes crear: bucles, llamadas, etcs, ..., lo suficientemente complejas en su estructura como para que el emulador "se las trague" y las emule pensando que es código legítimo, porque de lo contrario no te las va a emular, y por tanto no perderá ese tiempo que quieres que pierda con tus rutinas de sistema anti-emulación.


La idea que dices es la complejidad temporal. Los emuladores tienen un quantum=fracción de tiempo, para emular cada fichero que consideran sospechoso. Si mientras emulan, ese quantum es superado, y a la vez no han dado con una identificación positiva como que ese fichero es sospechoso, entonces lo dejan y pasan al siguiente. La técnica es atacar la complejidad temporal del emulador. Y para ello como dices, hacer que dé vueltas y vueltas en tu rutina, hasta que "se aburra", y deje el fichero. Pero eso no es fácil de implementar. Prueba y verás. Si no sabes hacer código polimórfico, entonces en mi opinión poco puedes hacer. Y para hacer código polimórfico, has de programar en Ensamblador, el C no te sirve para nada para eso. Saludos.

El tema es que me parece que cuando escaneas, el emulador se toma todo el tiempo del mundo para emularlo. El problema es que mi sistema anti-emulacion se basa en hacer que el emulador tarde demasiado tiempo en analizarlo y lo descarte. Debería hacer algo que el emulador no pueda emular y entonces detectarlo de esa manera...

Tu "cifrado" que lo tienes por no simple, te digo que sí es simple. Vamos, yo diría que muy simple.

No es polimórfico, es simple cifrado. Además, aún siendo cifrado, no son distintas capas de cifrado una sobre otra, sino sólo una. ¿Me equivoco o te entendí mal? Pero es que aunque fueran varias capas de cifrado, cosa que no es tu caso, de poco te iba a servir ante los emuladores: lo pillan aún con varias capas.

Resumen: Tu cifrado es simple: una sóla capa. Es cifrado, no polimorfismo: o sea tu operación es siempre la misma: XOR en tu caso (además la clásica y más usada). Y lo único que varías es la clave con que cifras esa XOR, que aunque fuera de 32 bits es totalmente pobre ante un emulador.

Te repito que un emulador te lo pilla rápido. Los emuladores no analizan todo el fichero, sino sólo partes sospechosas. A veces ni siquiera necesitan descifrar todo el fichero (la parte que esté cifrada), ni si quiera todo tu virus, sino tan sólo una parte. Y con eso solo ya saltan.


Y finalmente: te diría que para mí el que te lo detecten es por:

1. Tu propia rutina de cifrado, que es el típico bucle loop XOR de los antiguos virus cifrados simples, (rutina por cierto que hoy día ya casi ni se utiliza (o al menos sola), de lo vieja y conocida que es). Eso mismo: tu rutina, ya les hace saltar. O sea lo que utilizas para que no te detecten, eso mismo les sirve para detectarte, al menos ya como código sospechoso.

2. Y aún más seguro: En tu código, ya plano descifrado, debe haber unas cuantas cadenas=patterns que corresponden a otros malwares, más si lo tienes escrito en C, ya que C utiliza=compila según qué trozos de código, de la misma manera siempre igual. Mira como cada AV te da como distintos malware tu virus= te lo confunde con distintos otros programas malware.


Puedes probar a:

1. Quítale tu rutina de cifrado XOR. Deja tu código plano.

2. Comenta y Descomenta, trozos de tu código, y luego compila, ..., y luego pásale los AVs, ..., prueba... , y es posible que veas que alterando tu código plano, o sea quitando o poniendo según qué partes, los AVs te seguirán saltando o te dejarán de saltar.


Además: ¿hablas de virus? O sea que tu programa INFECTA otros programas. ¿? ¿Y en C? Lo dudo. No lo veo. Explica un poco qué tipo de programa es el tuyo. O es simplemente un worm sencillo en C que se automanda por email, ¿o qué?

Otras cosas que comentabas, que no te siente mal, perdona pero se ve que no tienes nivel, no al menos el suficiente. Por ejemplo cuando dices que las funciones de las DLL que importas las tienes encriptadas. ¿Y qué? ¿Que las sacas dinámicamente? Eso no es nada nuevo, técnica que tiene al menos 10 años.
Y además eso no tiene relación directa con no ser detectado. La detección está en primer lugar en tu código ejecutable, aún antes de ser ejecutado. Y si te lo emulan, al ejecutarse, antes de llegar a ejecutarse las funciones de tu virus como el de obtener las API de las DLL que necesites, están muchas otras cosas, como por ejemplo tu rutina de cifrado, que a todas luces parece un: "¡hey Antivirus, que soy un virus!": o sea más que esconder código, llama la atención como rutina  sospechosa.


Mira: el tema de la cifrado, polimorfismo, metamorfismo, ..., no es sencillo.
Si pretendes hacer una rutina de cifrado, que haga que tu código, de momento, pase desapercibido sin ser detectado, tendrás que estudiar bastante más, yo diría que mucho más, que el nivel que tienes con tu bucle XOR.

Como ejemplo, aquí tienes un artículo COJONUDO sobre el tema:
http://www.thehackademy.net/madchat/vxdevl/papers/avers/x-raying.pdf

Y aún siendo COJONUDO, a la vez te digo que ya está algo desfasado.

Aún así si lo lees=estudias, comprobarás que virus mucho más complejos que el tuyo, pero mucho más complejos, como el Magistr, (ya por cierto viejo, muy viejo), tenían técnicas de cifrado polimórfica que le dan 1000 vueltas a la tuya, y aún así fueron cogidos=detectados al poco de salir.

Un saludo. Y no por ello te desanimes. Está genial que estés en este tema. Muchos ingenieros informáticos con título, no saben ni hacer un volcado de memoria. Son ignorantes con título. Lo suyo es la administración empresarial usando un ordenador: las bases de datos, SQL, Visual Basic, etcs: patético.

Así que tú dale y ánimo con el SISTEMA y con cómo funcionan las máquinas, que es lo que realmente es la ingeniería informática, en este caso particularizando en el área de la seguridad.

Para karmany:

Perdonad si os sentísteis heridos con cómo preguntaba. Pero es que muchos van de "hackers" (hablo en general, no tanto de este foro) y lo único que hacen es nombrar cosas y programas y tutoriales, pero saber y hacer, saben y hacen poco. Por eso, como no sabía si era vuestro caso, pues os pude resultar "hiriente".

Me dabas un enlace para entender RING0.
Gracias, pero yo el RING0 ya lo entiendo. No es ése mi problema.
Sino el no poderlo tracear desde que se terminó la cosa con el SoftICE.

Decirte además que la mayoría de los artículos de ese enlace que me dabas, están desfasados, muchos de hace 5 o 10 años. Y por poner un ejemplo: los CallGates de los que hablan algunos de esos artículos, imagino que sean los antiguos de Win9X, cosa que para WinNT olvídate que no funcionan.

Gracias también por los 2 enlaces a kernel debuggers que me dabas.

El del syser lo conocía. Ya probé el syser en su día y no acaba de convencerme, pretende ser el sustituto del SoftICE y en mi opinión no le llega ni a la mitad.
Por poner dos ejemplos: no me funciona bien, medio se me cuelga, y por decir otra cosa: es que mientras estoy traceando la memoria de Windows = código ASM RING0 de algún driver del SO Windows, no muestra el nombre del driver en cuestión. Mientras que por ejemplo el SoftICE te mostraba en todo momento a qué modulo del SO pertenecía el código ASM que uno estaba recorriendo: (por ejemplo en Win9X) VMM, IFSMgr, ...

El del hyperdbg me parece que también en su día algo miré y no me acabó tampoco de funcionar o convencer. Pero como no lo recuerdo bien, voy a echarle otro vistazo. Gracias.

En general: Gracias por responderme.

PD: me quedo con ganas de poder hablar con algún programador de algún laboratorio de virus, por ejemplo de PANDA ya que son españoles, y que me digan tan sólo ese dato: CON QUE KERNEL DEBUGGER TRABAJAN. Porque yo usaría ese mismo, el que fuese. Si a ellos les sirve, a mí también.

Para MCKSys Argentina:

Los 3 links que me dabas los conocía los 3. De todas maneras, gracias.
Sin embargo esto otro que me decías: "gdb server de vmware y depurar el kernel del SO virtualizado", creo que no lo conozco y le echaré un vistazo. Gracias.

También deciros (sin ironía) que a pesar de sentiros ¿insultados? por mi post, gracias por responderme.

Lo último: sólo decirte que estás comparando usar el OllyDbg en RING3 con usar el SoftICE en RING0 diciendo que el asunto está al mismo nivel. Pues aunque te sientas "¿herido?" te vuelvo a decir que sí: (perdonad) pero OllyDbg (o cualquier otro) en RING3 es mariconeo al lado de un kernel debugger en RING0.

Depurar un programa lo sabe hacer casi cualquiera que sepa programar, mientras que entrar en las partes del SO y depurar drivers RING0 tanto personales como del SO, sólo lo sabe hacer quien conoce cómo está escrito el SO y lo ha traceado y modificado, cosa que la inmensa mayoría de los programadores que se quedan en el OllyDbg (u otros debuggers RING3) no saben ni sabrán nunca hacer. Comparar el RING3 con el RING0 y encima ponerlos al mismo nivel, no es de alguien que se supone sabe.

Saludos.