Pato aventura : Analisis de un virus en frio…

Hola:

les voy a contar mi ultima pato aventura..

Ddaz.mode=Daniel

hoy en la mañana me llego un email, de esos típicos que te dicen que alguien te envío una postal… 

a diferencia de antes cuando enviaban este tipo de emails  de alguna cuenta inventada, que podía ser fácilmente marcada como “no deseado”, están enviando estos emails de la cuenta “info@hi5.com” que esta tomada como “cuenta normal” y a casi nadie le llega a la carpeta de “correo no deseado” – lógicamente fue enviado desde un lugar que no es el verdadero…  en teoría el email viene desde el dominio metropostales.com, y el que envió el email no es el mismo dominio

email

lo primero que suelo hacer en este tipo de casos es ver el encabezado del email, en hotmail – o live mail – pueden darle con el botón derecho al email y seleccionar “ver código fuente”, les dejo  la imagen del encabezado, no borre las direcciones ni dominios originales – para que vean quien  fue el que lo envió… –

header

Al ver este tipo de datos  en la cabecera del email es posible estar seguros a un 99.9%  de que es un email falso,  al dar clic al vinculo – no pude resistirme – me di cuenta que descargaba un archivo que tenia un icono de un circulo y decía claro –si, el de una empresa de telefonía que funciona en Perú –, en este momento ya estaba totalmente seguro que era un virus, solo que aun no estaba muy seguro de que sea de Perú. 

icono

en esta ocasión hice lo que siempre hago – soy partner de ESET,si  los del nod32 –,   y les envío de vez en cuando alguna muestra de virus que encuentro – bueno tbm me gusta coleccionarlos,  quien sabe, quizá algún día los ocupe –, lógicamente al ser domingo es lógico que no respondan rápidamente, así que decidí esta vez analizarlo un poquito,

luego me puse a ver las propiedades del archivo  y pude ver esto :

propiedadesarchivo

Al ver estos datos pude ver que el que creo el virus no es tan metódico, ya que dejo demasiadas cosas sueltas como el nombre del proyecto “Proyecto1” ,  y el archivo  original se llamaba formulario.. e visto virus mas elaborados y no se saltan este tipo de detalles.

el segundo paso era saber con que fue compilado – en que lenguaje se hizo –, para esto use la herramienta “File Inspector XL”, el cual pueden descargar desde esta web http://www.exetools.com/file-analyzers.htm , dándome como resultado :

headerfile ya con esto pude saber que lo hicieron con Visual Basic  –  donde están los que dicen que el VB no sirve ? –

ya sabiendo esto, solo tenia que buscar el descompilador – o desensamblador –  adecuado, ya que  no todos los desensambladores funcionan con todos los ejecutables, en este caso use 2, uno es el VB decompiler lite  y el otro fue el W32DASM – con un parche para referencias VB –, y las imágenes que salieron fueron:

vbdecompiler

de esta imagen algo que destaca es “MicrosoftUpdateManager”  suena a la ventana de Windows update, pero no dijo mucho, así que me fui con el W32DASM.

w32dasm al abrir el archivo con el w32dasm,  y luego ir a la sección de “String references” salieron estos datos – cadenas de texto usadas en el programa  y que  pudo analizar el de compilador, en frio, vienen datos como :

  • “load=C:windowssystem32updmngr.exe”  que debe ser el nombre de como se instalara el Virus, y esto se podría ver luego en el msconfig.
  • “http://minux2010.no-ip.org” este es el sitio donde el virus envía /recibe información.
  • “c:windowssystem32driversetchosts” este es un archivo de sistema que guarda unas urls en cache de la pc… el virus – como muchos – infectara la pc,  lo mas común es para que cuando uno abra una ventana del navegador, automáticamente se conecte allí.
  • En la imagen se ven algunas secciones como <PRE> y </PRE>  así que de aquí se puede suponer que mostrara una ventana con algo de código HTML.

 

todo esto aun sin analizar en código ensamblador mostrado – que tomaría algo mas de tiempo – y bueno, al menos por ahora es suficiente, ya que es un analisis simple, sin tener que ejecutar la aplicación.

intente correr el programa en una pc virtual con Windows 2003 y en mi pc host con Windows 7, pero como no tenia las librerías de VB6 – msvbvm60.dll – , salió un error y el virus no funciono uhh que pena – si alguien quiere el virus, se lo puedo enviar por email – si es que me lo pide… lógicamente-

Quería enviarles un screenshot de la ventana del virus… pero al menos por ahora aun no me animo a descargar la dll que hace falta, para poder abrirlo….

lógicamente no mostré mucho sobre el desensamblado – cosas que mostrare en un futuro  – , el w32dasm pueden encontrarlo en “Crackerskit 2” – googleando lo encuentran – o  tbm en esta pagina http://www.exetools.com/disassemblers.htm .

Se que esto no tiene nada que ver con .net… pero recuerden que “No solo de .Net vivirá el hombre, sino de todo código que sea escrito y sea funcional.”

con esto respondo el pedido de Ebersys

Ddaz.mode=Dacito

Salu2 

Ddaz

Mi Opinión y Experiencia Personal sobre TDD – y de por que NO estoy MUY de acuerdo con el –

Estoy últimos días e visto platicas, post ( uno de ellos es este )   y mensajes en el twitter sobre cuestiones “agiles”  y temas afines, aunque un tema en particular atrajo mi atención, es sobre TDD o  como algunos lo conocen, y ya no pude evitar querer dar mi opinión al respecto; aunque antes que nada me veo obligado a dar unas premisas, en las cuales basare mi “punto”

Premisas ( o como las quieran llamar)  :

  1. No todos los Programadores tienen el mismo Nivel : Esto es conocido por todos, aunque no aceptado públicamente – cuestiones de orgullo –,  así como hay programadores que no necesitan documentación – un amante de gnu por allí de ejemplo? –, y otros que no necesitan pruebas unitarias para hacer programas con cero errores o quizá un numero mínimo de ellos… así también hay programadores, que con toda la documentación, capacitación y pruebas unitarias les falla la aplicación.. causas?  quizá algún gen maligno, magia negra, el chupa cabras, la CIA interfiriendo nuestras ondas cerebrales con algún aparato electrónico a lo “Agente 86”… o quizá algo mas de experiencia y aprender de los errores pasados sumado un poquito de mucho estudio y practica.
  2. Que exista cierta metodología o proceso, implica que hay personas a las que SI les funciono, pero no significa que a todos les funcionara. que exista RUP, SCRUM, etc. significa que hay personas a las que siguiendo los pasos que le fueron indicados, tuvieron éxito en lo que buscaban, pero esto a su vez no implica que a todos les ira bien, posibles factores son muchos –
  3. Las Metodologías, técnicas, etc., no son Leyes : aunque suene feo, si obviamos usar determinada metodología “así tal cual viene en la caja”, si evitamos usar rup, scrum, etc etc etc.. esto no implica que nuestro software tenga muchos errores, o no sea optimo, las metodologías solo son una guía en la cual nos podemos basar para intentar tener un buen resultado con un mínimo costo / tiempo, OJO no estoy impulsando a no usarlas, solo quiero aclarar que no es un pecado capital “el no usarlas”, lógicamente que es como el juego de la ruleta rusa, nos puede ir bien  o nos puede ir mal, personalmente no soy de los que usa algo “tal cual viene en la caja” sino que lo personalizo hasta poder sacar el máximo rendimiento.
  4. Un Programador no piensa igual que alguien involucrado a fondo en el área de pruebas – a menos que tenga extrema experiencia en el tema-  :  en este punto e tenido algunas discusiones – muy placenteras – con algunos colegas; tengo algunos años – no muchos  si los comparo con algunos de los maestros que rondan por aquí en geeks.ms – e trabajado junto  a desarrolladores de al menos 2 países ( Perú y México) y con mas de 6 años de experiencia en pruebas, y e podido constatar – eso sin tomar en cuenta a lo que ya dicen muchos  respecto al tema –, que la forma de pensar de un programador “promedio” – ojo con la premisa 1 –  su forma de ver las cosas es como “construir” algo, su mente este abocada a armar software y es muy difícil – por no decir casi imposible – en pensar a fondo en pruebas, lógicamente se le ocurrirá una que otra, de cosas simples o básicas, pero no de las que son a profundidad;  a diferencia de alguien involucrado en pruebas – y no me refiero a los pica botones – en el cual su mente esta abocada a “Destruir” y pensar en como destrozar algo que otro realizo, se que muchos me dirán que no es cierto, pero e realizado la prueba con muchos programadores -soy del tipo que le gusta hacer experimentos son la gente- y los resultados fueron muy claros. Lógicamente hay personas con algo de experiencia – y que no tienen perdida de memoria –  y con el transcurrir el tiempo van pensando en pruebas cada vez mas complejas, lamentablemente este ultimo grupo es muy reducido. – no me extiendo mas, sino me auto robo el tema del siguiente post, que espero sacarlo ahora si –
  5. Una prueba unitaria básicamente es: probar que metiendo A datos a X función me devuelva Y; pero esto no implica que si meto B me devolverá Z:  el titulo habla por si solo, me extenderé en esto mas adelante.
  6. Basarse “solamente” en una forma de medir el software  puede ser tu perdición : aquí es simple, el usar “solo X” puede ser la causa que un proyecto se venga abajo, ya que en el software interviene el factor humano, el cual  es capaz de romper cualquier regla, en otras palabras, el hombre esta aplica principio de incertidumbre de Heisenberg, y por lo mismo quizá una forma única de ver las cosas nos diría que estamos en lo correcto, mientras que otra medida nos diría que no. ( al hablar de medidas me refiero a pruebas )

 

Veamos ahora algunos puntos acerca de TDD – por comodidad me fusilare los pasos descritos en wikipedia

  1. Escribir El Requerimiento.
    • Esto es algo que se repite en cualquier metodología/ y forma de trabajar, el error en este punto varia directamente proporcional al que recoge los requerimientos… aunque de aquí depende mucho  el avance del proyecto, sobre que tantos y que tan buenos fueron los requerimientos recogidos –aquí hay material para extenderse otro post –
  2. Escribir las Pruebas.
    • Bueno:
      • El fin aquí es escribir el menor código “funcional” – de la app – al hacer que el programador se dedique a generar código que pase las pruebas,  estas pruebas están basadas en los requerimientos establecidos, aquí el nivel de efectividad depende de la calidad de requerimientos.
      • El echo de escribir la prueba antes que la funcionalidad, nos abre un poco mas la vista sobre que es lo que realmente necesita la aplicación de acuerdo a determinado requerimiento – ya que hay casos en que el error es que simplemente no se entendió bien el requerimiento –.
      • Cuando hay cambios en la aplicación,  se puede correr las pruebas y verificar que la aplicación “aun” supere las pruebas.
      • Las Pruebas unitarias no son el chupa cabras : algo que es absoluto es que Si o SI se tienen que hacer pruebas a la aplicación, ya sea antes o después – como puso Rodrigo en este post , aunque para algunos, escribirlas después hace que ya NO sea TDD-; personalmente las prefiero después.
      • Muchos de los beneficios los integro Ibon Landa en varios links de  este post, que seria bueno que lo vean.
    • Malo:
      • El Echo de que TDD pida que se hagan las pruebas antes, implica que el programador hace tareas de el encargado de pruebas : algo que se puede subsanar dando las pruebas para que lo realice una tercera persona, o se realicen luego de escrita la funcionalidad, lo cual podría traer líos con los puristas de TDD
      • Algunas veces para intentar cubrir todo, se crean requerimientos redundantes, que traen a su vez  pruebas redundantes, lo que implica una perdida de tiempo que se puede entender por perdida de $$.
      • En Algunos casos las pruebas terminan siendo mas complejas que la funcionalidad en si, haciendo que mas que una ayuda, sea un lastre para el proyecto – ojo que no es en todos los casos-
      • Muchas personas – no aplica en todos los casos – consideran que es una perdida de tiempo escribir las pruebas antes que el código, esto también depende de la pericia del programador y a como este acostumbrado a trabajar, personalmente no soy “fan” de escribir las pruebas antes, aunque si me gusta desde la etapa de requerimientos, definir las pruebas que debería pasar la aplicación.
      • que tenga 3000 ( o mas ) pruebas unitarias, no implica que este tomando en cuenta la totalidad de “posibilidades”, ya que una cuestión es probar valores puntuales en funcionalidad puntual  y otra muy diferente  tomar valores y estados en conjunto, ya que por ejemplo tomando un universo de 10 variables, estas 10 independientemente pueden funcionar a la perfección, pero en conjunto, en determinada situación pueden causar un error, que quizá no será un error de aplicación, sino un error de lógica y a su vez obtener valores erróneos,
      • Trabajar con demasiadas pruebas puede hacer que uno caiga en la desesperación como en este caso , que por cierto tiene gran  parte de razón, ya que las pruebas se pueden extender infinitamente, y un proyecto que pudo desarrollarse en 3 meses podría extenderse 2 años por el puro echo de ir programando pruebas, a la hora de hacer las pruebas, hay que saber en que punto detenerse.
      • Algunas personas llegan a creer que por el echo de que la aplicación haya pasado las pruebas unitarias significa que ya esta lista para irse a producción: Lamentablemente aun hay personas y empresas, que toman a menos a los encargados de pruebas, quizá  por que en muchos casos se contrata a  personas sin – o muy bajos – conocimientos técnicos y esto hace que los programadores y jefes de proyectos tomen a menos a los del área de pruebas. – aunque si hay casos en el que el razonamiento es justificado –; esto sumado al ego – si, ya se, estoy desvariando, los programadores no tenemos el ego grande, ni tenemos complejo de todopoderosos, son alucinaciones mías –, han llegado al punto de hacer que en ciertos casos los programadores minimicen o ignoren errores reportados – me consta- , los cuales luego tronaron – fallaron – en producción y trajeron muchos dolores de cabeza, este tipo de problema es algo complejo de resolver, por que escapa a lo “profesional” y se va a lo personal. algo que si es definitivo es que a pesar de todas las pruebas unitarias que le hagamos, aun la aplicación debe de pasar por un proceso de pruebas,  algo mas especializadas y quizá no automatizadas.
      • Las pruebas Automatizadas no aseguran que la aplicación este libre al 100% de errores :  ya que muchos de los causantes de sitios web hackeados, son por vulnerabilidades que las pruebas automatizadas no detectaron, sino miren el ejemplo de MS y que le paso por confiar en sus pruebas automatizadas , por eso es casi de ley hacer pruebas de esas que son basadas en el “ojímetro” – espero poder dar ejemplo prácticos sobre esto en un futuro no muy lejano – 
  3. Verificar que la prueba falla:
    • Aquí verificaremos que el error se presente… el problema es que pudimos habernos pasado unos 30 minutos o 1 hora escribiendo cierta prueba, que a las finales no falla, y no necesariamente por que la prueba este mal, lo que implicaría de nuevo una perdida de tiempo, aunque a su vez nos podría confirmar que X funcionalidad trabaja correctamente.
  4. Escribir la implementación:
    • aquí escribimos la funcionalidad de la aplicación, la cual deberá integrar  las validaciones necesarias  para poder superar la o las pruebas, en teoría – si estuviéramos en con Alicia en el país de las maravillas – la aplicación debería de funcionar sin problemas, la codificación de la aplicación debería de ser mínima, lamentablemente es algo que no pasa muy seguido a menos que el programador ya tenga una amplia experiencia,  lo cual nos saca del foco del “programador promedio”.
  5. Ejecutar las pruebas automatizadas:
    • Aquí la aplicación debería de pasar todas las pruebas, pueda darse que la aplicación pase las pruebas a la primera corrida, pero esto no implica que este libre de errores, solo indica que puntualmente la aplicación esta respondiendo  con determinados datos, pero no a todos
  6. Eliminación de duplicación:  aquí vamos refactorizando, algo útil, que a su vez es una inversión, este proceso no es malo, siempre y cuando se haga mesuradamente, ya que existen personas que se trauman demasiado con la optimización – si, ya se, estarán pensando “perro hablando de pulgas” – y hacen que se pierda demasiado tiempo en esto.
  7. Actualización de la lista de requerimientos: como el nombre lo dice, reordenamos los requerimientos y si es posible a repetir el proceso!.

 

Mi Experiencia Personal: no es exactamente TDD, pero usaron el modelo de pruebas.

Creo que ya lo conté en algún post…, no me canso de ponerlo, por el impacto del proyecto – de algunos millones de pesos – , erase un soft, al cual se le hizo un listado de requerimientos, y fue construido tal cual los requerimientos, el soft había pasado las pruebas planteadas en los requerimientos; si uno usaba el soft  tal cual indicaba el manual – las funciones puntuales trabajaban a la perfección – la aplicación funcionaba súper bien, el problema era cuando alguien daba un clic de mas, o presionaba en otro botón,  o hacia cualquier acción no contemplada en el proceso del manual de usuario; en ese momento la aplicación tronaba, fallaba,hacia BOOM…, no participe en la construcción de ese proyecto, aunque si en la destrucción – viendo como tronaba igual al pop corn-  cual fue su error? basarse “exclusivamente” en las pruebas echas en base a los requerimientos, y no ir “mas allá”  error en el cual algunos caen por que se confían demasiado en “las pruebas unitarias”, lógicamente esto también depende con que se cuente con un área de pruebas, ya que existen empresas en las cuales el programador tiene que hacerlas de tester, y eso puede volverse un gran problema.

 

Mi Opinión  y conclusiones :

El echo de que TDD exista, es por que hay personas a las cuales les funciono, pero antes que nada tenemos que tomar en cuenta el tipo de personas que lo usan, ya que de acuerdo al nivel de las personas, es que podemos hacer determinadas cosas, por ejemplo yo no podría hacer algo al mismo ritmo de alguno de los Scott – que salen por todos lados – , o un recién egresado a mi ritmo, por lo mismo no todas las metodologías funcionarían con todas las personas – por mas que la teoría diga que si se puede.

Escribir las pruebas antes que la aplicación, en la mayoría de casos – por no decir casi todos-, involucra que el programador realice funciones que no le corresponde, por eso mismo, personalmente prefiero las pruebas luego que el código de la aplicación y mas aun, prefiero que el que escriba las pruebas sea uno encargado de pruebas, así el programador se enfoca básicamente a programar la aplicación, aunque podría ir escribiéndose las pruebas y la aplicación en paralelo, esto depende de si se cuenta con personal capacitado para esto – si el de pruebas sabe programar pruebas, o solo es un pica botones –

Por que no estoy muy conforme con TDD? 

como ya lo puse, así como el modelo lo muestra, – y como es implementado normalmente- el programador tiene que hacer las pruebas y la aplicación, lo que implica  doble trabajo y hacer tareas que deberían tocarle a otras personas; estoy totalmente de acuerdo en que se deben de hacer pruebas, pero a mi parecer, lo debería de hacer alguien mas,  y mas aun que esta persona debe de estar integrada al equipo desde la etapa de diseño – esto es del siguiente post – . Lógicamente existen en nuestro medio personas excepcionales, que programan a una gran velocidad, y estas personas pueden programar pruebas y la funcionalidad  aun en menos tiempo, de lo que un programador promedio podría hacerlo, si esta fuera la situación,  que se da, en no todos los casos, pero se da,  allí no tendría ningún problema con que el programador haga las pruebas que quiera; pero lamentablemente esto no pasa en todos los casos.

Jorge Gamba me dijo vía twitter que BDD es mejor que TDD… ya habrá tiempo para opinar sobre eso.

Para terminar creo que TDD no es del todo malo, siempre y cuando se apliquen pruebas exhaustivas aun luego de que estas pasen las pruebas unitarias o pruebas automatizadas, confiar “solo” en estas pruebas unitarias, seria un grave error – se que Jersson dirá de que en TDD tbm se hacen pruebas – , el problema que hay es cuando personas con poca experiencia en el desarrollo de software usan esta metodología, es muy fácil que sientan que con las pruebas unitarias, ya tienen todo a la perfección y alli empiezan los problemas.

 

por si alguien quiere saber las mensadas que suelo poner – y que no llego a poner aquí por lo corto de las ideas, pueden encontrarme en  el twt http://twitter.com/ddaz – y lo de las mensadas es muy en serio eh xD –, se que dicen que el twt no es un chat, pero hay ideas que hay que  replicar en caliente, sino se va la inspiración.

espero sus opiniones y retroalimentación al respecto, no olviden que es mi apreciación personal :), quizá se me paso escribir algunas cosas que en este momento no se me vienen a la mente… pero de todas maneras este paso a ser otro “Testamento de Dacito”, veamos cuantos llegan a leer hasta este punto.

 y como lo prometi….  lo publique antes de irme a dormir… siendo las 3:36 am.. fugo para dormir…

Salu2

 

Ddaz – El Dacito –

Off Topic Nacimiento de Sakura

Se que tengo algunos post prometidos pendientes, se que no es excusa, pero hace unos días nació mi primogénita, Sakura Susana, los últimos días del embarazo maría me tuvo muy ocupado.

Nació el 2 de Abril, y sus Especificaciones iniciales fueron :

  • Estatura 56 cm
  • Masa 3.4 Kg
  • Peso 3.4 Kg Fuerza a 0 msnm.

en este momento estoy escribiendo un post, pero no podría ponerlo, sin antes poner sobre esto. les dejo una imagen de sakura

 

 

 

si les da curiosidad…. regularmente iré poniendo como una bitácora en línea sobre ella aquí http://marddaz.com/Informes.aspx 

 

 y Aquí un video  de Sakura :

 

si… ya se…  estoy idiotizado por mi hija…  lo acepto!!!

Salu2

Ddaz – el Dacito –