ES2667024T3 - Análisis de archivos ejecutables portátiles - Google Patents
Análisis de archivos ejecutables portátiles Download PDFInfo
- Publication number
- ES2667024T3 ES2667024T3 ES10765530.0T ES10765530T ES2667024T3 ES 2667024 T3 ES2667024 T3 ES 2667024T3 ES 10765530 T ES10765530 T ES 10765530T ES 2667024 T3 ES2667024 T3 ES 2667024T3
- Authority
- ES
- Spain
- Prior art keywords
- field
- valid
- attribute
- syntactically analyzed
- portable executable
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/70—Software maintenance or management
- G06F8/74—Reverse engineering; Extracting design information from source code
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
- G06F11/0715—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a system implementing multitasking
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
- G06F11/0721—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment within a central processing unit [CPU]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0751—Error or fault detection not based on redundancy
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0793—Remedial or corrective actions
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/362—Software debugging
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/65—Updates
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Quality & Reliability (AREA)
- Software Systems (AREA)
- Computer Hardware Design (AREA)
- Computer Security & Cryptography (AREA)
- Stored Programmes (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Devices For Executing Special Programs (AREA)
- Input Circuits Of Receivers And Coupling Of Receivers And Audio Equipment (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
Abstract
Un método implementado por ordenador que comprende: analizar sintácticamente (50), mediante un dispositivo informático, una imagen binaria de un archivo ejecutable portátil para generar un campo analizado sintácticamente; determinar (54), mediante el dispositivo informático, un atributo del campo analizado sintácticamente; comparar (56), mediante el dispositivo informático, el atributo del campo analizado sintácticamente con una característica válida de un campo correspondiente válido en base a una especificación de formato de archivo ejecutable portátil; determinar (58), mediante el dispositivo informático, si el atributo del campo analizado sintácticamente coincide con la característica válida del campo correspondiente válido; identificar, mediante el dispositivo informático, si el campo analizado sintácticamente no coincide con la característica válida del campo correspondiente válido; y determinar (62), mediante el dispositivo informático, una probabilidad de modificar el campo analizado sintácticamente que no coincide con la característica válida del campo correspondiente válido para generar un campo válido en base, al menos en parte, a una o más reglas determinadas empíricamente, en donde las reglas determinadas empíricamente se basan, al menos en parte, en posibles errores que ocurren en el campo analizado sintácticamente y las posibles modificaciones que se pueden implementar para corregir cada posible error.
Description
5
10
15
20
25
30
35
40
45
50
DESCRIPCION
Análisis de archivos ejecutables portátiles Campo técnico
Esta solicitud se refiere de manera general a software de ingeniería inversa, y más particularmente se refiere a software de desempaquetado y análisis de validez de archivos de software.
Antecedentes de la descripción
El formato de archivo ejecutable portátil (formato de archivo PE), como se define por Microsoft Corporation en la “Microsoft Portable Executable and Common Object File Format Specification” es un formato de archivo para ejecutables, código objeto y DLL (bibliotecas de enlace dinámico). Los archivos PE se usan en versiones de 32 bits y 64 bits de los sistemas operativos Windows de Microsoft. El formato de archivo PE es un formato altamente versátil que se puede usar en numerosos entornos de sistemas operativos y soporta varias soluciones de procesador.
Los desarrolladores de software pueden usar diversos esquemas para proteger el software, incluyendo archivos PE. Por ejemplo, los empaquetadores de software se pueden utilizar para comprimir binarios, que pueden disminuir el uso de ancho de banda asociado con la transferencia de los binarios y volumen de almacenamiento. De manera similar, los empaquetadores se pueden utilizar para proteger la propiedad intelectual incorporada dentro del software y para evitar un robo de código. El empaquetado puede implicar diversos esquemas de compresión y/o cifrado que pueden ofuscar los contenidos del código ejecutable. La ejecución del archivo ejecutable empaquetado puede desempaquetar el código ejecutable original (por ejemplo, que puede incluir descomprimir y/o descifrar) y entonces transferir el control al código ejecutable original. Por tanto, la naturaleza del código ejecutable puede no ser conocida hasta que esté ejecutándose realmente el software. Esto puede ser problemático, por ejemplo, si el código ejecutable es un programa de ordenador malintencionado u otro software indeseable, ya que la naturaleza del software no puede ser conocida hasta que sea demasiado tarde. El documento US2009/0013405 en nombre de Schipka se refiere al escaneado de archivos de ordenador para detectar código malicioso. El documento US2009/133125 en nombre de Choi et al. se refiere a un método y aparato para detectar software malicioso analizando la cabecera de un archivo ejecutable.
Compendio de la descripción
Según una primera implementación, un método implementado por ordenador se define según la reivindicación 1.
También se pueden incluir una o más de los siguientes rasgos. El campo analizado sintácticamente puede incluir uno o más de una firma de formato ejecutable portátil, un campo ImageBase, un campo SizeOfImage, un campo FileAlignment, un campo SectionAlignment, una dirección EntryPoint, una tabla de importación, una tabla de direcciones de importación, una tabla de exportación, una tabla de reubicación, una tabla de recursos, una tabla de almacenamiento local de subprocesos, una tabla de configuración de carga, una tabla de importación vinculada, una tabla COM y una tabla de sección ejecutable portátil. El atributo del campo analizado sintácticamente puede incluir uno o más de un identificador de campo, una longitud de campo y un contenido de campo.
Según otra implementación, se define un programa de ordenador según la reivindicación 5.
Se pueden incluir uno o más de los siguientes rasgos. El campo analizado sintácticamente puede incluir uno o más de una firma de formato ejecutable portátil, un campo ImageBase, un campo SizeOfImage, un campo FileAlignment, un campo SectionAlignment, una dirección EntryPoint, una tabla de importación, una tabla de direcciones de importación, una tabla de exportación, una tabla de reubicación, una tabla de recursos, una tabla de almacenamiento local de subprocesos, una tabla de configuración de carga, una tabla de importación vinculada, una tabla COM y una tabla de sección ejecutable portátil. El atributo del campo analizado sintácticamente puede incluir uno o más de un identificador de campo, una longitud de campo y un contenido de campo.
Según aún otra implementación, se define un sistema según la reivindicación 9.
Se pueden incluir uno o más de los siguientes rasgos. El campo analizado sintácticamente puede incluir uno o más de una firma de formato ejecutable portátil, un campo ImageBase, un campo SizeOfImage, un campo FileAlignment, un campo SectionAlignment, una dirección EntryPoint, una tabla de importación, una tabla de direcciones de importación, una tabla de exportación, una tabla de reubicación, una tabla de recursos, una tabla de almacenamiento local de subprocesos, una tabla de configuración de carga, una tabla de importación vinculada, una tabla COM y una tabla de sección ejecutable portátil. El atributo del campo analizado sintácticamente puede incluir uno o más de un identificador de campo, una longitud de campo y un contenido de campo.
Los detalles de una o más implementaciones se exponen en los dibujos anexos y la descripción a continuación. Otras características y ventajas llegarán a ser evidentes a partir de la descripción, los dibujos, y las reivindicaciones.
5
10
15
20
25
30
35
40
45
50
55
Breve descripción de los dibujos
La FIG. 1 representa esquemáticamente un dispositivo informático que puede ejecutar uno o más de un proceso de comprobación de validez, un proceso de reparación y un proceso de desempaquetado automatizado.
La FIG. 2 es un diagrama de flujo de un proceso realizado por el proceso de comprobación de validez de la FIG. 1.
La FIG. 3 es un diagrama de flujo de un proceso realizado por el proceso de reparación de la FIG. 1.
La FIG. 4 es un diagrama de flujo de un proceso realizado por el proceso de desempaquetado automatizado de la FIG. 1.
Descripción detallada de las realizaciones ejemplares
Como se apreciará por un experto en la técnica, la presente invención se puede incorporar como un sistema, método o producto de programa de ordenador. Por consiguiente, la presente invención puede tomar la forma de una realización enteramente hardware, una realización enteramente software (incluyendo microprogramas, software residente, microcódigo, etc.) o una realización que combina aspectos software y hardware que puede ser referida en la presente memoria de manera general como un “circuito”, “módulo” o “sistema”. Además, la presente invención puede tomar la forma de un producto de programa de ordenador incorporado en uno o más medios legibles por ordenador (es decir, utilizables en ordenador) que tienen un código de programa utilizable en ordenador incorporado en el mismo.
Se puede utilizar cualquier combinación de uno o más medios legibles por ordenador. El medio legible por ordenador incluye un medio de almacenamiento legible por ordenador, que puede ser, por ejemplo, pero no está limitado a, un sistema, un aparato, un dispositivo electrónico, magnético, óptico, electromagnético, de infrarrojos, o de semiconductores, o cualquier combinación adecuada de los precedentes. Un medio de almacenamiento legible por ordenador ejemplar puede incluir, pero no se limita a, un disquete de ordenador portátil, un disco duro, una unidad de disco de estado sólido, una memoria de acceso aleatorio (RAM), una memoria de sólo lectura (ROM), una memoria de sólo lectura programable y borrable (memoria EPROM o rápida), una fibra óptica, un disco compacto portátil de memoria de sólo lectura (CD-ROM), un dispositivo de almacenamiento óptico, un dispositivo de almacenamiento magnético, o cualquier combinación adecuada de los precedentes. En el contexto de este documento, un medio de almacenamiento legible por ordenador puede ser cualquier medio que pueda contener, o almacenar un programa para uso por o en conexión con un sistema, aparato o dispositivo de ejecución de instrucciones.
El código de programa de ordenador para llevar a cabo las operaciones de la presente invención puede estar escrito en un lenguaje de programación orientado a objetos tal como Java, Smalltalk, C++ o similares. No obstante, el código de programa de ordenador para llevar a cabo las operaciones de la presente invención también puede estar escrito en lenguajes de programación de procedimiento convencional, tales como el lenguaje de programación “C” o lenguajes de programación similares. El código de programa puede ejecutarse totalmente en un único dispositivo informático, por ejemplo, un paquete de software autónomo, y o puede ser al menos ejecutado parcialmente en múltiples dispositivos informáticos que pueden estar remotos unos de otros. En este último escenario, los dispositivos informáticos remotos se pueden conectar entre sí a través de una red de área local (LAN) o red de área extensa (WAN), o la conexión se puede hacer a uno o más dispositivos informáticos remotos (por ejemplo, a través de Internet usando un Proveedor de Servicios de Internet).
La presente invención se describe a continuación con referencia a ilustraciones de diagrama de flujo y/o diagramas de bloques de métodos, aparatos (sistemas) y productos de programas de ordenador según realizaciones de la invención. Se entenderá que cada bloque de las ilustraciones de diagrama de flujo y/o de los diagramas de bloques, y combinaciones de bloques en las ilustraciones de diagrama de flujo y/o diagramas de bloques, se pueden implementar mediante instrucciones de programa de ordenador. Estas instrucciones de programa de ordenador se pueden proporcionar a un procesador de un ordenador de propósito general, un ordenador de propósito especial, u otro aparato de procesamiento de datos programable para producir una máquina, de manera que las instrucciones, que se ejecutan a través del procesador del ordenador u otro aparato de procesamiento de datos programable, creen medios para implementar las funciones/actos especificados en el bloque o bloques del diagrama de flujo y/o diagrama de bloques.
Estas instrucciones de programa de ordenador también se pueden almacenar en una memoria legible por ordenador que pueden dirigir a un ordenador o a otro aparato de procesamiento de datos programable a funcionar de una manera particular, de manera que las instrucciones almacenadas en la memoria legible por ordenador producen un artículo de fabricación que incluye medios de instrucciones que implementan la función/acto especificado en el bloque o bloques del diagrama de flujo y/o diagrama de bloques.
Las instrucciones de programa de ordenador también se pueden cargar en un ordenador u otro aparato de procesamiento de datos programable para hacer que se realicen una serie de pasos operativos en el ordenador u otro aparato programable para producir un proceso implementado por ordenador de manera que las instrucciones
5
10
15
20
25
30
35
40
45
50
55
que se ejecutan en el ordenador u otro aparato programare proporcionan los pasos para implementar las funciones/actos especificados en el bloque o bloques del diagrama de flujo y/o diagrama de bloques.
Con referencia a la FIG. 1, se muestra el proceso de comprobación de validez 10, el proceso de reparación 12, y el proceso de desempaquetado automatizado 14 que pueden residir cada uno en y se pueden ejecutar por el dispositivo informático 16. Mientras que cada uno del proceso de comprobación de validez 10, el proceso de reparación 12, y el proceso de desempaquetado automatizado 14 se muestran residiendo en el dispositivo informático 12, esto está previsto solamente con propósitos ilustrativos, ya que uno o más del proceso de comprobación de validez 10, el proceso de reparación 12, y el proceso de desempaquetado automatizado 14 pueden residir en un dispositivo informático separado.
Ejemplos de dispositivo informático 16 pueden incluir, pero no se limitan a: un ordenador personal, un ordenador servidor, una serie de ordenadores servidores, un miniordenador, y un ordenador central. El dispositivo informático
ffis ffis ffis ffis
16 puede ejecutar un sistema operativo, como por ejemplo, Microsoft Windows XP o Red Hat Linux , por ejemplo. Varios dispositivos informáticos y sistemas operativos adicionales/alternativos pueden ser utilizados igualmente. Por ejemplo, el dispositivo informático 16 puede ser parte de una red informática distribuida con uno o más del proceso de comprobación de validez 10, proceso de reparación 12 y proceso de desempaquetado automatizado 14 que se ejecuta, en todo o en parte, en otro dispositivo informático acoplado con el dispositivo informático 16 a través de una red de datos (por ejemplo, una LAN, una WAN, Internet, etc.).
Como se debatirá a continuación en mayor detalle, el proceso de comprobación de validez 10 puede analizar sintácticamente una imagen binaria de un archivo ejecutable portátil para generar un campo analizado sintácticamente. El proceso de comprobación de validez 10 también puede determinar un atributo del campo analizado sintácticamente. Además el proceso comprobación de validez 10 puede comparar el atributo del campo analizado sintácticamente con una característica válida de un campo correspondiente válido basado, al menos en parte, en una especificación de formato de archivo ejecutable portátil. El proceso de comprobación de validez 10 también puede determinar si el atributo del campo analizado sintácticamente coincide con la característica válida del campo correspondiente válido.
Además, y como también se debatirá a continuación en mayor detalle, el proceso de reparación 12 puede identificar un campo no válido de un archivo ejecutable portátil. El proceso de reparación 12 puede determinar también la probabilidad de reparar el campo no válido del archivo ejecutable portátil. El proceso de reparación 12 puede generar un modelo de reparación para reparar el campo no válido del archivo ejecutable portátil. El proceso de reparación 12 puede reparar el campo no válido del archivo ejecutable portátil que se repara basado, al menos en parte, en el modelo de reparación.
De manera similar, y como también se debatirá a continuación en mayor detalle, el proceso de desempaquetado automatizado 14 puede establecer un punto de interrupción de depuración en una dirección de punto de entrada original de un archivo ejecutable portátil empaquetado. El proceso de desempaquetado automatizado 14 puede ejecutar también un proceso de depuración para el archivo ejecutable portátil empaquetado para obtener un archivo ejecutable portátil depurado en memoria. El proceso de desempaquetado automatizado 14 puede recoger también uno o más de los datos de la tabla de direcciones de importación y de los datos de la tabla de reubicación durante la ejecución del proceso de depuración para el archivo ejecutable portátil empaquetado. El proceso de desempaquetado automatizado 14 puede copiar el archivo ejecutable portátil depurado en memoria a un medio de almacenamiento, y puede terminar el proceso de depuración.
Los conjuntos de instrucciones y subrutinas del proceso de comprobación de validez 10, el proceso de reparación 12, y el proceso de desempaquetado automatizado 14, que pueden incluir uno o más módulos de software, y que se pueden almacenar en el dispositivo de almacenamiento 18 acoplado al dispositivo informático 16, se pueden ejecutar por uno o más procesadores (no mostrados) y uno o más módulos de memoria (no mostrados) incorporados en el dispositivo informático 16. El dispositivo de almacenamiento 18 puede incluir, pero no está limitado a: una unidad de disco duro; una unidad de estado sólido, una unidad de cinta; una unidad óptica; una agrupación RAID; una memoria de acceso aleatorio (RAM); y una memoria de sólo lectura (ROM).
Debido al hecho de que los archivos PE (ejecutables portátiles) contienen código ejecutable, puede ser deseable realizar una validación de archivo anterior a la ejecución del objeto binario (por ejemplo, la imagen binaria del archivo PE). El proceso de comprobación de validez 10 puede analizar una imagen binaria PE anterior a la ejecución para determinar si el archivo PE es una imagen binaria válida. Una imagen binaria válida puede referirse a un archivo que se puede usar por un sistema operativo dado, o bien como una imagen que contiene código ejecutable o bien otro tipo de información multimedia.
Como se ha debatido anteriormente, y con referencia también a la FIG. 2, el proceso de comprobación de validez 10 puede analizar sintácticamente 50 una imagen binaria de un archivo ejecutable portátil (por ejemplo, una imagen binaria PE 20, que reside en el dispositivo de almacenamiento 18, mostrado en la FIG. 1) para generar 52 un campo analizado sintácticamente. El proceso de comprobación de validez 10 también puede determinar 54 un atributo del campo analizado sintácticamente. Además, el proceso de comprobación de validez 10 puede comparar 56 el atributo del campo analizado sintácticamente con una característica válida de un campo correspondiente válido basada, al
5
10
15
20
25
30
35
40
45
50
55
menos en parte, en una especificación de formato de archivo ejecutable portátil. El proceso de comprobación de validez 10 puede determinar 58 si el atributo del campo analizado sintácticamente coincide con la característica válida del campo correspondiente válido.
El proceso de comprobación de validez 10 puede analizar sintácticamente 50 la imagen binaria PE 20 para generar 52 un campo analizado sintácticamente. El proceso de comprobación de validez 10 puede analizar sintácticamente 50 la imagen binaria PE 20 para generar 52 una pluralidad de campos coherentes con el formato de archivo PE 100. Por ejemplo, el proceso de comprobación de validez 10 puede analizar sintácticamente 50 de manera general una imagen binaria PE en una firma de formato ejecutable portátil, un campo ImageBase, un campo SizeOflmage, un campo FileAlignment, un campo SectionAlignment, una dirección EntryPoint, una tabla de importación, una tabla de direcciones de importación, una tabla de exportación, una tabla de reubicación, una tabla de recursos, una tabla de almacenamiento local de subprocesos, una tabla de configuración de carga, una tabla de importación vinculada, una tabla COM y una tabla de sección ejecutable portátil.
Aunque se han indicado varios campos, éstos se prevén solamente con propósitos ilustrativos, en la medida que el proceso de comprobación de validez 10 puede analizar sintácticamente 50 la imagen binaria PE 20 en varios campos adicionales/alternativos seleccionados basada en criterios de diseño y necesidad del usuario. Adicionalmente, el análisis sintáctico 50 de la imagen binaria PE 20 para generar 52 uno o más campos analizados sintácticamente, puede incluir, pero no se limita a, aislar físicamente cada campo (por ejemplo, copiar cada campo en un archivo separado, un campo de base de datos o similar), leer individualmente cada campo, asociar un desplazamiento con el principio (y/o final) de cada campo, o similares. Por tanto, el análisis sintáctico 50 de la imagen binaria PE 20 para generar 52 uno o más campos analizados sintácticamente puede permitir un examen individual de cada campo.
Como se ha debatido anteriormente, el proceso de comprobación de validez 10 también puede determinar 54 un atributo del campo analizado sintácticamente. El atributo determinado 54 mediante el proceso de comprobación de validez 10 puede incluir uno o más de un identificador de campo, una longitud de campo, y un contenido de campo. Por ejemplo, el proceso de comprobación de validez 10 puede determinar 54 que la imagen binaria PE 20 incluye un campo ImageBase que tiene un valor de 0x00400000, un campo SectionAlignment que tiene un valor de 0x1000, y un campo FileAlignment que tiene un valor de 0x200.
El proceso de comprobación de validez 10 puede comparar 56 uno o más atributos determinados 54 del campo analizado sintácticamente con una característica válida de un campo correspondiente válido basada, al menos en parte, en una especificación de formato de archivo ejecutable portátil. Un campo correspondiente válido puede incluir un campo que se requiere o permite por la “Microsoft Portable Executable and Common Object File Format Specification” publicada por Microsoft Corporation (PECOFF), y que corresponde a un campo analizado sintácticamente. Por ejemplo, un campo correspondiente válido para el campo ImageBase analizado sintácticamente puede ser el campo ImageBase permitido como un campo específico de Windows opcional por PECOFF. Una característica válida de un campo correspondiente válido puede incluir una característica que es admisible por PECOFF. Por ejemplo, PECOFF puede especificar identificadores de campo, longitudes de campo y contenidos de campo aceptables de una imagen binaria PE aceptada. Por ejemplo, PECOFF puede definir un valor de ImageBase por defecto de 0x00400000, y puede requerir que el valor sea un múltiplo de 64 K. De manera similar, PECOFF puede especificar que el campo SectionAlignment tenga un valor que sea mayor o igual al FileAlignment. Además, PECOFF puede especificar que el FileAlignment tenga un valor que sea una potencia de 2 entre 512 y 64 K, con un valor por defecto de 512. Por consiguiente, el precedente puede ser un ejemplo de características válidas para los campos identificados.
El proceso de comprobación de validez 10 puede determinar 58 si el atributo del campo analizado sintácticamente coincide con la característica válida del campo correspondiente válido basada, al menos en parte, en la comparación 56 entre el atributo del campo analizado sintácticamente y una característica válida de un campo correspondiente válido. Continuando con el ejemplo indicado anterior, el atributo determinado 54 para el campo FileAlignment de la imagen binaria PE 20 era 512. Como también se ha debatido anteriormente, PECOFF puede especificar que el campo FileAlignment tenga un valor que sea una potencia de 2 entre 512 y 64 K. Por consiguiente, el proceso de comprobación de validez 10 puede determinar 58 que el atributo del campo FileAlignment analizado sintácticamente (por ejemplo, que tiene un valor de 512) coincide con una característica válida de un campo FileAlignment válido.
La determinación 58 de si el atributo del campo analizado sintácticamente coincide con la característica válida del campo correspondiente válido puede incluir determinar 60 si el atributo del campo analizado sintácticamente es válido para un sistema operativo predeterminado. De nuevo, continuando con el ejemplo indicado anteriormente, el proceso de comprobación de validez 10 puede haber determinado 54 un valor de campo ImageBase de 0x00400000 para la imagen binaria PE 20. Este valor determinado puede ser el valor por defecto para los sistemas operativos Windows NT, Windows 2000, Windows XP, Windows 95, Windows 98 y Windows Me. No obstante, el valor por defecto del campo ImageBase para Windows CE es 0x00010000, por PECOFF. Por consiguiente, el proceso de comprobación de validez 10 puede determinar 60 que el campo ImageBase analizado sintácticamente para una imagen binaria PE 20 no es válido para Windows CE.
5
10
15
20
25
30
35
40
45
50
55
60
El proceso de comprobación de validez 10 puede determinar 58 si el campo analizado sintácticamente no coincide con la característica válida del campo correspondiente válido. Continuando con el ejemplo indicado anteriormente, PECOFF especifica que el campo SectionAlignment tiene un valor que es mayor o igual que el FileAlignment. Además, el proceso de comprobación de validez 10 puede haber determinado 54 un atributo de campo SectionAlignment de 256 y un atributo de campo FileAlignment de 512 para la imagen binaria PE 20. Por consiguiente, como el atributo de campo SectionAlignment determinado 54 (es decir, 256) no es mayor o igual que el atributo de campo FileAlignment determinado 54 (es decir, 512) para la imagen binaria PE 20, el proceso de comprobación de validez 10 puede determinar 58 que el campo SectionAlignment analizado sintácticamente no coincide con una característica válida de un campo correspondiente válido (es decir, el atributo de campo SectionAlignment determinado 54 no es mayor o igual que el atributo de campo FileAlignment determinado 54). Por consiguiente, el proceso de comprobación de validez 10 puede proporcionar un indicador (por ejemplo, proporcionar un indicador en una interfaz gráfica de usuario, no mostrada).
Si el campo analizado sintácticamente no coincide con la característica válida del campo correspondiente válido, el proceso de comprobación de validez 10 puede determinar 62 una probabilidad de modificar el campo analizado sintácticamente que no coincide con la característica válida del campo correspondiente válido para generar un campo válido. El proceso de comprobación de validez 10 puede determinar 62 la probabilidad de modificar el campo analizado sintácticamente para generar un campo válido basado, al menos en parte, en el número y la naturaleza de los errores en un campo que no coincide con la característica válida de un campo correspondiente válido. Por ejemplo, y continuando con el ejemplo debatido anteriormente, el campo SectionAlignment analizado sintácticamente de la imagen binaria PE 20 no coincide con una característica válida de un campo SectionAlignment válido porque el valor es menor que el valor del campo FileAlignment. El proceso de comprobación de validez 10 puede determinar 62 una probabilidad relativamente fuerte de ser capaz de modificar el campo SectionAlignment de la imagen binaria PE 20 para generar una característica válida en la medida que el campo SectionAlignment analizado sintácticamente de la imagen binaria PE 20 incluye un error bien definido único (esto es, el valor es menor que el campo FileAlignment). Por ejemplo, puede ser posible modificar el campo SectionAlignment para incluir un valor que es mayor o igual que el campo FileAlignment. Aunque pueden ser necesarias algunas pruebas recursivas para modificar el campo SectionAlignment de la imagen binaria PE 20 para lograr un campo válido, puede ser razonablemente probable que se pueda lograr tal modificación.
La probabilidad de modificación de un campo para generar un campo válido se puede determinar 62 basada, al menos en parte, en una o más reglas determinadas empíricamente. La una o más reglas determinadas empíricamente se pueden basar, al menos en parte, en varios tipos posibles de errores que pueden ocurrir en diversos campos, y las posibles modificaciones que se pueden implementar para corregir los errores. Por tanto, un tipo de error en un campo dado para el cual puede haber relativamente pocas modificaciones posibles que pueden dar como resultado generalmente un campo válido, el proceso de comprobación de validez 10 puede determinar 62 una probabilidad relativamente alta de modificación del campo para generar un campo válido. Por el contrario, para un tipo de error que tenga muchas modificaciones posibles, muchas de las cuales pueden no dar como resultado un campo válido, el proceso de comprobación de validez 10 puede determinar 62 una probabilidad relativamente baja de modificación del campo para generar un campo válido. De manera similar, si el número de los errores detectados entre el campo analizado sintácticamente y un campo correspondiente válido son relativamente grandes, el proceso de comprobación de validez 10 también determina 62 una probabilidad relativamente baja de modificación del campo para generar un campo válido.
El proceso de comprobación de validez 10 también puede determinar 64 si la imagen binaria del archivo ejecutable portátil incluye una biblioteca de vínculos dinámicos, un controlador de núcleo, o un objeto ejecutable. El proceso de comprobación de validez 10 puede determinar 64 la naturaleza de la imagen binaria PE 20 basada, por ejemplo, en uno o más de los campos incluidos, el contenido de los campos incluidos, o similares, evaluando los campos analizados sintácticamente relativos a posibles características válidas y posibles campos válidos. Varias características adicionales/alternativas de la imagen binaria PE 20 se pueden determinar de manera similar. Por ejemplo, el proceso de comprobación de validez 10 puede determinar uno o más de un entorno en el que puede ejecutarse el archivo PE, si el archivo PE es una consola u otra aplicación con una interfaz gráfica de usuario, si el archivo PE incluye dependencias y si las dependencias existen en el sistema de destino, si el archivo PE incluye funciones dependientes y si la función dependiente existe en bibliotecas disponibles en el sistema de destino, etc.
Como se ha mencionado brevemente anteriormente, el proceso de comprobación de validez 10 puede proporcionar una salida indicando los diversos campos analizados sintácticamente, los atributos de campo, la validez de los campos, la naturaleza del archivo PE, etc. En una realización, el proceso de comprobación de validez 10 puede proporcionar una interfaz gráfica de usuario, a través de la cual se pueden reproducir las diversas salidas. El proceso de comprobación de validez 10 adicional/alternativamente puede proporcionar una salida a una base de datos, archivo, etc., que puede ser consumida por un usuario a través de un programa adecuado, tal como una aplicación de base de datos. Otras diversas salidas adecuadas se apreciarán por los expertos en la técnica.
Las imágenes binarias PE pueden llegar a ser dañadas a través de varios mecanismos. Por ejemplo, los archivos PE pueden llegar a ser dañados cuando los archivos se transfieren de un medio a otro. De manera similar, se pueden introducir errores por los empaquetadores de software (por ejemplo, UPX, PECompact, ASPack, etc.). El error introducido por los empaquetadores de software puede reproducir algunos archivos válidos solamente para
5
10
15
20
25
30
35
40
45
50
55
60
ciertas versiones de sistemas operativos que soportan formatos de archivos PE. Por consiguiente, el proceso de reparación 12 se puede implementar para reparar los archivos PE dañados.
Con referencia también a la FIG. 3, el proceso de reparación 12 puede identificar 100 un campo no válido de un archivo ejecutable portátil (por ejemplo, la imagen binaria PE 20 mostrada en la FIG. 1). Además, el proceso de reparación 12 puede determinar 102 una probabilidad de reparar el campo no válido del archivo ejecutable portátil. El proceso de reparación 12 puede generar 104 un modelo de reparación para reparar el campo no válido del archivo ejecutable portátil. El proceso de reparación 12 puede reparar 106 el campo no válido del archivo ejecutable portátil basado, al menos en parte, en el modelo de reparación generado 104 por el proceso de reparación 12.
El proceso de reparación 12 puede identificar 100 un campo no válido de imagen binaria PE 20 utilizando una variedad de mecanismos. Por ejemplo, el proceso de reparación 12 puede recibir 108 un indicador del proceso de comprobación de validez 10 (descrito en detalle anteriormente) indicando la validez de la imagen binaria PE 20 y/o partes del subconjunto de la imagen binaria PE 20 (es decir, la validez de los diversos campos de la imagen binaria PE 20). El proceso de reparación 12 puede recibir 108 el indicador directamente del proceso de comprobación de validez 10. Adicional/alternativamente, en una realización en la que el proceso de comprobación de validez 10 puede generar un informe de validez (por ejemplo, en forma de un archivo, entradas de base de datos, o similares), el proceso de reparación 12 puede identificar 100 un campo no válido (y/o una pluralidad de campos no válidos) accediendo 110 al informe de validez e interpretando los contenidos del mismo.
En realizaciones adicionales, el proceso de reparación 12 puede identificar 100 un campo no válido de la imagen binaria PE 20 realizando 112 una o más comprobaciones de validez en la imagen binaria PE 20. Por ejemplo, el proceso de reparación 12 puede realizar una o más comprobaciones de validez en la imagen binaria PE 20 de una manera similar a la debatida anteriormente con referencia al proceso de comprobación de validez 10. Por ejemplo, el proceso de reparación 12 puede analizar sintácticamente de manera general la imagen binaria PE 20 en una pluralidad de campos, y puede comparar atributos de la pluralidad de campos con características válidas de los campos correspondientes válidos. Como se ha debatido anteriormente, las características válidas de los campos correspondientes válidos se pueden especificar por PECOFF. Por consiguiente, la validez de un campo (y/o de la imagen binaria PE 20 como un todo) se puede determinar basada, al menos en parte, en si los diversos campos y atributos cumplen con PECOFF. Por lo tanto, el proceso de reparación 12 puede identificar 100 un campo no válido como un campo que tiene un atributo que no cumple con una característica válida de unos campos correspondientes válidos como se especifica por PECOFF.
Cuando se identifica 100 un campo no válido, el proceso de reparación 12 puede examinar todos los campos de la imagen binaria PE 20, y/o puede prestar especial atención a los campos más cruciales de la imagen binaria PE 20. Ejemplos de campos que pueden ser particularmente importantes (por ejemplo, que pueden tener el impacto más grande sobre la capacidad de ejecución de la imagen binaria PE 20) pueden incluir, pero no se limitan a, firmas de formato PE, campos específicos PE (por ejemplo, ImageBase, SizeOfImage, FileAlignment, SectionAlignment, y la dirección de EntryPoint), y tablas específicas PE (por ejemplo, tabla de importación, tabla de direcciones de importación, tabla de exportación, tabla de reubicación, tabla de recursos, tabla de almacenamiento local de subprocesos, tabla de configuración de carga, tabla de importación vinculada, tabla COM y tablas de sección PE).
Como se ha debatido anteriormente, el proceso de reparación 12 puede determinar 102 una probabilidad de reparación del campo no válido (o múltiples campos no válidos) de la imagen binaria PE 20. El proceso de reparación 12 puede determinar 102 una probabilidad o reparar el campo no válido de imagen binaria PE 20 basado, al menos en parte, en la determinación 114 del número y las características de los atributos del campo no válido que no coinciden con una característica válida de un campo correspondiente válido basado, al menos en parte, en una especificación de formato de archivo ejecutable portátil (por ejemplo, PECOFF). Por ejemplo, se apreciará que diversos errores pueden tener una mayor probabilidad de ser reparables que otros errores. De manera similar, un archivo PE que tiene relativamente pocos errores puede tener una mayor probabilidad de ser reparable que un archivo PE que tiene un número relativamente grande de errores.
El proceso de reparación 12 puede determinar 102 la probabilidad de reparación de un campo no válido que incluye la comparación del campo o de los campos no válidos identificados 100 (incluyendo los atributos de los campos no válidos que no cumplen con PECOFF) contra una biblioteca de posibles errores y probabilidad de reparación del error. La biblioteca (por ejemplo, la biblioteca 22 que reside en el dispositivo de almacenamiento 18), puede incluir datos derivados empíricamente de varios errores que se hayan encontrado previamente y si fue posible reparar el error para obtener un archivo ejecutable.
Como se ha mencionado anteriormente, el proceso de reparación 12 puede generar 104 un modelo de reparación para reparar el campo o los campos no válidos identificados 100. El modelo de reparación generado 104 por el proceso de reparación 12 puede incluir uno o más algoritmos para reparar uno o más campos no válidos identificados 100. Similar a determinar 102 una probabilidad de reparación del campo no válido, el proceso de reparación 12 puede generar 104 el modelo de reparación basado, al menos en parte, en una o más reglas derivadas empíricamente (por ejemplo, que se pueden incluir en la biblioteca 22). Por ejemplo, el proceso de reparación 12 puede generar 104 un modelo de reparación para reparar un campo SizeOflmage no valido que tiene un valor anormal, en el que la regla puede incluir el nuevo cálculo de un valor SizeOflmage correcto. De manera
5
10
15
20
25
30
35
40
45
50
55
60
similar, el proceso de reparación 12 puede generar 104 un modelo de reparación para reparar una sección de punto de entrada no válida que no incluye un atributo ejecutable, en el que la regla puede incluir la corrección de los atributos de sección. En un ejemplo adicional, el proceso de reparación 12 puede generar 104 un modelo de reparación para reparar datos de una tabla de recursos no válidos que no se pueden situar físicamente, en el que la regla puede incluir la eliminación temporal de los valores de la tabla de recursos no válidos en la cabecera PE. Adicionalmente, la biblioteca 22 puede incluir reglas que se derivan empíricamente basadas en una comparación entre diferentes versiones de sistema operativo y la forma en que las diferentes versiones de sistema operativo procesan el formato de archivo PE.
El proceso de reparación 12 puede reparar 106 el campo no válido del archivo ejecutable portátil basado, al menos en parte, en el modelo de reparación generado 104 por el proceso de reparación 12. Algunos errores (es decir, campos no válidos) se pueden reparar “en disco” modificando la imagen binaria PE 20 residente en el dispositivo de almacenamiento 18. Por consiguiente, el proceso de reparación 12 puede reparar 106 el campo no válido mediante la reparación 116 estática del campo no válido. La reparación 116 estática del campo no válido puede incluir modificar 118 la imagen del archivo ejecutable portátil (por ejemplo, imagen binaria PE 20) en el dispositivo de almacenamiento 18. El proceso de reparación 12 puede almacenar 120 la imagen PE modificada en el dispositivo de almacenamiento 18.
Por ejemplo, y continuando con el ejemplo anterior, en el que el campo PE SizeOflmage fue identificado 100 como que es no válido para tener un valor anormal, el proceso de reparación 12 puede reparar estáticamente el campo SizeOflmage de la imagen binaria PE 20. Por ejemplo, el proceso de reparación puede volver a calcular un valor SizeOflmage correcto. El proceso de reparación 12 puede modificar la imagen binaria PE 20 para incluir el valor de SizeOflmage correcto. El proceso de reparación 12 puede almacenar la imagen binaria PE 20 modificada en el dispositivo de almacenamiento 18.
Además de los errores que se pueden reparar “en disco”, otros errores se pueden reparar en memoria. La determinación en cuanto a qué errores se pueden reparar “en disco” sobre qué errores se pueden reparar en memoria se puede basar, al menos en parte, en las reglas derivadas empíricamente (por ejemplo, que pueden residir en la biblioteca 22). Para errores que se pueden reparar en memoria, el proceso de reparación 12 puede reparar 122 dinámicamente el campo no válido. Para reparar 122 dinámicamente un campo no válido, el proceso de reparación 12 puede ejecutar 124 el archivo ejecutable portátil (por ejemplo, la imagen binaria PE 20). El proceso de reparación 12 además puede modificar 126 el archivo ejecutable portátil que reside en memoria (por ejemplo, en RAM) durante la ejecución, en la que el archivo ejecutable portátil que reside en memoria durante la ejecución se basa en el archivo ejecutable portátil (por ejemplo, basado en la imagen binaria PE 20).
Además, el proceso de reparación puede reparar 106 el campo no válido deshabilitando 128 el campo no válido. Por ejemplo, el proceso de reparación puede deshabilitar 128 temporalmente un campo no válido eliminando 130 el campo no válido de una imagen del archivo ejecutable portátil (por ejemplo, la imagen binaria PE 20) almacenada en el dispositivo de almacenamiento 18 anterior a la ejecución del archivo ejecutable portátil.
En algunas realizaciones, el proceso de reparación 12 puede reparar 106 un campo no válido deshabilitando 128 el campo no válido y reparando 122 dinámicamente el campo no válido. Por ejemplo, y con referencia al ejemplo anterior en el que los datos de la tabla de recursos podrían no estar situados físicamente, el proceso de reparación 12 puede eliminar 130 temporalmente los valores de la tabla de recursos no validos en la cabecera PE. El proceso de reparación 12 entonces puede ejecutar 124 la imagen binaria PE 20 (por ejemplo, el proceso de reparación 12 puede ejecutar un desempaquetador de la imagen binaria PE 20) hasta el punto de entrada original del archivo ejecutable portátil. El punto de entrada original puede incluir la primera instrucción de código del archivo ejecutable portátil antes de que el archivo ejecutable portátil fuera protegido (por ejemplo, empaquetado). Una vez que la ejecución de la imagen binaria PE 20 alcanza el punto de entrada original, la memoria de proceso se puede volcar 132 al dispositivo de almacenamiento 18. Es decir, la memoria de proceso asociada con la ejecución de la imagen binaria PE 20 que reside en RAM se puede guardar en el dispositivo de almacenamiento 18. Los datos de la tabla de recursos adquiridos de la memoria durante el desempaquetado de la imagen binaria PE 20 se pueden revertir a un estado original, y se puede almacenar un nuevo archivo PE basado, al menos en parte, en la memoria de proceso volcada. Por consiguiente, se puede lograr un archivo PE válido (es decir, un archivo PE en cumplimiento con PECOFF).
En una realización, una imagen binaria PE 24 puede incluir un archivo ejecutable portátil empaquetado. Un archivo ejecutable portátil empaquetado puede incluir un archivo ejecutable portátil (coherente con pEcOfF, debatido en la presente memoria anteriormente) que puede incluir una o más protecciones de software, tales como compresión, cifrado, combinaciones de compresión y cifrado, etc. El proceso de desempaquetado automatizado 14, de manera general, puede ejecutar un proceso de depuración para el archivo ejecutable portátil empaquetado, y puede utilizar varios puntos de interrupción y rellamada para recoger datos de llenado de la tabla de direcciones de importación, así como otros diversos datos que se pueden usar para construir un archivo ejecutable portátil válido, desprotegido basado en la imagen binaria PE 24 (por ejemplo, protegida) empaquetada.
Con referencia también a la FIG. 4, el proceso de desempaquetado automatizado 14 en general puede fijar 150 un punto de interrupción de depuración en una dirección de punto de entrada original de un archivo ejecutable portátil
5
10
15
20
25
30
35
40
45
50
55
60
empaquetado (por ejemplo, una imagen binaria de PE empaquetada 24, mostrada en la FIG. 1). El proceso de desempaquetado automatizado 14 también puede ejecutar 152 un proceso de depuración para el archivo ejecutable portátil empaquetado para obtener un archivo ejecutable portátil depurado en memoria (por ejemplo, en RAM). El proceso de desempaquetado automatizado 14 puede recoger 154 uno o más de los datos de la tabla de direcciones de importación y de los datos de la tabla de reubicación durante la ejecución 152 del proceso de depuración para el archivo ejecutable portátil empaquetado. El proceso de desempaquetado automatizado 14 puede copiar 156 el archivo ejecutable portátil depurado almacenado en memoria a un medio de almacenamiento (por ejemplo, el dispositivo de almacenamiento 18). El proceso de desempaquetado automatizado 14 puede terminar 158 el proceso de depuración en el punto de entrada original del archivo ejecutable portátil.
Como se ha debatido, el proceso de desempaquetado automatizado 14 puede establecer 150 un punto de interrupción de depuración en una dirección de punto de entrada original de la imagen binaria PE empaquetada 24. El punto de entrada original de la imagen binaria PE empaquetada 24 puede ser la primera instrucción del código ejecutable antes de que el archivo fuera protegido. El establecimiento 150 de un punto de interrupción de depuración en la dirección del punto de entrada original de la imagen binaria PE empaquetada 24 puede permitir que la ejecución de la imagen binaria PE empaquetada 24 sea suspendida anterior al control que se pasa al archivo ejecutable incorporado dentro de la imagen binaria PE empaquetada 24. Tal como se usa en la presente memoria, “ejecución de la imagen binaria PE empaquetada” y “ejecutar la imagen binaria PE empaquetada” se puede referir a la ejecución del archivo incorporado por la imagen binaria PE empaquetada y ejecutar el archivo PE incorporado por la imagen binaria PE empaquetada. El proceso de desempaquetado automatizado 14 puede determinar 160 los datos del campo ImageBase del archivo ejecutable portátil empaquetado y los datos de AddressOfEntryPoint del archivo ejecutable portátil empaquetado. Los datos del campo ImageBase y los datos de AddressOfEntryPoint se pueden cargar desde la imagen binaria PE 24. La dirección del punto de entrada original de la imagen binaria PE empaquetada 24 puede ser la suma de los datos de ImageBase y de los datos de AddressOfEntryPoint. La determinación del punto de entrada original puede incluir adicionalmente otros cálculos numéricos, que se pueden basar, al menos en parte, en la disposición del empaquetador de software en sí mismo. El proceso de desempaquetado automatizado 14 puede cargar varios datos adicionales de la imagen binaria PE empaquetada 24, tales como, pero no limitados a, datos de ImageBase, datos de SizeOflmage, y datos de sección PE.
El proceso de desempaquetado automatizado 14 puede inicializar 162 el proceso de depuración. La inicialización 162 del proceso de depuración puede incluir crear un proceso de depuración basado, al menos en parte, en la imagen binaria PE empaquetada 24. Es decir, la inicialización 162 del proceso de depuración puede establecer un entorno de depuración en el que se puede ejecutar la imagen binaria PE empaquetada 24. En el proceso de depuración inicializado, el proceso de desempaquetado automatizado 14 puede establecer 150 un punto de interrupción de depuración en el punto de entrada original. El punto de interrupción de depuración establecido en el punto de entrada original se llamará una vez que el proceso de depuración finaliza la carga, antes de la ejecución de la primera instrucción del archivo ejecutable incorporado dentro de la imagen binaria PE empaquetada 24.
El proceso de desempaquetado automatizado 14 puede ejecutar 152 el proceso de depuración inicializado. Es decir, la imagen binaria PE empaquetada 24 se puede ejecutar dentro del entorno de depuración establecido. El proceso de desempaquetado automatizado 14 puede recoger 154 uno o más de los datos de la tabla de direcciones de importación y de los datos de la tabla de reubicación. La recogida 154 de uno o más de los datos de la tabla de direcciones de importación y de los datos de la tabla de reubicación puede incluir ejecutar el proceso de depuración hasta que alcance el código de llenado de la tabla de direcciones de importación. En parte, el proceso de desempaquetado automatizado 14 puede recoger 154 uno o más de los datos de la tabla de direcciones de importación y de los datos de la tabla de reubicación estableciendo 164 uno o más puntos de interrupción de depuración asociados con una llamada LoadLibrary, una llamada GetModuleHandle, y una llamada GetProcAddress. También se pueden asociar puntos de interrupción adicionales con una parte del empaquetador de software que reubica el archivo en memoria. Los puntos de interrupción asociados con una llamada LoadLibrary, una llamada GetModuleHandle, y una llamada GetProcAddress se pueden establecer, en algunas realizaciones, durante la inicialización 162 del proceso de depuración.
La imagen binaria PE empaquetada 24 que se ejecuta dentro del proceso de depuración puede utilizar una llamada de API LoadLibrary o una llamada de API GetModuleHandle con el fin de cargar una biblioteca de vínculos dinámicos dependientes. El ajuste 164 de uno o más puntos de interrupción asociados con una llamada LoadLibrary o una llamada GetModuleHandle puede dar como resultado una rellamada al proceso de desempaquetado automatizado 14 cuando se ejecuta la imagen binaria PE empaquetada 24 carga una biblioteca de vínculos dinámicos. En respuesta a la rellamada del punto de interrupción asociada con una llamada LoadLibrary o una llamada GetModuleHandle, el proceso de desempaquetado automatizado 14 puede recoger 154 el nombre de la biblioteca de vínculos dinámicos que se carga ejecutando la imagen binaria PE empaquetada 24.
De manera similar, la imagen binaria PE empaquetada 24 que se ejecuta dentro del proceso de depuración puede utilizar una llamada de API GetProcAddress para encontrar las ubicaciones de las API (interfaces de programación de aplicaciones) necesarias. El ajuste 164 de uno o más puntos de interrupción asociados con una llamada de API GetProcAddress puede dar como resultado una rellamada al proceso de desempaquetado automatizado 14 cuando se ejecuta la imagen binaria PE empaquetada 24 carga las direcciones de las API necesarias. En respuesta a la rellamada de punto de interrupción asociado con una llamada de API GetProcAddress, el proceso de
5
10
15
20
25
30
35
40
45
50
55
desempaquetado automatizado 14 puede recoger 154 las direcciones de las API que se sitúan ejecutando la imagen binaria PE empaquetada 24. La ejecución de la imagen binaria PE empaquetada 24 puede llamar a la API GetProcAddress en dos ubicaciones, por ejemplo, para la ubicación de la API de cadena y la ubicación de la API ordinal. El proceso de desempaquetado automatizado 14 puede establecer 164 un punto de interrupción asociado con cada llamada de API GetProcAddress. El proceso de desempaquetado automatizado 14 puede añadir las ubicaciones de las API ubicadas por las llamadas de API GetProcAddress a la última biblioteca de vínculos dinámicos recogida.
El proceso de desempaquetado automatizado 14 puede copiar 156 un archivo PE depurado de memoria (por ejemplo, RAM) a un medio legible por ordenador, tal como el dispositivo de almacenamiento 18. Una vez que la imagen binaria PE empaquetada 24, que se ejecuta dentro del entorno de depuración, alcanza el punto de entrada original del archivo ejecutable incorporado en el mismo, el desempaquetado del archivo puede ser sustancialmente completo. Es decir, el archivo se puede descomprimir y/o descifrar, o similar (dependiendo de la naturaleza de las protecciones asociadas con la imagen binaria PE empaquetada 24). Por tanto, en este punto un archivo PE desempaquetado puede residir en memoria asociada con el dispositivo informático 16 (por ejemplo, PE en memoria 26, mostrada en la FIG. 1). El proceso desempaquetado automatizado 14 puede copiar el Pe desempaquetado en memoria 26, por ejemplo, a un archivo que reside en el medio de almacenamiento 18. Por tanto, el proceso de desempaquetado automatizado 14 puede crear el PE almacenado 28, que puede ser al menos una parte de un archivo ejecutable portátil desempaquetado basado, al menos en parte, en la imagen binaria PE empaquetada 24.
El proceso de desempaquetado automatizado 14 puede pegar 166 una o más de una tabla de direcciones de importación, basada, al menos en parte, en los datos de la tabla de direcciones de importación recogidos 154, y una tabla de reubicación, basada, al menos en parte, en los datos de la tabla de reubicación recogidos 154 en el archivo ejecutable portátil depurado (por ejemplo, PE 28 almacenado). Por ejemplo, el proceso de desempaquetado automatizado 14 puede construir una o más de una tabla de direcciones de importación y una tabla de reubicación basada, al menos en parte, en los datos de la tabla de direcciones de importación y los datos de la tabla de reubicación recogidos 154 por el proceso de desempaquetado automatizado 14 durante la ejecución 152 del proceso de depuración (por ejemplo, que puede incluir la ejecución de la imagen binaria PE empaquetada 24 dentro de un entorno de depuración).
El pegado 166 de una o más de una tabla de direcciones de importación, basada, al menos en parte, en los datos de la tabla de direcciones de importación 154 recogidos, y una tabla de reubicación, basada, al menos en parte, en los datos de la tabla de reubicación 154 recogidos en el archivo ejecutable portátil depurado (por ejemplo, PE 28 almacenado) puede incluir añadir 168 una nueva sección al archivo ejecutable portátil depurado. Por ejemplo, el PE 28 almacenado puede no incluir una sección para una tabla de direcciones de importación y/o una sección para una tabla de reubicación. Por consiguiente, el proceso de desempaquetado automatizado 14 puede hacer espacio para una tabla de direcciones de importación y/o una tabla de reubicación dentro del PE 28 almacenado (por ejemplo, añadiendo 168 una sección adecuada dentro del PE 28 almacenado para una tabla de direcciones de importación y/o una tabla de reubicación). El proceso de desempaquetado automatizado 14 entonces puede pegar 166 la tabla de direcciones de importación y/o la tabla de reubicación en las ubicaciones adecuadas del PE 28 almacenado.
Una vez que se han pegado 166 la tabla de direcciones de importación y/o la tabla de reubicación en el PE 28 almacenado, el proceso de desempaquetado automatizado 14 puede realinear 170 el archivo PE depurado (por ejemplo, PE 28 almacenado). Generalmente, realinear 170 el archivo PE depurado puede incluir compactar el archivo y verificar que el archivo es una imagen válida, por ejemplo, que puede incluir verificar que los tamaños físicos de las secciones PE individuales del archivo son correctas y tan pequeñas como sea posible. Adicionalmente, el proceso de desempaquetado automatizado 14 puede hacer leer, escribir y ejecutar todos los atributos de sección del archivo PE depurado (por ejemplo, PE 28 almacenado). Por tanto, el proceso de desempaquetado automatizado 14 puede crear un archivo PE válido que puede parecerse sustancialmente a la imagen binaria PE empaquetada 24 anterior a empaquetar (es decir, anterior a modificar el archivo con protecciones y/o compresión de software).
Con el proceso de desempaquetado completo, el proceso de desempaquetado automatizado 14 puede terminar 158 la depuración de la imagen binaria PE empaquetada 25 en el punto de entrada original.
Aunque se han debatido en la presente memoria anteriormente diversos procesos discretos, tal discusión se pretende por facilidad de explicación. Los diversos procesos discretos (y/o partes de los mismos) pueden incluir módulos de una mayor aplicación que pueden interactuar unos con otros. Adicionalmente, las diversas características y pasos de los procesos se pueden utilizar en combinación con las características y pasos de otros procesos descritos en la presente memoria. Por consiguiente, la presente descripción no se debería interpretar como que está limitada a los procesos discretos que se han descrito anteriormente.
Se han descrito una serie de implementaciones. Sin embargo, se entenderá que se pueden hacer diversas modificaciones. Por consiguiente, otras implementaciones están dentro del alcance de las siguientes reivindicaciones.
Claims (12)
- 5101520253035404550REIVINDICACIONES1. Un método implementado por ordenador que comprende:analizar sintácticamente (50), mediante un dispositivo informático, una imagen binaria de un archivo ejecutable portátil para generar un campo analizado sintácticamente;determinar (54), mediante el dispositivo informático, un atributo del campo analizado sintácticamente;comparar (56), mediante el dispositivo informático, el atributo del campo analizado sintácticamente con una característica válida de un campo correspondiente válido en base a una especificación de formato de archivo ejecutable portátil;determinar (58), mediante el dispositivo informático, si el atributo del campo analizado sintácticamente coincide con la característica válida del campo correspondiente válido;identificar, mediante el dispositivo informático, si el campo analizado sintácticamente no coincide con la característica válida del campo correspondiente válido; ydeterminar (62), mediante el dispositivo informático, una probabilidad de modificar el campo analizado sintácticamente que no coincide con la característica válida del campo correspondiente válido para generar un campo válido en base, al menos en parte, a una o más reglas determinadas empíricamente, en donde las reglas determinadas empíricamente se basan, al menos en parte, en posibles errores que ocurren en el campo analizado sintácticamente y las posibles modificaciones que se pueden implementar para corregir cada posible error.
- 2. El método implementado por ordenador de la reivindicación 1, en donde el campo analizado sintácticamente incluye uno o más de una firma de formato ejecutable portátil, un campo ImageBase, un campo SizeOfImage, un campo FileAlignment, un campo SectionAlignment, una dirección EntryPoint, una tabla de importación, una tabla de direcciones de importación, una tabla de exportación, una tabla de reubicación, una tabla de recursos, una tabla de almacenamiento local de subprocesos, una tabla de configuración de carga, una tabla de importación vinculada, una tabla COM y una tabla de sección ejecutable portátil.
- 3. El método implementado por ordenador de la reivindicación 1, en donde el atributo del campo analizado sintácticamente incluye uno o más de un identificador de campo, una longitud de campo y un contenido de campo.
- 4. El método implementado por ordenador de la reivindicación 1, en donde la determinación de si el atributo del campo analizado sintácticamente coincide con la característica válida del campo correspondiente válido además incluye determinar (60), mediante el dispositivo informático, si el atributo del campo analizado sintácticamente es válido para un sistema operativo predeterminado.
- 5. Un producto de programa de ordenador que comprende un medio legible por ordenador que tiene una pluralidad de instrucciones almacenadas en el mismo, que, cuando se ejecutan por un procesador, hacen al procesador realizar operaciones que comprenden:analizar sintácticamente (50) una imagen binaria de un archivo ejecutable portátil para generar un campo analizado sintácticamente;determinar (54) un atributo del campo analizado sintácticamente;comparar (56) el atributo del campo analizado sintácticamente con una característica válida de un campo correspondiente válido en base a una especificación de formato de archivo ejecutable portátil;determinar (58) si el atributo del campo analizado sintácticamente coincide con la característica válida del campo correspondiente válido;identificar si el campo analizado sintácticamente no coincide con la característica válida del campo correspondiente válido; ydeterminar (62) una probabilidad de modificar el campo analizado sintácticamente que no coincide con la característica válida del campo correspondiente válido para generar un campo válido en base, al menos en parte, a una o más reglas determinadas empíricamente, en donde las reglas determinadas empíricamente se basan, al menos en parte, en posibles errores que ocurren en el campo analizado sintácticamente y las posibles modificaciones que se pueden implementar para corregir cada posible error.
- 6. El producto de programa de ordenador de la reivindicación 5, en donde el campo analizado sintácticamente incluye uno o más de una firma de formato ejecutable portátil, un campo ImageBase, un campo SizeOfImage, un campo FileAlignment, un campo SectionAlignment, una dirección EntryPoint, una tabla de importación, una tabla de direcciones de importación, una tabla de exportación, una tabla de reubicación, una tabla de recursos, una tabla de510152025303540almacenamiento local de subprocesos, una tabla de configuración de carga, una tabla de importación vinculada, una tabla COM y una tabla de sección ejecutable portátil.
- 7. El producto de programa de ordenador de la reivindicación 5, en donde el atributo del campo analizado sintácticamente incluye uno o más de un identificador de campo, una longitud de campo y un contenido de campo.
- 8. El producto de programa de ordenador de la reivindicación 5, en donde la determinación de si el atributo del campo analizado sintácticamente coincide con la característica válida del campo correspondiente válido además incluye determinar (60) si el atributo del campo analizado sintácticamente es válido para un sistema operativo predeterminado.
- 9. Un sistema que comprende: un procesador;una memoria acoplada con el procesador;un primer módulo de software ejecutable por el procesador y la memoria, el primer módulo de software configurado para analizar sintácticamente (50) una imagen binaria de un archivo ejecutable portátil para generar un campo analizado sintácticamente;un segundo módulo de software ejecutable por el procesador y la memoria, el segundo módulo de software configurado para determinar (54) un atributo del campo analizado sintácticamente;un tercer módulo de software ejecutable por el procesador y la memoria, el tercer módulo de software configurado para comparar (56) el atributo del campo analizado sintácticamente con una característica válida de un campo correspondiente válido en base a una especificación de formato de archivo ejecutable portátil; yun cuarto módulo de software ejecutable por el procesador y la memoria, el cuarto módulo de software configurado para determinar (58) si el atributo del campo analizado sintácticamente coincide con la característica válida del campo correspondiente válido;un quinto módulo de software ejecutable por el procesador y la memoria, el quinto módulo de software configurado para identificar si el campo analizado sintácticamente no coincide con la característica válida del campo correspondiente válido; yun sexto módulo de software ejecutable por el procesador y la memoria, el sexto módulo de software configurado para determinar (60) una probabilidad de modificar el campo analizado sintácticamente que no coincide con la característica válida del campo correspondiente válido para generar un campo válido en base, al menos en parte, a una o más reglas determinadas empíricamente, en donde las reglas determinadas empíricamente están basadas, al menos en parte, en posibles errores que ocurren en el campo analizado sintácticamente y las posibles modificaciones que se pueden implementar para corregir cada posible error.
- 10. El sistema de la reivindicación 9, en donde el campo analizado sintácticamente incluye uno o más de una firma de formato ejecutable portátil, un campo ImageBase, un campo SizeOfImage, un campo FileAlignment, un campo SectionAlignment, una dirección EntryPoint, una tabla de importación, una tabla de direcciones de importación, una tabla de exportación, una tabla de reubicación, una tabla de recursos, una tabla de almacenamiento local de subprocesos, una tabla de configuración de carga, una tabla de importación vinculada, una tabla COM y una tabla de sección ejecutable portátil.
- 11. El sistema de la reivindicación 9, en donde el atributo del campo analizado sintácticamente incluye uno o más de un identificador de campo, una longitud de campo y un contenido de campo.
- 12. El sistema de la reivindicación 9, en donde el cuarto módulo de software configurado para determinar si el atributo del campo analizado sintácticamente coincide con la característica válida del campo correspondiente válido, está configurado además para determinar (60) si el atributo del campo analizado sintácticamente es válido para un sistema operativo predeterminado.
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US22949709P | 2009-07-29 | 2009-07-29 | |
US229497P | 2009-07-29 | ||
PCT/US2010/043660 WO2011014623A1 (en) | 2009-07-29 | 2010-07-29 | Portable executable file analysis |
Publications (1)
Publication Number | Publication Date |
---|---|
ES2667024T3 true ES2667024T3 (es) | 2018-05-09 |
Family
ID=43033144
Family Applications (3)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
ES10752652.7T Active ES2644856T3 (es) | 2009-07-29 | 2010-07-29 | Desempaquetado automatizado de archivos ejecutables portátiles |
ES10765530.0T Active ES2667024T3 (es) | 2009-07-29 | 2010-07-29 | Análisis de archivos ejecutables portátiles |
ES10742940.9T Active ES2660538T3 (es) | 2009-07-29 | 2010-07-29 | Reparación de archivos ejecutables portátiles |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
ES10752652.7T Active ES2644856T3 (es) | 2009-07-29 | 2010-07-29 | Desempaquetado automatizado de archivos ejecutables portátiles |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
ES10742940.9T Active ES2660538T3 (es) | 2009-07-29 | 2010-07-29 | Reparación de archivos ejecutables portátiles |
Country Status (10)
Country | Link |
---|---|
US (5) | US8826071B2 (es) |
EP (3) | EP2460076B1 (es) |
CA (3) | CA2806370C (es) |
ES (3) | ES2644856T3 (es) |
HR (3) | HRP20171470T1 (es) |
HU (2) | HUE038328T2 (es) |
NO (2) | NO2460075T3 (es) |
PT (3) | PT2460113T (es) |
TW (3) | TW201128383A (es) |
WO (3) | WO2011014625A1 (es) |
Families Citing this family (23)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CA2806370C (en) | 2009-07-29 | 2019-07-09 | Reversinglabs Corporation | Automated unpacking of portable executable files |
US8607094B2 (en) * | 2009-09-29 | 2013-12-10 | Hyundai Motor Company | Operational system test method |
US10445309B2 (en) * | 2009-11-13 | 2019-10-15 | Ab Initio Technology Llc | Managing record format information |
US8756695B1 (en) * | 2010-10-26 | 2014-06-17 | Emc Corporation | Analysis of binary code |
US9158605B2 (en) * | 2010-12-01 | 2015-10-13 | Microsoft Technology Licensing, Llc | Method, system and device for validating repair files and repairing corrupt software |
US9019850B2 (en) * | 2011-04-11 | 2015-04-28 | Qualcomm Incorporated | CSI reporting for multiple carriers with different system configurations |
US9009678B2 (en) * | 2011-06-28 | 2015-04-14 | International Business Machines Corporation | Software debugging with execution match determinations |
CN102507682B (zh) * | 2011-10-27 | 2013-09-18 | 浙江大学 | 一种基于银/纳米银的溶解硫化氢探测电极的制备方法 |
US9047293B2 (en) | 2012-07-25 | 2015-06-02 | Aviv Grafi | Computer file format conversion for neutralization of attacks |
CN103632088A (zh) * | 2012-08-28 | 2014-03-12 | 阿里巴巴集团控股有限公司 | 一种木马检测方法及装置 |
CN103019739B (zh) * | 2012-12-28 | 2015-07-29 | 北京神州绿盟信息安全科技股份有限公司 | 重定位表的修复方法、程序脱壳方法及相关装置 |
CN103077029B (zh) * | 2012-12-28 | 2016-07-13 | 北京神州绿盟信息安全科技股份有限公司 | 一种导入表的修复方法及装置 |
US9841959B2 (en) * | 2015-02-02 | 2017-12-12 | Google Llc | Fine-grained demand driven IPO infrastructure |
US9742796B1 (en) * | 2015-09-18 | 2017-08-22 | Palo Alto Networks, Inc. | Automatic repair of corrupt files for a detonation engine |
US10032914B2 (en) * | 2015-10-20 | 2018-07-24 | Taiwan Semiconductor Manufacturing Co., Ltd. | Semiconductor device and manufacturing method thereof |
RU2606559C1 (ru) * | 2015-10-22 | 2017-01-10 | Акционерное общество "Лаборатория Касперского" | Система и способ оптимизации антивирусной проверки файлов |
US9858424B1 (en) | 2017-01-05 | 2018-01-02 | Votiro Cybersec Ltd. | System and method for protecting systems from active content |
CN108614680A (zh) * | 2016-12-14 | 2018-10-02 | 中国航空工业集团公司西安航空计算技术研究所 | 一种信息查询命令程序的自动生成方法和系统 |
US10013557B1 (en) | 2017-01-05 | 2018-07-03 | Votiro Cybersec Ltd. | System and method for disarming malicious code |
US10331890B2 (en) | 2017-03-20 | 2019-06-25 | Votiro Cybersec Ltd. | Disarming malware in protected content |
US10331889B2 (en) | 2017-01-05 | 2019-06-25 | Votiro Cybersec Ltd. | Providing a fastlane for disarming malicious content in received input content |
CN111796850B (zh) * | 2020-07-20 | 2021-05-11 | 上海航天电子通讯设备研究所 | 一种卫星载荷软件在轨维护设备及方法 |
CN115145571A (zh) * | 2021-03-31 | 2022-10-04 | 武汉斗鱼鱼乐网络科技有限公司 | 在程序核心代码中隐藏系统函数调用的方法、装置和介质 |
Family Cites Families (59)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4533997A (en) * | 1972-08-25 | 1985-08-06 | Westinghouse Electric Corp. | Computer monitored or controlled system which may be modified and de-bugged on-line by one not skilled in computer programming |
US3987420A (en) | 1973-12-28 | 1976-10-19 | Ing. C. Olivetti & C., S.P.A. | Electronic computer with equipment for debugging operative programs |
US5892900A (en) | 1996-08-30 | 1999-04-06 | Intertrust Technologies Corp. | Systems and methods for secure transaction management and electronic rights protection |
US5812848A (en) * | 1995-08-23 | 1998-09-22 | Symantec Corporation | Subclassing system for computer that operates with portable-executable (PE) modules |
US5892904A (en) * | 1996-12-06 | 1999-04-06 | Microsoft Corporation | Code certification for network transmission |
US6367012B1 (en) * | 1996-12-06 | 2002-04-02 | Microsoft Corporation | Embedding certifications in executable files for network transmission |
US6141698A (en) * | 1997-01-29 | 2000-10-31 | Network Commerce Inc. | Method and system for injecting new code into existing application code |
US5983366A (en) * | 1997-03-19 | 1999-11-09 | Optimay Corporation | Data processing system having monitoring of software activity |
US6026235A (en) | 1997-05-20 | 2000-02-15 | Inprise Corporation | System and methods for monitoring functions in natively compiled software programs |
US6202199B1 (en) * | 1997-07-31 | 2001-03-13 | Mutek Solutions, Ltd. | System and method for remotely analyzing the execution of computer programs |
US5983348A (en) * | 1997-09-10 | 1999-11-09 | Trend Micro Incorporated | Computer network malicious code scanner |
US5953534A (en) * | 1997-12-23 | 1999-09-14 | University Of Washington | Environment manipulation for executing modified executable and dynamically-loaded library files |
US6802006B1 (en) * | 1999-01-15 | 2004-10-05 | Macrovision Corporation | System and method of verifying the authenticity of dynamically connectable executable images |
TW446872B (en) * | 1999-08-26 | 2001-07-21 | Mitac Int Corp | Detection method of boot-up virus |
TW451125B (en) * | 1999-11-06 | 2001-08-21 | Mitac Int Corp | Tracking and inspecting method for files infected with computer virus |
US7058928B2 (en) * | 1999-12-23 | 2006-06-06 | Identify Software Ltd. | System and method for conditional tracing of computer programs |
US6640317B1 (en) | 2000-04-20 | 2003-10-28 | International Business Machines Corporation | Mechanism for automated generic application damage detection and repair in strongly encapsulated application |
US7146531B2 (en) | 2000-12-28 | 2006-12-05 | Landesk Software Limited | Repairing applications |
US7096368B2 (en) | 2001-08-01 | 2006-08-22 | Mcafee, Inc. | Platform abstraction layer for a wireless malware scanning engine |
US6792543B2 (en) | 2001-08-01 | 2004-09-14 | Networks Associates Technology, Inc. | Virus scanning on thin client devices using programmable assembly language |
US7043596B2 (en) | 2001-08-17 | 2006-05-09 | Sun Microsystems, Inc. | Method and apparatus for simulation processor |
US20030070087A1 (en) | 2001-10-05 | 2003-04-10 | Dmitry Gryaznov | System and method for automatic updating of multiple anti-virus programs |
TWI310919B (en) | 2002-01-11 | 2009-06-11 | Sap Ag | Context-aware and real-time item tracking system architecture and scenariors |
US7181603B2 (en) * | 2002-03-12 | 2007-02-20 | Intel Corporation | Method of secure function loading |
US7818657B1 (en) * | 2002-04-01 | 2010-10-19 | Fannie Mae | Electronic document for mortgage transactions |
US7174320B2 (en) | 2002-04-04 | 2007-02-06 | Intel Corporation | Method of providing adaptive security |
US7367056B1 (en) * | 2002-06-04 | 2008-04-29 | Symantec Corporation | Countering malicious code infections to computer files that have been infected more than once |
GB2389432B (en) * | 2002-06-07 | 2005-09-07 | Advanced Risc Mach Ltd | Instruction tracing in data processing systems |
US7478431B1 (en) * | 2002-08-02 | 2009-01-13 | Symantec Corporation | Heuristic detection of computer viruses |
US7076774B2 (en) | 2002-09-10 | 2006-07-11 | Microsoft Corporation | Infrastructure for generating a downloadable, secure runtime binary image for a secondary processor |
US8219801B2 (en) | 2003-03-10 | 2012-07-10 | International Business Machines Corporation | Method of authenticating digitally encoded products without private key sharing |
US7123141B2 (en) * | 2003-08-20 | 2006-10-17 | Contestabile Robert A | Electronic monitoring systems and methods |
US8042179B2 (en) * | 2003-09-04 | 2011-10-18 | Science Park Corporation | False code execution prevention method, program for the method, and recording medium for recording the program |
US7549148B2 (en) | 2003-12-16 | 2009-06-16 | Microsoft Corporation | Self-describing software image update components |
US7620990B2 (en) * | 2004-01-30 | 2009-11-17 | Microsoft Corporation | System and method for unpacking packed executables for malware evaluation |
US7523343B2 (en) | 2004-04-30 | 2009-04-21 | Microsoft Corporation | Real-time file system repairs |
US7349931B2 (en) * | 2005-04-14 | 2008-03-25 | Webroot Software, Inc. | System and method for scanning obfuscated files for pestware |
US8606950B2 (en) | 2005-06-08 | 2013-12-10 | Logitech Europe S.A. | System and method for transparently processing multimedia data |
CN101228509B (zh) | 2005-07-27 | 2010-05-26 | 松下电器产业株式会社 | 生成执行二进制图像的装置及方法 |
US8161548B1 (en) * | 2005-08-15 | 2012-04-17 | Trend Micro, Inc. | Malware detection using pattern classification |
US7725737B2 (en) | 2005-10-14 | 2010-05-25 | Check Point Software Technologies, Inc. | System and methodology providing secure workspace environment |
US7546412B2 (en) * | 2005-12-02 | 2009-06-09 | International Business Machines Corporation | Apparatus, system, and method for global metadata copy repair |
US8479174B2 (en) * | 2006-04-05 | 2013-07-02 | Prevx Limited | Method, computer program and computer for analyzing an executable computer file |
US7594136B2 (en) | 2006-04-19 | 2009-09-22 | Microsoft Corporation | Paging-triggered corrupted file recovery |
US7814544B1 (en) * | 2006-06-22 | 2010-10-12 | Symantec Corporation | API-profile guided unpacking |
US20080101381A1 (en) | 2006-10-25 | 2008-05-01 | Mediatek Inc. | Address resolution protocol (arp) cache management methods and devices |
US7797743B2 (en) * | 2007-02-26 | 2010-09-14 | Microsoft Corporation | File conversion in restricted process |
WO2008146475A1 (ja) | 2007-06-01 | 2008-12-04 | Panasonic Corporation | 記録装置 |
US20090013405A1 (en) * | 2007-07-06 | 2009-01-08 | Messagelabs Limited | Heuristic detection of malicious code |
US8769268B2 (en) | 2007-07-20 | 2014-07-01 | Check Point Software Technologies, Inc. | System and methods providing secure workspace sessions |
US8037536B2 (en) | 2007-11-14 | 2011-10-11 | Bank Of America Corporation | Risk scoring system for the prevention of malware |
KR100942795B1 (ko) * | 2007-11-21 | 2010-02-18 | 한국전자통신연구원 | 악성프로그램 탐지장치 및 그 방법 |
US8627302B2 (en) * | 2007-11-27 | 2014-01-07 | Oracle America, Inc. | Sampling based runtime optimizer for efficient debugging of applications |
US7996904B1 (en) * | 2007-12-19 | 2011-08-09 | Symantec Corporation | Automated unpacking of executables packed by multiple layers of arbitrary packers |
US8782615B2 (en) * | 2008-04-14 | 2014-07-15 | Mcafee, Inc. | System, method, and computer program product for simulating at least one of a virtual environment and a debugging environment to prevent unwanted code from executing |
US8073840B2 (en) | 2008-06-17 | 2011-12-06 | Attivio, Inc. | Querying joined data within a search engine index |
CA2806370C (en) | 2009-07-29 | 2019-07-09 | Reversinglabs Corporation | Automated unpacking of portable executable files |
US8510615B2 (en) | 2009-10-22 | 2013-08-13 | Xerox Corporation | Virtual repair of digital media |
US9349103B2 (en) | 2012-01-09 | 2016-05-24 | DecisionQ Corporation | Application of machine learned Bayesian networks to detection of anomalies in complex systems |
-
2010
- 2010-07-29 CA CA2806370A patent/CA2806370C/en active Active
- 2010-07-29 EP EP10765530.0A patent/EP2460076B1/en active Active
- 2010-07-29 HU HUE10742940A patent/HUE038328T2/hu unknown
- 2010-07-29 ES ES10752652.7T patent/ES2644856T3/es active Active
- 2010-07-29 WO PCT/US2010/043666 patent/WO2011014625A1/en active Application Filing
- 2010-07-29 NO NO10742940A patent/NO2460075T3/no unknown
- 2010-07-29 WO PCT/US2010/043657 patent/WO2011014620A1/en active Application Filing
- 2010-07-29 HU HUE10765530A patent/HUE038791T2/hu unknown
- 2010-07-29 EP EP10752652.7A patent/EP2460113B1/en active Active
- 2010-07-29 WO PCT/US2010/043660 patent/WO2011014623A1/en active Application Filing
- 2010-07-29 TW TW099125053A patent/TW201128383A/zh unknown
- 2010-07-29 PT PT107526527T patent/PT2460113T/pt unknown
- 2010-07-29 ES ES10765530.0T patent/ES2667024T3/es active Active
- 2010-07-29 CA CA2806368A patent/CA2806368C/en active Active
- 2010-07-29 CA CA2806367A patent/CA2806367C/en active Active
- 2010-07-29 ES ES10742940.9T patent/ES2660538T3/es active Active
- 2010-07-29 TW TW099125055A patent/TWI494751B/zh active
- 2010-07-29 US US12/846,030 patent/US8826071B2/en active Active
- 2010-07-29 PT PT107655300T patent/PT2460076T/pt unknown
- 2010-07-29 TW TW099125054A patent/TWI482013B/zh active
- 2010-07-29 NO NO10765530A patent/NO2460076T3/no unknown
- 2010-07-29 US US12/846,044 patent/US9361173B2/en active Active
- 2010-07-29 US US12/846,048 patent/US9389947B2/en active Active
- 2010-07-29 EP EP10742940.9A patent/EP2460075B1/en active Active
- 2010-07-29 PT PT107429409T patent/PT2460075T/pt unknown
-
2016
- 2016-05-09 US US15/150,046 patent/US10261783B2/en active Active
- 2016-06-09 US US15/177,978 patent/US9858072B2/en active Active
-
2017
- 2017-10-02 HR HRP20171470TT patent/HRP20171470T1/hr unknown
-
2018
- 2018-02-21 HR HRP20180306TT patent/HRP20180306T1/hr unknown
- 2018-05-03 HR HRP20180689TT patent/HRP20180689T1/hr unknown
Also Published As
Similar Documents
Publication | Publication Date | Title |
---|---|---|
ES2667024T3 (es) | Análisis de archivos ejecutables portátiles | |
US9996696B2 (en) | Systems and methods to optimize execution of a software program using a type based self assembling control flow graph | |
US9530006B2 (en) | Method and system for performing a memory safety check of a program written in an unmanaged programming language | |
US10511598B2 (en) | Technologies for dynamic loading of integrity protected modules into secure enclaves | |
KR101966754B1 (ko) | 소프트웨어 코드의 생성 및 캐싱 기법 | |
US10782943B1 (en) | Encoding data and metadata for run-time checking of computer code and data serialization | |
US20220308991A1 (en) | Test processing method and information processing apparatus | |
Gribov et al. | Fast memory debugger for large software projects | |
CN113688359A (zh) | 针对程序代码的处理方法、装置、计算设备及介质 | |
Lamaison | Finding What C++ Lost: Tracking Referent Objects with GCC |