Necesito sugerencia

Hola como estan.

Bueno despues de un saludo corto, aqui mi inquietud, la cual es, que metodo me recomendarian para hacer un Serial no para un Keygen o Crack.

Sino como creen que seria mas dificil de hacer una Ingenieria Inversa de un programa, aun que se que a ultimas instancias seria imposible hacer un un Serial para un programa ya que como programador independiente, me ha tocado ver cada Keygen o Crack a empresas dedicadas de lleno a proteccion, seguridad etc etc.

Que que mas proteccion ofrecer yo que no hayan previsto ellos, Lo unico que se me ocurre, es registro en linea, y que siempre sea forozoso al arranque del programa verificar el registro, quizas me quitaria algunos segunos de la aplicacion pero a mi forma de ver valdria el tiempo en la revision del registro y Genualidad del registro.

Fuera de ello se que todo es Crackeable.

De antemano gracias por la informacion que puedan proporcionar.

No hay respuestas. Si corre, se puede crackear...

Totalmente cierto MCKSys, se puede afirmar que no existe una protección invencible. Aunque el tema principal no es ese, sino mas bien, se trata de diseñar una protección satisfactoria, esto es, ser capaz de diseñar un sistema de protección de software resistente a la mayoría de las técnicas de ataque, cuya anulación suponga invertir gran cantidad de tiempo. Este tiempo supone para muchas empresas, generar dinero, ya que hasta que no se anule la protección, el producto original recibirá mayor número de ventas.


Un saludo.

Una manera de asegurarse que el programa no ofrezca la funcionalidad completa es no incluyéndo esa funcionalidad en la demo (no que se incluya pero que haga falta activarla), de tal manera que esa demo no podrá nunca podrá crackearse para que funcione como el programa completo.
Si lo que se quiere es ofrecer el producto completo pero que solo se pueda activar con un serial, existen muchas formas de proteger tu programa aunque no estoy muy puesto en ellas, pero ofuscar el código, no permitir la ejecución de debuggers, tener cuidado con las excepciones (tipo utilizar alguna llamada al so para escribir una ventana de error si el serial es incorrecto), son buenas ideas.

miguel86 tiene razón. Si vas a generar un producto con demo, la misma no debe incluir toda la funcionalidad. Ahora esto conlleva un gasto de tiempo y dinero sustanciales, dependiendo del lenguaje, tipo de aplicación, recursos humanos, etc.

Los programas basados en protección con seriales PUEDEN crackearse. Es cuestion de tiempo, pero tambien de suerte, porquer si lo agarra un cracker experimentado (no es mi caso) la protección puede no durar mucho (y encima puede quedar expuesta completamente en un tutorial)

Quizas deberias usar una mezcla de protecciones: firmar los archivos digitalmente, usar un código de registro lo bastante grande como para que se le haga dificil al cracker (Archivos de clave), también el contenido del archivo puede ser la clave para desencriptar la parte "comercial" del programa, etc. Si a eso le sumas protecciones de ejecutables "libres" (PESpin, Armprotector, etc), podes llegar a tener una protección ANTI-LAMER

Aunque mi experiencia me demuestra lo que dije al principio.

Saludos!

MCKSys Argentina

Hola y gracias a todos se los agradesco.

Lo del programa DEMO estoy conciente que si va completo se puede desbloquear :D, como que me suena a que lo hemos hecho mas de uno jejeje.

El detalle es que cuando este en una empresa, no pueda ser copiado a otra empresa, y sip.. todo programa en Windows es rompible :(

Pasado al empaquetado, con esta imagen se puede determinar que use.... o se ocuparia el EXE completo.. para determinar la compresion...

http://img527.imageshack.us/img527/5584/hexani1.jpg

gracias por la atencion prestada y estare al pendiente de los comentarios.

Vamos a ver que te veo algo perdido.

Crackear se puede, por supuestísimo (eso es algo que sabemos todos los programadores).

Pero te veo algo pez, ya que hasta pones la imagen del exe que, realmente, no has visto si está realmente packed o no... tienes que leer algo mas.

Consejos, el editado exadecimal es lo último, empieza por saber y por buscar, PeID, Win32DASM, OllyDebugger... OK? Verás como se te empiezan a abrir las puertas.

Cita:

---

Iniciado por SxR

Vamos a ver que te veo algo perdido.

Crackear se puede, por supuestísimo (eso es algo que sabemos todos los programadores).

Pero te veo algo pez, ya que hasta pones la imagen del exe que, realmente, no has visto si está realmente packed o no... tienes que leer algo mas.

Consejos, el editado exadecimal es lo último, empieza por saber y por buscar, PeID, Win32DASM, OllyDebugger... OK? Verás como se te empiezan a abrir las puertas.

---

Hola, gracias por tu respuesta...

Lo del crack es muy cierto desde un inicio lo he dicho ;)

La imagen del Exe la subo para no tener que subir el Exe en si, y en efecto la aplicacion esta empaquetada ya que asi lo he hecho, la cuestion era ver si seria posible saber con cual.

Ahora lo del PeID, Win32DASM, OllyDebugger... caigo tbm en cuenta que les VALE a esos programas si esta o no empaquetado de todos modos muestra todo... :$

de antemano gracias, he visto la opcion de los programas, y si es cierto lo habia olvidado ahi se hace todo.. :$, nimodo.

Si no fuera por los Crakers el caballo no andaria...

Empezar por aquí te puede ayudar:

http://support.microsoft.com/?scid=kb%3Bes%3B65122&x=7&y=16

Empaquetar significa unificar toda la información en un sólo fichero, el cual normalmente comprime (o encripta) su contenido, utilizando algoritmos conocidos. Dicho ésto, tienes un ejemplo claro como puede ser .zip, .rar, .wma, .mpeg, etc...

Para lograr desempaquetarlo (y posteriormente descomprimirlo o desencriptarlo), es necesario guardar la información de cómo se ha empaquetado y comprimido o encriptado. Leyendo esa información, normalmente guardada en forma de tablas, sólo basta leer las posiciones de memoria dónde se aloja en dicho fichero.

Para el caso de un fichero ejecutable (.exe), empaquetar (y comprimir), significa coger el .exe original, encapsularlo en otro .exe el cual comprimirá la información del .exe original. Por tanto observando las cabeceras del resultado empaquetado, a simple vista será como un .exe normal, sólo que su contenido no es mas que otro .exe comprimido, y por tanto todo lo que lea cualquier desensamblador o editor, no será correcto si antes no ha sido desempaquetado y descomprimido (o desencriptado).

Ok?

En cuanto a temas de protección, vuelvo a decir, la idea es dificultar la tarea lo más que se pueda. Empaquetando y comprimiendo o encriptando no tienes garantizado nada, ya que leyendo las tablas con la información de cómo se hizo la empaquetación, junto con la compresión y encriptación, ya lo tienes vulnerado.

Yo en tu lugar lo enfocaría desde el punto de vista del diseño... es decir, pararse un poco durante el diseño del software porque luego se agradecerá...

Un simple y claro ejemplo, fácil y rápido de implementar y a la vez muy eficaz, consistiría por ejemplo en aislar aquel módulo que se encargue de validar claves o comprobar números de serie. Algo tan simple como implementar una función, procedimiento o método, que lo realice, pero que en vez de ser ejecutado en el hilo de ejecución principal del programa, sea lanzado en un nuevo hilo de ejecución. En este caso, un desensamblador puede ver la lista de instrucciones hacia la llamada a un nuevo hilo, con su paso de parámetros, pero lo que no verá el debugger será la ejecución paralela del mismo... Esto es algo muy simple, pero eficaz, ya que para el procesador es como un proceso aparte, con su puntero de instrucción independiente, y es más complejo seguirle el rastro.

En cuanto a otros ejemplos de protección, lo único que se ha hablado es de "empaquetar" (aunque realmente lo interesante es la compresión o encriptación que realiza dicho proceso de empaquetación), pero de una forma "estática" es decir, tener algo sin codificar, realizarle una serie de pasos, y obtener un resultado que siempre será igual. Existen otras técnicas "dinámicas", que se basan en que en tiempo de ejecución, ese ejecutable va cambiandose asímismo, y según un criterio unas instrucciones que antes eran definidas, ahora son totalmente distintas, aunque el resultado final sea el mismo.

La demostración matemática, o mejor dicho computacional de ésto se basa en que un programa escrito en un lenguaje de alto nivel, puede ser traducido de infinitas formas a lenguajes del tipo GOTO, como el ensamblador, por ejemplo un bucle del tipo:

Cita:

---

for (int i=0; i<10; i++){
a++;
}

Puede ser códificado en ensamblador de muchas maneras, por ejemplo, siguiendo un criterio de recorrido ascendente:
INC registro
CMP registro,10
JNE repite

o descendente, es decir, decrementar y ver si es cero, algo como:

DEC registro,
JNZ bucle

y un largo etc... por supuesto sin contar criterios de optimización del compilador.

---

Un claro ejemplo de todo ésto es el viejo conocido polimorfismo. En la ezine 3, si quieres puedes echar un vistazo al artículo que yo mismo he escrito. Observarás como algo que antes era una instrucción que no hacia nada, un simple NOP, se convierte en una instrucción que si hace algo, (por ejemplo un ADD). Y con lo cual, algo que antes era un (INC registro - CMP registro,10 - JNE repite), puede ser convertido a (DEC registro, JNZ repite), por supuesto he puesto un ejemplo sencillito para captar la idea...

Con todo ésto me vengo a referir que no existe unos pasos a seguir en cuanto al sistema de protección de software. Para hacer ingeniería inversa, hay que saber primero ingeniería... :), lo cual no es fácil... no basta con aplicar los pasos que hay en google, aunque la mayoría de las veces de resultado (lo que demuestra el copy&paste de los diseñadores xD). Y por supuesto hay que saber ingeniería inversa para conseguir una proteccion decente.


Un saludo.

No esoty muy puesto en las protecciones en los programas pero una forma segura que se podría hacer si no se va a comercializar en grandes cantidades es cifrando el ejecutable por ejemplo con AES y que solo se pueda descifrar con un código que fuese el serial, sólo conocido ese código se podría desencriptar el ejecutable, por tanto no sería crackeable si para conocer el código hubiese que ponerse en contacto contigo.

No creo que todo lo que corra es crackeable, quizás las posibles soluciones de hoy en día si lo son pero tópicos como que todo es crackeable o hackeable no son ciertos, existen cosas no hackeables hoy en día por muy hacker que seas por que detrás existen teorías que hoy en día no han sido superadas (por ejemplo la factorización lineal de números primos en RSA, por muy hacker que seas no vas a poder descifrar la comunicación de tu vecino con el banco utilizando tls).

Una cosa es crackear y otra muy distinta desencriptar. Son conceptos totalmente distintos.

Un saludo.

Crackear es un concepto distinto al de desencriptar estoy de acuerdo, me refiero a que van unidos. Crackear es saltarte una protección, y muchas veces la seguridad se esconde detrás de algoritmos criptográficos. Si hoy se puede "crackear" la seguridad de las redes inalámbricas cifradas con wep es por una debilidad en el algoritmo rc4, cosa que no ocurre con wpa, que no se puede crackear. Si detrás de un sistema de seguridad está la teoría que no es vulnerable, ese sistema no se puede crackear. Romper(Crackear) un algoritmo criptográfico es lo que te permite descifrar el criptograma sin tener la clave, es decir, si la protección es el cifrado, y garantizas un cifrado seguro, no hay forma de romper (crackear) esa protección de cifrado, y por tanto de crackear el sistema.

Muchas gracias a todos, sus comentarios y sugerencias me sirven de mucho para seguir, avanzando, se agradece todo el tiempo y dedicacion al tema, y si me pondre a seguir leyendo, para despus si me hacen el favor de revisar un EXE.

Una duda, hace tiempo hice un Serial usando C++ solo que usaba la funcion Random, pero con el uso del Windows Los numeros aleatorios aun siendo inicializados muy rara vez me daban numeros consecutivos.

De hecho son conceptos compatibles pero no tienen porqué aplicarse en lo mismo.

Desempaquetar > descomprimir un ejecutable y desprotegerlo para poder ver su código.
Crackear > saltarse una protección o realizar un programa para que se la salte...

En esencia es eso... no tienen mucho que ver entre ellos pero sí se necesitan el uno del otro (sobretodo el crack del umpacker)