Me pregunto donde se usa ingeniería inversa. Estoy interesado en aprenderlo. Pero no sé si puedo/debo ponerlo en mi CV.¿Dónde se usa ingeniería inversa?
No quiero que mi nuevo jefe piense que soy un malvado pirata informático o algo así. :)
La ingeniería inversa se usa comúnmente para descifrando los formatos de archivo para mejorar la interoperabilidad. Por ejemplo, muchas aplicaciones comerciales populares de Windows no se ejecutan en Linux, lo que requiere la ingeniería inversa de los archivos producidos por esas aplicaciones, para que puedan ser utilizadas en Linux. Un buen ejemplo de esto serían los diversos formatos soportados por Gimp, OpenOffice, Inkscape, etc.
Otro uso común de la ingeniería inversa es descifrando los protocolos. Buenos ejemplos incluyen el soporte Samba, DAAP en muchas aplicaciones que no son iTunes, clientes de mensajería instantánea multiplataforma como Pidgin, etc. Para la ingeniería inversa de protocolo, las herramientas comunes de la operación incluyen Wireshark y libpcap.
Sin duda, la ingeniería inversa se asocia a menudo con el agrietamiento de software, que es principalmente la comprensión del programa de desmontaje. No puedo decir que alguna vez necesitó para desmontar un programa que no sea por pura curiosidad o para hacer que hiciera algo que no era. Un lado positivo para invertir los programas de ingeniería es que, para darle sentido, necesitará aprender programación de ensamblaje. Sin embargo, hay formas legales de perfeccionar sus habilidades de desensamblaje, específicamente usando Crackmes. Un punto importante que debe hacerse es que cuando desarrolla medidas de seguridad en sus aplicaciones, o si está en ese negocio, necesita para saber cómo operan los ingenieros de inversión para tratar de mantenerse un paso adelante.
En mi humilde opinión, la ingeniería inversa es una habilidad muy poderosa y útil que tener. Sin mencionar que, por lo general, es divertido y adictivo. Al igual que hmemcpy mencionado, no estoy seguro de utilizar el término "ingeniería inversa" en mi CV, solo las habilidades/conocimientos asociados.
Uno de los campos, en mi opinión, donde la ingeniería inversa podría ser útil es la industria antivirus, por ejemplo. Sin embargo, no colocaría "ingeniería inversa" en mi currículum, sino que escribiría experiencia en el lenguaje ensamblador, utilizando desensambladores/depuradores misceláneos (como IDA, SoftIce o OllyDbg) y otras habilidades relevantes.
La ingeniería inversa generalmente es algo que debe hacer, porque debe hacerlo, no porque lo desee. Por ejemplo, hay problemas legales con simplemente invertir un producto de ingeniería. Pero hay casos necesarios: donde (por ejemplo) el proveedor se ha ido y ya no existe o no se puede contactar. Un buen ejemplo sería el editor de WMD en el que escribió su pregunta. El equipo SO/comunidad had to reverse engineer this from obfuscated source para aplicar algunas correcciones de errores.
La ingeniería inversa se necesita cada vez que se pierde la documentación o nunca existió. Tener la fuente ayuda, pero todavía tiene que realizar una ingeniería inversa de la lógica original, el control de flujo y los errores.
Trabajar con hardware extraño a menudo lo obliga a realizar una ingeniería inversa. Por ejemplo, una vez estaba trabajando con una antigua tarjeta de adquisición de señales que se comportaba de manera extraña; poner en hermosa onda sinusoidal produjo datos terriblemente lisiados. Resultó que cada otro byte era el complemento de dos y el complemento de cada uno, o al menos, cuando se interpretaba de esa manera, los datos se volvían bastante hermosos. Por supuesto, esto no fue documentado en ninguna parte, y la tarjeta funcionó perfectamente cuando se usó con su propio software propietario.
He trabajado en proyectos de ingeniería inversa, y ciertamente no tuvieron nada que ver con la piratería. Teníamos el código fuente para todos esos proyectos (legítimamente), pero para uno de los proyectos nadie sabía realmente qué hacía el código detrás de escena, y cómo interactuaba con otros sistemas. Esa información se había perdido durante mucho tiempo. En otro proyecto, teníamos el código fuente y cierta documentación, pero la documentación no estaba actualizada, por lo que tuvimos que realizar una ingeniería inversa de la fuente para actualizar la documentación.
No me importa tener tales proyectos en mi CV. De hecho, creo que aprendí mucho durante el proceso.
Es muy común (en mi experiencia) encontrar un código anterior que tiene defectos, se ha quedado obsoleto debido a requisitos cambiantes, o ambos. A menudo ocurre que no hay documentación adecuada, y los desarrolladores originales ya no están disponibles. La ingeniería inversa que codifica para entender cómo funciona (y algunas veces para tomar una decisión de reparar o reemplazar) es una habilidad importante.
Si tiene la fuente, a menudo es razonable hacer una pequeña, cuidadosamente planificada y estricta cantidad de limpieza. (¡Estoy diciendo en voz alta que esto no puede convertirse en un sumidero para un valioso tiempo de desarrollo!)
También es muy útil poder ejercitar el código en un banco de pruebas, ya sea para verificar que hace qué se esperaba o para identificar, documentar, aislar y reparar defectos.
Hacerlo de manera segura requiere un trabajo cuidadoso. Recomiendo encarecidamente el libro de Michael Feathers Working with Legacy Code por su práctica guía para obtener dicho código bajo prueba.
RCE es una gran habilidad para chicos de seguridad (investigación, explotación, IDS, IPS, AV, etc.) pero también demuestra que tienes una comprensión profunda y de bajo nivel del tema.
También es más fácil abrirse camino cuando se trabaja con bibliotecas de terceros.
Si no está trabajando en la industria de la seguridad, si no es bueno en ASM no se moleste en aprenderlo, generalmente es difícil de aprender.
Libros
Hacking the art of exploitation habla sobre el tema desde el punto de vista de la seguridad.
También es posible que desee leer libros sobre Ollydbg e IDA Pro
Sí, invertir la engeneering se puede utilizar para vulnerabilidades en el código de búsqueda (de bajo nivel o errores de arquitectura y características indocumentados ''). Este proyecto trata sobre este problema (pero con idioma ruso): http://demono.ru –