Como ocultar el codigo fuente despues de compilar

[mamcx]

Ademas, igualmente un hacker/cracker le puede importar poco eso. Quien sabe assembler no necesita el codigo fuente.

No me parece que exista una razón de peso para encriptar codigo ni ofuscarlo.

Pa' rematar, la mayoría de los que intentan esconder tan brutalmente su código dificilmente hacen algo taaaaaan innovador que pudiera justificarlo, y los que saben de seguridad no ofuscan su codigo: Protegen los datos (ej: NO quemar claves en el exe!), usan las librerias de seguridad que provee el OS y/o librerias de terceros (pa' proteger datos) como http://nacl.cr.yp.to/, y la unica cosas que veo que hagan rara es hacer el codigo hostil para un cracker (reubicando direcciones de memoria y esas cosas).

Total, para el programador promedio? Es una total perdida de tiempo. Lo mismo digo de usar seriales, dongles y similares, aun si el programa es comercial y vale $$$$$$$$. En mi experiencia, lo mejor es:

0- Hacer un producto bueno. O por lo menos no malo
1- Tratar bien al cliente
2- No joderle la vida al cliente
2a - No hacer un proceso de instalacion, reinstalacion, que aumentara N veces los costos de soporte (seriales obtusos, "activaciones", dongles, etc)
2b- Tener un plan de que cobrar y como que sea lo mas simple y directo posible. Preferiblemente: Pagar no deberia demorar mas de 1min con tarjeta de credito en mano.
3- Registar los clientes

Yo diria que hasta aqui es lo mas practico para la mayoria de los programadores en general.


4- Autenticar a la hora de soporte (ej: si es telefonico, o requiere que personal se meta de fondo) y/o actualizar el software. Es mejor pedir clave/usuario cada vez que hay un update a que haya un serial.
5- Proteger datos mas que codigo (ej: Si es un ERP, con algo tan simple como encriptar un valor en la BD o la BD entera es mucho mas eficaz)
6- No inventarse ideas raras. Un experto en seguridad? NUNCA se inventa cosas raras.

Y lo mas importante:

7- Tratar bien al cliente