El clonado ya no se lleva. Parte I

Si alguna vez habéis asistido a una de mis charlas sobre tratamiento de evidencias digitales, posiblemente me habréis escuchado decir que los clonados de discos duros ya no se llevan. Algunos se extrañan al oírme decir tal afirmación, más si cabe, si la persona que lo escucha, no conoce otra palabra en el ámbito del análisis forense que no sea la del “clonado” y “volcado”. Pero en realidad esto no es cosa de modas: es un tema de eficiencia y eficacia. Clonar un disco duro implica copiar bit a bit toda la información que este contiene, es decir, copiar todos los bits (0 y 1) de un disco duro original sobre otro disco copia. Como seguro que ya os imaginaréis, por cada disco duro (físico) original, se necesitará un disco duro (físico) copia, no vale con lo de “si tengo varios discos duros originales pequeñitos, clonarlos todos a uno más grande y ya está“. No, no es así. Un clonado siempre implica que, por cada disco duro origen, se necesite otro disco duro físico de destino, y no solo eso, no servirá cualquier disco duro. El disco duro que se utilizará para realizar la copia deberá ser de las mismas características que el disco duro original: tipo, tamaño, sectores… Además de tener que estar completamente wipeado, esto no es otra cosa que “poner” previamente todos los bits del disco destino a 0, para así evitar que se “contamine” con los datos que ya pudieran estar grabados en el disco de destino.

Fig.1 MorterueloCON 2017

 

Por otra parte, si lo que tenemos que hacer es clonar un par de discos duros al mes, nos dará igual este extremo. El problema surge cuando es necesario adquirir  (capturar) mediante clonado cientos de discos duros al mes, cada uno de ellos con un tamaño distinto, un fabricante distinto, un tipo distinto… Además, como ya comenté, el disco de destino tiene que estar wipeado. En este caso, tampoco vale la excusa de decir que “el disco de destino está a estrenar, y que lo acabo de sacar del embalaje del fabricante“, hoy en día aún hay técnicos que afirman que es necesario desprecintar el disco duro de destino al momento de realizar el clonado para garantizar que no tiene otros datos anteriores grabados. El problema es que un disco duro, nuevo, a estrenar, recién sacado de su caja original, que huele a nuevo, no tiene porque venir de fábrica con todos los bits a cero, es más, algunos de ellos ya vienen con formato asignado y un par de ficheros PDF informativos y publicitarios en su interior, por no hablar de los discos reacondicionados. Así que para hacer clonados forenses de discos, los discos copia o destino tienen que estar previamente wipeados si o si, este proceso si será el que garantice la validez del disco duro destino, y no el sacarlo de una caja con una pegatina de plástico que ha puesto ahí el fabricante.

Fig.2 Disco duro en una bolsa electro estática.

 

Para solucionar estos problemas y otros que conllevan el clonado de discos duros, ya hace muchos años que se “inventaron” las imágenes forenses de discos duros, pero ¡OJO!, una imagen forense de un disco duro no es fotocopiar un disco duro por las dos caras y luego compulsar la fotocopia. (verídico 😉 )

Fig.3 Imagen “casi-forense” de un disco duro

 

Realizar una imagen forense del contenido de un disco duro, implica tomar todos esos ceros y unos que están grabados en el disco duro origen, y en vez de grabarlos directamente sobre la superficie de otro disco (esto sería un clonado), los “empaquetamos” en un fichero contenedor, como puede ser los ficheros Ex, DD, ISO, RAW. De este modo, podremos copiar, mover, analizar estar imágenes forenses, sin necesidad de trabajar con un disco duro (físico) copia. Es decir, en vez de custodiar un elemento físico como es un disco duro, custodiamos y operamos con ficheros digitales que se pueden mover de un lado al otro, y que en todo momento podremos garantizar su integridad mediante el uso de sistemas de firmado digital HASH.

Ahora que ya os he convencido (o no) sobre la conveniencia de realizar imágenes forenses en vez de clonados para la adquisición de dispositivos de almacenamiento, vamos a ver como poder realizar esas imágenes forenses. Lógicamente, el método más sencillo, es coger una mal llamada “clonadora” forense, conectarle dos discos, origen y destino, pulsar sobre el botón de “Realizar Imagen” y ya solo nos queda esperar a que termine. Pero explicar el funcionamiento de estos dispositivos en este blog no tendría mucho sentido.

Fig.4 ImageMASster SoloIV G3 Plus

 

Así que explicaré como poder “jugar” con los sistemas de creación de imagen forense, para en cierto modo perder el miedo que todavía hoy en día existe sobre ellos.

Aunque normalmente no me gusta hablar de sistemas o marcas de software concretos, para desarrollar lo que explicaré a continuación utilizaré el sistema operativo forense Deft de Linux (o Deft Zero, que es la versión “reducida”), con las siguientes herramientas: Guymager, sha1deep, sha1sum, dhash, fdisk y cat. Además también utilizaré el software comercial Encase desarrollado por Guidance, para comprobar que los resultados obtenidos son exactamente los mismos. Seguir leyendo

Que el calor no te haga salir de la piscina. Parte II

Hace una semana os contaba en la Primera Parte de este Articulo, como diseñar y poner en producción a través de una Raspberry Pi y unos sensores de temperatura y humedad DHT11, para que a través de una página web desplegada en la propia RPi, poder controlar la temperatura de nuestro datacenter de una forma muy económica y eficaz.

El problema que tiene la primera versión de este sistema (la que os contaba en la primera parte de este articulo) es que si nos encontrábamos fuera de la red local en la que estaba publicado el servidor web, no podíamos conocer el estado del CPD, cierto es que se podría desplegar una VPN para acceder remotamente a esta red y así poder monitorizar la temperatura desde cualquier parte del mundo, pero esto me parecía un poco desproporcionado, y más si la RPi la tenemos desplegada en una VLAN aislada del resto de la red. La opción que me pareció más adecuada fue la de montar un bot de Telegram, para que a través de una serie de comandos predefinidos poder consultar en cualquier momento el estado de nuestro CPD, consulta que podremos realizar desde nuestro propio teléfono móvil, y lo más importante, desde cualquier parte del mundo. Pero claro, no vamos a estar cada dos por tres preguntándole a nuestro BOT por el estado del CPD, lo suyo es que exista un sistema autónomo que compruebe cada cierto tiempo el estado de la temperatura y que si detecta algún tipo de incidencia, nos avise a través de Telegram automáticamente. De este modo, nos podemos despreocupar completamente de el estado de la temperatura. En esta segunda parte del artículo, describiré como añadir la funcionalidad de un Bot de Telegram, a nuestra RPi de gestión de temperatura.

Fig. 1 Logotipo de Telegram.

 

En primer lugar, para poder desplegar nuestro BOT de Telegram en la RPi, tan solo tendremos que instalar el API de Telegram: https://github.com/eternnoir/pyTelegramBotAPI.git. Una vez instalada, ya podremos controlar desde otro script, en Python la actividad del bot. En mi caso, he decidido dividir la tarea en dos hilos: el primer hilo sería el BOT propiamente dicho, su función sería estar escuchando continuamente los mensajes que recibe, y si alguno coincide con los comandos que se le han indicado, que actúe en consecuencia respondiendo con la información solicitada. El segundo hilo, se encarga de comprobar cada cierto tiempo el log de la temperatura del CPD, si detecta una temperatura más alta de lo normal, automáticamente enviará un mensaje a través del grupo de Telegram que se le ha indicado, para notificar la incidencia al departamento de TI y que estos actúen en consecuencia.

Fig. 2 Extracto del código Python que ejecuta el primer hilo del bot.

 

Fig. 3 Extracto del código Python que ejecuta el segundo hilo para las alertas.

 

Para que no tengáis que escribir el código Python que gestiona los dos hilos, os lo dejo por Aquí y así os lo podéis Descargar tranquilamente. Como ya dije en la primera parte del artículo, no soy desarrollador, así que si encontráis en el código partes que sean mejorables, bienvenidas serán esas modificaciones, eso sí, no me digáis que defina las variables al inicio, que de eso ya se encargan mis compañeros 😉 Aunque el código que os paso es totalmente funcional, tendréis que definir una serie de variables para poder hacerlo funcionar. Estas son:

Fig. 4 Extracto del código Python dónde se definen las variables: Token, CIDID y temperatura.

 

Seguir leyendo

Que el calor no te haga salir de la piscina. Parte I

Estamos en pleno mes de agosto, medio país de vacaciones, otros esperando a que nos lleguen, pero todos pasando calor. Hace unos días los termómetros marcaban más de 40 grados a la sombra, 48 grados en algunos puntos de España. Los afortunados pudisteis pasar esa ola de calor a remojo en piscinas, ríos y playas, con vuestros mojitos, horchatas y refrescos, otros nos conformamos con poder tomar un rico café con leche y hielo a media tarde para poder estar fresquitos, aunque lo mas importante es mantenerse hidratado y evitar realizar en la horas centrales del día tareas que requieran un gran esfuerzo físico. Con estos simple consejos evitaremos sufrir un desfallecimiento o golpe de calor. Pero… ¿y lo servidores?, ¿qué ocurre con los servidores, ordenadores, centros de procesos de datos en pleno mes de agosto?, ¿también pueden aplicar estos consejos? La respuesta a esta última pregunta es sí, pero de una forma un tanto distinta que explicaré ahora.

Fig.1 “¿Es que nadie va a pensar en los servidores?” – 16 de marzo de 1997, Helen Lovejoy.

 

Lo que ocurre con servidores, ordenadores y centros de procesos de datos (datacenters) en los meses de verano, es que se calientan y mucho. Que un servidor se caliente un par de grados más en verano que en invierno, no tiene mayor importancia. El problema es cuando estos servidores o centros de procesos se calientan tanto que llegan al punto en el que los equipos se apagan automáticamente por seguridad y así evitar males mayores. Si lo que tenemos es un servidor o un par de ellos a nivel domestico, poco más podemos hacer que mantener el aire acondicionado de la habitación encendido continuamente. El problema viene, cuando lo que tenemos es un centro de proceso de datos (CPD: sala habilitada para mantener un gran números de equipos informáticos en las condiciones técnicas adecuadas) y falla el sistema de climatización de nuestro CPD. Si falla en invierno, el problema no es tan grave, pero como sabéis esto es informática, y en informática Murphy nunca anda lejos, así que si un sistema de climatización puede fallar, lo hará en pleno verano cuando las temperaturas exteriores sean máximas y la mitad del personal de TI se encuentre de vacaciones a cientos de Kilómetros del CPD. – ¿Qué podemos hacer nosotros para evitar que el sistema de climatización de nuestro CPD nunca falle?. – Pues poco más que cumplir con el mantenimiento de los equipos y no sobrecargar un sistema mal dimensionado.

Aunque lo más importante es que si falla el sistema de climatización o simplemente pierde potencia, podamos detectar la subida de temperatura a tiempo y así poder actuar en consecuencia antes de que sea demasiado tarde: por ejemplo, apagando los sistemas no críticos en primer lugar, para que no sigan calentando el aire del resto de la sala, tratando de refrigerar la sala por otros medios o sirviéndole un rico café con hielo bien frío a nuestra querida EVA (Enterprise Virtual Array). Lo de poder actuar a tiempo, no siempre es fácil. Si el sistema de climatización falla y nuestro CPD no cuenta con islas (pasillos fríos y calientes), si no que es un sala diáfana de armarios y no muy alta, la temperatura puede subir 10 grados en menos de 10 minutos, lo que significa que si la temperatura ambiente era de 25 grados (lo de tener los CPD a 20-22 grados ya no se lleva 😉 ), en diez minutos, la temperatura ambiente estará en 35 grados y el interior de las máquinas tranquilamente por encima de los 70 grados, y solo hay que esperar un poco más para que lleguen a un temperatura critica y se apaguen automáticamente, con todos los problemas que esto conlleva.


Fig.2 CPD distribuido en islas: pasillo caliente, pasillo frío.

 

En el mercado existen soluciones de sondas de medición para controlar la temperatura de nuestras salas de ordenadores (CPD) que no solo miden y registran las temperaturas, si no que son capaces de enviar notificaciones con alertas en caso de que surja alguna incidencia con la temperatura del CPD para que los técnicos puedan actuar en consecuencia sin perder un segundo. No es lo mismo estar controlando la temperatura de los CPUs, GPUs, HDs, Fuentes de Alimentación internas de los servidores… que del ambiente del CPD, ya que si controlamos la temperatura ambiente del CPD nos podemos adelantar a la detección que puedan hacer las sondas internas de los distintos equipos: servidores, switches, router… El problema que estas sondas comerciales suelen tener unos precios bastante elevados, que no caros, ya que son equipos suficientemente probados y construidos de tal manera que su fiabilidad y resistencia están más que demostrada y certificada.

Hoy os voy a explicar como montar una estación de control de temperatura y humedad para nuestros CPD, domicilios, habitaciones… con visualización de alertas web, gráficas de rendimiento, así como con un sistema online de alertas y comunicación vía Telegram con solicitud de datos, todo ello por tan solo 20€, que es lo que cuesta una Raspberry Pi A. Si, la RPi A de hace 5 años, la que traía salida de vídeo RCA, 2 USB y solo consumía 500mA. Realmente con una RPi A nos sobra para los que vamos a hacer, eso sí, si tenéis una RPi v2 o una v3 lógicamente también os servirá. También necesitaremos una sonda DHT11 analógica, recomiendo comprar el modelo que incluye PCB, el de tres pines ya trae la resistencia integrada. También podemos utilizar el modelo DHT22 que es un poco mas potente que el 11. El funcionamiento del sensor de temperatura y humedad DHT11 es muy simple: cuando recibe el orden de realizar una medición, devuelve un valor digital de 40 bits de datos: 8 primeros bits, el valor entero de la humedad, los segundos 8 bits, valor decimal de la humedad, terceros 8 bits valor entero de la temperatura, cuartos 8 bits, valor decimal de la temperatura, quinto y ultimo grupo de 8 bits, suma de verificación de los cuatro anteriores para comprobar que los datos entregados no están corruptos.

Así es como quedaría el sensor integrado en la RPi A de una forma un tanto “artesanal”:

Fig.3 Raspberry Pi A + Sensor DHT11.

Fig.4 Si, es una manguera de regar y dos tacos de clavar en la pared.

 

Seguir leyendo

Webs Amigas

Webs amigas, 20 años después. Aún recuerdo hace años, cuando Internet era 1.0 y funcionaba en html. Cuando los que teníamos páginas web eran “domésticas” y funcionaban bajo un dominio gratuito de aquél archipiélago de pescadores llamado Tokelau a través de una línea de 56kbps, que se cortaba cada vez que alguien descolgaba el teléfono, linea que por cierto, mas que en par de cobre, parecía que estaba fabricada en oro puro, y no lo digo por la velocidad, si no por las facturas de teléfono que llegaban a final de mes, curioso si pensamos que hoy en día por ese mismo precio, podemos alquilarnos varios VPS para todo un año y aun estaríamos ahorrando dinero. En aquella época en la que nos dedicábamos a intercambiar las URL de nuestra web con la de todo aquél que estuviera dispuesto a enlazar nuestro sitio en su página web. Hoy en día igual no se entiende todo esto, pero la finalidad de todo aquello era sencilla: cuantos más sitios enlazaran a nuestra página web, más altos estaríamos en el famoso “Page Rank” de Google y por lo tanto nuestro sitio recibiría más visitas procedentes de Google. Lo que venía siendo un bonito mercadeo de “referrers”, junto a las “black keywords” y otras estratagemas de Black SEO hicieron a Google y al resto de buscadores tomar cartas en el asunto para evitar este tipo de “trampas” en el posicionamiento web. Todo aquello no se hacía ni por ganar ingresos por publicidad (que apenas había), ni por ser el “influencer” de la red, ya que por aquellas muchas de esas webs eran anóminas: apenas se podía saber quien o quienes estaban detrás de ellas. Todo aquello simplemente se hacía por engordar aquel contador de visitas javascript que por cada página vista, sin importar si era el mismo usuario o no, sumaba un punto, un palote, una nueva visita. Hoy en día ya no tendría sentido todo esto, además que practicamente no merece la pena realizar este tipo de actividades irregulares para aumentar el posicionamiento de una web.

Fig 1. Glider retro

Por eso, lo que presento en este apartado de GLIDER.es no es un sistema de mercadeo de refferes, es otra cosa, una cosa bien distinta. Es una forma de agradecer a amigos y conocidos el trabajo que realizan de forma totalmente desinteresada compartiendo sus conocimientos, proyectos y quebraderos de cabeza a través de sus webs y blogs personales. Es una forma de compartir el trabajo que, de forma periódica realizan alimentando sus páginas web, con el trabajo que todos sabemos que esto conlleva. Simplemente, este será ese lugar, el lugar de las Webs Amigas.

 

Silvia Barrera https://sbarrera.es/ Una web de mi compañera y amiga Silvia, en la que trata temas de actualidad sobre cibercrimen, ciberseguridad y redes sociales. Además en este sitio podrás comprar su libro premio Circulo Rojo: “Claves de la Investigación en Redes Sociales”.

 

El blog de Angelucho http://elblogdeangelucho.com/ El blog de mi buen amigo Ángel, el que desde un punto de vista de un ciudadano cualquiera, o del internauta básico, irá lanzado consejos de seguridad, para que todo el mundo pueda encontrarse seguro en el mundo de Internet. Si lo que quieres es tener todos esos consejos reunidos en un único libro, no dudes en descargarte su libro: “X1Red+Segura Informando y Educando V1.0!”

 

Aratech https://www.aratech.es/ El blog de mi compañero de batallas, Oscar Navarrete, si te gusta el hacking de redes, este será tu blog. Eso sí, cuidado con el lado oscuro y no cruzar esa delgada línea roja.

 

Yolanda Corral https://www.yolandacorral.com/ El blog de Yolanda, una periodista especializada en ciberseguridad, artífice del programa Palabra de Hacker.

 

Palabra de Hacker https://www.youtube.com/ Canal divulgativo en temas de ciber seguridad, en el que sin bucear mucho encontrareis entrevistas muy interesantes.

 

Informático Forense https://www.informaticoforense.eu/ Un muy buen blog sobre Informática Forense, escrita por Jose Aurelio, el Maese.

 

Kinomakino http://kinomakino.blogspot.com.es/ Blog de este murciano llamado Kino, en el que si no quieres sentirte inseguro en internet, deberás añadir a tus RSS.

 

Blog Protegerse https://blogs.protegerse.com/ Uno de los referentes en España, en cuanto a contenidos divulgativos de ciber seguridad. Como no podía ser de otro modo, con la esencia de Josep Albors.

 

Hacking Ético https://hacking-etico.com/ Un blog escrito por mis amigos cordobeses. Si el hacking ético y el pentesting te interesa, es un blog que tienes que comenzar a seguir si todavía no lo has hecho.

 

Gurú de la Informática http://www.gurudelainformatica.es/ Como su propio nombre indica, Álvaro es un Gurú de la informática, un especialista en gestión de redes que de forma periódica nos cuenta en su blog técnicas para mejorar la eficiencia y seguridad de nuetras redes.

 

Computación Neuronal https://computacionneuronal.com/ Si quieres aprender a base de bien sobre Redes Neuronales e Inteligencia Artificial, este es tu blog. En el, Jose Luis os irá contado y explicando todas sus invesigaciones sobre este apasionante campo.

 

Security by Default http://www.securitybydefault.com/ Uno de los blogs pioneros de seguridad informática en España, un referente para muchos apasionados de la ciber seguridad.

 

FWHIBBIT https://www.fwhibbit.es/ ¿Todavía no sigues al conejo blanco? Este es un blog muy fresco, que aún a pesar de llevar muy poco tiempo online, ya tiene en su haber ni más ni menos que un premio Bitácoras. Seguir leyendo

Whatsapp: no solo de SQLite vive el hombre.

Posiblemente si pensamos en análisis forense de dispositivos móviles, lo primero que se nos viene a la cabeza es la idea de lograr ver las conversaciones de la aplicación de mensajería online Whatsapp, y esto no es nada nuevo, ya que Whatsapp lleva años estando a la cabeza en el ranking de aplicaciones de este tipo mas usadas en todo el mundo. Este mérito tienes sus consecuencias, una de ellas es que los mensajes enviados a través de esta aplicación se puedan convertir en pruebas de un crimen y por lo tanto será necesario extraer estos mensajes del teléfono, de tal forma que puedan ser utilizados en un eventual procedimiento judicial, es decir, realizar una correcta adquisición forense de estos mensajes. Además, que Whatsapp sea una de las aplicaciones mas usadas en todo el mundo, la convierten en objetivo de todo tipo de ataques y pruebas para tratar de desvirtuar una prueba o indicio criminal obtenido a través de la misma.

Últimamente se está hablando mucho de lo sencillo que puede resultar modificar o alterar una conversación de Whatsapp, para que dónde diga “Diego”, diga “digo”, no seré yo quien diga que esto técnicamente no se puede hacer, ya que es bien conocido el funcionamiento de un base de datos SQLite y como se pueden llegar a modificar los datos de una de sus tablas para volver a inyectarla a dicha aplicación y que efectivamente dónde decía “Diego”, ahora diga“Digo”, cosa bien distinta es lograr realizar esta manipulación sin llegar a dejar ningún rastro que un analista forense no pueda o sepa detectar. ¿Como era la frase…?, todo contacto deja un rastro, ¿no?. En este caso el mérito es localizar ese rastro de manipulación. Hoy no os voy a hablar de esos “lugares” recónditos en los que poder detectar una manipulación de una base de datos de Whatsapp, porque: “haberlos haylos, o caso é encontralos”, os voy a hablar de otra potente fuente de información que tiene Whatsapp, que desde mi punto de vista no siempre se explota suficientemente, y esta no es otra que los LOGS, que Whatsapp genera diariamente.

Lógicamente, el “core” de un análisis forense de Whatsapp, se deberá centrar en las distintas bases de datos SQLite en las que se van almacenando todas las conversaciones de Whatsapp. Pero a veces esto no es suficiente, ya sea porque estas bases de datos no registran lo que estamos buscamos, o porque se han eliminado y ya no podemos disponer de ellas. Así que en el artículo de hoy, voy a tratar de desmenuzar y exprimir el fichero LOG de Whatsapp (El Registro Central de nuestro Whatsapp) que se almacena en la ruta por defecto: “/com.whatsapp/files/Logs/whatsapp.log” de nuestros teléfonos móviles Android, así podréis ver toda la información que en un momento dado podemos obtener de este fichero tan desconocido en algunos casos.

 

1.) Números de teléfono registrados en Whatsapp: Como seguro que ya sabéis, Whatsapp, solamente permite iniciar sesión con un solo número de teléfono al mismo tiempo en un único dispositivo móvil, es decir, por regla general no se puede tener vinculados en Whatsapp dos números de teléfono en el mismo dispositivo móvil, del mismo modo, que tampoco se puede tener el mismo número de teléfono, vinculado al mismo tiempo en dos dispositivos distintos (siempre y cuando no sea con la versión web). Pero esto no implica, que en un mismo teléfono móvil, no se pueda usar Whatsapp con diferentes números de teléfono en distintos momentos, es decir, registramos un número, lo usamos, desconectamos ese número y registramos otro distinto. Quizás, que alguien en un momento dado vincule a su teléfono móvil, el número de otra persona (con, o sin su consentimiento), puede ser indicador de muchas cosas, buenas y malas. ¿Pero, como lo podemos detectar?, tan fácil, como irnos a nuestro: “whatsapp.log” y buscar la cadena “register/phone/cc”. Con esta búsqueda no solo encontraremos los números de teléfonos que se han vinculado a la aplicación de Whatsapp, si no que podremos determina la fecha y la hora a la que se realizaron estas vinculaciones. En la siguiente imagen podéis ver como el mismo número de teléfono se vincula cuatro veces distintas en fechas muy dispares, y entre medias, se registra otro número distinto que comienza por 62XXX. Esto no es lo habitual, ocurre en este caso, porque se trata de uno de los dispositivos que tengo para realizar este tipo de pruebas y el número de teléfono asociado lo utilizo con otras cuentas. Un usuario normal, no debería tener mas de un “Inicio de Sesión” en todo el log, y si los tiene, será porqué vinculó o desvinculó a propósito el número de teléfono en cuestión.

Fig.1 Verde: Fecha. Azul: String. Magenta: Teléfono registrado en Whatsapp.

 

2.) Determinar si un teléfono se encontraba encendido en un momento dado: Como dije anteriormente, en ciertos casos a alguien se le puede ocurrir tratar de manipular un dato dentro de un smartphone por el motivo que sea, esta alteración puede ser mas o menos sencilla de realizar, lo que si que no es para nada sencillo, es lograr realizar esta manipulación sin que nadie la pueda detectar. Por ejemplo, imaginemos que yo ayer a las 2:00 de la madrugada cuando estaba en el Summer Boot Camp de Incibe en León, hago algo que no debo con mi teléfono móvil, y como soy muy listo, se me ocurre modificar el LOG de mi teléfono, en el que se registran los encendidos y apagados del terminal, para que parezca que mi teléfono a las 2:00 de la mañana estaba apagado. Sin embargo, llega un analista forense competente, analiza mi dispositivo, y descubre que aunque el LOG de funcionamiento de mi teléfono dice que se apagó a las 00:30 horas y hasta las 08:00 horas no se volvió a encender, el log de funcionamiento de Whatsapp, con el string “msgstore/backup” registra la copia de seguridad automática de la base de datos de conversaciones msgstore.db a un fichero cifrado tipo .db.crypt12, nombrado con la fecha de creación. Quedando registrada esta acción en el log de Whatsapp, como se muestra en la siguiente imagen (además la fecha de creación del fichero .db.crypt12 será a las 2:00 de la madrugada). Como podéis ver, las mentiras suelen tener la patas muy cortas, además, con el número de aplicaciones que existen hoy en día instaladas en un solo dispositivo móvil, es muy difícil realizar una alteración en un de ellas, y que este alteración no quede registrada en otra aplicación o en otro lugar del teléfono móvil.

Fig.2 Verde: Fecha. Rojo: Backup creado a la 2:00 horas.

 

Seguir leyendo