¿Se pueden pasar por alto las contraseñas de software mediante ingeniería inversa?

En resumen, sí, puedes modificar el ejecutable, usar un depurador, etc. para alterar la lógica del código que se está ejecutando.

Pero, eso puede no ser suficiente.

Para usar su ejemplo de "contraseñas .zip", los archivos protegidos con contraseña usan la contraseña para obtener una clave de cifrado. A menos que proporcione una contraseña correcta, la clave generada será incorrecta, e incluso si la modifica para usar una clave incorrecta, no descifra correctamente el archivo ZIP.

Otro escenario podría involucrar un ejecutable setuid que se ejecuta con privilegios más altos. Puede ejecutarlo bajo un depurador, o copiarlo a su cuenta de usuario y hacer cambios, pero todo lo que logrará es ejecutarlo con los permisos de su usuario, lo que anulará las posibilidades de explotación.

Bueno, tu percepción de las contraseñas .zip no es precisa. El enfoque, también utilizado por muchos otros programas es siempre ejecutar un algoritmo de descifrado y obtener un resultado, incluso antes de que el programa llegue a la decisión de "buena o mala contraseña". El truco es que el descifrado produce basura en cualquier contraseña excepto una buena que "mágicamente" (o más bien - matemáticamente) calcula los datos adecuados. Entonces, el programa no sabe cuál es la contraseña correcta.

El momento "bueno o malo" en el que desea piratear solo verifica si el resultado es basura. No es mucho beneficio anular eso.

Sí y No .

Ya que nadie ha creado un ejemplo de la vida real (no relacionado con la computadora), lo intentaré aquí:

Imagínate tratando de abordar un vuelo. Necesitas una tarjeta de embarque, o los tíos de seguridad no te dejarán pasar. Si tiene acceso al sistema y puede modificarlo (digamos que es el CEO), ¿puede pasar por alto la seguridad? ¡Sí! Usted puede:

• Eliminar los tipos de seguridad (eliminar todo el componente de autenticación)
• Pídales a los muchachos que dejen entrar a todos (quite el cheque "si el pasajero tiene una tarjeta de embarque válida")
• Pídales a los muchachos que den acceso si alguien presenta una tarjeta de embarque especial (agregue una nueva regla de validación para permitir credenciales falsas)

Ahora, otro escenario: un montón de cajas fuertes se almacenan en un banco. Para abrir una caja fuerte, necesita una llave física para activar la cerradura.

¿Puedes sacar el truco anterior? Sí puedes, pero no ayudará. No es como si el tipo de seguridad que está allí tiene acceso a todas las cajas fuertes, no tiene la llave de ninguna de las cajas fuertes. Puedes vencerlo, pero él no solo posee lo que es necesario (la llave física) para abrir las cerraduras.

Puedes intentar seleccionar el bloqueo (fuerza bruta), pero consumirías mucho tiempo (la matemática de las claves de cifrado modernas dice que necesitas miles de millones de años para desbloquearlo, incluso si tienes todas las computadoras del mundo). haciéndolo por ti). Así que ahí está: en este diseño (cifrado de datos), la única forma de obtener los datos almacenados es mediante una clave, lo que hace que sea imposible omitirla.

Claro, el software puede hacer lo que usted programe para hacer.

Como ejemplo trivial, si me proporcionaron un programa de Python que comprobó una contraseña:

password = raw_input('Enter your password: ')
if password != 'oh-so-secret':
    sys.exit(1)

do_secure_thing()

Simplemente podría cambiarlo para que no me importe cuál es la contraseña:

password = raw_input('Enter your password: ')

do_secure_thing()

(En este caso, también podría ver qué es la contraseña de texto simple codificada e ingresarla).

Con las aplicaciones binarias, debes descompilarlas antes de poder modificar la fuente, pero hay muchos descompiladores para lenguajes comunes.

Por eso existe firma de código .

Ahora, si este no es su propio sistema, sus opciones pueden ser un poco más limitadas. En la mayoría de los sistemas similares a Unix, los ejecutables generalmente se almacenan con permisos de solo lectura y ejecución para usuarios no root; por lo tanto, si no es root, no puede modificar el ejecutable de destino. Hay otros métodos menos directos que puedes probar, pero si fallas, estás pensando en moverte a un vector diferente.

Por ejemplo, un keylogger registrará las contraseñas que ingresa el usuario, lo que le permitirá reutilizarlos por su cuenta más adelante.

Otro método de ataque que no requiere modificar la fuente de un programa es modificar la ruta de carga de la biblioteca dinámica de manera que el programa utilice una llamada de biblioteca que usted haya escrito, en lugar de la que espera. Si usan una biblioteca externa, cargada dinámicamente para la administración de contraseñas, y esa biblioteca tiene una función verify_password() que devuelve un booleano, puede escribir su propio verify_password() que siempre devuelve true, y cargarlo en su lugar.

La distinción real que cambia la respuesta de "sí" a "no" es si la contraseña no es realmente una contraseña, sino una clave de cifrado. Si los datos están encriptados, entonces no importa lo que hagan los programas externos, los datos que aún están encriptados hasta que el algoritmo de descifrado se alimenta con la clave adecuada.

Suponga que tiene una aplicación que almacena datos en un archivo de texto (o una pequeña base de datos), pero para acceder al archivo desde la aplicación debe ingresar una contraseña o usar un proceso especial. Simplemente puede abrir el archivo de texto (o db) desde el directorio de archivos usando el sistema operativo (no se requiere ingeniería inversa). Esto solía ocurrir mucho en programas más antiguos (juegos, especialmente).

Es por eso que las aplicaciones que esperan estar seguras toman medidas para proteger los datos del propio sistema operativo. Como cifrar los datos u ofuscarlos para que sea difícil de usar.

Depende de cómo el software XYZ utiliza la contraseña para producir la acción deseada y con qué tipo de datos trabaja.

Si observamos el algoritmo abstracto del programa XYZ sería:

1. Pida al usuario que ingrese la contraseña.
2. Haga algo con la contraseña ingresada por el usuario.
3. Producir resultados deseables (o realizar acciones deseables).

Por lo tanto, su pregunta puede reducirse al paso # 3 :

¿Es posible producir un resultado deseable (o realizar una acción) sin utilizar el programa XYZ?

Hay muchas variantes posibles aquí, pero el punto principal es que el software XYZ realiza pasos particulares para producir el resultado.

Si se puede crear un programa ABC que puede producir el mismo resultado en un tiempo razonable sin necesidad de una contraseña, se puede omitir XYZ .

Eso indicaría que toda la "protección" se implementa en el programa XYZ .

Si la creación de dicho programa ABC no es posible, la protección se basa en un algoritmo que requiere la contraseña independientemente de qué programa esté intentando usarlo .

Ejemplo 1 : una cuenta de sistema operativo sin privilegios no puede establecer una contraseña para otro usuario, ya que el sistema operativo la impone. Así que el sistema operativo en este caso es XYZ . Pero se puede iniciar el equipo desde una unidad de inicio y sobrescribir el archivo que contiene las contraseñas, ya que el sistema operativo original no funciona en este momento, por lo tanto, no puede imponer la protección. Por lo tanto, pudimos producir un resultado deseable sin utilizar el programa XYZ .

Ejemplo 2 : en el segundo ejemplo, la unidad del sistema del sistema operativo está correctamente encriptada con un fuerte algoritmo de cifrado. Si arrancamos la computadora con una unidad de arranque para intentar evitar el sistema operativo original, descubriremos que no podemos lograr nuestro objetivo, ya que no podemos acceder al archivo que contiene las contraseñas. Reside en una partición que debe descifrarse primero, pero no sabemos la contraseña. Un intento de forzar con fuerza el proceso de descifrado no traería el resultado deseable en el corto plazo, por lo que en este caso no fue posible omitir el programa XYZ ni ningún otro programa con funcionalidad similar, ya que el los datos subyacentes requieren la contraseña .