¿Qué tan difícil es aplicar ingeniería inversa a los archivos .pyd?

Question

Después de leer How do I protect Python code?, decidí probar un módulo de extensión realmente simple en Windows. Recopilé mi propio módulo de extensión en Linux antes, pero esta es la primera vez que lo compilé en Windows. Esperaba obtener un archivo .dll, pero en su lugar, obtuve un archivo .pyd. Docs dice que son similares, pero debe tener una función init[insert-module-name]().

Es seguro asumir que es tan difícil revertirlos como archivos dll. Si no, ¿cuál es su dureza para realizar ingeniería inversa en una escala de archivo .pyc a archivos .dll?

Answer 1

Son, como ya has descubierto, equivalentes a los archivos DLL con una cierta estructura. En principio, son igualmente difíciles de aplicar ingeniería inversa, son códigos de máquina, necesitan muy pocos metadatos, y el código puede haberse optimizado más allá del reconocimiento.

Sin embargo, la estructura requerida, y saber que muchas funciones manejarán PyObject * sy otros tipos de CPython bien definidos, puede tener algún efecto. Realmente no ayudará con el mapeo del código ensamblador a C (en todo caso, se vuelve más difícil debido a las macros específicas de CPython). El código que en su mayoría interactúa con los tipos de Python se verá bastante diferente del código que manipula las estructuras C (y comparativamente hinchado). Esto puede hacer que sea aún más difícil de comprender, o puede revelar un código que no hace nada interesante y permite que un ingeniero de ingeniería inversa lo saltee y obtenga sus secretos comerciales antes.

Ninguno de estos problemas se aplica a piezas de código que son código C puro (es decir, no interactúan con Python). Y probablemente tengas muchos de esos. Por lo tanto, no debería hacer una diferencia significativa al final.

Answer 2

Básicamente son código nativo. Pero debido a que cada función tiene listas de argumentos divertidas, puede ser más difícil ver qué hace cada función. Yo diría que son tan duros como dll, si no más difíciles.