Tengo una aplicación de escritorio compilada en el marco .Net.
Si ofusco el código, incluso si alguien hace una ingeniería inversa del código e intenta llamar a mi API utilizando la fuente modificada, ¿puedo saber si las llamadas a la API no son del código fuente original?
Si compilo mi aplicación utilizando la firma de código, ¿ayuda?
Cada vez que surge esta pregunta, señalo a Chat Wars de David Auerbach: Microsoft vs. AOL . La historia muestra el alcance que algunas personas muy inteligentes han hecho para tratar de hacer lo que intentas hacer, y los espectaculares fracasos uno tras otro.
Es posible que el artículo se haya escrito para una pila de tiempo y tecnología diferente, pero los datos básicos no han cambiado y nunca cambiarán, independientemente del tipo de tecnología que esté utilizando para desarrollar su aplicación. Dado un adversario suficientemente determinado, es fundamentalmente imposible verificar que una solicitud de red provenga únicamente de su cliente autorizado.
El hecho de que pueda o no identificar llamadas de una forma modificada o de ingeniería inversa de su código depende de su capacidad para reconocer si el código original pudo haber realizado las llamadas.
Por ejemplo, si su código solo puede emitir un valor para un parámetro de un número establecido de valores posibles, es probable que cualquier llamada con un valor desconocido sea realizada por algún otro código que no sea el suyo.
De lo contrario, no hay forma posible de saber qué ha llamado a su API, especialmente si la llamada es válida. Por ejemplo, si está alojando un servicio web http público, puedo emitir comandos curl para enviarle solicitudes GET, y no sería posible decir que usé curl en lugar de su binario (e incluso si su binario hace algo inteligente como agregar encabezados, siempre puedo olerlos e imitarlos más tarde).
Para una biblioteca, no hay una manera eficiente de evitar que otro binario se vincule contra ella y comience a usar su API.
La ofuscación solo ralentizará una ingeniería inversa. Si invertir su binario es lo suficientemente valioso, alguien está obligado a superar su ofuscación tarde o temprano: el código no lo es todo, también puede descargar la memoria durante la ejecución y ver qué hay allí, por ejemplo. urls, valores de variables, etc. Sin embargo, puede desviar a los hackers más diletantes que podrían querer hurgarlo. Además, tenga en cuenta que no es un medio para proteger información crítica como las claves de API o credenciales incrustadas, como lo demostró recientemente y espectacularmente la brecha Retina-X , lo que significa que un inversor puede adquirir e imitar cualquier mecanismo que pueda implementar para autenticar su binario original contra su API.
La firma de código no es una forma de proteger su código contra la ingeniería inversa. Es una forma de garantizar criptográficamente que la integridad de un binario no se haya comprometido antes de adquirirlo, es decir, que el binario sea exactamente el mismo que compiló el autor original. Sin embargo, significa que nadie debería poder distribuir un binario alterado y hacerlo pasar por una versión legítima que usted mismo habría distribuido.
Lea otras preguntas en las etiquetas authentication integrity .net web-service