¿Qué es un virus “ransomware”?

Es un código malicioso que al ejecutarse ataca algunos archivos de usuario encriptándolos y dejándolos inutilizables. Dicho código generalmente llega a través de archivos adjuntos a men-sajes de correo electrónico no deseado (spam). Los mensajes suelen indicar que son una orden de compra o el comprobante de una transferencia bancaria, el número de seguimiento de un paquete, etc. La idea es que enviando masivamente ese tipo de mensajes, alguna persona que está esperando una orden de compra, etc. sentirá curiosidad por ver el adjunto y así recibirá el ataque. Se llaman ransom-ware porque constituyen una extorsión o pedido de rescate al creador de ese código que en teoría, contra recepción de un pago devolverá un software y las llaves necesarias para desencriptar los archivos. Como en cualquier situación de secuestro, las víctimas lidian con delincuentes con comportamientos impredecibles. No se trata de una sim-ple transacción comercial. El fenómeno del ransomware está muy atomizado, por lo que no se puede afirmar que cierto código produce determinado daño y que con el pago del rescate la víctima efectivamente resuelve su problema.
Además, claro, está la dimensión ética: si cada víctima pagase el rescate, le estaría dando a los delincuentes enormes recursos económicos para inversiones en infraestructura y desarrollo que les permitan aumentar y perfeccionar sus delitos.
Los pagos de rescates se realizan por medios electrónicos, empleando criptomonedas como el Bitcoin en la expectativa de mantener el anonimato. Sin embargo se ha conseguido atrapar a varias bandas dedicadas a estos delitos.

¿Es posible recuperar datos de un disco atacado por un virus de tipo ransomware?

La gente suele creer que los archivos atacados se convirtieron instantáneamente en datos inaccesibles. En realidad estos códigos maliciosos primero generan una copia de ciertos archivos aplicándoles una encriptación fuerte, que en general no es susceptible de ser quebrada por ataques de fuerza bruta –aunque siempre hay que verificar. En una segunda instancia borran los archivos originales en modo seguro, es decir, tratando de que no sean más recuperables. Ese proceso tiene tiempos de ejecución, consumen recursos de RAM y procesador. A veces el usuario al darse cuenta del ataque puede interrumpir el proceso, por ejemplo apagando la computadora y limitando el daño.
Cada código malicioso de esas características tiene sus variantes y además hay que ver cómo actuó sobre una partición en particular, durante cuánto tiempo, etc. De allí que a veces sea factible conseguir recuperaciones de archivos, al menos parciales. Hay que tomarse el trabajo de analizar cada caso en particular si es que los datos revisten importancia. Por lo comentado más arriba, para que el virus actúe es preciso tener capacidad de procesamiento disponible, espacio en RAM y espacio en disco. Por ejemplo si la partición atacada estaba muy llena es posible que el virus pueda hacer menos daño o que la ejecución lleve más tiempo o que se cuelgue el equipo. En todos esos casos el perjuicio sería menos generalizado.

¿Tienen la solución para el Cryptowall 2.15?

Esta pregunta es análoga a consultar si existe un antídoto para contrarrestar los efectos tóxicos que produce una pastillita lila con una letra S que venden en una fiesta electrónica. La gente tiende a creer que los códigos maliciosos son creados por empresas de software establecidas que cumplen normas de calidad. En realidad cada código tiene sus particularidades. En internet incluso existen “kits” para la creación de códigos ransomware de modo que cada uno pueda iniciar su emprendimiento delictivo. En síntesis: 1) cada código tiene sus particularidades. 2) hay que ver qué daño provocó un código particular en una partición particular.
En teoría si todo salió como planificó el creador del virus, los datos no tendrían que ser más recuperables a menos que paguemos el rescate. Sin embargo la experiencia nos muestra que a menudo por defectos del código o bien por deficiencias en la ejecución en un equipo en particular, quedan archivos que pueden rescatarse. En general las soluciones que se pueden ofrecer son parciales.
Por ejemplo hace pocos días recibimos una consulta de una empresa financiera de Mar del Plata. Lo más crítico eran nueve archivos de tipo DBF. Cuatro estaban efectivamente encriptados con una codificación no susceptible de ser revertida en tanto que cinco tenían una corrupción al principio pero tenían más del 90% de los datos en bruto perfectamente recuperables.
Además en los discos suelen residir varias versiones de los archivos más usados así como copias temporarias. Esos archivos borrados y/o ocultos en general son omitidos por los virus y si son rescatados pueden colaborar a solucionar el problema.
Quien diseña un virus de estas características tiene que definir cuáles serán los archivos objetivo. No se atacan los archivos del sistema operativo ni programas porque la idea es que el usuario pueda seguir arrancando su sistema y constatar por sus propios medios que los archivos de trabajo no funcionan. En general establecen criterios por tipos de archivos (extensiones) y/o por fechas de modificación. Además hay varios factores que pueden impedir o limitar la ejecución “exitosa” del virus. Eso explica que muchos usuarios detallan que algunos archivos fueron encriptados y otros no.

¿Qué ofrecemos?

Ofrecemos una consultoría para determinar si hay datos recuperables luego de un ataque de virus. El análisis lleva entre dos y tres días hábiles y tiene un costo fijo que se abona anticipadamente.
Conviene siempre analizar el disco original que sufrió el ataque y no una copia de los archivos.
Una vez analizado le enviaremos al cliente un diagnóstico y presupuesto para la recuperación de archivos.
En caso de que el recupero se lleve a cabo, el cargo de diagnóstico se descuenta del total a pagar.
El disco tiene que venir con su correspondiente formulario de solicitud de servicio completado donde el cliente indicará los detalles del problema y qué datos se requiere recuperar.

Ricardo Pons © 2016

A menudo los fotógrafos pierden archivos, los borran por error o formatean la tarjeta para luego darse cuenta de que falta alguna foto o video. En esos casos recurren a programas automáticos de recuperación de datos que encuentran los archivos perdidos. El éxito de la operación depende de que los bloques que los constituían no hayan sido ocupados por nuevos archivos.
En el caso de cámaras Canon ese truco generalmente no funciona para archivos de video. Los usuarios consiguen restaurar una estructura coherente de directorios y archivos pero los archivos de video están corruptos, y lo que es más extraño, aparecen unos archivos de tipo DAT que no parecen contener nada útil.

Confidencialidad y Seguridad Informática

En nuestro artículo de reseña del funcionamiento del sistema de archivos de FAT16 habíamos rozado el tema de la seguridad de la información. Comentábamos que si un cluster o unidad de asignación se escribe parcialmente (por ejemplo un cluster de 32768 B es ocupado por un archivo de 1000 B, quedan los 31768 B sin ser escritos y se puede leer parcialmente la información que tal vez ocupaba un archivo borrado en esa ubicación). Esto permite dos cosas, por un lado que un especialista en el sistema operativo oculte información confidencial en partes no utilizadas de un cluster, pero por otro lado, que la información que uno creía borrada o sobreescrita, pueda ser accedida por medios no convencionales. Es decir, ¡la información continúa allí!

Comentábamos también (no profundizaremos aquí en la implementación concreta) que el sistema de archivos NTFS de Windows NT (un sistema que cumple con más pautas de seguridad que Windows y DOS) devuelve ceros cuando se intenta acceder a clusters utilizados parcialmente. Es decir que en el caso anterior, NT dará acceso a los primeros 1000 Bytes pero cuando queramos acceder al resto del cluster en la pantalla veremos la información original transformada en ceros, aunque en el disco permanezca grabada.

En esta serie de artículos de difusión técnica nos propusimos dar solamente contenido técnico y evitar todo lo que pudiese parecer material publicitario encubierto. Sin embargo en esta ocasión, para lograr el primer objetivo nos vemos obligados describir procedimientos de nuestro laboratorio de recuperación de información.

Cada día recibimos más consultas acerca del tema de la confidencialidad de la información contenida en los sistemas informáticos. Es decir, los potenciales clientes quieren saber quién va a manejar su información y qué garantía le ofrece nuestro servicio de que los datos no van a hacerse públicos.

En CompExcell hemos hecho trabajos para la policía, los militares, funcionarios del gobierno, instituciones bancarias públicas y privadas, abogados y diputados que tenían causas importantes y secretas cargadas en sus discos, etc. Yo a menudo respondo a la inquietud acerca de la confidencialidad explicando en qué consiste nuestro negocio. Nosotros hemos desarrollado técnicas y herramientas de hardware y software y tenemos un laboratorio especializado en almacenamiento de información que permanentemente es mejorado y actualizado. El negocio es que esas herramientas y ese laboratorio estén permanentemente trabajando recuperando exitosamente la información perdida de la mayor cantidad posible de usuarios. Esta tarea se tiene que realizar a una proporción costo/beneficio conveniente (para que el cliente acepte pagar los honorarios) y –last but not least- en la menor cantidad de tiempo posible.

Resumiendo:

1) inversión en infraestructura e Investigación y Desarrollo

2) eficiencia costo/beneficio

3) optimización de tiempos

A menudo los discos llegan al laboratorio con problemas electromecánicos, magnéticos o electrónicos. Se debe determinar el grado de daño del disco y elegir los métodos a ser aplicados para la recuperación (es común que para diferentes partes del disco se empleen distintas metodologías). Antes de realizar la recuperación en forma extensiva se comprueba que la información se recupere consistentemente con un muestreo de archivos de formato conocido. Por ejemplo si se trata de bases de datos se eligen algunas, las más grandes posibles y se las chequea con un visualizador de bases de datos. Por regla general si los archivos más grandes funcionan también lo harán los más chicos. Este es el primer momento en el que vemos contenidos de la información del cliente. Claro que para cumplir con los puntos 2 y 3 el muestreo será lo más breve posible, sólo como para justificar la elección del método.

Por otro lado cabe mencionar que el muestreo se realiza sobre la información solicitada por el usuario como prioritaria a ser rescatada. Muchas veces ocurre que se rescatan muchos archivos que no se chequean explícitamente pero que son entregados al usuario en correcto estado.

Si hubiese dudas en cuanto a la consistencia de la información a ser recuperada, se profundiza en el control de calidad extendiendo el muestreo.

Nuestro negocio se basa en el valor subjetivo que cada usuario de computadora otorga a la información, no a valores objetivos preestablecidos. Puede ocurrir que un empresario traiga su disco roto para que rescatemos un cuento que debe mandar a un concurso literario y no se interese por el último balance de su empresa, que reside en el mismo disco, por el hecho de que cuenta con respaldo de esa información. Objetivamente, comercialmente, se podría pensar que el balance es más importante, pero en este caso nuestra función será recuperar satisfactoriamente el texto del cuento sin interesarnos por el resto, sin perder tiempo en una tarea que el usuario, razonablemente, no estaría dispuesto a contratar.

Por otra parte virtualmente todo el mundo tiene en su computadora alguna información que si cayera en manos de alguna persona, en alguna circunstancia, podría producirle un perjuicio. Esas cuestiones escapan absolutamente de nuestro ámbito, de modo que lo más aconsejable para un usuario que perdió información es que se comporte de una manera desapasionada y no nos dé detalles de la gravitación que esa información tiene en su negocio o su vida, sabiendo que está contratando un servicio tecnológico y que a nosotros no nos interesan los contenidos (digamos la semántica) sino solo la consistencia estructural (digamos la sintáctica).

Si en su empresa ya cuentan con una política interna de confidencialidad y propiedad intelectual, nosotros en CompExcell no tenemos problemas en suscribir dicho acuerdo de manera de cumplir con las mismas condiciones que los empleados internos. Ya hemos realizado convenios de confidencialidad con varias empresas que toman nuestros servicios (Argencard, IBM, Motorola, etc.) En caso contrario puede contactarnos para confeccionar un convenio ad hoc.

Adónde van los discos cuando mueren

Si usted tiene algunos años en este negocio seguramente tendrá en algún estante viejos discos de 120, 240, 340, 540, 1080… MB que se han ido dando de baja por mal funcionamiento o reemplazados por discos de más capacidad y performance. Si usted está a cargo de una gerencia de sistemas, es importante que informe a los usuarios menos especializados, que la información permanece durante años registrada magnéticamente en los platos y que la información confidencial puede quedar allí, en un estante de trastos al alcance de cualquiera que tenga un cierto nivel de especialidad en sistemas.

Es el tiempo de empezar a pensar que también los discos han de ser borrados según normas estrictas así como la papelería es pasada por una máquina destructora. Para decirlo gráficamente, borrar sus archivos con el comando “delete” o “borrar”, o bien formatear el disco rígido es casi como destruir un documento impreso haciendo un bollo y tirándolo a un cesto de papeles.

Deténgase a pensar en las siguientes circunstancias:

* Si su disco falla y debe mandarlo al proveedor por la garantía.

* Si su disco quedó chico y debe ser reemplazado por uno de mayor capacidad.

* Si su oficina o el ambiente en el que se ubica el/los server/s tiene acceso restringido.

En CompExcell recibimos discos que no funcionan, o que fueron formateados o borrados y nosotros devolvemos la información (pasando por encima de las claves del sistema operativo) totalmente accesible en un CD u otro medio. Por lo menos hasta donde sabemos, todos nuestros clientes actúan honestamente trayendo discos propios o de sus clientes, pero podría ocurrir que una persona trajese un disco robado, por ejemplo de un server Novell o NT y que nos solicitara que le diésemos en formato DOS en un diskette o CD determinado directorio…

Por eso es importante que cada disco en su organización esté perfectamente identificado y ubicado. Existen programas que le ayudarán a mantener una base de datos del equipamiento instalado.
Ricardo Pons © 1999

Un sistema de archivos es el modo en que un sistema operativo almacena información sobre un medio, que puede ser un diskette, un disco rígido, etc.

Desde los sistemas más antiguos se han planteado algunos problemas y limitaciones acerca de los cuales pasaremos revista en esta serie de artículos.

Empezaremos con el sistema de archivos o file system más difundido en la actualidad que es el que utiliza el DOS, el Windows 3.X y el windows 95. Se llama FAT 16. De este sistema hay variaciones tales como FAT 12 y el nuevo FAT 32. El FAT 12 se emplea en diskettes y se usó en los primeros discos de menos de 20 MB. El FAT 32 es la última implementación que propuso Windows para superar algunos problemas típicos de FAT16.

Tengamos en cuenta que FAT16 es un sistema bastante primitivo y que fue pensado para discos de 20 o 30 MB y actualmente se lo continúa utilizando con discos de 2 ó 3 GB. La idea de este sistema es dividir la distribución (layout) física del disco, que se divide en cilindros, cabezas y sectores (CHS), en unidades de asignación lógicas o clusters que se numeren simplemente desde 0 hasta X.

La Fat, es la tabla de ubicación de archivos (file allocation table) y es uno de los elementos, no el más importante, de un sistema de archivos. Ante todo, lo que es fundamental en un disco es un sector de arranque o boot record que es el primer sector del disco o de la partición y que permitirá a la CPU saber cómo tratar a ese disco. Es decir que aquí el disco “informa” a la CPU características tales como de qué medio se trata, el tamaño del cluster, el tamaño de la fat, qué sistema de archivos se usan, cantidad de cabezas y sectores, etc., etc., etc.

Hay que tener en cuenta que en un solo disco rígido podemos tener varios discos lógicos. De esta forma tendremos un boot record por cada disco lógico. La información acerca de cuántos volúmenes o “particiones” hay en un disco y su tipo, se encuentra en una tabla de un sector de longitud que se llama tabla de particiones. En realidad lo primero que lee la CPU de un disco es esta tabla, y esta remite al/a los boot record/s pertinentes. (En los diskettes no hay tabla de partición sino directamente el boot record).

No confundamos boot record con el hecho de que un disco o diskette sea “booteable”.

Luego, los directorios nos darán el nombre, el tamaño, las ubicaciones lógicas de los archivos, atributos, etc. considerándose los subdirectorios como de la misma naturaleza que los archivos. Es decir que se trata de una estructura recursiva que se puede extender indefinidamente. Esto es lo que se llama comúnmente árbol jerárquico o tree. Hay un atributo, un byte, que determina si una entrada de directorio es un archivo o un subdirectorio que a su vez puede contener otros archivos o subdirectorios.

Hasta este momento con este file system que estamos describiendo ya tenemos la posibilidad de almacenar archivos y subdirectorios en forma contigua. La implementación de la FAT se hace necesaria porque las aplicaciones de la vida real necesitan que los archivos puedan aumentar su tamaño.

Pensemos el siguiente ejemplo. Si copio a un disco tres archivos de un MB c/u con un file system sin fat, en el momento en que necesite agregar información al primer archivo, tendré que efectuar operaciones complicadas tales como: verificar el espacio libre contiguo que tengo disponible en el disco (como condición tiene que haber espacio igual o mayor al tamaño final que tendrá el archivo). Luego tendría que copiar el primer archivo de 1 MB a continuación del último y a continuación agregar la información nueva, digamos otros 200KB. De este modo el disco quedaría con 1 MB libre al inicio (espacio del archivo que se movió), 1 MB ocupado por el segundo archivo, 1 MB ocupado por el tercero y 1,2MB ocupado por el primer archivo que creció 200KB y a continuación el resto libre del disco hasta el final. Este tipo de implementaciones ocuparía mucha memoria y traería además problemas de performance insalvables.

La solución que adoptan todos los sistemas operativos de una u otra manera es la de considerar los archivos como compuestos de unidades lógicas o clusters. Esto soluciona el problema descripto más arriba y por otro lado hace que una vez interpretado el boot record, la cpu ya no maneje cilindros, cabezas y sectores sino siempre clusters o unidades de asignación.

Pero cuántos clusters puede tener un disco, o mejor dicho una partición: pues bien, la respuesta viene dada justamente por la denominación que se usa para distinguir los file systems: en un sistema fat12 podrá haber cómo máximo 2^12 (=4096) clusters y en FAT16 2^16 (=65536) clusters.

En fat 16 veremos que la cantidad final de clusters de una partición va a ser variable entre 2^15 y 2^16, es decir entre 32768 y 65536. Hagamos algunas cuentas: sabemos que podemos asignar un máximo de 65536 unidades por partición. Por lo tanto, si se trata de una particiónde entre 1024 y 2048 MB, el tamaño del cluster será de 32768 B

En el caso de 1024MB se usarán aproximadamente 32768 clusters (2 ^15) y en el caso de una partición de 2 GB, 65536. En una partición de 1600MB, por ejemplo, la cantidad de clusters será la división de los 1600MB por 32768 Bytes.

Mencionemos de paso que el tamaño máximo de partición que soporta el DOS es de 2 GB.

Se desprende la conclusión de que para una partición de 1 GB no se puede tener más cantidad de clusters porque el tamaño del mismo es de 32KB. Pero si la partición va a ser de menos de 1 GB, entonces, puedo nuevamente tener los 65536 clusters, pero esta vez de 16KB cada uno. De la misma manera, una partición de entre 512 MB y 1024 MB se formará por clusters de 16384 bytes. La cantidad de clusters será siempre entre 32768 y 65536. Y así sucesivamente.
Ahora que vimos la justificación, podemos verlo en una tabla.

Recalquemos que todo esto no lo decide el usuario sino que el OS funciona así. La única forma que hay en DOS de modificar el tamaño del cluster es modificando el tamaño de la partición.Quiere decir que una partición se dividirá lógicamente en una cantidad de clusters que se “asignarán” o ubicarán (allocate) cuando haya que escribir un archivo.

El sistema operativo DOS permite al usuario solamente decidir en que lugar jerárquico dentro del árbol de directorio pondrá sus archivos, pero no permite como sí lo hacen otros sistemas, decidir en que cluster o CHS irá a parar un archivo. Esto lo determina el OS por sí mismo por la aplicación de algoritmos no modificables por el usuario.

Aquí comienza el problema bastante discutido por los programadores de utilitarios acerca de lo poco económico que resulta este file system en cuanto a espacio en disco. Veamos. Tenemos una partición de 1000 MB. El tamaño del cluster en este caso es (determinado automáticamente por el SO) de 32768 Bytes. Esto significa que el OS no podrá asignar menos que eso. Esta es la unidad mínima de espacio que se le puede asignar a un archivo, aunque este sea de 10 Bytes. Lo mismo si un archivo ocupa 33KB, estaremos usando todo un cluster y un poquito del siguiente. Dicen algunas estadísticas que de este modo se desaprovecha entre un 30 y un 40 % del espacio total. Obviamente, si tengo muchos archivos chicos el desperdicio será mayor y si tengo archivos grandes, menor. ¿Soluciones? Cambiar de OS o realizar particiones más chicas. Por ejemplo, si se particiona el mismo disco de 1000MB en tres o cuatro, el tamaño del cluster será menor y habrá menos desperdicio.

Tan grave es esta cuestión del desperdicio de espacio que veremos, en la revisión de otros file systems cómo Netware 4,1 y algunas implementaciones de Unix, que se ha desarrollado una estructura donde almacenar clusters parcialmente utilizados.

Otro capítulo merecería la seguridad, dado que si tengo un archivo que ocupaba todo un cluster, lo borro y luego genero uno que ocupe la décima parte de ese mismo cluster, quedaría accesible para un especialista el 90% del cluster no sobreescrito, lo cual en algunas aplicaciones puede ser inaceptable. De la misma forma, yendo más allá de los límites normales del OS, es posible ocultar información confidencial en clusters parcialmente ocupados.

La tabla de asignación de archivos, que en rigor debería llamarse tabla de asignación de clusters, es una tabla que lleva cuenta (to track), en tiempo real de qué cluster está siendo ocupado por qué archivo. Esto permite la fragmentación, porque cuando se va a leer o recuperar un archivo grabado en un disco, se consulta esta tabla y se va levantando en memoria cluster por cluster no ya en orden de contigüidad sino en el orden que dicta esta tabla.

Cuando se pensó el DOS, se sospechó que esta tabla podría ser crítica para el correcto acceso a la información, de modo que se implementó esta estructura duplicada. El OS actualiza siempre ambas tablas “al mismo tiempo” y deben en teoría ser iguales. Solo que finalmente el OS no llegó nunca a dar un uso a la copia 2 de la FAT. Es decir, no hay subrutinas nativas del DOS que echen mano de la segunda copia cuando las cosas se ponen feas. Hay, como todos sabemos, utilitarios que comparan ambas copias y detectan si hay diferencias entre ellas. Este es un procedimiento que sigue todo usuario en el mantenimiento normal de su sistema. Los utilitarios están programados con algoritmos que tratan de determinar cuáles serían las partes de la FAT 1 y de la FAT 2 que “están buenas” (es decir, que permiten el acceso a los archivos fragmentados a lo largo de toda la partición) o que son mejores. El utilitario considera cumplida su misión si ambas copias terminan siendo iguales bit a bit, es decir que buscan una coherencia desde el punto de vista formal del file system, sin importar que en el camino se pierdan archivos.

Si la fat me indica que mi archivo estaba compuesto por los clusters 1000, 1002, 1003 y 1022 pero en realidad se componía por los 1000, 1001, 1002 y 1003, obviamente no podré leer el archivo como corresponde sino que obtendré “algo” con el mismo nombre que el archivo perdido pero que tendrá el primer cluster igual, el segundo desaparecido, el tercero en lugar del segundo, etc.

Tengamos en cuenta que la relación entre la información de la FAT y la distribución real de información en las superficies magnéticas es univoca. Cuando esto no es así se generan códigos de error tales como “clusters perdidos”, “clusters cruzados”, “hay espacio asignado en su fat que probablemente no hace más que ocupar espacio”, etc.

Para resumir digamos que la estructura de un disco DOS es como sigue:

1 tabla de partición para todo el disco
1 tabla de partición adicional por cada partición a partir de la segunda
1 boot record por partición
2 copias de FAT iguales por partición
1 directorio raíz por partición
Algunos consejos útilesVeremos a lo largo de estos artículos que si bien hay sistemas de archivos mejores que otros, no existe uno perfecto. Cuando no hay desperdicio de espacio se hace a costa de agregar complejidad a estructuras que pueden poner todo el sistema más propenso a sufrir daños o que pueden empobrecer la performance del acceso a la información. En general se puede aplicar la regla de que es bueno tener un poco de background teórico para entender los puntos débiles del sistema que usamos y así estar prevenidos.

En un sistema FAT 16, para la mayoría de los usuarios será suficiente con mantener el disco defragmentado. Esto se logra con utilitarios que leen y escriben los archivos reubicándolos de modo que queden conformados por clusters contiguos y dejando un solo espacio libre al final del disco. El DOS y las distintas versiones de windows 3,1 y 95 traen “Defrag” para realizar esta tarea aunque hay otros programas que también lo hacen. Obviamente, si los archivos no están fragmentados los clusters se accederán y se cargarán en memoria con menor movimiento mecánico de los cabezales y de esta manera el acceso será más rápido. De modo que defragmentar un disco es una tarea básica en el mantenimiento de cualquier equipo y colabora a que el rendimiento de todo el sistema sea superior.

Para usuarios que den un uso más exigente a su sistema es recomendable, además, mantener una copia de la tabla de partición, boot record, fat y directorio raíz. También para esta aplicación hay programas comerciales y/o shareware disponible.

En ambos casos, ya sea con un disco no fragmentado o teniendo una copia actualizada de la fat, se puede recuperar el 100% de la información en caso de un daño al file system.

La tabla de partición y el boot record son estáticos, no cambian y pueden ser reconstruidos por alguien experimentado en este tema. En caso de que se haya perdido definitivamente la fat (que es dinámica y cambia cada vez que se escribe o borra un archivo del disco), entonces se puede encarar una recuperación de información de la siguiente manera: asumir que la tabla era plana, es decir que representaba la ubicación de archivos no fragmentados. De esta manera se recuperarán satisfactoriamente al 100% los archivos que efectivamente estuviesen en este estado. Con respecto a los archivos fragmentados… bueno, todavía queda alguna esperanza debido a que por los indicios de donde comienzan los demas archivos (información contenida en directorios y subdirectorios) y conociendo cómo hace internemante el OS para ubicar archivos, se puede inferir cómo se habrá fragmentado un archivo en particular. Cabe aclarar que esto es un modelo, una aproximación a esa realidad que era el estado del disco antes de un crash, y que en estos casos no hay seguridad de que lo que se recree tenga correspondencia con los archivos originales.
Ricardo Pons © 1997

De acuerdo a lo que indicamos más arriba para FAT 12 y 16, el lector habrá ya inferido que la nueva FAT32 tiene como peculiaridad una tabla de 32 bits que permite llevar cuenta de los clusters en uso.

Este sistema que por ahora está disponible solamente en el sistema Windows95 realease 2, se generalizará el año próximo cuando salga a la venta el Windows 98. Por ahora no se puede comprar este sistema sino que viene preinstalado con las máquinas nuevas.

Esta FAT nos permite en teoría dividir el disco hasta en 2^32 (=4.294.967.296) clusters o unidades de asignación. Digo en teoría porque tendría poco sentido dividir un disco de 2 GB en 4 Gclusters. De modo que Windows dará en general un tamaño mínimo de cluster de 4096 Bytes, al igual que en Windows NT con formato NTFS.

Las ventajas de esta implementación (que seguramente será la última antes de que se generalice NTFS) del viejo sistema de archivos con FAT son dos:

1)  Menor desperdicio de disco por clusters parcialmente utilizados.

Como habíamos visto en el artículo anterior, no hay forma de dividir un cluster, es decir no hay ninguna estructura que nos permita direccionar dentro de un cluster. De modo que salvo en los casos en que se ocupan varios clusters, o bien en los clusters múltiplos del tamaño de cluster para esa partición, hay desperdicio. Este desperdicio, habíamos dicho, es directamente proporcional a la cantidad de archivos.

La cuenta que se puede hacer estadísticamente es la siguiente:

Hay un desperdicio por cada archivo de entre 0 y 1 cluster. Estadísticamente dará un desperdicio de 0,5 cluster por archivo. Acá se ve claramente que en cuantos menos archivos tenga, y en cuanto más chico sea el cluster de la partición, menos desperdicio final habrá. Por ejemplo el límite para FAT16 son particiones de 2 GB que es el tamaño de disco mínimo disponible hoy. FAT16 da un cluster de 32KB en tanto que FAT32 uno de 4KB. Claramente el desperdicio es ocho veces menor. Para una instalación con 8000 archivos tendremos un desperdicio de 128 MB en FAT16 y de 16MB en FAT32. Esto es un cálculo grosso modo. Hay utilitarios que lo calculan al byte para cada instalación.

2)  La segunda ventaja es que se puede superar el límite impuesto por FAT16 de 4,128,768 sectores (4096 cilindros x 16 cabezas x 63 sectores o bien 1024 cilindros x 64 cabezas por 63 sectores si empleamos LBA) por partición (=2GB). Es decir, que si uno tiene un disco de 3, 4 u 8 GB puede sin problemas formatearlo como una sola partición sin preocuparse por el tamaño del cluster, que seguirá siendo de 4KB.

El Windows95 release2 viene con los mismos utilitarios de mantenimiento de disco que la versión anterior, de modo que se pueden corregir eventuales problemas en el file system y defragmentar cuando sea necesario.

Algunos consejos útiles

Hay que tener en cuenta que en caso de que un disco deje de ser booteable, habrá que bootear el equipo con un disquette release 2 porque si lo hacemos uno win95 o DOS, notaremos que el disco no es reconocido. Por lo tanto hay que tener un diskette booteable con Win95 Release2 disponible. Lo mismo cuando se detecte algún virus y el antivirus nos pida arrancar con un diskette limpio.

En este file system se aplican las mismas consideraciones que en FAT16 en cuanto a posibilidades de recuperación, fragmentación e importancia de la información contenida en las fats.

Sólo queda por agregar que al tener clusters más chicos tenemos más posibilidad de fragmentación. Por ejemplo si manejamos en general archivos de 20KB, estos no pueden aparecer fragmentados de ninguna manera en una partición FAT 16 con clusters de 32KB, pero en FAT32 harán falta 5 clusters para formar un archivo de tal tamaño, de lo que se desprende que hay una tendencia mayor a la fragmentación al verificarse crecimiento de archivos. De lo que a su vez se deduce que si antes la FAT era una estructura crítica para la integridad de los archivos, ahora lo es más.

Por lo que llegamos a la conclusión (y lo haremos varias veces en los próximos artículos al evaluar otros file systems) de que ganamos en aprovechamiento del espacio en disco y en manejo de discos grandes pero tenemos ahora una mayor dependencia de estructuras de datos más complejas.

Ricardo Pons © 1997

Posibilidades de recuperación en Novell Netware

La recuperación de información es el trabajo que consiste en leer y copiar a un medio seguro información que se hizo inaccesible al usuario por medios convencionales. Esto puede ser por desperfectos en el funcionamiento del medio de almacenamiento o por problemas en el sistema de archivos o ambos.

Ante todo, la tarea de recuperación de información radica en poder leer el medio, que puede tratarse de un disco rígido u otra forma de almacenamiento tales como cintas, DATs, diskettes, discos ópticos, etc. En general esta es la tarea más compleja: poder hacer lo que se llama una recuperación ASCII o bit a bit de la información original. En discos que han dejado de ser reconocidos por sus controladoras o por los motherboards, hay que aplicar un entendimiento profundo de las tecnologías de almacenamiento para efectuar una reparación temporaria de la unidad que contenía la información. Decimos temporaria debido a que realizar una reparación permanente es algo más difícil y costoso y lo que se busca en la tarea de recuperación de información no es dejar operativo un disco sino lograr al menos una lectura buena de los datos de un medio que luego será dado de baja.

Las fallas en discos pueden deberse a una multitud de causas: fallos inherentes en los componentes electrónicos o bien introducidos por descargas electrostáticas externas, etc. o bien fallas electromecánicas por stress mecánico de las piezas, heterogeneidades en los medios, stiction (static friction), etc. etc.

En algunas ocasiones los usuarios tienen su medio de almacenamiento en perfecto estado de funcionamiento de hardware pero no pueden acceder a la información porque faltan o son inconsistentes las estructuras administrativas del sistema operativo que permiten ubicar físicamente los archivos en diferentes zonas del disco. En estos casos lo que hay que hacer es ante todo un relevamiento, de qué impide al sistema operativo, tener acceso al sistema de archivos. Se realiza una comprobación de qué estructuras sufrieron daños, cuáles están presentes y son confiables y cuáles pueden necesitar ser reescritas o reprogramadas.

Hay que destacar que muchas veces cuando se realiza una reparación temporaria de un disco, luego no se obtiene un file system «limpio», sino también hay que reinterpretarlo, sobre todo cuando hay daños en los medios y quedan zonas sin poder recuperarse.

La recuperabilidad de los sistemas Novell Netware

Por lo dicho más arriba, queda claro que para encarar esta tarea, entre otras cosas, hay que tener capacidad de efectuar intervenciones de tipo electrónicas y electromecánicas en las unidades de almacenamiento. Esto es igual para cualquier sistema operativo. Se trata de una etapa sintáctica, en donde lo que cuenta es el ordenamiento (taxos=orden, en griego) de los componentes mínimos (sectores, clusters, bloques, etc.) sin hacer interpretación de ningún tipo. En esta etapa no importa si un string determinado es un directorio, parte de un archivo o cualquier otra estructura.

Llamamos parte semántica a la segunda instancia, en que se interpreta qué es cada cosa de acuerdo a un tipo de file system de un sistema operativo concreto.

En el caso de Novell Netware los file systems se dividen en dos grandes grupos: los sistemas hasta la versión 2.2 y los sistemas desde la versión 3.11 hasta las actuales 4.x. Estos dos tipos de sistemas son totalmente diferentes y nadie podría confundirlos observando un disco a bajo nivel (con un editor de sectores físicos o con debug) una instalación digamos 2.12 con una 3.12. Debido a que quedan pocas instalaciones con Novell 2.x no nos extenderemos aquí en descripciones técnicas pero digamos que se trata de un sistema bastante confiable por un lado y poco eficiente por otro si lo comparamos con las versiones 3.x y 4.x Generalmente los problemas con estos sistemas se deben a degradaciones de archivos de arranque, que una vez repuestos o bypasseados permiten acceder a la estructura de archivos. Inclusive con daños en directorios es un sistema que suele tener buenas tasas de recuperación.

Con respecto a los sistemas 3.x y 4.x podemos decir que se trata del mismo sistema con sutiles diferencias. Si uno ve a bajo nivel un disco formateado en versión 3.x y otro en 4.x encontrará diferencias bastantes evidentes. Tenemos que pensar que entre la liberación de uno y otro sistema pasaron varios años y con ellos hubo un gran crecimiento en el promedio de capacidad de los discos de los servers. Las diferencias se verán en que las instalaciones típicas de una versión 3.11 o 3.12 tienen un tamaño de bloque de 4 KB, en tanto que para la versión 4.x el default para volúmenes de más de 500 MB es de 64 KB (esto es modificable en la instalación con las correspondientes consecuencias en performance y desperdicio). Esto, como el lector estará imaginando, va a implicar que vamos a encontrar FATs estructuralmente similares pero de tamaños totalmente disímiles. (Algo análogo ocurriría si se comparase un disco formateado con el file system FAT16 que usa DOS, Windows 3.X y 95 con el de FAT32 que usa Windows 95 release 2 y Windows 98).

Si mucha gente se estaba lamentando del problema del desperdicio que traía el sistema de FAT 16 con tamaños de clusters de 32KB para una partición de entre 1 y 2 GB, ahora ¿qué tendríamos que decir de un tamaño de bloque de 64KB? Pero los diseñadores del sistema operativo Netware 4 implementaron una solución de compromiso entre desperdicio y performance: por un lado favorecieron un tamaño de bloque grande, pero por otro incorporaron una estructura adicional en donde se registra dónde se ubican segmentos de información que no llegan a ocupar un bloque entero. La presencia de esta estructura llamada subasignación de bloque es la opción por defecto pero se puede desactivar durante la instalación. Si se desinstala tendremos mayor seguridad y performance pero mayor desperdicio. Los problemas que acosan a los diseñadores de file systems son siempre los mismos: desperdicio, performance, seguridad, recuperabilidad. Los veteranos en Unix recordarán que la versión Berkeley implementaba ya una reubicación de bloques parcialmente ocupados muy parecida conceptualmente a la de Netware 4.x.

La estructura de subasignación de bloque es muy importante, al punto que su ausencia torna casi irrecuperable un volumen Netware (por más que tengamos buenas copias de FATs y directorios) debido a que allí estará la clave para recuperar cualquier archivo de menos de 64 KB y los fragmentos finales de los archivos que excedan múltiplo de 64 KB. (Esto mismo vale si se tomó tamaño de bloque 32 o 16 KB). Las unidades en esta estructura son de 512 B.

La regla general para cualquier sistema operativo con respecto al tema de seguridad es que en cuantas menos estructuras administrativas críticas existan, mejor, o en otras palabras: en cuantas menos cosas haya que se puedan romper en un file system, más segura estará la información. Esta prestación no existe en NetWare 3, de modo que estadísticamente hay más chances de recuperar más cantidad de archivos buenos en una instalación 3.x que en una 4.x

Cada volumen tiene sus propias copias de FATs, DETs, subasignación, etc. De modo que los daños en un volumen no deben alterar la información de otros volúmenes. Estadísticamente se comprueba que el volumen que más sufre daños es el primero, el SYS. Por lo tanto es recomendable generar otros volúmenes para datos de modo que en caso de que el primer volumen tenga desperfectos nos queden copias limpias de directorios, Fats, etc. del volumen más importante.

Asimismo, si debe agregar capacidad a un volumen tenga en cuenta que si agrega un disco al mismo volumen, la información de ambos discos va a depender de un solo juego de directorios y no podrá levantar información si falta (o se rompe) alguno de los discos que integraban este volumen. En estos casos la tarea de recuperación consiste, en primera instancia en obtener una copia completa, bit a bit del disco que tuvo desperfectos y rearmar la instalación como estaba originalmente. En caso que la recuperación bit a bit no sea completa, o que luego de ella encontremos errores lógicos habrá que trabajar con las estructuras de ambos discos. Generalmente estos problemas se encaran generando un disco único auxiliar con partes que se levantan de uno y otro disco.

No podemos extendernos en esta ocasión sobre los RAIDs pero la forma de encarar estas instalaciones es similar. A partir de la información que proporciona el usuario, a veces incompleta o dudosa, y de la información que se levanta a bajo nivel de los discos, se determina qué tipo de RAID era, el tamaño del stripe y otras variables necesarias para iniciar el rearmado de los archivos. Hay muchas tareas de ingeniería reversa que se aplican pero esto tiene que ver no sólo con el conocimiento de las tecnologías sino también con mucha experiencia, intuición y experimentación. A veces instalar un RAID similar al que estamos intentando reconstruir puede permitir comprobar empíricamente si el camino tomado es el correcto.

Por último recordemos que desde la versión 4.x, se instala también por default la opción de cargar automáticamente el Vrepair.nlm en caso de que en el arranque se hallen inconsistencias. El Vrepair es un utilitario cuyo objetivo principal es lograr un volumen que se pueda montar, más allá de que en el camino se pueda perder información o se puedan actualizar erróneamente FATs dejando archivos sin referencia. Aconsejamos desactivar esta opción para que sea el administrador quien decida si corresponde correr Vrepair o no y cuándo. La opción más conservadora sería nunca correr este NLM a menos que no haya información importante sin respaldo o sea realmente la últimaalternativa.

Ricardo Pons © 1998

Funcionamiento electromecánico de los discos rígidos

Los discos rígidos son dispositivos electromecánicos de alta precisión. Constan de un grupo de platos en los que se graba la información en forma magnética. Estos platos giran a una velocidad constante dada por un motor de platos o spindle motor. La velocidad en los discos rígidos de PC van de 3600 a 10000 RPM.

Los platos son de aluminio y manganeso recubiertos por una capa magnética de cobalto y fósforo y un lubricante. Esto es una simplificación y en realidad los platos tienen entre cinco y siete capas de diferentes aleaciones que son propiedad intelectual de cada fabricante de medios. Hay que tener en cuenta que no necesariamente cada fabricante de discos produce sus propios medios.

Los primeros discos tenían una coercitividad de 500 ó 600 Oe. En tanto que los medios que se utilizan actualmente tienen una coercitividad de 3000 o 4000 Oe. Esto implica que el tamaño de los dominios magnéticos que se orientan en uno u otro sentido para de esta manera memorizar un estado lógico pueden ser más pequeños. Se lo puede entender con analogía al tamaño del grano en una película fotográfica o el tamaño del pixel en un monitor. La mayor coercitividad permite grabar los tracks de un disco más cercanos uno del otro sin pérdida de información.

La información es leída a través de cabezales magnéticos que sobrevuelan la superficie de los platos a una distancia del orden de los 30 nanómetros. La velocidad de los mismos en relación a los platos es de aproximadamente 30 metros / segundo. Los platos y el conjunto de cabezales se encuentran en un gabinete cerrado llamado burbuja que no tiene contacto con el exterior. Es importante la aislación absoluta de los mecanismos con respecto al exterior debido a que el polvillo del ambiente puede producir daños en cabezales y medios. Este es un gran problema para los diseñadores de medios de almacenamiento removible. Algunos modelos de discos tienen orificios en su burbuja. Detrás de estos encontramos un pequeño filtro de clase 100. Esto se implementa para equiparar la presión atmosférica interna con la externa. Téngase en cuenta que siempre que un disco esté en funcionamiento va a tener una presión muy positiva con respecto a la presión atmosférica, de modo que el flujo de aire (en caso de que tenga lugar) se efectúa hacia fuera. Esta presión (generada por el flujo de aire que producen los platos al girar) permite que los cabezales vuelen. En cuanto más pequeña sea la distancia de vuelo mayores densidades (información sobre unidad de superficie) se podrán obtener. La altura de vuelo se regula por el tamaño de los cabezales. Hay que tener en cuenta por último que la distancia real entre la capa magnética del plato y la capa magnética del cabezal es mayor a la distancia física entre cabezal y plato debido a las múltiples capas que componen uno y otro elemento.

Cada cabezal tiene dos bobinados, uno de lectura y uno de escritura. Es importante notar que a diferencia de otros dispositivos de cintas, aquí no existe cabezal de borrado. La única forma de borrar es escribiendo encima. Esto tiene consecuencias en el campo de la protección de información, confidencialidad, recuperación de información, etc.

No nos extenderemos aquí acerca de la construcción de los cabezales y las diferentes tecnologías. Actualmente se emplean diversos tipos de cabezales llamados MR por magneto resistivos. Sólo el cabezal de lectura es MR, el de escritura sigue siendo de película delgada o thin film. El rol de la tecnología MR es una de las claves de los actuales niveles de densidad de información alcanzados.

Sabemos que los platos tienen vías (tracks) concéntricas donde se registra la información. Los mismos se enumeran desde el cero hasta n. Cada track está dividido en sectores circulares. Los cabezales leen un solo track a la vez, de modo que para leer un sector (típicamente de 512 Bytes cada uno) el cabezal deberá hacer una búsqueda (seek) hasta el track correspondiente y esperar a que el sector deseado se ubique bajo el cabezal por efecto de la rotación de los platos. A este tiempo se lo llama tiempo de latencia y estadísticamente se puede decir que es de la mitad del tiempo que tarda el plato en dar una vuelta completa.

En la actualidad la inmensa mayoría de los discos emplean un mecanismo para mover los cabezales que se llama rotary voice coil. Se trata de una bobina que se mueve dentro de un campo magnético fijo al ritmo de la energización que se le aplica (a la manera de un parlante de audio, que traduce energía eléctrica en movimiento del cono). La principal ventaja del rotary voice coil sobre el voice coil y el stepper motor es la precisión de posicionamiento y el bajo costo de fabricación. El voice coil hace entrar los cabezales en forma totalmente radial a los platos en tanto que el rotary voice coil los hace entrar en forma de arco. Esto trae ciertas complicaciones en el diseño de los cabezales debido a que entre el track más externo y el más interno hay un ángulo (valor constante para cada modelo de disco) de unos 20 grados que deberá ser proporcional al offset o desplazamiento que deben mantener los bobinados de lectura y escritura dentro de cada cabeza.

El stepper motor (similar al de las disketteras) mencionado más arriba fue en su momento una alternativa al voice coil por ser mucho más económico pero cayó en desuso cuando se necesitó más velocidad y mayor precisión en medios con mayor cantidad de tracks por pulgada (TPIs). De esta época son los discos que recomendaban ser instalados en posiciones bien definidas. Actualmente con la tecnología que se usa no hay recomendaciones explícitas al respecto pero siempre se recomienda instalar los discos en forma horizontal con la plaqueta hacia abajo o sobre uno de los laterales longitudinales a 90 grados del piso. No en otra posición.

Servomecanismo de lazo cerrado para posicionamiento de cabezales (búsqueda de track y seguimiento de track)

Los primeros discos de PCs, al igual que los discos de mainframes, contaban con una superficie que venía de fábrica grabada con una señal de servo. Dicha señal era la entrada a un sistema de realimentación de lazo cerrado que permitía la búsqueda de tracks a lo largo de las superficies. Esto fue un gran avance en comparación con drives anteriores que hacían el posicionamiento a través de una reglita (fija) que era seguida por un sensor (movil) en el voice coil (en forma análoga al mecanismo que utilizan las actuales impresoras de chorro de tinta para posicionar el carro con el cabezal de impresión). La superficie de servo dedicada permitió mayores densidades debido a que el servo estaba grabado de una forma muy parecida a la de la información real.

Los diseñadores de discos, presionados por lograr mayores densidades, no podían permitirse toda una superficie sin datos, de modo que el servo se incorporó a los platos con datos. Esto se llamó embedded servo o servo «incorporado». La naturaleza de las señales de servo se aproximaron aún más a las de datos: a partir de aquí los mismos cabezales que leen datos leen también servo, solo que a diferentes frecuencias. Es decir que habrá un circuito encargado de multiplexar servo a una frecuencia determinada. Obviamente la electrónica se complica, porque ahora necesitamos una etapa adicional que discrimine lo que es servo y lo que es data, pero se simplifica la mecánica y se logra mayor capacidad por drive. (Podemos pensar en la analogía con un sistema de televisión en el que por un cable recibimos señal de video compuesta. Los circuitos deben discriminar lo que son pulsos de sincronismo horizontal y vertical, audio y señal de video).

En el caso de los discos el amplificador de lectura y escritura que se encuentra en el conjunto de los cabezales, dentro de la burbuja, amplificará por igual los pulsos de servo (con período constante) y las señales de datos. Cada cabezal es una señal de datos en serie. La circuitería posterior lo que hace es discriminar los datos del servo y pasar los datos a paralelo (integrando la información obtenida de cada cabezal).

La última evolución que sufrió el sistema de servo de los discos se llama «Idless» o «no ID». En este tipo de arquitectura seguimos teniendo servo incorporado pero se simplifica la cantidad de información de identificación que es necesaria para ubicar cada sector. Digamos, sin profundizar demasiado, que cuando el disco se haya inicializado se habrá generado en ram un mapa del disco que hace aún más «de acceso aleatorio» el disco debido a que no hay que leer los ID de los sectores antes de leerlos. Esto permite también quitarle toda criticidad al problema del offset entre cabezal de lectura y de escritura y habilita a mayores densidades de track. Esta es la arquitectura que se emplea en la mayoría de los discos en uso actualmente.

Ricardo Pons © 1998