Extraer a archivos y unidades extendidas
A partir de IsoBuster 5.2 es posible crear/extraer (Archivos de Imagen) a archivos (y unidades) extendidos.
Opening them is also possible with IsoBuster.
La extracción a un archivo/unidad expandida se hace [1] por medio dethe command line (/ei:) o [2] por medio del comando de control de breadcrumb control command @cmdl:/ei:
Los archivos/unidades extendidos están separados por el carácter '|'.
Al igual que es posible crear un único archivo de imagen:
[1] isobuster.exe /ei:c:\image.img /et:u /d:1
[2] @cmdl: /ei:c:\image.img /et:u /d:1
Es posible crear un archivo de imagen extendida:
[1] isobuster.exe/ei:c:\image1.img|c:\image2.img /et:u /d:1
[2] @cmdl:/ei:c:\image1.img|c:\image2.img /et:u /d:1
Nota: IsoBuster siempre respeta el tamaño de un archivo que no sea el último archivo de la cadena. Solamente el último archivo de la ruta puede crecer, y globally set file splitting también se tiene en cuenta la división de archivos establecida globalmente.
Así, en el ejemplo anterior, si el archivo c:\image1.img está vacío o no existe, no crecerá, pero se creará si es necesario. Su tamaño seguirá siendo 0 bytes y por lo tanto todos los datos se extraerán a c:\image2.img
Si c:\image1.img existe y tiene un tamaño, por ejemplo 50MB, entonces los 50MB serán sobreescritos, el tamaño permanecerá sin cambios, y el resto de la imagen será extraída a c:\image2.img.
La misma lógica se aplica a las unidades (por ejemplo, \.\PhysicalDrive2). Obviamente las unidades existen y tienen un tamaño fijo
Al igual que es posible crear un clon de una unidad (p.e. clonar la unidad 1 a la unidad 2):
[1] isobuster.exe /d:1 /ei:\\.\PhysicalDrive2 /et:u
[2] @cmdl: /d:1 /ei:\\.\PhysicalDrive2 /et:u
Es posible crear un clon de unidades extendidas (por ejemplo, clonar la unidad 1 en las unidades 2 y 3):
Ejemplo: suponga que está creando una imagen de una unidad de 2 TB en dos unidades de 1 TB. El primer TB termina en la unidad 2, y el último TB termina en la unidad 3.
[1] isobuster.exe /d:1 /ei:\\.\PhysicalDrive2|\\.\PhysicalDrive3 /et:u
[2] @cmdl: /d:1 /ei:\\.\PhysicalDrive2|\\.\PhysicalDrive3 /et:u
También es posible combinar esto con archivos normales (cualquier combinación vale):
[1] isobuster.exe /d:1 /ei:\\.\PhysicalDrive2|\\.\PhysicalDrive3|c:\part3.dsk /et:u
[2] @cmdl: /d:1 /ei:\\.\PhysicalDrive2|\\.\PhysicalDrive3|c:\part3.dsk /et:u
Otro ejemplo loads a spanned image file y crea un clon en las unidades distribuidas:
[1] isobuster.exe "c:\image1.dsk|c:\image2.dsk|c:\image3.dsk" /ei:\\.\PhysicalDrive2|\\.\PhysicalDrive3|c:\part3.dsk /et:u
[2] @cmdl: "c:\image1.dsk|c:\image2.dsk|c:\image3.dsk" /ei:\\.\PhysicalDrive2|\\.\PhysicalDrive3|c:\part3.dsk /et:u
O para convertir un archivo de imagen en un único archivo:
[1] isobuster.exe "c:\image1.dsk|c:\image2.dsk|c:\image3.dsk" /ei:c:\full_image.dsk /et:u
[2] @cmdl: "c:\image1.dsk|c:\image2.dsk|c:\image3.dsk" /ei:c:\full_image.dsk /et:u
Al escribir en unidades físicas o lógicas, también conocidas como "clonación", la interfaz gráfica de usuario excluye las unidades críticas (*) de la selección de destino.
(*) Unidad del sistema, la unidad de origen no puede ser también la de destino, etc.
Se realizan comprobaciones similares cuando las unidades se proporcionan a través de la línea de comandos y se muestra un cuadro de diálogo pidiendo continuar cuando se detectan colisiones.
A diferencia de la interfaz gráfica de usuario, es posible proporcionar estas unidades en la ruta y continuar. Esto le da un gran poder de ingeniería. Pero recuerde, un gran poder conlleva una gran responsabilidad, ¡¡¡puede fastidiar totalmente su sistema!!!
Por ejemplo, es perfectamente posible clonar un archivo de imagen a la unidad física 0, que con toda probabilidad sobrescribirá la unidad de su sistema y... ka-boom...
Además, es posible suprimir por completo el cuadro de diálogo de advertencia (see command line parameter /ep:NCD). Si utiliza este parámetro puede arruinar su sistema aún más rápido sin ni siquiera una advertencia en caso de que accidentalmente proporcione una ruta de destino incorrecta. Ha sido advertido.
La extracción a archivos o unidades extendidas puede combinarse con todos los demás command line parameters como /range: /t: /s: /p: etc.
Sin embargo, /ef: sólo tiene sentido cuando se extrae un único archivo. Por ejemplo, el siguiente ejemplo extrae un archivo (que resulta ser un archivo de imagen) de otro archivo de imagen, y lo escribe directamente en una unidad Física (por ejemplo, una memoria USB), esencialmente haciendo un clon de un archivo de imagen que resulta residir en otro archivo de imagen:
[1] isobuster.exe "c:\image.vhdx" /ef:ntfs\usb_stick_image.img|\\.\PhysicalDrive2
O a dos memorias USB separadas:
[1] isobuster.exe"c:\image.vhdx" /ef:ntfs\usb_stick_image.img|\\.\PhysicalDrive2|\\.\PhysicalDrive3
Los managed image files archivos de Imagen Controlados de IsoBuster (*.ibp / *.ibq) se crean siempre en pares (o más archivos si el ibq está dividido en múltiples archivos).
Si usted abre posteriormente el archivo IBP con IsoBuster, IsoBuster también abrirá automáticamente el archivo(s) IBQ. Esto se basa en nombres de archivo idénticos y extensiones ibp vs ibq.
Usted puede sobrecargar esta funcionalidad proporcionando el(los) archivo(s) IBQ en la línea de comando (o por medio de @cmdl:)
El primer archivo (el IBP) debe tener la extensión *.ibp (si no, se renombra automáticamente), la parte IBQ puede tener cualquier extensión.
Nota importante, si se desvía de la norma (same_name.ibp y same_name_ibq) siempre tendrá que load the image file via the command line or via @open or @cmdl cargar el archivo de imagen a través de la línea de comandos o mediante @open o @cmdl.
Por ejemplo, en el siguiente ejemplo se crea un archivo de imagen controlada de la unidad 0, y se almacena en los archivos: managed.ibp y part1.bin (observe que la extensión del primer archivo se cambia de bin a ibp - para que cuando abra el archivo, IsoBuster sepa que es un archivo de imagen controlada)
[2] @cmdl:/d:0 /ei:c:\managed.bin|c:\part1.bin /et:m
Para volver a abrir esta imagen
[2] @open:c:\managed.ibp|c:\part1.bin
En el siguiente ejemplo, el IBQ se divide en tres archivos/unidades. La primera parte se almacena en el archivo part1.bin (suponiendo que part1.bin existe y tiene un tamaño), la segunda parte se almacena en PhysicalDrive2 y así sucesivamente:
[2] @cmdl:/d:0 /ei:c:\managed.doh|c:\part1.bin|\\.\PhysicalDrive2|\\.\PhysicalDrive3 /et:m
Para abrir esta imagen de nuevo:
[2] @open:c:\managed.ibp|c:\part1.bin|\\.\PhysicalDrive2|\\.\PhysicalDrive3