Repositorio Institucional de Documentos

PROYECTO FIN DE CARRERA Desarrollo de una aplicaci´on para la extracci´on y an´alisis de metainformaci´on en dispositivos iPhone Autor: Javier Checa Beteg´on Director: Manuel S´anchez Chumillas Ponente: ´ Alvaro Alesanco Iglesias Centro Polit´ecnico Superior Ingenier´ıa en Inform´atica 9 de noviembre de 2011 PROYECTO FIN DE CARRERA Desarrollo de una aplicaci´on para la extracci´on y an´alisis de metainformaci´on en dispositivos iPhone Autor: Javier Checa Beteg´on Director: Manuel S´anchez Chumillas Ponente: ´ Alvaro Alesanco Iglesias Centro Polit´ecnico Superior Ingenier´ıa en Inform´atica 9 de noviembre de 2011 Agradecimientos Son muchas las personas que han contribuido a que haya llegado hasta aqu´ı y hoy pueda leerse este documento. Nombrarlas todas es tarea complicada, as´ı que me resignar´e a mencionar s´olo a algunas de las m´as destacables. Gracias a mis compa˜neros de carrera por hacer que 5 a˜nos de estudio y levantarse temprano por la ma˜nana se conviertan en la mejor etapa de mi vida. Sois muchos y sab´eis qui´enes sois A los miembros de la rama de estudiantes del IEEE de la Universidad de Zaragoza que he tenido el placer de conocer, gracias por haberme echado una mano cuando lo he necesitado y por vuestra acertadas recomendaciones. A Chema Alonso, por ofrecerme la idea para este proyecto y aquella vuelta en el maligno-m´ovil. A ´el, y a los compa˜neros de Inform´atica64, en especial a Alejandro Mart´ın y Manuel S´anchez, gracias por acogerme y ayudarme a dar los primeros pasos. Gracias tambi´en a Fernando Oca por sus direcciones en el an´alisis de los ficheros Office. Gracias a Ismael Saad por su inestimable ayuda a la hora de desarrollar la interfaz gr´afica de esta aplicaci´on. A mis traductoras personales, Olga Bichert y Jekaterina Vargunina, por ofrecerme su conocimiento del alem´an y el ruso, respectivamente. A´ Alvaro Alesanco, por orientarme durante estos meses, por ser tan cercano, aguantar mis quejas sobre los problemas que encontraba y por las veloces respuestas a mis correos. Gracias a www.stackoverflow.com y otras comunidades que han conseguido sacarme de muchos apuros durante estos meses de trabajo. A los creadores de las clases ZipArchive y FileReader (sec. 4.2) por facilitarme la labor y permitir que me centrara en lo verdaderamente importante. Y, por supuesto, gracias a mi familia por los sabios consejos cuando los he necesitado y, sobretodo, por su apoyo incondicional y por creer en m´ı. iv ´ Indice general 1. Introducci´on 1 1.1. Motivaci´on ............................ 1 1.2. Entorno de aplicaci´on . . . . . . . . . . . . . . . . . . . . . . 2 1.3. Objetivo.............................. 2 1.4. Resumen.............................. 3 2. Tecnolog´ıa usada 5 2.1. iOS................................. 5 2.2. ObjectiveC............................ 5 2.2.1. Losm´etodos ....................... 6 2.2.2. Paso de mensajes . . . . . . . . . . . . . . . . . . . . . 6 2.2.3. Categor´ıas......................... 6 2.2.4. Internacionalizaci´on . . . . . . . . . . . . . . . . . . . 7 2.3. Xcode ............................... 7 2.3.1. Interface Builder . . . . . . . . . . . . . . . . . . . . . 8 3. An´alisis 9 3.1. Archivosdetexto......................... 9 3.2. Archivosbinarios......................... 10 3.3. Archivos zip ............................ 10 3.4. Planificaci´on ........................... 10 4. Dise˜no de la aplicaci´on 13 4.1. La clase MetaAnalyzer . . . . . . . . . . . . . . . . . . . . . . 13 4.2. Clases, categor´ıas y archivos de apoyo . . . . . . . . . . . . . 15 4.2.1. Categor´ıas de NSString y NSData . . . . . . . . . . . 15 4.2.2. Categor´ıa de NSMutableDictionary . . . . . . . . . . . 15 4.2.3. Clase ZipArchive . . . . . . . . . . . . . . . . . . . . . 16 4.2.4. Clase FileReader . . . . . . . . . . . . . . . . . . . . . 16 4.2.5. Archivos strings ..................... 16 4.3. La interfaz gr´afica . . . . . . . . . . . . . . . . . . . . . . . . 16 4.4. Pruebas .............................. 20 vi ´ INDICE GENERAL 5. Conclusiones 21 5.1. Problemas encontrados . . . . . . . . . . . . . . . . . . . . . . 21 5.2. Posibles mejoras . . . . . . . . . . . . . . . . . . . . . . . . . 22 5.3. Reparto de horas invertidas . . . . . . . . . . . . . . . . . . . 22 5.4. Opini´on personal . . . . . . . . . . . . . . . . . . . . . . . . . 25 A. Categor´ıas de MetaAnalyzer 27 A.1.Categor´ıa3gp........................... 27 A.2.Categor´ıaAIFF.......................... 27 A.3.Categor´ıaASF .......................... 28 A.4.Categor´ıagif ........................... 28 A.5.Categor´ıaHTML......................... 29 A.6. Categor´ıa iWork . . . . . . . . . . . . . . . . . . . . . . . . . 29 A.7.Categor´ıajpg........................... 30 A.8.Categor´ıamov .......................... 30 A.9.Categor´ıamp3 .......................... 31 A.10.Categor´ıamp4 .......................... 31 A.11.Categor´ıa Office binario . . . . . . . . . . . . . . . . . . . . . 32 A.12.Categor´ıa Office zip . . . . . . . . . . . . . . . . . . . . . . . 33 A.13.Categor´ıaogg........................... 33 A.14.Categor´ıapdf........................... 33 A.15.Categor´ıaRIFF.......................... 34 A.16.Categor´ıartf ........................... 34 A.17.Categor´ıatiff ........................... 35 A.18.Categor´ıaXML.......................... 35 A.19.Categor´ıaXMP.......................... 36 A.20.Categor´ıa zip ........................... 36 B. Manual de usuario 37 C. Pruebas 49 Cap´ıtulo 1 Introducci´on La informaci´on ha jugado siempre un papel fundamental a todos los niveles y en concreto para el empresarial: datos de empleados, de clientes, de facturaci´on, etc. Hoy en d´ıa esta importancia sigue vigente y, con el desarrollo de las nuevas tecnolog´ıas, aparecen nuevas amenazas de fuga o p´erdida de esta informaci´on: ataques malintencionados por medio de virus otroyanos, dispositivos de almacenamiento masivo con datos sensibles sin protecci´on o datos relevantes cedidos de manera involuntaria a trav´es de otros archivos son s´olo algunos ejemplos. La metainformaci´on, o informaci´on de la informaci´on, que de un documento podr´ıa entenderse como el nombre del autor o el programa con el que fue editado, puede resultar ´util a la hora de clasificarlo y buscarlo, por ejemplo. Actualmente la mayor´ıa de los archivos que se crean llevan alg´un tipo de metadato asociado desde el primer momento, lo que puede suponer un problema si no se tiene un control sobre ello, pues, al compartir un documento, se puede, adem´as, facilitar informaci´on no deseada. Esto hace referencia a la tercera amenaza mencionada anteriormente. Los tel´efonos de empresa, en especial los smartphones, debido a las amplias posibilidades que ofrecen, son muy propensos a almacenar un gran volumen de datos, por lo que pueden suponer un foco importante de fuga de informaci´on. 1.1. Motivaci´on Poco despu´es del comienzo del curso 2006-2007, mi primer a˜no de carrera, tuve la oportunidad de asistir a uno de los Code Camp organizados por Microsoft, donde se trataron y organizaron actividades sobre temas muy interesantes, a pesar de que por aqu´el entonces la gran mayor´ıa me fueran ajenos. All´ı conoc´ı a Chema Alonso, gur´u de la seguridad inform´atica que 2 CAP´ ITULO 1. INTRODUCCI ´ ON fund´o su propia empresa, Inform´atica64, hace ya m´as de 11 a˜nos, y desde entonces he asistido a varias de sus charlas y mantenido el contacto con ´el. A la hora de buscar un proyecto fin de carrera, puesto que ya desde peque˜no encontr´e la criptograf´ıa y, no mucho despu´es, la seguridad de la informaci´on, muy interesante, decid´ı contactar con Chema en busca de ideas. Me propuso realizar una aplicaci´on iPhone para extraer metainformaci´on de archivos puesto que no se contaba con herramientas con esas caracter´ısticas. Me pareci´o una idea estupenda debido a todo lo que pod´ıa aprender por el camino al no saber nada de programaci´on para dispositivos iOS (el sistema operativo utilizado por iPhone, iPod e iPad), as´ı que acept´e y poco despu´es la propuesta de proyecto estaba entregada. 1.2. Entorno de aplicaci´on Tal y como se deja entrever en la introducci´on, los archivos pueden contener informaci´on, aunque no seamos conscientes de ello, que represente un problema de seguridad. Para un usuario normal, puede suponer revelar qu´e software utiliza, con qu´e versi´on y, por ende, con qu´e vulnerabilidades no corregidas, su nombre real o incluso una aproximaci´on de las horas a las que est´a frente al ordenador analizando las fechas de creaci´on y modificaci´on de sus archivos. Si vamos al caso empresarial, adem´as de lo mencionado para usuarios medios, hay que sumar que los archivos pueden contener informaci´on sobre clientes. Por ejemplo, muchos archivos tienen un campo “descripci´on” o “asunto” que puede revelar informaci´on sensible. Es m´as, el simple hecho de dar a conocer la versi´on del software usado puede exponer a la empresa a ataques o software malintencionado dirigido hacia ella, lo que puede derivar en una muy importante fuga de informaci´on. 1.3. Objetivo Este proyecto fin de carrera busca desarrollar una aplicaci´on para iPhone, uno de los smartphones m´as comunes del mercado, que sea capaz de analizar ficheros dentro del dispositivo en busca de informaci´on relevante. En la actualidad no se dispone de ninguna aplicaci´on que cumpla con estas caracter´ısticas, por lo que el PFC se presenta como una soluci´on para esta necesidad. Cap´ıtulo 3 An´alisis Una vez se conocen las herramientas de las que se dispone, y antes de comenzar a utilizarlas para implementar una soluci´on el problema, hay que entender el problema en s´ı: para un archivo dado, obtener los metadatos que contiene. Esto conlleva conocer la estructura del fichero, c´omo se organiza, para poder buscar la informaci´on en los lugares en los que puede estar presente. En este proyecto se distinguen tres tipos de archivos: los archivos de texto, los archivos binarios y los archivos zip. 3.1. Archivos de texto Por archivos de texto se entienden aqu´ellos cuyo contenido es legible si se abren con un simple editor de textos, como wordpad,gedit otextEdit, por ejemplo. Pese a que los formatos de estos archivos suelen estar divididos en partes, se˜nalizadas con tags o etiquetas, habitualmente no se indica el tama˜no de la misma, lo que obliga realizar una lectura secuencial del fichero en busca de lo que interesa, no pudiendo, sencillamente, desplazar el lector. Adem´as, al tratarse de texto plano, se hace necesario realizar comparaciones entre cadenas de texto para localizar el comienzo y el final de un dato. En ocasiones esto no resulta inmediato y supone realizar numerosas comprobaciones. Dentro de esta primera clasificaci´on se encuentran los archivos con extensi´on “rtf” (Rich Text Format), “html” (HyperText Markup Language) o “xml” (eXtensible Markup Language) 10 CAP´ ITULO 3. AN ´ ALISIS 3.2. Archivos binarios Los archivos binarios tienen una estructura interna definida en su formato y gran parte de su contenido es ilegible porque no tiene representaci´on como una serie de caracteres. Para explorarlos se utilizan editores hexadecimales, que muestran su contenido en hexadecimal junto a su equivalencia en texto. Es com´un que aparezcan estructuras de tama˜no constante o siguiendo un patr´on similar a [Tama˜no][Identificador][Contenido], con “Tama˜no” e “Identificador” de longitud constante, por lo que resulta sencillo saltar porciones de fichero que no contienen datos relevantes. Algunos de los archivos binarios con los que se trabaja m´as adelante son los “mov” (formato multimedia de QuickTime, de Apple), “jpg” (o “jpeg”, formato de compresi´on de im´agen con p´erdidas), “mp3” (formato muy extendido de compresi´on de audio con p´erdidas) y los pertenecientes a Microsoft Office hasta la versi´on 2003, incluida, entre otros. 3.3. Archivos zip Zip es un formato de compresi´on de archivos. Algunos de los archivos que la aplicaci´on deber´a analizar, como por ejemplo los pertenecientes a Micrososft Office a partir de la versi´on 2007, incluida, o los de iWork, paquete de ofim´atica de Apple, son en realidad varios archivos en uno, y utilizan zip para presentarse como uno solo. De hecho, cambiar la extensi´on de uno de estos archivos a “.zip” har´a que nuestro descompresor favorito lo reconozca y nos permita ver el contenido, que no es sino una serie de carpetas y archivos. La aparici´on en juego del formato zip hace necesario que la aplicaci´on sea capaz de descomprimir contenedores de este tipo. 3.4. Planificaci´on A pesar de las similitudes que puedan aparecer entre formatos dentro de una misma clasificaci´on, lo cierto es que sus diferencias hacen muy dif´ıcil abstraerse y generalizar el an´alisis de varios de ellos. Esto influir´a en la forma en la que se dise˜ne la aplicaci´on. A la vista de la naturaleza del problema y de las herramientas, se decide seguir el siguiente plan: Recabar informaci´on b´asica sobre los distintos formatos, que es lo que se ha comentado ahora. 3.4. PLANIFICACI ´ ON 11 Desarrollar una aplicaci´on simple para explorar el sistema de archivos. Trabajar en una clase de an´alisis de archivos y profundizar m´as en cada formato a la hora de trabajar en ´el. Realizar pruebas de la clase. Desarrollar una interfaz gr´afica m´as elaborada. Realizar pruebas sobre la interfaz. Probar la aplicaci´on a fondo con muchos archivos. Redactar la memoria, que es el presente documento. Adem´as, y para facilitar el ´ultimo paso, durante las distintas fases se ir´an recogiendo notas sobre los avances, problemas encontrados o posibles ampliaciones futuras. 12 CAP´ ITULO 3. AN ´ ALISIS Cap´ıtulo 4 Dise˜no de la aplicaci´on Los diferentes componentes de la aplicaci´on implementada se pueden agrupar en tres conjuntos diferentes: los encargados de gestionar la interfaz gr´afica, los pertenecientes a la clase MetaAnalyzer, que gestiona la extracci´on de la metainformaci´on, y clases, categor´ıas y archivos de apoyo destinadas a facilitar una determinada labor. A continuaci´on se explican con m´as detalle cada una de estas partes. 4.1. La clase MetaAnalyzer Esta clase presenta, en su cabecera, un ´unico m´etodo, llamado analyzeFileAtPath:withError:, que devuelve un diccionario de pares clave-valor con la informaci´on obtenida o indica en su par´ametro de error si algo ha ocurrido. Este archivo tambi´en declara una serie de defines para los c´odigos de error y otros en los que se crean cadenas internacionalizadas (ver secci´on 2.2.4) para las distintas posibles claves as´ı como para algunos valores sencillos. Seg´un el idioma seleccionado en el dispositivo, la aplicaci´on mostrara el texto en un idioma u otro, siempre que la traducci´on est´e disponible. Tambi´en se define la cadena separadora que permite almacenar varios valores para una misma clave (m´as en 4.2.2), que en este caso es “ |”. En la implementaci´on de la clase, se importa el fichero “MAIncludes.h”, que a su vez incluye las cabeceras de todas las categor´ıas de esta clase, que se explican en detalle en el ap´endice A. Todas ellas incorporan gesti´on de excepciones para capturar posibles problemas durante la ejecuci´on. Los formatos soportados en la versi´on de este proyecto se presentan en la tabla 4.1. Aunque algunos formatos presentan similitudes entre ellos, ha sido necesario realizar un extenso y concienzudo estudio de cada uno para poder desarrollar sus m´etodos correspondientes. Adem´as de la especificaci´on, que 14 CAP´ ITULO 4. DISE ˜ NO DE LA APLICACI ´ ON Formato Tipo de fichero Extensiones 3gp Binario .3gp AIFF Binario .aif, .aiff ASF Binario .wma, .wmv gif Binario .gif HTML Texto .htm, .html iWork Zip .key, .pages, .numbers jpg Binario .jpg, .jpeg mov Binario .mov mp3 Binario .mp3 mp4 Binario .mp4 Office binario Binario .doc, .xls, .ppt Office Zip Zip .docx, .xlsx, .pptx ogg Binario .ogg pdf Binario .pdf RIFF Binario .wav, .avi rtf Texto .rtf tiff Binario .tif, .tiff XML Texto .xml XMP Texto .xmp Cuadro 4.1: Formatos soportados por la aplicaci´on no est´a disponible para todos los formatos, tambi´en se ha hecho un uso intensivo de un editor hexadecimal para comprender la estructura interna de cada tipo de fichero, ya que he en ocasiones no se sigue al pie de la letra. En cuanto al m´etodo antes mencionado, su funcionamiento es simple: comprobar la extensi´on del fichero que se indica por la ruta recibida, asegurarse de que la firma del fichero corresponde con la del tipo de fichero y llamar al m´etodo de la categor´ıa adecuada para analizarlo. Si la firma y extensi´on no coinciden, se llama al m´etodo analyzeFileAtPathCheckingSignature:withError:, no declarado en la interfaz, para elegir qu´e m´etodo usar en funci´on de la firma. S´olo se mantiene un m´etodo visible en la cabecera, y el resto “ocultos” en categor´ıas, para que resulte inmediato decidir qu´e m´etodo llamar en caso de que la clase se reutilice en otras aplicaciones. Adem´as, se ha implementado una categor´ıa por formato de fichero, no por tipo, lo que podr´ıa ocasionar que no resultara trivial elegir el m´etodo correcto. Por ejemplo, los archivos Windows Media Audio (wma) y Windows Media Video (wmv) siguen el formato ASF, como se puede ver en la tabla 4.1. 4.2. CLASES, CATEGOR´ IAS Y ARCHIVOS DE APOYO 15 4.2. Clases, categor´ıas y archivos de apoyo En ocasiones ha resultado necesario poder realizar acciones que no ven´ıan implementadas por defecto en las clases disponibles. Cuando una situaci´on as´ı ha aparecido, por ser algo ajeno a la clase MetaAnalyzer, se han creado categor´ıas de clases ya existentes o se han a˜nadido nuevas clases encargadas de llevar a cabo esa funci´on. 4.2.1. Categor´ıas de NSString y NSData NSString es la clase que se utiliza para trabajar con cadenas de texto. Para esta aplicaci´on, se han implementado dos categor´ıas: una para trabajar con cadenas de caracteres hexadecimales y otra para buscar subcadenas. En la primera se pueden encontrar m´etodos para traducir la cadena a texto, calcular el valor num´erico que representa, cambiar de little abig endian y viceversa, etc. Por su parte, la clase NSData permite almacenar bytes de informaci´on y se ha utilizado en la lectura de ficheros. ´ Estos pueden almacenar informaci´on en little ybig endian y en ocasiones es necesario leer los datos, cambiar su endianness y usarlos. Para evitar operaciones innecesarias, en lugar de interpretar la informaci´on como una cadena hexadecimal, cambiar de un formato a otro y volver a su representaci´on en bytes, se ha creado una categor´ıa que a˜nada la funcionalidad de invertir el orden de los bytes. 4.2.2. Categor´ıa de NSMutableDictionary En la aplicaci´on se utilizan diccionarios modificables1para almacenar los pares clave-valor de los metadatos encontrados. En un mismo fichero pueden aparecer varios metadatos del mismo tipo o incluso el mismo varias veces. En el caso de esta aplicaci´on se trabaja con cadenas, pero los diccionarios pueden contener objetos de cualquier tipo. Es por ello que por defecto la clase no incorpora un mecanismo para concatenar valores al ya existente para una clave. En esta categor´ıa se implementa un m´etodo que, primero, comprueba si ya hab´ıa un valor asociado a la clave. En caso de no existir, crea una nueva entrada con el valor dado; si ya hab´ıa alg´un valor presente, comprueba si alguno de los distintos valores, separados por la cadena separadora definida en la clase MetaAnalyzer, coincide con el que se quiere introducir y, en funci´on de esto ´ultimo, decide si concatenarlo, junto con la cadena separadora, o rechazarlo por duplicado. 1Como tantos otros objetos de Objective C, la versi´on mutable o modificable permite a˜nadir, eliminar o modificar los datos que contiene 16 CAP´ ITULO 4. DISE ˜ NO DE LA APLICACI ´ ON 4.2.3. Clase ZipArchive Para trabajar con archivos zip se hace uso de la clase ZipArchive, disponible en Google Code [3]. En ella se presentan diversos m´etodos para comprimir y descomprimir archivos, con o sin contrase˜na. En esta aplicaci´on se ha hecho uso ´unicamente de la funcionalidad de descompresi´on. 4.2.4. Clase FileReader Algunos formatos de archivos de texto utilizan saltos de l´ınea para separar unidades. La clase FileReader, extra´ıda del proyecto LineReader [4], implementa la lectura de l´ıneas en ficheros de texto con un lectura por bloques. En este caso se han a˜nadido nuevos m´etodos y modificado otros seg´un las necesidades de la aplicaci´on. 4.2.5. Archivos strings Los archivos strings se utilizan para almacenar las traducciones de las cadenas internacionalizadas (secci´on 2.2.4). Las aplicaciones contienen uno de estos archivos por cada uno de los idiomas soportados. Si una lengua no tiene su archivo correspondiente, la aplicaci´on muestra el texto introducido por defecto, que en este caso es en ingl´es. 4.3. La interfaz gr´afica La implementaci´on de la interfaz gr´afica se ha realizado con la ayuda de Interface Builder (secci´on 2.3.1) y es muy intuitiva. Al iniciar la aplicaci´on se muestra una pantalla de presentaci´on (figura 4.1) desde la que el usuario puede pasar a explorar el sistema de ficheros en una nueva pantalla. En el explorador de archivos se presenta una tabla que contiene los ficheros del directorio actual, encima de la cual se indica el nombre de este ´ultimo y se muestra un bot´on con el texto internacionalizado “Atr´as” para subir un nivel. La figura 4.2 muestra un ejemplo de lo que puede encontrarse un usuario mientras navega una carpeta con distintos ficheros. Si se pulsa sobre un directorio se accede a ´el, y, si se hace sobre un fichero, se crea una instancia de la clase MetaAnalyzer para que analice el fichero. Los metadatos encontrados se muestran a continuaci´on en otra pantalla, agrupados seg´un la informaci´on que representan. Por ejemplo, si se pulsa sobre el archivo “2011-08-16 13.51.42.jpg” de la figura 4.2, se obtienen los metadatos mostrados en la figura 4.3. 4.3. LA INTERFAZ GR ´ AFICA 17 Figura 4.1: Men´u principal de la aplicaci´on Si el fichero no contuviera metadatos o se produjera alg´un error, se mostrar´ıa un aviso por pantalla con detalles de lo ocurrido En el ap´endice B, que contiene el manual de usuario, puede encontrase un recorrido en profundidad y con m´as im´agenes de la interfaz gr´afica as´ı como del funcionamiento de la aplicaci´on en general. 18 CAP´ ITULO 4. DISE ˜ NO DE LA APLICACI ´ ON Figura 4.2: Explorando el sistema de ficheros 5.4. OPINI ´ ON PERSONAL 25 5.4. Opini´on personal Comenzar un nuevo programa suele hacerse un poco cuesta arriba, pero comenzar un proyecto en el que se ha de hacer uso de un lenguaje y unas herramientas no utilizadas hasta el momento es un reto. Si adem´as se tiene en cuenta que este proyecto se ha realizado “a distancia”, en el que no se han fijado fechas l´ımite ni se ha controlado cu´anto tiempo dedicaba a su desarrollo, tambi´en ha resultado ser un interesante ejercicio de autodisciplina. Como puntos positivos hay que destacar el haber aprendido a utilizar un nuevo lenguaje y herramienta, el haber desarrollado una aplicaci´on para uno de los smartphones m´as populares del mercado y, naturalmente, el haber obtenido experiencia en lo que supone llevar a cabo por uno mismo un proyecto de tama˜no algo mayor a lo que se est´a acostumbrado. Me han gustado las facilidades que ofrece Xcode para desarrollar y lo r´apido que se adapta uno a programar en Objective C. Adem´as, la soluci´on para la internacionalizaci´on de aplicaciones me ha parecido acertada y he podido comprobar lo sencillo que resulta incorporar nuevos idiomas a un proyecto. Por contra, a veces el contacto con la empresa no ha sido todo lo fluido y r´apido que me habr´ıa gustado, pudiendo pasar semanas hasta recibir una respuesta. La fase de documentaci´on ha sido algo tediosa porque ha tenido mucha carga y las pruebas han sido bastante repetitivas: descargar, analizar a mano y comprobar con la aplicaci´on. Sin embargo, el principal punto negativo tiene que ver con el hecho de no poder probar la aplicaci´on en un dispositivo real si no es pagando una suscripci´on: a pesar de que Xcode incluye un simulador, no s´e hasta qu´e punto se limita el uso de memoria o la velocidad de procesamiento. No obstante, puesto que se ha minimizado en la medida de lo posible el uso de recursos, se espera un funcionamiento correcto. 26 CAP´ ITULO 5. CONCLUSIONES Ap´endice A Categor´ıas de MetaAnalyzer Para la clase MetaAnalyzer se ha creado una categor´ıa por formato de archivo analizable. A continuaci´on se detallan brevemente los formatos para los que a˜naden soporte. A.1. Categor´ıa 3gp 3gp sigue un formato de cajas muy imitar a los ´atomos del formato mov (secci´on A.8): cada una comienza con 4 bytes indicando el tama˜no total de la misma seguidos de otros 4 bytes con el tipo de caja de la que se trata. Los metadatos (si los hay), se encuentran en la caja “udta”, que a su vez est´a contenida por la caja “track” o ”moov”. El m´etodo principal de esta categor´ıa itera de caja en caja buscando “moov” y, seguidamente, busca dentro “udta” o “trak”, saltando el resto. Si se encuentra con la segunda, busca dentro la primera. Una vez la aplicaci´on encuentra la caja, itera sobre cada una de sus subcajas, extrayendo la informaci´on. No todas las subcajas tienen el mismo formato (aunque siempre manteniendo los primeros 8 bytes como se ha comentado antes), por lo que ha sido necesario implementar varios m´etodos para los distintos tipos. Por cada subcaja encontrada se actualizan los pares clave-valor del diccionario de metadatos, que es devuelto al finalizar el an´alisis. Documentaci´on sobre este formato puede encontrarse en [5]. A.2. Categor´ıa AIFF En esta categor´ıa se ha implementado la extracci´on de metainformaci´on tanto del formato AIFF como de AIFF-C. En ellos, al igual que en otros 28 AP´ ENDICE A. CATEGOR´ IAS DE METAANALYZER formatos, el fichero se estructura en “chunks”, cuyos primeros 8 bytes indican su tama˜no y tipo. En este formato los “chunks” que pueden contener datos son “COMT”, “AUTH” , “NAME”, “(c) ” y “ANNO”, por lo que el m´etodo implementado itera busc´andolos. Para cada uno de ellos se extraen los datos, en forma de cadena. En el caso de los comentarios (primer “chunk” de los comentados), aparece antes la fecha en la que se realiz´o, a la que se da formato y se a˜nade a la cadena. Adem´as, pueden aparecer varios “chunks” de comentario, por lo que el diccionario se actualiza a˜nadiendo los nuevos comentarios separados por la cadena “ |”. Documentaci´on sobre este formato puede encontrarse en [6]. A.3. Categor´ıa ASF En esta categor´ıa se incluye soporte para los archivos wma y wmv. Cada archivo est´a constituido por objetos, identificados por un “GUID” (Global Unique IDentifier) de 16 bytes, divididos en 4 n´umeros. Los tres primeros, de 4, 2 y 2 bytes, respectivamente, se almacenan en little endian, mientras el ´ultimo, de 8 bytes, en big endian. Adicionalmente, este formato utiliza little endian, por lo que hay que invertir el endian. En esta categor´ıa se define una estructura de datos para leer y almacenar los “GUID” de forma m´as c´omoda. Siguiendo a estos 16 bytes aparecen 8 bytes indicando el tama˜no del objeto, de forma que los que no nos interesan pueden ser saltados. Los objetos a analizar en este formato se encuentran dentro de la cabecera, o Header Object, y son: Content Descriptor Object,Extended Content Descriptor Object,Content Branding Object yHeader Extension Object, que contiene a su vez Metadata Object yMetadata Library Object. Para cada uno de estos objetos se ha implementado un m´etodo espec´ıfico que extrae los datos. Documentaci´on sobre este formato puede encontrarse en [7]. A.4. Categor´ıa gif Para implementar esta categor´ıa se ha tomado como referencia el implementado por Sean M. Burke (sburk[email protected]) en python [9] debido a que la documentaci´on encontrada resultaba ligeramente confusa en algunos aspectos. A.5. CATEGOR´ IA HTML 29 Los ficheros gif se componen de bloques, de los cuales interesa el bloque de comentarios. A diferencia de otros formatos, los bloques gif no tienen un indicador del tama˜no del mismo. Adem´as, no es sencillo identificar d´onde comienza un nuevo bloque. Sin embargo, lo que s´ı aparece es el identificador del bloque, por lo que resulta posible saltar aqu´ellos que aparezcan y sean conocidos. Se han implementado m´etodos para dejar atr´as los bloques Image Descriptor yLogical Screen Descriptor, que pueden tener un tama˜no variable. Los comentarios se encuentran en los Extension Block que contienen a su vez 0 ´o m´as subbloques, precedidos por su tama˜no. En este caso, s´ı es posible saltarlos en el caso de que no se trate de un subbloque de comentarios. Si se encuentra uno de este tipo, se extrae la informaci´on y se incorpora al diccionario, concatenando su contenido al ya existente. Documentaci´on sobre este formato puede encontrarse en [8]. A.5. Categor´ıa HTML Los archivos HTML, que son ficheros de texto, suelen tener una cabecera al comienzo donde pueden incluirse metadatos, que siguen el esquema <meta name=“clave” content=“valor”>. El m´etodo implementado busca apariciones de esta cadena dentro de la cabecera y extrae las claves y valores, que a˜nade al diccionario. Para las claves conocidas se crea una cadena localizable como clave. Si no, se usa la clave original. M´as informaci´on sobre la cabecera de archivos HTML puede encontrarse en [10]. A.6. Categor´ıa iWork A diferencia del formato mov (secci´on A.8), tambi´en perteneciente a Apple, para el que la documentaci´on es extensa, la informaci´on sobre los archivos pertenecientes al paquete de ofim´atica iWork, Keynotes,Numbers yPages, es extremadamente escasa. Para obtener algo sobre lo que trabajar se envi´o un correo a Apple pidiendo documentaci´on, de qui´en se recibi´o la respuesta “the information you have requested regarding Pages, Numbers, and Keynotes file format is not a benefit of our developer programs” (la informaci´on que ha solicitado en relaci´on a los formatos Pages, Numers y Keynotes no est´a disponible para nuestros programas developer). 30 AP´ ENDICE A. CATEGOR´ IAS DE METAANALYZER Si se abre un fichero de este tipo con un editor hexadecimal, se puede ver que el comienzo coincide con el de un fichero zip. Es m´as, si se cambia la extensi´on al archivo, se podr´a abrir con un descompresor zip est´andar. Los archivos de iWork, juntos con los de Microsoft Office a partir de la versi´on del 2003 (secci´on A.12), utilizan este formato y, por tanto, la clase ZipArchive (secci´on 4.2.3). Si se descomprime un archivo de este tipo, seg´un de cu´al se trate, aparece un archivo “index.xml” (en Pages yNumer) o “index.apxl” (en Keynotes). El an´alisis de estos archivos ha indicado que pueden contener metainformaci´on. Adem´as, siempre aparece en las primeras l´ıneas la versi´on del software utilizado. El m´etodo desarrollado descomprime el fichero en un directorio temporal y analiza el XML (secci´on A.18) correspondiente para extraer los datos, que se devuelven en un diccionario al terminar. A.7. Categor´ıa jpg Los ficheros jpg est´an constituidos por segmentos, que comienzan con 2 bytes de identificaci´on y otros 2 con el tama˜no. Los metadatos pueden encontrase en el segmento APP1, identificado por 0xFFE1, y en el APP13, 0xFFED. El primero puede almacenar datos en el formato “Exif”, para el que se utiliza un m´etodo de la categor´ıa tiff (secci´on A.17), o en formato “XMP” (secci´on A.19); el segundo, por su parte, puede contener informaci´on a˜nadida por la herramienta Photoshop. Para este segmento concreto se han creado una serie de m´etodos espec´ıficos dentro de la categor´ıa. Documentaci´on sobre este formato puede encontrase en [11]. A.8. Categor´ıa mov El formato mov se construye sobre una estructura de ´atomos y sub´atomos. Cada uno de ellos comienza con 4 bytes destinados al identificador seguidos de otros 4 bytes para el tama˜no, que incluye estos 8 bytes. El ´atomo en el que buscar datos utiliza el identificador “meta”, y puede aparecer hasta uno dentro de cada ´atomo “moov”, “trak” y “mdia”. El m´etodo principal itera sobre los ´atomos del fichero, saltando los que no interesan y llamando a otro m´etodo si encuentra alguno de estos tres. Este segundo m´etodo se encarga de buscar “meta” entre los sub´atomos. Si aparece alguno de los tres nombrados al principio, se realiza una llamada recursiva. Una vez se ha encontrado un ´atomo “meta”, desde un tercer m´etodo se extraen primero las claves de los metadatos, que se encuentran en el A.9. CATEGOR´ IA MP3 31 sub´atomo “keys”, y, seguidamente, los valores, almacenados en “ilst”. Los datos pueden ser cadenas, enteros, flotantes, etc. El m´etodo los transforma a cadena y los incorpora al diccionario. Tambi´en podr´ıa darse el caso de aparecer una imagen como metadato, pero el soporte para im´agenes todav´ıa no est´a implementado y por el momento s´olo se muestra la cadena localizada “Imagen”. Documentaci´on sobre este formato puede encontrase en [12]. A.9. Categor´ıa mp3 Los ficheros mp3, utilizados para almacenar m´usica, suelen llevar como prefijo una cabecera de tipo ID3v2 con informaci´on sobre el mismo. La categor´ıa incluye m´etodos para soportar este tipo de archivos. Al comienzo del archivo aparece la versi´on de cabecera utilizada y el tama˜no de la misma. Si la versi´on no est´a soportada, el an´alisis se detiene y se avisa al usuario. El tama˜no de la cabecera viene indicado por 4 bytes, utiliz´andose s´olo 7 bites de cada uno, descartando el de m´as peso. En total, 28 bites efectivos que se unen mediante desplazamientos. La cabecera est´a compuesta por “frames”. Cada uno contiene un identificador de 4 bytes seguido de otros 4 indicando su tama˜no. Hay varios “frames” que contienen datos que pueden resultar relevantes. Para cada tipo de ellos se ha implementado un m´etodo que extrae la informaci´on. Adicionalmente, para el caso concreto del “frame” “TCON”, que contiene informaci´on sobre el g´enero musical, se ha creado un archivo con una tabla con todos los g´eneros . Seg´un la informaci´on sobre este formato hay 126 distintos definidos, que pueden aparecer identificados con un valor num´erico entre 0 y 125, por lo que la tabla permite una traducci´on r´apida. Por el momento no se han localizado las cadenas de texto para cada g´enero. Documentaci´on sobre este formato puede encontrarse en [13]. A.10. Categor´ıa mp4 El formato contenedor mp4 es muy similar al formato mov (secci´on A.8). Esto ha resultado importante porque en este caso no se dispon´ıa de documentaci´on gratuita, solamente de la ISO asociada [14]. Haciendo uso de editores hexadecimales para analizar los distintos ficheros se han podido desarrollar los m´etodos espec´ıficos para este formato. Los ficheros est´an organizados en ´atomos, que comienzan con su tama˜no e identificador, ambos de 4 bytes. Interesa encontrar el ´atomo “meta”, contenido por “udta”. A su vez, este ´atomo puede estar dentro de “trak” o 32 AP´ ENDICE A. CATEGOR´ IAS DE METAANALYZER “moov”. Tambi´en pueden darse casos en los que aparecen ´atomos “meta” adicionales dentro de “meco” (metadata container). La b´usqueda se realiza analizando los ´atomos y sub´atomos de forma recursiva. Una vez en “meta”, se analiza una lista de ´ıtems en el sub´atomo “ilst”, donde, para cada ´atomo, se analiza el contenido, se decide si es de inter´es y, si lo es, se incorpora al diccionario. Se ha observado que, en ocasiones, dentro de la lista aparece la clave “Xtra”, que es en realidad un sub´atomo de “ilst” donde se almacenan metadatos de forma similar al formato ASF (secci´on A.3). Esto es as´ı, presumiblemente, porque los datos fueron a˜nadidos desde un ordenador con windows. No se han encontrado archivos con metadatos en este sub´atomo con formato distinto, pero podr´ıan existir. La aplicaci´on soporta s´olo el aqu´ı explicado. A.11. Categor´ıa Office binario Los ficheros de Micrososft Office hasta la versi´on del 2003 utilizan un formato binario que se asemeja mucho al sistema de archivos FAT: el fichero contiene streams a las que se les asigna un determinado espacio dentro del fichero; para saber d´onde se encuentra una stream concreta hay que acceder a la tabla de asignaci´on y obtener los sectores (o incluso “mini-sectores”) en los que se encuentra. Como ya se comenta en los problemas encontrados (secci´on 5.1), la documentaci´on oficial de Microsoft acerca de este formato resulta un tanto confusa, mientras que la ofrecida por Open Office es m´as aclaratoria. Para poder extraer metainformaci´on de este tipo de archivos, hay que buscar y analizar las streams DocSummaryInfo ySummaryInfo. Esta categor´ıa define m´etodos que construyen las distintas tablas de asignaci´on en memoria y pasan a analizar el nodo ra´ız de directorios. A partir de ´el se puede obtener el identificador de stream de las buscadas, para acceder a ellas despu´es gracias a las tablas previamente obtenidas. Puesto que los datos pueden estar contenidos en diversos sectores, que pueden no ser consecutivos, se hizo indispensable implementar un m´etodo de lectura que tuviera en cuenta si al leer del fichero era necesario cambiar de posici´on el puntero por acabarse un sector y comenzar otro. Tambi´en se le a˜nadi´o funcionalidad para poder leer de “mini-sectores”. De esta forma, se puede realizar una lectura del fichero de forma transparente. Para cada una de las streams de inter´es se ha creado un m´etodo espec´ıfico para extraer la informaci´on. Tambi´en existen m´etodos adicionales de apoyo que calculan offsets, fechas, tiempo invertido y que traducen los identificadores de clave a cadenas localizadas. A.12. CATEGOR´ IA OFFICE ZIP 33 Documentaci´on oficial de este formato en [15]. La documentaci´on facilitada por Open Office puede encontrase en [16]. A.12. Categor´ıa Office zip A partir de la versi´on 2003 de Microsft Office, los archivos de este paquete de ofim´atica utilizan el formato zip, del mismo modo que se hace en los archivos de iWork (secci´on A.6). El m´etodo implementado descomprime el archivo y busca dentro de la carpeta “docProps” los archivos “core.xml” y “app.xml”, que posteriormente env´ıa a un m´etodo espec´ıfico de la categor´ıa XML (secci´on A.18) para su an´alisis. Documentaci´on de Microsoft sobre este formato en [17]. A.13. Categor´ıa ogg Los archivos ogg utilizan una estructura de p´aginas para almacenar la informaci´on, estando cada una dividida en segmentos. Al comienzo de ella, tras los 4 bytes con “OggS” y un byte a 0, se indica el tipo de la p´agina. Algo despu´es aparece el n´umero de lacing values, que indica la cantidad de segmentos que aparecen en la p´agina. Los tama˜nos de ´estos aparecen a continuaci´on, todos juntos, de la siguiente manera: se leen bytes que se van sumando hasta que aparece un valor inferior a 0xFF (255), que tambi´en se suma, que indica el final del tama˜no de ese segmento; a continuaci´on se lee el tama˜no del siguiente segmento. Esto se repite tantas veces como lacing values. Una vez se han calculado los tama˜nos de los segmentos, se itera sobre ellos, saltando los que no sean comentarios. Cuando se encuentra uno de este tipo, se llama a un m´etodo que extrae la informaci´on y actualiza el diccionario con los valores obtenidos. Documentaci´on sobre el formato puede encontrarse en [18]. A.14. Categor´ıa pdf El formato pdf se estructura en objetos y su an´alisis comienza por el final del fichero, que deber´ıa estar marcado con la cadena “ % %EOF”. Los ficheros pdf hacen uso, seg´un la documentaci´on, de los saltos de l´ınea para separar las cosas. Sin embargo, como se comentar´a m´as adelante, esto no siempre se cumple. 34 AP´ ENDICE A. CATEGOR´ IAS DE METAANALYZER La l´ınea anterior al final del fichero indica el offset de la tabla de referencias, que contiene los offset de los distintos objetos en el fichero. Siguiendo la lectura hacia atr´as, se encuentra el trailer, que detalla algunos aspectos del archivo: d´onde se encuentra la anterior tabla de referencias (que, si aparece, se habr´a de tener en cuenta en lugar de la anteriormente le´ıda), el n´umero total de objetos, cu´al es el objeto ra´ız y cu´al es el objeto de informaci´on. Con la tabla de referencias construida y los offset calculados, gracias a otro m´etodo, es posible acceder a cualquier objeto dentro del fichero. En concreto se accede a los dos ´ultimos objetos mencionados, si est´an presentes, que son analizados en busca de metainformaci´on por m´etodos espec´ıficos. El objeto ra´ız no contiene metadatos en s´ı mismo, pero puede tener una referencia a un objeto “metadata” que encapsula c´odigo XML, que es procesado por la categor´ıa asociada (secci´on A.18). Pdf es un formato muy utilizado y numerosos programas ofrecen la posibilidad de exportar documentos a este formato. Lamentablemente, como ya se ha comentado en los problemas encontrados (secci´on 5.1), en ocasiones la especificaci´on no se respeta completamente y ha sido com´un encontrar ficheros que no inclu´ıan saltos de l´ınea o espacios cuando deb´ıan estar presentes o que ten´ıan estructuras ligeramente distintas. Por ello, los m´etodos se han hecho algo menos estrictos, permitiendo que soporten tambi´en las variaciones encontradas. Documentaci´on sobre el formato puede encontrarse en [19]. A.15. Categor´ıa RIFF En el formato RIFF (wav y avi, por ejemplo, utilizan este formato) se vuelve a utilizar el sistema de “chunks” o ´atomos visto anteriormente. En este caso se busca el identificado como “LIST”, as´ı que se saltan “chunks” hasta que se encuentra uno de este tipo. Una vez en ´el, se obtiene de que tipo es, ya que ´unicamente interesa el de tipo “INFO”. Una vez se ha encontrado el punto donde se almacenan los datos, se itera dentro del contenedor, obteniendo la clave del dato, la longitud del valor y el valor en s´ı mismo, que son a˜nadidos al diccionario. Documentaci´on sobre el formato puede encontrase en [20]. A.16. Categor´ıa rtf Los ficheros rtf, a diferencia de la gran mayor´ıa de los formatos explicados hasta ahora, son de tipo texto. Incorporan una cabecera que puede contener 41 el nombre del directorio o su accesorio, se actualiza la tabla con los contenidos del nuevo directorio as´ı como la etiqueta superior, para que contenga el nombre del nuevo directorio. Si se produce un error al cambiar de directorio, se mantiene el actual y se notifica al usuario con una alerta (fig. B.5). Figura B.5: Se alerta al usuario si no se puede cambiar de directorio Mientras se muestra el directorio ra´ız no es posible subir un directorio, por lo que el bot´on “Atr´as” aparece desactivado (fig. B.6). Figura B.6: No hay directorios por encima de la ra´ız 42 AP´ ENDICE B. MANUAL DE USUARIO Al presionar un archivo, la aplicaci´on comprueba de qu´e tipo es y comienza su exploraci´on en busca de metadatos. Si el tipo de fichero no estuviera soportado o el formato del mismo fuera incorrecto, se mostrar´ıa una alerta con el aviso (figuras B.7 y B.8, respectivamente). La aplicaci´on tambi´en mostrar´ıa una alerta si surgiesen problemas al abrir o descomprimir un archivo, si la versi´on del formato no estuviera soportada (fig B.9) o en el caso de que ocurriese un error inesperado. Figura B.7: Alerta si el tipo de fichero no est´a soportado Si el an´alisis del fichero resulta exitoso y el fichero conten´ıa metainformaci´on, la aplicaci´on mostrar´a una nueva vista con los resultados (fig. B.10). En cada secci´on el t´ıtulo indica el tipo del metadato y a continuaci´on aparecen tantas filas como metadatos de ese tipo estuvieran almacenados en el archivo. En la figura B.11 aparece un ejemplo en el que un archivo contiene varias entradas para un mismo tipo. Podr´ıa ocurrir, no obstante, que pese a que el an´alisis de un fichero haya sido posible, ´este no contuviera metadatos de inter´es. En ese caso la aplicaci´on mostrar´a una alerta avisando de ello al usuario (fig. B.12). 43 Figura B.8: Alerta si el formato del fichero no est´a soportado 44 AP´ ENDICE B. MANUAL DE USUARIO Figura B.9: Alerta si la versi´on del formato no est´a soportada 45 Figura B.10: El fichero conten´ıa metainformaci´on 46 AP´ ENDICE B. MANUAL DE USUARIO Figura B.11: Ejemplo de fichero con varias entradas para el mismo tipo de metadato 47 Figura B.12: El fichero no conten´ıa metadatos 48 AP´ ENDICE B. MANUAL DE USUARIO La aplicaci´on ajusta su idioma autom´aticamente al seleccionado en el dispositivo1, siempre y cuando est´e disponible la traducci´on. Si se selecciona ingl´es o un idioma a´un no soportado, la aplicaci´on se mostrar´a en ingl´es. En la siguiente figura se puede ver el aspecto de la aplicaci´on en este caso. Figura B.13: La aplicaci´on ajusta su idioma al seleccionado en el dispositivo Actualmente la aplicaci´on se encuentra disponible en alem´an, espa˜nol, ingl´es y ruso. Adem´as, gracias a la internacionalizaci´on realizada en ella, es posible traducirla de forma sencilla a otros lenguajes: tan s´olo hay que a˜nadir un fichero strings con las cadenas en el idioma correspondiente, siguiendo el mismo esquema de los ya disponibles. 1La configuraci´on de idioma del dispositivo se realiza en Ajustes / General / Internacional / Idioma Ap´endice C Pruebas Durante el desarrollo del proyecto ha habido dos fases de pruebas diferentes: la primera ha abarcado el desarrollo de la clase principal MetaAnalyzer, prob´andose archivos del tipo apropiado cada vez que se realizaba una nueva categor´ıa, para comprobar su correcto funcionamiento. Despu´es, una vez que la interfaz gr´afica fue dise˜nada, lleg´o la segunda fase de pruebas, en la que se generaron nuevos archivos, para comprobar que la informaci´on se obten´ıa correctamente, y se obtuvieron ficheros de distintos lugares para comprobar que no se produc´ıan errores durante la ejecuci´on. Por ejemplo, con Photoshop se crea un archivo en el que se introduce metainformaci´on como se ve en la figura C.1. Seguidamente se comprueba con un editor hexadecimal que los datos est´an all´ı (fig. C.2. En este caso, los datos est´an en el segmento APP13 (ver A.7) del fichero jpg, que efectivamente ha de contener estos datos seg´un la especificaci´on [11]. Cuando se lanza la aplicaci´on y se analiza el fichero en cuesti´on, los metadatos son recuperados correctamente (fig. C.3). 50 AP´ ENDICE C. PRUEBAS Figura C.1: Creando un fichero con metadatos 57 Figura C.8: Pueden aparecer metadatos con otros alfabetos 58 AP´ ENDICE C. PRUEBAS Figura C.9: La aplicaci´on puede mostrar texto en otros alfabetos Bibliograf´ıa [1] Stephen G. Kochan: Programming in Objective C 2.0, Addison-Wesley Professional, ISBN-10: 0321566157. [2] Documentaci´on office de Apple sobre la internacionalizaci´on: http://developer.apple.com/library/ios/#documentation/ MacOSX/Conceptual/BPInternational/BPInternational.html. [3] P´agina del proyecto ZipArchive: http://code.google.com/p/ ziparchive/. [4] P´agina del proyecto LineReader: https://github.com/johnjohndoe/ LineReader. [5] Documentaci´on del formato 3gp: http://www.3gpp.org/ftp/Specs/ archive/26_series/26.244/26244-930.zip, archivo zip. [6] Documentaci´on del formato AIFF: http://bellatrix.ece.mcgill. ca/Documents/AudioFormats/AIFF/AIFF.html. [7] Documentaci´on del formato ASF: http://www.microsoft.com/ download/en/details.aspx?displaylang=en&id=14995. [8] Documentaci´on del formato gif: http://www.martinreddy.net/gfx/ 2d/GIF89a.txt. [9] Algoritmo en python de Sean M. Burke: http://interglacial.com/ ~sburke/pub/list_gif_comments.pl. [10] Documentaci´on del formato HTML: http://www.comptechdoc.org/ independent/web/html/guide/htmlhead.html. [11] Documentaci´on del formato jpg: http://www.metadataworkinggroup. org/pdf/mwg_guidance.pdf. [12] Documentaci´on del formato mov: http://developer.apple.com/ library/mac/#documentation/QuickTime/QTFF/QTFFPreface/ qtffPreface.html. 60 BIBLIOGRAF´ IA [13] Documentaci´on del formato mp3: http://www.id3.org/id3v2.3.0. [14] ISO del formato mp4: http://www.iso.org/iso/iso_catalogue/ catalogue_tc/catalogue_detail.htm?csnumber=38538. [15] Documentaci´on oficial del formato binario de Office: http://msdn. microsoft.com/en-us/library/dd942265(v=prot.10).aspx. [16] Documentaci´on de Open Office sobre el formato binario de Office: http: //sc.openoffice.org/compdocfileformat.pdf. [17] Documentaci´on del formato zip de Office: http://msdn.microsoft. com/en-us/library/aa338205(v=office.12).aspx. [18] Documentaci´on del formato ogg: http://www.xiph.org/ogg/doc/. [19] Documentaci´on del formato pdf: http://partners.adobe.com/ public/developer/en/pdf/PDFReference.pdf. [20] Documentaci´on del formato RIFF: http://www-mmsp.ece.mcgill. ca/documents/audioformats/wave/Docs/riffmci.pdf. [21] Documentaci´on del formato rtf: http://www.biblioscape.com/ rtf15_spec.htm#Heading25. [22] Documentaci´on del formato tiff: http://partners.adobe.com/ public/developer/en/tiff/TIFF6.pdf. ´ Indice de figuras 4.1. Men´u principal de la aplicaci´on . . . . . . . . . . . . . . . . . 17 4.2. Explorando el sistema de ficheros . . . . . . . . . . . . . . . . 18 4.3. Los datos se muestran en una nueva pantalla . . . . . . . . . 19 5.1. Esquema del reparto de horas . . . . . . . . . . . . . . . . . . 24 B.1. Icono de la aplicaci´on en el dispositivo . . . . . . . . . . . . . 37 B.2. Men´u al iniciar la aplicaci´on . . . . . . . . . . . . . . . . . . . 38 B.3. Acerca de iMetadata . . . . . . . . . . . . . . . . . . . . . . . 39 B.4. Explorando el sistema de ficheros . . . . . . . . . . . . . . . . 40 B.5. Se alerta al usuario si no se puede cambiar de directorio . . . 41 B.6. No hay directorios por encima de la ra´ız . . . . . . . . . . . . 41 B.7. Alerta si el tipo de fichero no est´a soportado . . . . . . . . . . 42 B.8. Alerta si el formato del fichero no est´a soportado . . . . . . . 43 B.9. Alerta si la versi´on del formato no est´a soportada . . . . . . . 44 B.10.El fichero conten´ıa metainformaci´on . . . . . . . . . . . . . . 45 B.11.Ejemplo de fichero con varias entradas para el mismo tipo de metadato ............................. 46 B.12.El fichero no conten´ıa metadatos . . . . . . . . . . . . . . . . 47 B.13.La aplicaci´on ajusta su idioma al seleccionado en el dispositivo 48 C.1. Creando un fichero con metadatos . . . . . . . . . . . . . . . 50 C.2. Con el editor hexadecimal se comprueba que los datos est´an dondedeben............................ 51 C.3. Los metadatos introducidos son extra´ıdos correctamente . . . 52 C.4. Datos que se van a almacenar al crear un archivo mov . . . . 53 62 ´ INDICE DE FIGURAS C.5. Se comprueba con el editor hexadecimal que los datos est´an presentes en el archivo . . . . . . . . . . . . . . . . . . . . . . 54 C.6. Se extraen los datos con la aplicaci´on . . . . . . . . . . . . . . 55 C.7. Se han utilizado motores de b´usqueda para encontrar archivos deprueba ............................. 56 C.8. Pueden aparecer metadatos con otros alfabetos . . . . . . . . 57 C.9. La aplicaci´on puede mostrar texto en otros alfabetos . . . . . 58 4.3. LA INTERFAZ GR ´ AFICA 17 Figura 4.1: Men´u principal de la aplicaci´on Si el fichero no contuviera metadatos o se produjera alg´un error, se mostrar´ıa un aviso por pantalla con detalles de lo ocurrido En el ap´endice B, que contiene el manual de usuario, puede encontrase un recorrido en profundidad y con m´as im´agenes de la interfaz gr´afica as´ı como del funcionamiento de la aplicaci´on en general. 18 CAP´ ITULO 4. DISE ˜ NO DE LA APLICACI ´ ON Figura 4.2: Explorando el sistema de ficheros 4.3. LA INTERFAZ GR ´ AFICA 19 Figura 4.3: Los datos se muestran en una nueva pantalla 38 AP´ ENDICE B. MANUAL DE USUARIO Figura B.2: Men´u al iniciar la aplicaci´on 45 Figura B.10: El fichero conten´ıa metainformaci´on 46 AP´ ENDICE B. MANUAL DE USUARIO Figura B.11: Ejemplo de fichero con varias entradas para el mismo tipo de metadato 47 Figura B.12: El fichero no conten´ıa metadatos 48 AP´ ENDICE B. MANUAL DE USUARIO La aplicaci´on ajusta su idioma autom´aticamente al seleccionado en el dispositivo1, siempre y cuando est´e disponible la traducci´on. Si se selecciona ingl´es o un idioma a´un no soportado, la aplicaci´on se mostrar´a en ingl´es. En la siguiente figura se puede ver el aspecto de la aplicaci´on en este caso. Figura B.13: La aplicaci´on ajusta su idioma al seleccionado en el dispositivo Actualmente la aplicaci´on se encuentra disponible en alem´an, espa˜nol, ingl´es y ruso. Adem´as, gracias a la internacionalizaci´on realizada en ella, es posible traducirla de forma sencilla a otros lenguajes: tan s´olo hay que a˜nadir un fichero strings con las cadenas en el idioma correspondiente, siguiendo el mismo esquema de los ya disponibles. 1La configuraci´on de idioma del dispositivo se realiza en Ajustes / General / Internacional / Idioma 51 Figura C.2: Con el editor hexadecimal se comprueba que los datos est´an donde deben 52 AP´ ENDICE C. PRUEBAS Figura C.3: Los metadatos introducidos son extra´ıdos correctamente 53 En otra prueba, se crea un archivo mov desde un ordenador de Apple con las caracter´ısticas mostradas en la figura C.4. Figura C.4: Datos que se van a almacenar al crear un archivo mov De nuevo, se comprueba con el editor hexadecimal que los datos est´an presentes y aparecen en el ´atomo “meta” (fig. C.5). Finalmente, se utiliza la aplicaci´on para comprobar que los resultados son los esperados (fig. C.6). 54 AP´ ENDICE C. PRUEBAS Figura C.5: Se comprueba con el editor hexadecimal que los datos est´an presentes en el archivo 55 Figura C.6: Se extraen los datos con la aplicaci´on 57 Figura C.8: Pueden aparecer metadatos con otros alfabetos