Rotten Apples: Cuidado con los gusanos!

Oh, Apple, has hecho a mí otra vez! …

Con cada encarnación iOS, bases de datos clave cambian la estructura. Esto no es un secreto para nadie que examina los datos de iDevices. El Sms.db iOS4 difiere mucho de la Sms.db iOS5, y ambos difieren significativamente de la nueva sms.db. iOS6 Se espera que esto, y no presentaron pirosis aquí en todo

Pero el mes pasado que fue abofeteado en la cara por parte de Apple de una forma inesperada:. Encontré dos versiones diferentes de la Sms.db de la misma versión de iOS! Esto es inesperado, y pone de relieve por qué yo no debo tomar nuestras herramientas por sentado y asumir nuestra salida en este caso es exacta debido a una prueba de la herramienta se realizó en un caso anterior.

El

Quandry

Las exposiciones:

• iPhone # 1: Tipo de producto: iPhone 4, 1; versión 5.1.1 del producto
• iPhone # 2: Tipo de producto: iPhone 4,1; Producto Versión 5.1.1

. Así que, para todos los intentos y propósitos, que estaba tratando con el mismo teléfono y el sistema operativo

Eche un vistazo a los esquemas de tabla de mensajes Sms.db:

mensaje CREAR MESA (ROWID INTEGER PRIMARY KEY autoincrement, TEXTO dirección, fecha INTEGER, TEXT texto, banderas INTEGER, reemplace INTEGER, TEXT svc_center, INTEGER group_id, INTEGER association_id, altura INTEGER, INTEGER UIFlags, versión INTEGER, TEXT tema, TEXTO país, BLOB cabeceras, destinatarios BLOB, INTEGER leer, BLOB madrid_attributedBody , TEXTO madrid_handle, INTEGER madrid_version, TEXTO madrid_guid, INTEGER madrid_type, TEXTO madrid_roomname, TEXTO madrid_service, TEXTO madrid_account, madrid_flags INTEGER, madrid_attachmentInfo BLOB, TEXT madrid_url, madrid_error INTEGER, INTEGER is_madrid, INTEGER madrid_date_read, madrid_date_delivered INTEGER, TEXT madrid_account_guid);

iPhone # 2
Crear mensaje MESA (ROWID INTEGER PRIMARY KEY autoincrement, dirección TEXTO, fecha INTEGER, TEXT texto, banderas INTEGER, reemplace INTEGER, TEXT svc_center, INTEGER group_id , INTEGER association_id, altura INTEGER, INTEGER UIFlags, versión INTEGER, TEXT tema, TEXTO país, BLOB cabeceras, destinatarios BLOB, INTEGER leer, BLOB madrid_attributedBody, TEXTO madrid_handle, INTEGER madrid_version, TEXTO madrid_guid, INTEGER madrid_type, TEXTO madrid_roomname, TEXTO madrid_service, madrid_account texto, texto madrid_account_guid, madrid_flags INTEGER, madrid_attachmentInfo BLOB, TEXT madrid_url, madrid_error INTEGER, INTEGER is_madrid, INTEGER madrid_date_read, INTEGER madrid_date_delivered);

¿Usted lo ve? No lo hice al principio, porque yo traté de automatizar la extracción de los mensajes de texto desde iPhone # 1 con un programa de python que había escrito previamente. Cuando fracasó, yo estaba muy confundido porque sólo había utilizado el programa en el iPhone # 2 días de dispositivos similares antes. Y, francamente, no lo hizo darme cuenta que comprobar inmediatamente el esquema, mientras que la búsqueda de la fuente de error, que es el propósito de este post:. Que le ahorra un poco de mi dolor

Encontrar los Worms

Si no detectar el problema, no te preocupes, yo te ayudaré:

iPhone # 1
(mensaje CREAR MESA (ROWID INTEGER PRIMARY KEY autoincrement, dirección de texto, fecha INTEGER, TEXT texto, banderas INTEGER, reemplace INTEGER, TEXT svc_center, INTEGER group_id, association_id INTEGER, INTEGER altura, UIFlags INTEGER, INTEGER versión, texto del tema TEXTO país, BLOB cabeceras, destinatarios BLOB, INTEGER leer, BLOB madrid_attributedBody, TEXTO madrid_handle, INTEGER madrid_version, TEXTO madrid_guid, INTEGER madrid_type, TEXTO madrid_roomname, TEXTO madrid_service, TEXTO madrid_account, madrid_flags INTEGER, madrid_attachmentInfo BLOB, TEXT madrid_url, madrid_error INTEGER, INTEGER is_madrid, INTEGER madrid_date_read, madrid_date_delivered INTEGER, madrid_account_guid TEXTO );

iPhone # 2
Crear mensaje MESA (ROWID INTEGER PRIMARY KEY autoincrement, dirección TEXTO, fecha INTEGER, TEXT texto, banderas INTEGER, reemplace INTEGER, TEXT svc_center, INTEGER group_id, INTEGER association_id, altura INTEGER, INTEGER UIFlags, versión INTEGER, TEXT tema, TEXTO país, BLOB cabeceras, destinatarios BLOB, INTEGER leer, BLOB madrid_attributedBody, TEXTO madrid_handle, INTEGER madrid_version, TEXTO madrid_guid, INTEGER madrid_type, TEXTO madrid_roomname, TEXTO madrid_service, TEXTO madrid_account, TEXTO madrid_account_guid , madrid_flags INTEGER, madrid_attachmentInfo BLOB, TEXT madrid_url, madrid_error INTEGER, INTEGER is_madrid, INTEGER madrid_date_read, INTEGER madrid_date_delivered);

Ok, dices, » Veo las luces, pero son los mismos contenidos ¿Cuál es la gran cosa «Estoy de acuerdo, lo hacen decir lo mismo … pero el» madrid_account_guid» está en una posición diferente en la base de datos, o para ser más lingüísticamente ; correcto, el orden de los campos es diferente en las dos bases de datos ¿Importa Bueno, sí y no …

Considere:
‘SELECT ROWID, dirección, texto, madrid_date_read DE mensaje;’

Esta consulta podría funcionar igual de bien en el cuadro de mensaje, ya sea teléfono, ya que llama a los campos por su nombre. Cualquier aplicación, forenses o de otra manera, haciendo preguntas específicas que continuarán operando completamente ajeno a las diferencias de base de datos. Pero una más consulta genérica, podría conducir a problemas.
Courier New, Courier, monospace; font-size: x-small;»> ‘SELECT * FROM mensaje; ‘

Esta consulta salida cada campo en el registro, y cualquier herramienta que trató de leer la salida de datos posicionalmente obtendría datos inesperados en los últimos ocho campos (en un caso, de todos modos). ; Esto es lo que sucedió en mi programa «Bueno, estúpido», dices, «no código como eso.» Una vez más, estoy de acuerdo, y yo arreglé mi programa al cambiar la manera en la que me preguntó la base de datos.. .. pero resulta que yo no soy el único de codificación de esta manera />.
Lo que olvidó mencionar fue por eso que estaba procesando estos teléfonos. iPhone # 1 era parte de una investigación de tiro. Saqué de un vehículo sospechoso e inicialmente procesado que al hacer una copia de seguridad de iTunes del dispositivo en funcionamiento. El segundo teléfono fue traído a mí después de una fecha-hasta-UFED de Cellebrite no pudo extraer ningún mensaje desde el servicio iMessage. Los campos de los madrid ‘se relacionan con el servicio iMessage, y son los campos de madrid que se lanzan fuera de servicio por el cambio de esquema de base de datos. Parece que Cellebrite puede haber sido arrojado por la orden de la bandera de la misma manera que era . Por lo menos estoy en buena compañía!

Esto también tiene implicaciones en SQLite registro tallado. En los datos en bruto, los campos se establecen en el orden del esquema. Si una plantilla para tallar los campos de los registros de SQLite caído tiene el esquema equivocado (y por qué se puede esperar de un iOS 5.1.1 Sms.db difiera de otro), entonces vas a encontrar los datos incorrectos y poco fiables.

He estado trabajando muy duro para recuperar caído registros de las páginas de SQLite y han tenido bastante éxito. Manténgase atento a lo que he aprendido en este frente …