ES2901532T3 - Autodepuración - Google Patents

Abstract

Método para asegurar software, que comprende: iniciar un proceso de software; asociar un proceso de depuración al proceso de software; ejecutar el proceso de software de manera que el proceso de depuración se invoque al menos una vez; realizar una o más funciones del proceso de software dentro del proceso de depuración; donde una salida producida por la una o más funciones del proceso de software dentro del depurador sirve como entrada para la parte restante del proceso de software.

Description

DESCRIPCIÓN

Autodepuración

BREVE DESCRIPCIÓN DE LOS DIBUJOS CAMPO

[0001] La presente divulgación se refiere a la seguridad del software, en particular a la protección de software, como aplicaciones o bibliotecas, frente a ataques que utilizan técnicas de depuración.

ANTECEDENTES

[0002] La depuración es el proceso mediante el cual se pueden identificar errores en el código. Una herramienta para esto es el depurador, un tipo de utilidad que muchos sistemas operativos permiten emparejar con el código que se quiere depurar. Cuando se produce una excepción u otro error, se informa al depurador, que puede inspeccionar entonces el código e identificar el origen de este problema. La capacidad de emparejar un depurador con código ha sido utilizada por partes malintencionadas para poner en riesgo la seguridad de ese código. En particular, puesto que un depurador puede identificar el funcionamiento del código, puede ser una fuente de vulnerabilidad.

[0003] Se han desarrollado técnicas para intentar proteger el código contra este tipo de ataques. Estas técnicas incluyen intentos de permitir que el código identifique cuándo se ha acoplado ilícitamente un depurador activo al código. Otro enfoque es diseñar el código para que este mismo inicie un depurador cuando se ejecute (este depurador puede denominarse "autodepurador"). La mayoría de los sistemas operativos solo permitirán emparejar un único depurador con un proceso determinado, lo que significa que el autodepurador ocupa el espacio que, de lo contrario, podría querer utilizar un depurador malintencionado.

[0004] El documento US7647589 B1 da a conocer un método para ejecutar una máquina virtual en un sistema informático que incluye (a) iniciar un monitor de máquina virtual (^v M^m , por sus siglas en inglés) que usa un depurador de software; (b) iniciar una máquina virtual (VM, por sus siglas en inglés) que puede ejecutar instrucciones seguras de forma nativa; (c) determinar, en tiempo de ejecución, si la instrucción es segura o potencialmente insegura; (d) ejecutar instrucciones seguras en modo nativo; y (e) activar la lógica de control para procesar instrucciones potencialmente inseguras en el depurador de software. El depurador de software puede omitir al menos una de las instrucciones potencialmente inseguras. Las instrucciones potencialmente inseguras incluyen instrucciones que no se pueden ejecutar de forma segura en el contexto de la VM e instrucciones que pueden provocar resultados impredecibles en el contexto de la VM.

La Figura 1 es una representación esquemática de las características principales de un proceso de código de la técnica anterior, y el proceso de código acoplado y el proceso de depuración de la presente divulgación; la Figura 2 es un diagrama de flujo que muestra las etapas del tiempo de ejecución según una forma de realización;

la Figura 3 muestra aspectos primarios de la generación de binarios según la presente divulgación; y la Figura 4 muestra una infraestructura de hardware para implementar una forma de realización preferida. DESCRIPCIÓN DETALLADA DE LOS DIBUJOS

[0005] El objeto de la invención se resuelve mediante un método que tiene las características de la reivindicación 1, un programa ejecutable por ordenador que tiene las características de la reivindicación 9 y un dispositivo que tiene las características de la reivindicación 10. Las formas de realización ventajosas del mismo se definen en las respectivas reivindicaciones dependientes.

[0006] En resumen, se proporcionan métodos para asegurar el funcionamiento del código. Según la divulgación, un método puede comprender iniciar un proceso de código e inicializar un proceso de depuración unido al proceso de código. Durante la ejecución del proceso de código, las operaciones de importancia crítica para la funcionalidad del proceso de código se pueden llevar a cabo dentro del proceso de depuración. Como resultado, el proceso de depuración no se puede reemplazar ni alterar sin afectar a la funcionalidad del proceso de código. Por lo tanto, el proceso de código puede protegerse de la inspección mediante técnicas de depuración modificadas o maliciosas.

[0007] En este contexto, se puede entender que "crítica" significa que la salida producida por las operaciones llevadas a cabo en el proceso de depuración sirve como entrada para la parte restante del proceso de código, y que esa entrada es necesaria para permitir que el proceso de código genere su salida correcta dada la otra entrada del proceso de código.

[0008] En algunos aspectos de la divulgación se proporciona un método para asegurar el software. El método puede comprender iniciar un proceso de software y vincular un proceso de depuración al proceso de software. A continuación, el proceso de código se puede ejecutar de modo que el proceso de depuración se invoque al menos una vez. Al invocarse, se pueden realizar una o más funciones dentro del proceso de depuración, teniendo estas funciones una salida que depende de los datos asociados con el proceso de software. Puesto que la salida puede variar dependiendo de los datos asociados con el proceso de software (es decir, no está predeterminada), la funcionalidad general solo se logra cuando tanto el proceso de software como el proceso de depuración funcionan correctamente. Esto no deja espacio para interferencias con el proceso de depuración para analizar el código.

[0009] El proceso de software de este aspecto puede considerarse un proceso “depurado”, ya que ocupa el lugar del proceso que está siendo depurado por el depurador. El proceso de depuración se puede inicializar cuando se inicia el proceso de software o en un momento posterior. Por ejemplo, un proceso de depuración se puede inicializar cuando se carga cierta funcionalidad (por ejemplo, una biblioteca) en el proceso de software. En algunos ejemplos, el proceso de software se bifurca para inicializar el proceso de depuración. En otros ejemplos, el proceso de depuración puede inicializarse primero y luego bifurcarse para generar el proceso de software.

[0010] En algunas formas de realización, la salida comprende una salida de datos para su uso por el proceso de software. Por lo tanto, la salida de las funciones dentro del proceso de depuración puede influir directamente en el funcionamiento posterior del proceso de software, acoplando así estrechamente los dos procesos de una manera que no es fácil de romper. La salida de la función en el proceso de depuración comprende una entrada de datos para el proceso de software, siendo dicha entrada de datos crítica para la ejecución del proceso de software.

[0011] En algunas formas de realización, la salida de una función determinada puede indicar múltiples puntos de retorno dentro del proceso de software para su ejecución continua. Como tal, el punto de retorno de al menos una función es variable (en lugar de fijo). Por lo tanto, el flujo de control es variable según el comportamiento del proceso de depuración y no se puede inferir o recrear fácilmente.

[0012] En algunas formas de realización, el proceso de depuración proporciona capacidades de soporte de memoria para permitir que la una o más funciones recuperen datos de la memoria dentro del espacio de direcciones del proceso de software. Como tal, las funciones relevantes para el programa pueden tener la capacidad de procesar datos como si se llevaran a cabo dentro del proceso de software.

[0013] El proceso de depuración se puede invocar cuando se alcanza un punto de interrupción dentro del proceso de código. El proceso de depuración se puede separar del proceso de software cuando finaliza el proceso de software. El proceso de software puede finalizar porque se ha completado, o de otra manera (por ejemplo, cuando se cancela). Alternativamente, el proceso de depuración puede separarse del proceso de software cuando finaliza la funcionalidad dentro del proceso de software en lugar de esperar a que finalice el proceso en su conjunto.

[0014] En algunas formas de realización, el proceso de software implementa un ejecutable, como una aplicación. En otras, el proceso de código implementa una biblioteca.

[0015] En otro aspecto de la divulgación, se proporciona un método para generar código protegido. Se pueden identificar los fragmentos de código dentro del código objeto que se van a migrar a un depurador. Luego se puede generar código binario, donde el código binario en tiempo de ejecución provoca que un proceso de depuración se vincule a un proceso de software, y los fragmentos de código identificados se ejecutan dentro del proceso de depuración. El proceso de software y el proceso de depuración pueden bifurcarse a partir de un único proceso. Por ejemplo, el proceso de software puede inicializar el proceso de depuración.

[0016] La etapa de generación puede comprender la incorporación de código predefinido correspondiente a la funcionalidad genérica del depurador dentro del código binario. La etapa de generación puede ser una etapa de enlace que incorpora algunos aspectos predefinidos del depurador, tales aspectos pueden denominarse "minidepurador". Como tal, el depurador general incluye algunos aspectos genéricos, así como algunos aspectos específicos del código fuente en virtud de la inclusión de los fragmentos de código identificados.

[0017] El método puede comprender la extracción a partir del código fuente de una o más anotaciones que identifican fragmentos de código que se van a migrar a un depurador. A continuación, se compila el código fuente para generar el código objeto. A continuación, se puede generar código binario a partir del código objeto, y los fragmentos de código identificados se integran con un depurador en el código binario. De esta manera, la generación de código binario puede ser una etapa de enlace que incluye un elemento de reescritura para mover fragmentos identificados a otra ubicación. Cuando se usa después el código binario, se genera un depurador que comprende aspectos del código fuente original, que pueden ser pertinentes para la funcionalidad del código fuente.

[0018] En algunas formas de realización, el código binario comprende un primer archivo de código binario correspondiente al código fuente, pero excluyendo los fragmentos de código identificados, y un segundo archivo de código binario correspondiente al depurador. Alternativamente, un único archivo de código binario puede incorporar tanto el código fuente como el depurador.

[0019] Otros aspectos de la divulgación se refieren a productos de programas ejecutables por ordenador que comprenden instrucciones ejecutables por ordenador para llevar a cabo los métodos de los aspectos anteriormente descritos. Los aspectos de la divulgación también pueden referirse a dispositivos configurados para llevar a cabo los métodos de los aspectos anteriormente descritos.

[0020] Algunas formas de realización específicas se describen a continuación a modo de ilustración con referencia a los dibujos adjuntos, en los que números de referencia similares se refieren a características similares.

[0021] Mediante técnicas de reescritura binaria, la presente divulgación se pueden migrar partes enteras de funcionalidad del software original a un autodepurador. Esto ofrece varias ventajas. En primer lugar, el comportamiento de entrada-salida del autodepurador ya no está predeterminado: cada vez que interviene el autodepurador, este ejecuta una funcionalidad diferente que no está predeterminada, sino que, en cambio, puede variar tanto como puede variar la funcionalidad en los programas protegidos. Esto hace que la protección sea mucho más resistente frente al análisis, la desofuscación y la deconstrucción automatizados. En segundo lugar, incluso aunque el atacante pueda averiguar el flujo de control y el flujo de datos equivalente del programa original, es mucho más difícil para un atacante deshacer la protección y reconstruir ese programa original. En combinación, estos dos puntos fuertes hacen que sea mucho más difícil para un atacante desasociar el autodepurador al mismo tiempo que se mantiene el rastreo o la depuración en vivo de un programa en funcionamiento.

DISEÑO GENERAL DEL AUTODEPURADOR

[0022] La Figura 1 ilustra los conceptos básicos de un esquema de autodepuración según la presente divulgación. Esta forma de realización se dirige a Linux (y derivados como Android), los principios también se pueden aplicar a otros entornos como Windows y OS X.

[0023] A la izquierda de la Figura 1, se muestra una aplicación original sin protección, que incluye un pequeño fragmento de gráfico de flujo de control. El código de ensamblado representado es (pseudo) código ARMv7. Esta aplicación desprotegida se convierte en una aplicación protegida que consta de dos partes: un depurado, que corresponde principalmente a la aplicación original como se muestra en el centro de la figura, y un depurador, como se muestra a la derecha. Aparte de algunos componentes nuevos inyectados en el depurado y el depurador, la principal diferencia con la aplicación original es que el fragmento del gráfico de flujo de control se ha migrado de la aplicación al depurador. Esta forma de realización particular admite todos los fragmentos de código de entrada única y salida múltiple que no contienen ningún flujo de control entre procedimientos, como las llamadas de función.

[0024] La migración de dichos fragmentos es más que una simple copia: las referencias de memoria, como la instrucción LDR, deben transformarse porque, en la aplicación protegida, el código migrado que se ejecuta en el espacio de direcciones del depurador puede acceder preferiblemente a los datos que aún residen en el espacio de direcciones del depurador. Todos los componentes y transformaciones relevantes se describirán con más detalle en secciones posteriores.

[0025] Los fragmentos migrados son preferiblemente críticos para el funcionamiento de la aplicación. Es decir, la salida producida por esas operaciones llevadas a cabo migradas al proceso de depuración sirve como entrada para la parte restante del proceso de código, y esa entrada es necesaria para permitir que el proceso de código genere su salida correcta dada la otra entrada de ese proceso de código. Este requisito es fácil de pasar por alto en la práctica. Por ejemplo, un programador típico podría considerar ejecutar la inicialización de variables del proceso de código en el contexto del depurador. Sin embargo, en general, no es suficiente con ejecutar la inicialización de variables del proceso de código en el proceso de depuración, ya que, en la práctica, en los procesos sucede con bastante frecuencia que se realiza la inicialización de variables (por ejemplo, de variables locales al ingresar a una función) como resultado de buenas prácticas de programación y para cumplir con los requisitos de definición del lenguaje de programación fuente, sin que realmente sea necesario para el correcto funcionamiento del proceso y para generar salidas correctas. Esto puede deberse a que las variables simplemente no se utilizan en las rutas ejecutadas en el proceso de código, o porque los valores iniciales se sobrescriben antes de que puedan afectar a la ejecución o la salida del proceso de código.

[0026] En tiempo de ejecución, el funcionamiento de esta aplicación protegida es el siguiente. Primero, se inicia el depurado en la etapa s21, como si fuera la aplicación original. Un inicializador recién inyectado bifurca a continuación un nuevo proceso para el depurador, en el que el inicializador del depurador se asocia inmediatamente al proceso del depurado. Por lo tanto, el proceso de depuración se inicia y se vincula al proceso del depurado en la etapa s22.

[0027] Cuando posteriormente durante la ejecución del programa se alcanza el punto de entrada del fragmento de código migrado, un posible flujo de control en la aplicación sigue las flechas de la Figura 1. En la aplicación/depurado, se ejecuta la instrucción de inducción de excepción y provoca una excepción en la etapa s23 (marcada como 1 en la Figura 1). Se notifica al depurador de esta excepción y la gestiona en su bucle de depuración en la etapa s24 (marcada como 2 en la Figura 1). Entre otros, el código de este bucle es responsable de obtener el estado del proceso del depurado, buscar el fragmento de código migrado correspondiente y transferir el control al punto de entrada de ese fragmento en la etapa s25 (marcada como 3 en la Figura 1). Como se ha indicado, en ese fragmento, los accesos a la memoria no se pueden realizar tal cual. Por lo tanto, se sustituyen por invocaciones 4 de funciones de soporte de memoria 5 que acceden a la memoria en el espacio de direcciones del depurado en la etapa s26. Cuando finalmente se alcanza un punto de salida 6 en el fragmento de código migrado, el control se transfiere al punto correspondiente en el bucle de depuración 7 en la etapa s27, que actualiza el estado del depurado con los datos calculados en el depurador en la etapa s28, y 8 el control se transfiere de nuevo al depurado la etapa s29. En el caso de fragmentos de código con múltiples salidas, como en el ejemplo de la figura, el control se puede transferir de nuevo a múltiples puntos de continuación en el depurado. En este sentido, el depurador de la presente divulgación se comporta de una manera más compleja que los autodepuradores ya existentes, que implementan un mapeo uno a uno entre las transferencias de flujo de control hacia delante y hacia atrás entre el depurado y el depurador.

[0028] Finalmente, cuando se cierre la aplicación, los finalizadores integrados realizarán las operaciones de separación necesarias.

[0029] Cabe destacar que este esquema no solo se puede implementar para proteger ejecutables (es decir, binarios con una función principal y un punto de entrada), sino también para proteger bibliotecas compartidas. Al igual que los ejecutables, las bibliotecas pueden contener inicializadores y finalizadores que se ejecutan cuando el cargador del sistema operativo los carga o descarga. En ese momento, también se pueden realizar todas las bifurcaciones, asociaciones y separaciones necesarias.

[0030] Aunque la siguiente descripción se refiere principalmente a la protección de aplicaciones, los principios se aplican implícitamente por igual a aplicaciones y bibliotecas. Un aspecto que es particularmente relevante para las bibliotecas es la necesidad de una inicialización y finalización adecuadas del depurador. Esto es necesario porque no es extraño que las bibliotecas se carguen y descarguen varias veces en una sola ejecución de un programa. Por ejemplo, la carga y descarga repetitiva ocurre con frecuencia para complementos de reproductores multimedia y navegadores. Además, mientras que los programas principales constan de un solo subproceso cuando se inician, pueden constar de varios subprocesos cuando se cargan y descargan las bibliotecas.

SOPORTE DE HERRAMIENTAS

[0031] La Figura 3 muestra un posible flujo de herramientas conceptual.

Anotaciones de código fuente

[0032] Existen varias opciones para determinar los fragmentos de código que se migrarán al depurador. Una, que se muestra en la figura, y que es también la que usamos en nuestra implementación, es anotar el código fuente en la etapa s31 con pragmas, comentarios o cualquier otra forma de anotación que marque los inicios y finales de las regiones de código que se migrarán al proceso de depuración. Un simple grep es suficiente para extraer anotaciones y sus números de línea y para almacenar esa información en un archivo de anotaciones en la etapa s32.

[0033] Las opciones alternativas serían enumerar los procedimientos o archivos de código fuente que se van a proteger, o recopilar rastros o perfiles para seleccionar fragmentos interesantes de forma semiautomática.

[0034] En este sentido, es importante tener en cuenta que los fragmentos que se van a migrar al depurador no deben ser necesariamente fragmentos frecuentes. Para lograr un vínculo fuerte entre el depurado y el depurador, basta con generar excepciones con relativa frecuencia, pero no es necesario que esto sea con las rutas de código más frecuentes. A continuación, se detallarán más consideraciones para la selección de fragmentos. Puesto que cada excepción generada introducirá una cantidad significativa de sobrecarga (cambio de contexto, muchas llamadas ptrace, ...) es importante minimizar su número sin comprometer el nivel de protección.

Herramientas y compiladores estándar

[0035] Para que se implemente el enfoque de autodepuración descrito, se puede utilizar cualquier compilador "estándar" en la etapa s33. La técnica no impone ninguna restricción al código generado por el compilador. En evaluaciones experimentales, se han utilizado tanto GCC como LLVM, en las que no se requería adaptar o afinar la generación de código.

[0036] Sin embargo, un requisito es que el compilador y las utilidades binarias (el ensamblador y el enlazador) proporcionen al reescritor en tiempo de enlace información suficientemente precisa con reubicación y símbolos. Esto es necesario para permitir análisis y transformaciones de código en tiempo de enlace fiables y conservadores para implementar todo el esquema de autodepuración, incluyendo la migración y transformación de los fragmentos de código seleccionados. El hecho de proporcionar información suficientemente precisa está ciertamente al alcance de las herramientas de uso común. Los compiladores propietarios de ARM, por ejemplo, lo han hecho durante mucho tiempo de forma predeterminada, y para GNU binutils, GCC y LLVM, basta con parches muy simples para evitar que esas herramientas realicen una relajación de símbolos demasiado agresiva y una simplificación de la reubicación, y para obligarles a insertar símbolos de mapeo para marcar datos en el código. Estos requisitos se han documentado anteriormente, y se ha demostrado que son suficientes para realizar una reescritura en tiempo de enlace fiable y conservadora de código tan compleja y poco convencional como las versiones CISC (x86) y RISC (ARMv7) del kernel de Linux y las bibliotecas C, que están llenas de código de ensamblado escrito manualmente.

[0037] Una gran parte genérica del depurador, el "minidepurador", se puede precompilar con el compilador estándar y luego simplemente vincularlo a la aplicación que se va a proteger. Otras partes, como los prólogos y epílogos del bucle de depuración para cada uno de los fragmentos migrados, son generados por el reescritor en tiempo de enlace, ya que están personalizados para sus fragmentos específicos.

[0038] Para permitir que el reescritor en tiempo de enlace identifique los fragmentos que se anotaron en el código fuente, basta con pasarle la información del número de línea extraída de los archivos del código fuente y permitir que los compiladores generen archivos objeto con información de depuración. Esa información de depuración asigna entonces todas las direcciones en el código binario a los números de línea fuente, que el reescritor puede vincular a los números de línea de las anotaciones.

Binarios, bibliotecas y procesos

[0039] El reescritor en tiempo de enlace tiene dos opciones para generar una aplicación protegida en la etapa s35. Una primera opción es generar dos binarios, uno para la aplicación/depurado y otro para el depurador. Desde una perspectiva de seguridad, esto podría ser preferible, porque la semántica de la aplicación y su implementación se distribuyen entonces en múltiples binarios, lo que probablemente hace que sea aún más difícil para un atacante deshacer la protección, es decir, parchear el depurado en la aplicación original. Sin embargo, esta opción introduce una sobrecarga adicional en tiempo de ejecución, ya que el inicio del depurador también requiere entonces cargar el segundo binario.

[0040] La opción alternativa, que se utiliza en los siguientes ejemplos adicionales, es incorporar todo el código del depurado y todo el código del depurador en un binario. En ese caso, una simple bifurcación será suficiente para iniciar el depurador. Si esto facilita o no los ataques a la protección proporcionada por la autodepuración, y en qué medida, es una cuestión en investigación abierta.

IMPLEMENTACIÓN

Inicialización y finalización

[0041] Se puede agregar una rutina de inicialización adicional a un binario protegido. Esta rutina se invoca tan pronto como se ha cargado el binario (porque asignó una prioridad alta), después de lo cual se ejecutan todas las demás rutinas enumeradas en la sección .init del binario.

[0042] Esta rutina de inicialización invoca fork(), creando así dos procesos llamados padre e hijo. Una vez finalizada la rutina de inicialización, el proceso padre continuará la ejecución, normalmente invocando la siguiente rutina de inicialización.

[0043] Existen dos opciones para asignar los roles de depurador y depurado: después de la bifurcación (fork), el proceso hijo se asocia al proceso padre, o viceversa. En el primer caso, el hijo se convierte en el depurador y el padre se convierte en el depurado; en el último caso, los roles obviamente se invierten.

[0044] Se prefiere la primera opción. El proceso padre (es decir, depurado) sigue siendo el proceso de aplicación principal y mantiene la misma ID de proceso (PID). Esto facilita la ejecución o el uso continuo de todas las aplicaciones externas y canales de comunicación entre procesos que dependen de la PID original, por ejemplo, porque se configuraron antes de cargarse y bifurcarse de una biblioteca protegida.

[0045] Sin embargo, este esquema tiene sus propios problemas. Como ya se ha mencionado, las bibliotecas compartidas se pueden cargar y descargar (usando dlopen() y dlclose ()) en cualquier momento durante la ejecución de un programa. Por lo tanto, existe el problema potencial de que una biblioteca compartida protegida se pueda descargar y volver a cargarse mientras que el depurador cargado originalmente y bifurcado aún no ha terminado su inicialización. Esto puede derivar en la existencia simultánea de dos procesos de depuración, ambos intentando (y uno fallando) asociarse al depurado. Para evitar esta situación, se bloquea la ejecución del subproceso que llamó a dlopen(). Por lo tanto, hasta ese momento, ese subproceso no puede invocar dlclose() usando el identificador que obtuvo con dlopen() y tampoco puede pasar el identificador a otro subproceso. Un bucle infinito en la rutina de inicialización del depurado evita que el subproceso de carga salga de la rutina de inicialización antes de que el depurador le permita continuar.

[0046] La rutina de inicialización también instala un finalizador en el depurado. Este finalizador no hace mucho. Al salir del programa (o cuando se descarga la biblioteca compartida), simplemente informa al minidepurador de este hecho al generar una señal SIGUSR1, lo que hace que el minidepurador se separe de todos los subprocesos del depurado y cierre el proceso de depuración.

Soporte de subprocesos múltiples

[0047] El hecho de asociar el depurador no es trivial, en particular en el caso de bibliotecas compartidas protegidas. Cuando se carga una biblioteca, la aplicación puede constar de varios subprocesos. Solo uno de ellos ejecutará la rutina de inicialización del depurado durante su llamada a dlopen. Esto es bueno, ya que solo se ejecutará una bifurcación, pero también tiene la desventaja de que solo un subproceso entrará en el bucle infinito mencionado en la sección anterior. Los otros subprocesos del proceso del depurado continuarán ejecutándose y pueden crear nuevos subprocesos en cualquier momento durante la ejecución de la rutina de inicialización del depurado o de la rutina de inicialización de depuración. Para garantizar una protección adecuada, el depurador debe asociar a cada subproceso del proceso del depurado como parte de su inicialización. Para garantizar que el depurador no pierda ningún subproceso creado en el depurado mientras tanto, se usa el directorio /proc/[pid]/task, que contiene una entrada para cada subproceso en un proceso. El proceso de depuración se asocia a todos los subprocesos iterando sobre las entradas de este directorio y manteniendo la iteración hasta que no se encuentren nuevas entradas. Tras asociarse al subproceso, lo que ocurre mediante una solicitud PTRACE_ATTACH, el subproceso también se detiene (y el sistema operativo notifica al depurador de este evento), lo que significa que ya no puede generar nuevos subprocesos a partir de ese momento. Entonces, para cualquier programa que genere un número finito de subprocesos, se garantiza que el procedimiento iterativo para asociarse a todos los subprocesos terminará. Una vez que se han adjuntado todos los subprocesos, el bucle infinito en el depurado finaliza y se permite que continúen sus subprocesos detenidos. Cuando se crean subprocesos adicionales posteriormente durante la ejecución del programa, el depurador se asocia automáticamente a ellos mediante el sistema operativo y recibe una señal de que se puede realizar toda la contabilidad necesaria.

Flujo de control

[0048] La transformación del flujo de control dentro y fuera de los fragmentos de código migrados consta de varias partes. Se describe la generación de excepciones para notificar al depurador, la transferencia de la ID que informa al depurador de qué fragmento se va a ejecutar y los prólogos y epílogos personalizados que se añaden a cada fragmento de código.

Generación de excepciones

[0049] La notificación real del depurador puede ocurrir a través de cualquier instrucción que provoque que se genere una excepción. En nuestra implementación, se usa un punto de interrupción de software (es decir, una instrucción BKPT en ARMv7) para simplificar. Por supuesto, se pueden utilizar otras excepciones menos notorias, como las provocadas por instrucciones ilegales o indefinidas. Cuando se puede acceder a estas instrucciones a través del flujo de control directo (derivación directa o ruta de paso explícita), por supuesto, se pueden detectar fácilmente de forma estática. Sin embargo, cuando se utilizan transferencias indirectas de flujo de control para saltar a datos en las secciones de código, y los bits de datos corresponden a una instrucción ilegal o indefinida, la detección estática puede resultar mucho más difícil. Del mismo modo, las instrucciones legales que lanzan excepciones solo cuando sus operandos son "inválidos" pueden usarse para ocultar el objetivo de las instrucciones. Dichas instrucciones incluyen división por cero, accesos a memoria inválidos (es decir, un fallo de segmentación) o la desreferenciación de un puntero inválido (dando como resultado un error de bus).

Transferencia de ID

[0050] Se denomina subproceso solicitante al subproceso en el depurado que genera una excepción, ya que fundamentalmente le pide al depurador que ejecute algún fragmento de código.

[0051] El depurador, después de que el sistema operativo le notifique sobre la solicitud, debe averiguar qué fragmento ejecutar. Para permitir esto, el depurado puede pasar una ID del fragmento de varias formas. Una opción es simplemente usar la dirección de la instrucción que induce la excepción como una ID. Otra opción es pasar la ID colocándola en un registro fijo justo antes de generar la excepción, o en una ubicación de memoria fija. En nuestra implementación, se usa esta última opción. Como varios subprocesos en el depurado pueden solicitar un fragmento diferente al mismo tiempo, la ubicación de la memoria no puede ser una ubicación global. En cambio, debe ser local del subproceso. Como cada subproceso tiene su propia pila, se opta por pasar la ID del fragmento a través de la parte superior de la pila del subproceso solicitante.

[0052] En función del tipo de instrucción utilizada para generar la excepción, también se pueden contemplar otros métodos. Por ejemplo, el operando divisor de una instrucción de división (por cero) también podría usarse para pasar la ID.

Prólogos y epílogos

[0053] El bucle de depuración en el minidepurador es responsable de obtener el estado del programa del depurado antes de que se ejecute un fragmento, y de transferirlo de nuevo después de su ejecución. Para ello, se utiliza la funcionalidad ptrace estándar.

[0054] Para cada fragmento de código migrado, el bucle de depuración también contiene un prólogo y un epílogo personalizados que se ejecutarán antes y después del fragmento de código resp. El prólogo carga los valores necesarios de la estructura en registros, el epílogo vuelve a escribir los valores necesarios en la estructura. El prólogo está personalizado en el sentido de que solo carga los registros que se utilizan realmente en el fragmento (los denominados registros en directo o live-in). El epílogo solo almacena los valores que no son en directo o live-out (es decir, que se consumirán en el depurado) y que se sobrescribieron en el fragmento de código.

Accesos a la memoria

[0055] Para cada operación de carga o almacenamiento en un fragmento de código migrado, se necesita un acceso a la memoria del depurado. Existen múltiples opciones para implementar dichos accesos.

[0056] La primera es simplemente usar la funcionalidad ptrace: el depurador puede realizar solicitudes PTRACE_PEEKDATA y PTRACE_POKEDATA para leer y escribir en el espacio de direcciones del depurado. En este caso, por cada palabra que se va a leer o escribir, se necesita una llamada al sistema ptrace, lo que resulta en una sobrecarga significativa. Algunas versiones recientes de Linux admiten accesos más amplios, pero aún no están disponibles en todas partes, como en Android.

[0057] La segunda opción es abrir el archivo /proc/[pid]/mem del depurado en el depurador, y luego simplemente leer o escribir en este archivo. Esto es más fácil de implementar y se pueden leer o escribir datos más amplios con una sola llamada al sistema, por lo que a menudo este método es más rápido. Sin embargo, la escritura en /proc/[pid]/mem de otro proceso no es compatible con todas las versiones de los kernel de Linux/Android, por lo que en nuestro prototipo las solicitudes de escritura aún se implementan con la primera opción.

[0058] Una tercera opción se basa en la segunda: si el reescritor binario puede determinar a qué páginas de memoria se accederá en un fragmento de código migrado, el ciclo de depuración puede copiar realmente esas páginas en el espacio de direcciones del depurador utilizando la opción 2. A continuación, el fragmento en el depurador simplemente ejecuta operaciones regulares de carga y almacenamiento para acceder a las páginas copiadas, y una vez que se ha ejecutado el fragmento, las páginas actualizadas se copian de nuevo en el depurado. Esta opción puede ser más rápida si, por ejemplo, el fragmento de código contiene un bucle para acceder a un búfer en la pila. Los experimentos que se llevaron a cabo para comparar la tercera opción con las dos opciones anteriores revelaron que esta técnica podría valer la pena para tan solo 8 accesos a la memoria. Sin embargo, no se implementó un soporte fiable para ello en nuestro prototipo: un análisis conservador del tiempo de enlace para determinar a qué páginas accederá un fragmento de código sigue siendo un trabajo futuro en este momento.

[0059] Una cuarta opción posible es adaptar el depurado, por ejemplo, proporcionando una biblioteca de gestión de montón de memoria personalizada (malloc, libre, ...) de modo que toda la memoria asignada (o al menos el montón) se asigne como memoria compartida entre los procesos del depurado y del depurador. A continuación, los fragmentos de código en el depurador pueden acceder a los datos directamente. Evidentemente, los fragmentos aún deben reescribirse para incluir una traducción de direcciones entre los dos espacios de direcciones, pero probablemente la sobrecarga de esta opción puede ser mucho menor que la sobrecarga de las otras opciones. El hecho de implementar y evaluar esta opción sigue siendo un trabajo futuro en este momento.

[0060] En cuanto a la seguridad, las diferentes opciones probablemente también tendrán un impacto diferente, en el sentido de que afectarán a la dificultad para que un atacante realice ingeniería inversa de la semántica original del programa y deconstruya la versión de autodepuración en un equivalente del programa original.

Combinación de la autodepuración con otras protecciones

[0061] Para proporcionar una sólida protección de software frente a los ataques MATE, se pueden emplear técnicas de protección adicionales. Por ejemplo, además de la autodepuración, se puede emplear la ofuscación para evitar el análisis estático, junto con técnicas de antimanipulación para prevenir todo tipo de ataques.

[0062] Por ejemplo, el reescritor binario que implementa el enfoque de autodepuración también puede aplicar una serie de otras protecciones, como una o más de las siguientes:

Ofuscaciones del flujo de control: las conocidas ofuscaciones de predicados opacos, aplanamiento de flujo de control, y funciones de ramificación.

Aleatorización del diseño del código: durante el diseño del código, el código de todas las funciones se mezcla y el diseño se aleatoriza.

Movilidad del código: técnica en la que los fragmentos de código se eliminan del binario estático y solo se descargan, como el denominado código móvil, en la aplicación en tiempo de ejecución.

Guardias de código: implementaciones en línea y fuera de línea de técnicas en las que se calculan hashes sobre el código en el espacio de direcciones del proceso para verificar que el código no ha sido alterado. Integridad del flujo de control: una técnica ligera en la que se comprueban las direcciones de retorno para evitar que se invoquen funciones internas desde un código externo.

Virtualización del conjunto de instrucciones: técnica con la que el código nativo se traduce a código de bytes, que es interpretado por una máquina virtual incorporada en lugar de ejecutarse de forma nativa.

[0063] La combinación de la técnica de autodepuración con todas esas protecciones no supone ningún problema en la práctica. En el reescritor en tiempo de enlace, no es difícil determinar un buen orden para realizar todas las transformaciones para todas las protecciones, y evitar que se apliquen múltiples técnicas en los mismos fragmentos de código cuando esas técnicas no se componen realmente. Por ejemplo, el código móvil se reubica en ubicaciones aleatorizadas. El manejo correcto de todas las protecciones requiere cierta contabilidad, pero nada complejo.

[0064] En cuanto al comportamiento en tiempo de ejecución, las técnicas también componen. Varias técnicas requieren inicializadores y finalizadores, pero en el proceso de depuración no se quiere ejecutar los inicializadores de las otras protecciones, ya que ese proceso de depuración solo debería ser un depurador, y no otro cliente para la movilidad de código o cualquier otra técnica. Para evitar que se ejecuten los otros inicializadores, los inicializadores del autodepurador reciben la máxima prioridad. Estos se ejecutan primero cuando se carga un binario o una biblioteca, y la rutina de inicialización del depurador implementa, de hecho, tanto el inicializador real como el bucle de depuración. Por lo tanto, la rutina nunca termina (es decir, siempre que no se invoque el finalizador) y, por lo tanto, el control nunca se transfiere a los otros inicializadores que podrían estar presentes en el binario.

EVALUACIÓN

Plataforma de evaluación

[0065] Una implementación del autodepurador se dirige a las plataformas ARMv7. Concretamente, esta implementación se dirigió y evaluó extensamente la implementación en Linux 3.15 y Android 4.3+4.4 (sin rootear). Además, se ha confirmado que las técnicas aún funcionan en las últimas versiones de Linux (4.7) y Android (7.0) y, de hecho, ese es el caso.

[0066] El hardware de prueba constaba de varias placas de desarrollo. Para Linux, se utilizó una placa Panda con un procesador Texas Instruments OMAP4 de un solo núcleo, una placa Arndale con un procesador Samsung Exynos de doble núcleo y una placa Boundary Devices Nitrogen6X/SABRE Lite con un procesador Freescale i.MX6q de un solo núcleo. Esta última placa también se utilizó para las versiones de Android.

[0067] En la cadena de herramientas se utilizaron GCC 4.8, LLVM 3.4 y GNU binutils 2.23. El código se compiló con las siguientes marcas: - Os -march=armv7-a -marm -mfloat-abi=softfp - mfpu=neon -msoft-float.

Casos de uso

[0068] Se ha demostrado que el esquema de autodepuración funciona en múltiples casos de uso. Por ejemplo, en un escenario de gestión de derechos digitales, se encontraron las siguientes consideraciones prácticas.

[0069] Este caso de uso consistió en dos complementos, escritos en C y C++, para el marco de medios de Android y el marco de DRM de Android. Estas bibliotecas son necesarias para obtener acceso a películas cifradas y para descifrarlas. Una aplicación de video programada en Java se utiliza como GUI para acceder a los videos. Esta aplicación se comunica con el servidor de medios y los marcos DRM de Android, informando los marcos del proveedor del que se necesitan complementos. A petición, estos marcos cargan entonces los complementos. Concretamente, estos servidores son los procesos mediaserver y drmserver que se ejecutan en Android.

[0070] Durante los experimentos y el desarrollo, se observaron varias características que hacen de este caso de uso una prueba de esfuerzo perfecta para esta técnica. En primer lugar, el servidor de medios tiene varios subprocesos y crea y elimina nuevos subprocesos todo el tiempo. En segundo lugar, las bibliotecas de complementos se cargan y descargan con frecuencia. A veces, la descarga se inicia incluso antes de que finalice la inicialización de la biblioteca. En tercer lugar, tan pronto como el proceso falla, se inicia una nueva instancia. A veces, esto permite que el reproductor de video Java continúe funcionando sin interrupciones, a veces no. Esto hace que la depuración de la implementación de nuestra técnica sea aún más compleja de lo que ya es para aplicaciones simples. En cuarto lugar, el mediaserver y el drmserver están involucrados en comunicaciones frecuentes entre procesos. Sin embargo, la implementación exitosa se logró sobre la base de los principios descritos anteriormente.

[0071] Las técnicas se pueden aplicar en muchos otros escenarios de casos de uso. Por ejemplo, en banca móvil, en cualquier otro escenario en el que la seguridad sea deseable.

[0072] La Figura 4 ilustra un diagrama de bloques de una implementación de un dispositivo informático 400 dentro del cual se puede ejecutar un conjunto de instrucciones, para hacer que el dispositivo informático realice una o más de las metodologías descritas en este documento. En implementaciones alternativas, el dispositivo informático puede estar conectado (por ejemplo, en red) a otras máquinas en una red de área local (LAN), una intranet, una extranet o Internet. El dispositivo informático puede funcionar en la capacidad de un servidor o una máquina cliente en un entorno de red cliente-servidor, o como una máquina par en un entorno de red de par a par (o distribuida). El dispositivo informático puede ser un ordenador personal (PC), una tableta, un decodificador (STB), un asistente digital personal (PDA), un teléfono móvil, un dispositivo web, un servidor, un enrutador de red, un conmutador o puente, o cualquier máquina capaz de ejecutar un conjunto de instrucciones (secuenciales o de otro tipo) que especifiquen las acciones que debe realizar esa máquina. Además, a pesar de que solo se ilustra un único dispositivo informático, el término "dispositivo informático" también se considerará para incluir cualquier conjunto de máquinas (por ejemplo, ordenadores) que ejecutan individual o conjuntamente un conjunto (o varios conjuntos) de instrucciones para realizar una o más de las metodologías descritas en este documento.

[0073] El ejemplo de dispositivo informático 400 incluye un dispositivo de procesamiento 402, una memoria principal 404 (por ejemplo, memoria de solo lectura (ROM), memoria flash, memoria dinámica de acceso aleatorio (DRa M) como DRAM síncrona (SDRAM) o DrAm Rambus (RDRAM), etc.), una memoria estática 406 (por ejemplo, memoria flash, memoria estática de acceso aleatorio (SRAM), etc.) y una memoria secundaria (por ejemplo, un dispositivo de almacenamiento de datos 418), que se comunican entre sí a través de un bus 430.

[0074] El dispositivo de procesamiento 402 representa uno o más procesadores de uso general, como un microprocesador, una unidad central de procesamiento, o similares. Más particularmente, el dispositivo de procesamiento 402 puede ser un microprocesador de computación de conjunto de instrucciones complejas (CISC), un microprocesador de computación de conjunto de instrucciones reducidas (RISC), un microprocesador de palabras de instrucciones muy largas (VLIW), un procesador que implementa otros conjuntos de instrucciones, o procesadores que implementan una combinación de conjuntos de instrucciones. El dispositivo de procesamiento 402 también puede ser uno o más dispositivos de procesamiento de uso especial tales como un circuito integrado específico de aplicación (ASIC), una matriz de puertas programables en campo (FPGA), un procesador de señal digital (DSP), un procesador de red o similares. El dispositivo de procesamiento 402 está configurado para ejecutar la lógica de procesamiento (instrucciones 422) para realizar las operaciones y las etapas descritas en el presente documento.

[0075] El dispositivo informático 400 puede incluir además un dispositivo de interfaz de red 408. El dispositivo informático 400 también puede incluir una unidad de visualización de vídeo 410 (por ejemplo, una pantalla de cristal líquido (LCD) o un tubo de rayos catódicos (CRT)), un dispositivo de entrada alfanumérico 412 (por ejemplo, un teclado o pantalla táctil), un dispositivo de control de cursor 414 (por ejemplo, un ratón o pantalla táctil) y un dispositivo de audio 416 (por ejemplo, un altavoz).

[0076] El dispositivo de almacenamiento de datos 418 puede incluir uno o más medios de almacenamiento legibles por máquina (o, más específicamente, uno o más medios de almacenamiento no transitorios legibles por ordenador) 428 en los que se almacena uno o más conjuntos de instrucciones 422 que incorporan una o más de las metodologías o funciones descritas en este documento. Las instrucciones 422 también pueden residir, completa o al menos parcialmente, dentro de la memoria principal 404 y/o dentro del dispositivo de procesamiento 402 durante su ejecución por el sistema informático 400, constituyendo también la memoria principal 404 y el dispositivo de procesamiento 402 medios de almacenamiento legibles por ordenador.

[0077] Los diversos métodos anteriormente descritos pueden implementarse mediante un programa informático. El programa informático puede incluir un código informático configurado para instruir a un ordenador para que realice las funciones de uno o más de los diversos métodos anteriormente descritos. El programa informático y/o el código para realizar tales métodos pueden proporcionarse a un aparato, tal como un ordenador, en uno o más medios legibles por ordenador o, más generalmente, un producto de programa informático. Los medios legibles por ordenador pueden ser transitorios o no transitorios. El uno o más medios legibles por ordenador podrían ser, por ejemplo, un sistema electrónico, magnético, óptico, electromagnético, infrarrojo o semiconductor, o un medio de propagación para la transmisión de datos, por ejemplo, para descargar el código a través de Internet. Alternativamente, el uno o más medios legibles por ordenador podrían adoptar la forma de uno o más medios físicos legibles por ordenador, como memoria de semiconductor o de estado sólido, cinta magnética, un disquete de ordenador extraíble, una memoria de acceso aleatorio (RAM), una memoria de solo lectura (ROM), un disco magnético rígido y un disco óptico, como un CD-ROM, CD-R/W o DVD.

[0078] En una implementación, los módulos, componentes y otras características descritas en este documento (por ejemplo, la unidad de control 410 en relación con la Figura 4) pueden implementarse como componentes discretos o integrarse en la funcionalidad de componentes de hardware como ASIC, FPGA, DSP o dispositivos similares como parte de un servidor de individualización.

[0079] Un "componente de hardware" es un componente físico tangible (p. ej., no transitorio) (por ejemplo, un conjunto de uno o más procesadores) capaz de realizar ciertas operaciones y puede configurarse o disponerse de cierta manera física. Un componente de hardware puede incluir lógica o circuitos dedicados que están configurados permanentemente para realizar ciertas operaciones. Un componente de hardware puede ser o incluir un procesador de uso especial, como una matriz de puertas programables en campo (FPGA) o un ASIC. Un componente de hardware también puede incluir circuitos o lógica programable que esté temporalmente configurada por software para realizar ciertas operaciones.

[0080] En consecuencia, debe entenderse que la frase "componente de hardware" abarca una entidad tangible que puede estar construida físicamente, configurada permanentemente (por ejemplo, cableada) o configurada temporalmente (por ejemplo, programada) para operar de cierta manera o para realizar ciertas operaciones descritas en el presente documento.

[0081] Además, los módulos y componentes se pueden implementar como firmware o circuitos funcionales dentro de los dispositivos de hardware. Además, los módulos y componentes se pueden implementar en cualquier combinación de dispositivos de hardware y componentes de software, o solo en software (por ejemplo, código almacenado o incorporado de otro modo en un medio legible por máquina o en un medio de transmisión).

[0082] A menos que se indique específicamente lo contrario, como se desprende de la siguiente descripción, se aprecia que, a lo largo de la descripción, las discusiones que utilizan términos como "recibir", "determinar", "comparar", "habilitar", "mantener", "identificar", "reemplazar", etc., se refieren a las acciones y procesos de un sistema informático, o dispositivo informático electrónico similar, que manipula y transforma datos representados como cantidades físicas (electrónicas) dentro de los registros y memorias del sistema informático en otros datos representados de manera similar como cantidades físicas dentro de las memorias o registros del sistema informático u otros dispositivos de almacenamiento, transmisión o visualización de información.

[0083] Debe entenderse que la descripción anterior pretende ser ilustrativa y no restrictiva. Muchas otras implementaciones resultarán evidentes para los expertos en la técnica al leer y comprender la descripción anterior. Aunque la presente divulgación se ha descrito con referencia a ejemplos específicos de implementaciones, se reconocerá que la divulgación no se limita a las implementaciones descritas, sino que se puede poner en práctica con modificaciones y alteraciones dentro del alcance de las reivindicaciones adjuntas.

Claims (10)

REIVINDICACIONES

1. Método para asegurar software, que comprende:

iniciar un proceso de software;

asociar un proceso de depuración al proceso de software;

ejecutar el proceso de software de manera que el proceso de depuración se invoque al menos una vez; realizar una o más funciones del proceso de software dentro del proceso de depuración;

donde una salida producida por la una o más funciones del proceso de software dentro del depurador sirve como entrada para la parte restante del proceso de software.

2. Método según la reivindicación 1, donde la salida comprende una salida de datos para su uso por el proceso de software.

3. Método según la reivindicación 1 o la reivindicación 2, donde la salida de una función determinada puede indicar múltiples puntos de retorno dentro del proceso de software para su ejecución continua.

4. Método según cualquiera de las reivindicaciones anteriores, donde el proceso de depuración proporciona capacidades de soporte de memoria para permitir que la una o más funciones recuperen datos de la memoria dentro del espacio de direcciones del proceso de software.

5. Método según cualquiera de las reivindicaciones anteriores, donde el proceso de depuración se invoca cuando se alcanza un punto de interrupción dentro del proceso de software.

6. Método según cualquiera de las reivindicaciones anteriores, que comprende, además, separar el proceso de depuración del proceso de software cuando se completa el proceso de software.

7. Método según cualquiera de las reivindicaciones anteriores, donde el proceso de software implementa un ejecutable, tal como una aplicación.

8. Método según cualquiera de las reivindicaciones 1 a 6, donde el proceso de software implementa una biblioteca.

9. Producto de programa ejecutable por ordenador que comprende un código ejecutable por ordenador para llevar a cabo el método según cualquiera de las reivindicaciones anteriores.

10. Dispositivo configurado para llevar a cabo el método según cualquiera de las reivindicaciones 1 a 8.