Junio 20, 2018, 06:53:16 am

Autor Tema: Cómo proteger tu programa by karmany  (Leído 25379 veces)

0 Usuarios y 1 Visitante están viendo este tema.

Desconectado proton6

  • Si te metes con CPH
    te metes conmigo
  • ****
  • Mensajes: 2582
  • Sexo: Masculino
    • Ver Perfil
Cómo proteger tu programa by karmany
« en: Agosto 09, 2008, 02:17:13 am »
PRÓLOGO

Después de recibir varias consultas sobre este tema, hemos decicido abrir este nuevo post, dando a conocer principalmente a los programadores los distintos sistemas para proteger sus aplicaciones:

-Protecciones que pueden implementar ellos mismos en sus programas...
-Programas gratuitos que pueden utilizar para empaquetar sus aplicaciones
-Programas de pago..
-Consejos...

Nosotros sabemos que a una persona con buenos conocimientos, cualquier protección le es indiferente, porque no hay nada infalible, pero vamos a mostrar las distintas formas que conocemos.

¿Por qué abrimos este post? Pues porque la gente que diariamente trabaja con Ingeniería Inversa es la gente que se enfrenta con las protecciones actuales y sabe cuáles son las más difíciles (que no imposibles) y cuáles puede aconsejar...

Un saludo y esperamos que os pueda servir de guía antes de decidiros por una u otra opción...



INTRODUCCIÓN

Varias de las preocupaciones de un programador a la hora de distribuir su aplicación pueden ser:

-Disminuir el tamaño de la misma todo lo posible
-Crear licencias para usuarios registrados
-Crear versión DEMO
-Proteger la aplicación para que no sean usadas licencias ilícitas



Primeramente, y antes de todo, hay que comentar unos detalles que todo programador debe saber:
-Ningún programa es incrackeable.
-Hay protecciones fáciles,...., difíciles, ...., muy difíciles y muy muy difíciles, pero no imposibles.
-Muchos programadores piensan que por no tener el código fuente, al cracker le va a resultar más complicado estudiar la aplicación. Ya les puedo asegurar a todos los que piensen así: que se equivocan al 100%. Si analizaramos cualquier programa compilado con cualquier lenguaje de programación, llegaríamos a ver secuencias de 0 y 1 que el procesador entiende directamente. Pero existen muchos programas denominados desensambladores que lo que hacen es convertir esa secuencia de 0 y 1 en código ensamblador. El cracker domina este lenguaje.
-A parte de la ayuda que es un desensamblador, se unen los debugger que son herramientas para la depuración del código. Estos debuggers a día de hoy, están muy desarrollados y les puedo asegurar que su aplicación será incapaz de detectarlos.
-Las personas que comienzan su andadura por el mundo de la Ingeniería Inversa son denominadas Newbies. Y no hay que subestimar a nadie.
-Existen en la actualidad muchísimos programas para proteger y/o reducir tu aplicacion, estos programas se denominan empacadores, empaquetadores o en inglés packers.
-En este tutorial vamos a hablar principalmente de aplicaciones a 32 bits en ejecutadas en Microsoft Windows.

Después de todo esto seguro que ya sabrás que tienes dos opciones:
    -Implementar tú mismo la protección en tu aplicación
    -Utilizar uno de los muchos empacadores que existen

Implementar uno mismo la protección:
Como ya se puede uno imaginar, hay que crear licencias y una versión demo. Es realmente una labor un tanto costosa, pero con toda la información que hay en Internet seguro que puedes conseguir una base para comenzar. Hay muchas personas que ya tienen el código fuente preparado para distintos software y lo que hacen es modificar ciertos parámetros y así los nombre-contraseña también son diferentes.

Utilizar un packer:
La utilización de estos programas tiene una gran ventaja: que en la mayoría de ellos se pueden ya crear licencias, versiones demo, protecciones contra desensamblados/debuggers, e incluso la disminución del tamaño de la aplicación consideramente.

Por contra, si quieres crear una aplicación comercial, en la mayoría de ellos deberás comprar el producto, lo que requiere que tu aplicación aumente también de precio.
También se debe tener en cuenta que los packers que hace unos años eran muy complicados, actualmente han sido analizados hasta su último bit y gente Newbie es capaz incluso de enfrentarse a este tipo de protecciones. Pero todo esto lo veremos con más detenimiento después.

Hablaremos un poco de los métodos anti debugger/desensambladores
« Última modificación: Diciembre 03, 2010, 12:59:49 pm por jep »
"Las ideas son más poderosas que las armas. Nosotros no dejamos que nuestros enemigos tengan armas, ¿por qué dejaríamos que tuvieran ideas?"

Desconectado proton6

  • Si te metes con CPH
    te metes conmigo
  • ****
  • Mensajes: 2582
  • Sexo: Masculino
    • Ver Perfil
Re: Cómo proteger tu programa by karmany
« Respuesta #1 en: Agosto 09, 2008, 02:19:37 am »
Protecciones contra debuggers/desensambladores

Sea cual sea la opción elegida de las dos mostradas, se suelen implementar distintas medidas contra el desensamblado del código o contra debuggers.



Protección de packers:

A día de hoy, los softwares para empaquetar aplicaciones están muy avanzados y no hace falta decir que existen empresas que dedican su tiempo en seguir investigando estos métodos. De este modo, y cada vez más a menudo, los nuevos packers que aparecen son obras de arte muy difíciles de romper y seguramente toda protección que se te ocurra ya ha sido investigada hasta la saciedad.
Sin embargo, cada protección, sea hecha por el usuario o sea utilizando software especializado es un mundo diferente y cada una tiene su complejidad.

Por otro lado, como los software de protección han avanzado tanto, pues también los que depuran las aplicaciones han avanzado tanto o más camino; conocen la mayoría de protecciones utilizadas y cada vez aparecen más herramientas de ayuda que hacen la depuración de programas una tarea muy sencilla. No hace falta decir que hay personas con unos conocimientos muy elevados y no solamente en el ámbito donde se mueven generalmente los software (ring3) sino a niveles donde trabaja el Sistema Operativo o incluso ¡por debajo de él!.


Desde hace muchos años se vienen estudiando formas para que sea más complicado acceder al código y poder utilizar dicha información; sin ir más lejos recuerdo perfectamente juegos de aventuras conversacionales de mi antiguo ZX Spectrum a 128K donde se encriptaban las cadenas de texto para que con un debugger no fuera tan sencillo encontrar la "palabra clave".

Actualmente, según mi opinión y mi experiencia, los software para empaquetar aplicaciones no se preocupan tanto en evitar que se pueda desensamblar/debuggear el código, sino lo que hacen es:
-Uso de Máquinas Virtuales para la creación del código
-Creación de zonas dinámicas de memoria donde se ejecutará parte de código.
-Código ofuscado: con mucho código inútil de más para evitar que se entienda el desensamblado. Esto hará aumentar de tamaño tu aplicación.
-Emulan la funciones y por consiguiente las llamadas a las mismas, por ejemplo si en nuestro código hemos hecho una llamada a MessageBox, pues la API MessageBox será totalmente emulada y posiblemente ofuscada.
-El mismo packer ejecuta las primeras instrucciones de tu programa y devuelve el control al mismo después, por lo tanto, conocer todo ese código que ya se ha ejecutado es un problema grandísimo. Si son sólo unos bytes los que han desaparecido se denomina Stolen Bytes, si por el contrario es gran parte de código se denomina Stolen Code.
-Suele ser muy fácil llegar a la comprobación de Nombre-Serial, pero han creado tantísimo código y tal complejidad a la hora de analizar un nombre-serial válido que es dificilísimo encontrarlo y por tal motivo se prefiere reparar el programa.
-Y algunas cosas más que iré añadiendo...
 
El lector dirá, y ¿qué consiguen con todo eso? Pues está muy claro:
1º- Hacen tan difícil encontrar un nombre-serial que el cracker seguramente desestimará esta opción porque requiere muchas horas y días de análisis.
2º-Imaginemos que al cabo solamente de 2 minutos encontramos un salto (que en ensamblador puede ser "je") que salta cuando estamos registrados pero que no salta cuando no lo estamos. Bien, sabiendo esto podríamos modificar el salto y se puede pensar que el asunto está arreglado... Aquí está la dificultad, que como la aplicación está empacada tú no puedes modificar ese "je" por un "jne" porque ese "je" todavía no existe y probablemente sea ejecutado en una memoria dinámica (que con cada ejecución varía) que el packer crea a la hora de descomprimirse.
3º-Al emular la funciones (IAT - Tabla de Importaciones), es muy difícil saber cuáles son y por lo tanto al intentar reconstruirlo puede resultar extremadamente complicado.
4º-El uso de Máquinas Virtuales hace muy difícil saber el camino que el packer está tomando.
5º-Como cada packer es un mundo diferente pues también sus protecciones.

En resumen de todo esto:
Para descomprimir un programa empacado, es necesario llegar y pararse en el punto de entrada del programa original (OEP), arreglar la IAT, reparar los Stolen Code o Stolen Bytes, el código que se ejecuta fuera de la memoria de la aplicación introducirlo dentro etc... Se trata de quitar el packer de la aplicación y dejar solamente esta última.
Es decir, un trabajo muy laborioso pero que en determinados casos como es un trabajo repetitivo con la práctica lo puedes resolver en unas cuantas horas.

Seguro que después de haber metido toda esta parrafada algunos no saben ni de lo que he hablado, bueno solamente hay que quedarse con lo más importante y si de verdad quieres indagar en el tema releer todo lo que he escrito o preguntar en el foro. Todo lo comentado suelen ser las protecciones habituales de packers comerciales. Y... a nivel de implementar uno mismo su protección ¿cómo se puede evitar el desensamblado/debugger?

Proteger uno mismo su aplicación:

Después de lo que se ha comentado, alguno pensará... pero si está todo estudiado ¿qué protección puedo yo poner a mi aplicación?
Aquí viene la invención de cada persona. Hay gente que tiene muy buenas e innovadoras ideas.

Siempre se han utilizado técnicas muy conocidas por todo el mundo como pueden ser:
-Uso de la API IsDebuggerPresent que se encuentra en la librería kernell32.dll. Es la más conocida por todo el mundo, simplemente se llama a esta API y si el resultado de la misma es 1 hay debugger, si es 0 no hay debugger.

-Retardo en la ejecución de código: es decir, si por ej. en cargar tu aplicación tiene que pasar solamente 1 segundo y han pasado 45 segundos --> ¡hay debugger!. Esto se suele hacer de varias formas: usando la función GetTickCount o usando funciones que te devuelven la fecha actual, incluídos segundos: GetLocalTime, GetSystemTime. Seguro que tú conoces muchas más formas. Te puedo indicar una muy curiosa que yo he usado de prueba y funciona perfectamente y es en ensamblador con la instrucción RDTSC. Esta última instrucción es interesante ya que si se ejecuta dos veces una detrás de otra, verás que el resultado de ambas es prácticamente igual, sin embargo, si ha pasado determinado tiempo entre la ejecución de la primera RDTSC y la segunda los valores son totalmente diferentes.

-En Window, el registro FS apunta hacia una estructura llamada Thread Information Block (TIB). Esta compleja estructura tiene otras y más complejas estructuras y en ella podemos tener información de si un Debugger está depurando la aplicación o no.
Ejemplos: GlobalFlags sería en ensamblador implementado de la siguiente forma:

mov eax, dword ptr fs:[30h]
mov eax, dword ptr ds:[eax+68h]


Si el resultado es cero --> no hay debugger
Si el resultado es distinto de cero --> hay debugger
Del mismo modo hay otras formas similares: ProcessHeap Flag, PEB_LDR_DATA etc...

-Podemos hacer uso de distintas API: ZwQueryInformationProcess, ZwSetInformation Thread, ZwQuerySystemInformation... Hay cosas muy curiosas incluso utilizando la función CsrGetProcessId que se encuentra ni más ni menos que en ntdll.dll. De este último ejemplo tengo uno hecho en ASM por si alguien quiere analizarlo.

-Podemos también investigar si se está usando algún debugger examinando los procesos que se están ejecutando. Esto se suele hacer de dos formas:

    *Utilizando la API CreateToolhelp32Snapshot desde el primer proceso Module32First y después yendo uno por uno con Process32Next.
    *Utilizando EnumProcesses que devuelve un array con el PID de cada uno de los procesos. Hay que observar que podemos también ver los procesos que cada proceso está ejecutando.

-Podemos buscar por el nombre o clase de ventana. Para esto utilizamos la API FindWindow.

-Evitar el uso de Breakpoints. Los Breakpoints, utilizados por un debugger, son lugares en donde el debugger para porque el usuario ha modificado una instrucción por INT3 (interrupción). Esto es una ayuda considerable, ya que se pueden poner muchos BP (breakpoints) en lugares adecuados para el análisis del código. En tu código si programas en ASM, puedes comprobar en sitios determinados, si se ha modificado la instrucción por un INT3. También es posible llamar a la API VirtualProtect y modificar las propiedades de determinada sección. Los BP serán borrados.

-Detección de Hardware Breakpoints. Un debugger puede poner infinidad de BP, pero solamente puede poner 4 HBP (Hardware Breakpoints). Son muy útiles, más cuando los BP normales fallan. Muchos packers lo que hacen es detectar estos HBP para saber si hay debugger o no. Para esto hay que entender antes las SEH o manejo estructurado de excepciones.

Desconectado proton6

  • Si te metes con CPH
    te metes conmigo
  • ****
  • Mensajes: 2582
  • Sexo: Masculino
    • Ver Perfil
Re: Cómo proteger tu programa by karmany
« Respuesta #2 en: Agosto 09, 2008, 02:21:13 am »
Herramientas para la depuración

Yo sé que todo esto que estoy explicando, si el lector nunca ha trabajado con Ingeniería Inversa, pues puede resultar complicado... de todos modos lo más difícil ya ha sido explicado, ahora vienen cosas "menos técnicas"

Muchas herramientas para el cracking ya reconocen estos métodos comentados.

Para tener una idea de la "fuerza" de algunos programas explicaré el archiconocido OllyDBG:
OllyDBG es un debugger a 32 bits (en ring3) potentísimo. Yo casi me atrevo a decir que para ring3 es el mejor. Desde su aparición, que al principio no causó buena sensación, fue sumando adeptos y su despegue ha sido brutal. Tiene una opción que es la posibilidad de insertar plugins... así que programadores de todo el mundo han hecho millones de plugins para este debugger. Unos plugins que hacen que OllyDBG sea una herramienta esencial e invisible a todo: sólo con un click de ratón, es posible anular ¡todas las protecciones anti-debugger que vimos en el apartado anterior!.
Con esto demuestro la magnitud de este programa. Es impresionante.

Hasta ahora sólo he comentado la existencia de dos herramientas: debuggers y desensambladores, sin embargo, existen muchísimas más que hacen que todo cracker tenga las cosas bien fáciles.

No todas estas herramientas están preparadas para detectar los trucos anti-debugger/desensambladores que vimos en el apartado anterior, así que es bueno por este motivo poner siempre algún tipo de protección de las ya vistas.

Hay herramientas específicas incluso para cada lenguaje de programación con que la aplicación haya sido compilada. Por ejemplo para programas compilados con Visual Basic hay aplicaciones como VB Decompiler, VB Reformer, SmartCheck (de verdad éste último es impresionante) etc.. para compilaciones con Delphi o Borland C++ tenemos Dede, E2A, MiniDe etc...
Todos estos programas ofrecen una ayuda al debugger muy precisa, con lo cual, el cracker rápidamente llega a la "zona caliente" que le interesa. Excepto Smartcheck que también actúa como "debugger", los demás normalmente trabajan analizando el código, por lo cuál determinadas protecciones anti-debugger no valen para nada.

Cada programa, cuando está ya compilado hay que tratarlo de forma muy diferente, por ej. un programa que haya sido compilado con Visual Basic ya se sabe que necesita de su librería de apoyo para funcionar , un programa en Delphi tiene bastante código ya que incorpora todo lo necesario en él para funcionar, los programas en NET suelen resultar muy requetefáciles de romper e incluso encontrar seriales también suele ser tarea relativamente sencilla.
Personalmente los programas en Delphi o Borland C++ me resultan los más difícultosos a la hora de analizar ya que cuando se realiza alguna función no se realiza directamente, sino que se envía un valor (normalmente 0 o 1) a un lugar de la memoria y posteriormente ese valor será tratado, me explico:
Si nosotros queremos activar un botón, por ej. en ensamblador haremos:
Call Activar_botón
Simplemente ejecutando esa subrutina (Activar_botón) el botón se activará.

Si ahora lo hacemos en Delphi o en Borland C++:
Call Activar_botón
Al pasar esa subrutina el botón NO se activa!! simplemente en un lugar de la memoria se habrá puesto un 1 y ese 1 será el que haga activar el botón más tarde.

Como se observa cada programa y según con qué lenguaje de programación fue escrito hay que tratarlo de forma muy diferente.

En todos estos casos, debes ver con qué lenguaje de programación trabajas y de este modo puedes implementar en tu aplicación alguna medida contra estas herramientas.

Como comenté antes existen debuggers (OllyDBG por ejemplo) que son invisibles a todo. Incluso algunos utilizan drivers para ejecutarse por debajo de donde las aplicaciones trabajan: ring3.
Yo pienso que es por este motivo que, como comenté al principio, los software especializados en protecciones no se preocupan tanto de poner trampas anti-debugger sino en "romper" el ejecutable para que no sea recompuesto... esta es la misión del cracker: recomponer el ejecutable que ha sido desmenuzado por un packer.

Voy a bajar el "listón" para que se entienda perfectamente:
-Un packer tiene dentro de sí mismo al ejecutable que se ha protegido. El packer se va descomprimiendo poco a poco, desencriptándose, realizando chequeos anti-debugger etc... hasta que llega un momento, cuando se ha descomprimido del todo que pasa la ejecución al programa que se ha protegido... y ¡zas! ahí entra el cracker a jugar. En ese mismo momento es cuando el cracker para todo y reconstruye poco a poco el puzzle. Como ya se sabe hay puzzles fáciles, y muy difíciles. Sin embargo, con tiempo todo puzzle se puede hacer.

Ese momento en el que ya se ha descomprimido todo y pasa a ejecutarse la aplicación protegida, es diferente también según qué compilador hayamos utilizado, por ej. en Visual Basic suele ser muy fácil llegar a este punto.

LLegados hasta aquí, ya sé que muchos se preguntan... pero yo quiero hacer mis protecciones y quiero fabricar un programa DEMO y licencia y.... ahora lo veremos en el siguiente apartado.

Desconectado proton6

  • Si te metes con CPH
    te metes conmigo
  • ****
  • Mensajes: 2582
  • Sexo: Masculino
    • Ver Perfil
Re: Cómo proteger tu programa by karmany
« Respuesta #3 en: Agosto 09, 2008, 02:24:09 am »
Quiero hacer yo mismo mi propia protección

Este apartado lo podríamos llamar consejos de gente que trata con "Ingeniería Inversa". Consejos para que tu aplicación sea más difícil de analizar.

Cuando se implanta una licencia, hay que tener presente que esa licencia es para un usuario y normamente es así:
1-Nombre del usuario
2-Contraseña del usuario

Ambas tienen una relación que sólo debe conocer el autor de la aplicación. Hay otros programas que simplemente con poner un serial ya está registrado correctamente. Me basaré en el primer caso: Nombre y contraseña.

Caso 1 - Protección (0 a 10): 1

Muchos programadores ponen la relación nombre-contraseña muy difícil de analizar: pasan los datos de nombre al valor ASCII que corresponda y realizan infinidad de operaciones matemáticas. Hasta aquí muy bien, pero...
después de realizar esas operaciones matemáticas comprueban directamente ese resultado con el serial. Ahí está la debilidad: si se compara directamente con el serial será muy fácil encontrarlo, simplemente hay que pararse en la comparación y veremos la contraseña correcta.
Puedo asegurar que infinidad(requetemuchísimos) de programas hacen esto comentado.

¿Cómo se puede arreglar?
Pues bien, todo programador debe saber una cosa lo más básico de todo: si el serial verdadero aparece directamente en memoria por cualquier causa, en menos de lo que canta un gallo será encontrado por cualquier Newbie.
Hay que evitar sea como sea la comparación directa del serial. Hay muchas formas, una por ej. sencilla es poner el valor ASCII también al serial y realizar otra serie de operaciones matemáticas...

Caso 2 - Protección (0 a 10): 2

Imaginemos un programa que la licencia para mi es:
Nombre: karmany
Serial: 1234
El chequeo que hace para la comprobación es:
Código:
Citar
Nombre: karmany --> pasa a valor ASCII --> operaciones matemáticas --> resultado final: 564
Serial: 1234    --> pasa a valor ASCII --> operaciones matemáticas --> resultado final: 564

Como se observa. ya no se compara el serial directamente pero tiene asímismo una gran debilidad: debe comparar esos resultados: 564
Esto en ensamblador aparecerá también como una comparación y aunque no tengamos el serial podemos modificar directamente el resultado de la comparación porque es una comparación: registrado- no registrado. Estaría crackeado en poco tiempo por un Newbie recién iniciado.
Hay que evitar esas comparaciones.

Caso 3 - Protección (0 a 10): 2-3

Imáginemos que tenemos el caso 2 en el que cuando introducimos una contraseña falsa nos aparece un mensaje que dice: "Contraseña no válida"
Sabemos que para el registro hay que comparar los 564 pero ¡hay que encontrarlos primero!
Lo primero que hace un cracker es ver: las 'string references', es decir, las cadenas de texto. Normalmente cualquier cadena de texto que se utilice en un programa, aparece literalmente en el mismo. Por este motivo, si cuando un usuario pone una contraseña correcta, aparece un mensaje que dice: "Gracias por registrarse" no dude ni un segundo que lo que primero va a buscar el cracker son esas palabras. Y cuando las encuentre irá directamente a parar a la comparación de 564 con 564.
Por todo esto que estoy comentando, hay que evitar las cadenas de texto literales.
Tú eres programador, esto te lo dejo a tí, hay mil formas.

Si partimos del Caso 2 y hemos eliminado toda referencia de texto, ya estamos protegiendo nuestra aplicación contra un número de Newbies. Sin embargo, este último, aunque tenga muy poca experiencia, con el tiempo encontrará esa comparación 564 con 564 y la modificará.

Caso 4 - Protección (0 a 10): 2-3

Partimos del Caso 3.
¿Qué ocurre cuando hemos introducido un código correcto? Muchos programas modifican cierto byte de ellos mismos de tal modo que si está el registro correcto el byte es 1 y si no está registrado el byte es 0.
Estamos en el Caso 4 y ya no resulta fácil encontrar un nombre-serial válido, pues el programador hace millones de operaciones matemáticas para obtener esos 564.
El cracker puede optar por dos sencillas opciones:
-modificar la comparación de 564 para que cualquier nombre-serial valga
-ver después cuál es el byte que se pone a 1 cuando nos registramos.

Sabiendo esta segunda forma, el cracker directamente modificará permanentemente ese byte a 1 y ya no hay que poner ningún nombre-serial porque ya será una versión registrada.

Caso 5 - Protección (0 a 10): 5-...

Cada persona es diferente así que lo que a mí me parece fácil a otro le parecerá difícil y viceversa.
Para mí un protección 5 ya es un tema para estrujarse las neuronas.
Partimos del caso anterior pero cuando está registrado ya no depende sólo de un byte. Para hacer esto podemos hacer que de vez en cuando sea comparado el nombre-serial, pero tenemos el problema de siempre: llegamos a la comparación de antes: 564 que hay que eliminar.
En ensamblador las comparaciones directas suelen hacerse con la instrucción cmp y después viene un salto por ejemplo "je" o "jne". El cracker lo primero que probará será modificar tras la comparación el "je" por un "jne" o viceversa.

Sólo pensando un poco se le pueden ocurrir a uno muchísimas formas de evitar que se compare directamente 564 con 564. Por ejemplo, con el nombre realizamos operaciones, con el serial lo mismo. Después realizamos operaciones con los valores obtenidos dando un valor de resultado. Con ese resultado podemos desencriptar parte de código. El problema de esto es que ese valor es siempre el mismo para cualquier nombre-serial.

Se pueden también realizar diversos chequeos, por ej. se puede examinar si la comparación 564 con 564 ha sido modificada, en tal caso no mostrar un mensaje inmediato ya que alerta al cracker y el mensaje le sirve de guía.

Se pueden realizar chequeos CRC, se pueden utilizar archivos para la licencia (keyfiles) donde cada archivo licencia es diferente según usuario.

Si no se te ocurre ninguna forma de ocultar la comparación 564 puedes hacer una cosa y es hacer esa comparación en memoria dinámica ya que ahí el cracker no puede modificar el "je" por "jne" porque en el ejecutable no existe todavía.

Si tu programa requiere actualizaciones de cualquier tipo, lo tienes bastante fácil porque según el usuario-serial tú puedes permitir la descarga o no de actualizaciones, aunque el programa esté crackeado.


Hay muchas formas que deben salir de tu imaginación. Cada programa es un mundo, como cada persona. Incluso para saber proteger una aplicación puedes analizar tutoriales de cracking, que te enseñarán las protecciones más comunes que se suelen utilizar.

Desconectado proton6

  • Si te metes con CPH
    te metes conmigo
  • ****
  • Mensajes: 2582
  • Sexo: Masculino
    • Ver Perfil
Re: Cómo proteger tu programa by karmany
« Respuesta #4 en: Agosto 09, 2008, 02:25:55 am »
Enlaces - Opinión personal

Como hemos aprendido, lo que siempre y en toda aplicación hay que evitar son las comparaciones directas tanto de serial malo-serial bueno como comparación registrado-no registrado. Eliminando asímismo las referencia a cadenas de texto haremos que nuestra aplicación ya no esté al alcance de todo Newbie. Después para aprender más recomiendo leer tutoriales de Ingeniería Inversa y así se aprenderán nuevas técnicas más complejas. Tal vez tú que estás leyendo esto seas un futuro programador de packers.


Ver Perfil Email Mensaje Personal (Desconectado)
   
   Re: Cómo proteger tu programa
« Respuesta #4 en: 06 Agosto 2008, 23:50 »
   
Enlaces - Opinión personal


Como hemos aprendido, lo que siempre y en toda aplicación hay que evitar son las comparaciones directas tanto de serial malo-serial bueno como comparación registrado-no registrado. Eliminando asímismo las referencia a cadenas de texto haremos que nuestra aplicación ya no esté al alcance de todo Newbie. Después para aprender más recomiendo leer tutoriales de Ingeniería Inversa y así se aprenderán nuevas técnicas más complejas. Tal vez tú que estás leyendo esto seas un futuro programador de packers.

Existen gran número de programas para empaketar nuestro programa, hay bastantes gratuitos pero siempre hay que leerse las condiciones porque en la mayoría ponen que si tu aplicación es comercial el packer no es gratuito.

El packer más conocido en todo el mundo es probablemente UPX.
Como ya sabrás, UPX es excelente para disminuir tu ejecutable de forma extraordinaria, por contra es muy fácil descomprimirlo: para Newbies recién comenzados en este Arte.

Intenté hacer una lista de packers, pero es tantísima la información y la gran cantidad de packers existentes, que me ha sido imposible continuar investigando uno por uno para poner enlaces de descarga o páginas web.
Así que he encontrado un enlace que seguro que os sorprende. Ojalá el enlace dure mucho tiempo:

You are not allowed to view links. Register or Login

Opinión personal:
karmany: personalmente siempre he estado en desacuerdo con aquellas personas que crackean programas y luego distribuyen el crack por la red. No entiendo esta finalidad.
Sin embargo, pienso que determinados programas ponen un precio bastante elevado, pero es tan amplio el mercado que a día de hoy casi cualquier programa que se necesite se puede encontrar gratuito por la red.

Pienso que no hay desperdiciar muchísimo tiempo en intentar proteger nuestra aplicación, porque solamente que haya un cracker de nivel medio-bajo con ganas de crackear lo conseguirá en poco tiempo, pero tampoco dejar que un Newbie recién iniciado sepa hacerlo.
También es cierto que el uso de packers hacen aumentar considerablemente la dificultad, pero como ya se comentó, hará aumentar también el precio de la aplicación. Sin embargo, packers difíciles han sido muy analizados, Armadillo es un claro ejemplo.

Por otro lado, también ocurre que si la protección es difícil, el cracker puede cansarse de analizarla y dejarla apartada. Lo digo por experiencia.
A fin de cuentas, es el programador el que tiene que pensar todo esto.

Finalmente creo que una de las cosas positivas que hacen los cracks es que la aplicación sea utilizada por mucha gente y así distribuida. Si un programa fuera incrackeable sólo lo utilizarían los usuarios registrados ya que mucha gente lo desecharía por sólo usarlo un determinado tiempo.

Un ejemplo que se me ocurre (subjetivamente) es el antivirus NOD32. Ha tenido desde hace un tiempo un éxito rotundo. Como hasta hace poco fue crackeado satisfactoriamente, pues habrá sido utilizado por millones de personas, sin embargo actualmente no permiten la descarga de actualizaciones mas que a usuarios realmente registrados, por este motivo estoy convencido que muchísimas personas dejarán de utilizarlo. Pero bueno...

Esto es ya otro tema...
Después de todo, espero que hayas obtenido información que no sabías y puedas decidir lo que quieres o no hacer.

Un saludo

Desconectado proton6

  • Si te metes con CPH
    te metes conmigo
  • ****
  • Mensajes: 2582
  • Sexo: Masculino
    • Ver Perfil
Re: Cómo proteger tu programa by karmany
« Respuesta #5 en: Agosto 09, 2008, 02:26:39 am »
Creado por You are not allowed to view links. Register or Login en You are not allowed to view links. Register or Login

Desconectado kamui23

  • Yo vivo en CPH
  • ***
  • Mensajes: 957
    • Ver Perfil
Re: Cómo proteger tu programa by karmany
« Respuesta #6 en: Agosto 28, 2008, 12:47:22 pm »
Coxonudo, proton6, coxonudo. Lo fijo:D
Busco una meta: conseguir lo que nadie ha conseguido. Y hacerlo en la mitad de tiempo.


No respondo preguntas por mensaje privado. para dudas, escribid en el foro, por favor.

Desconectado atomlux123

  • Me das tu IP?
  • *
  • Mensajes: 17
  • :)
    • Ver Perfil
Re: Cómo proteger tu programa by karmany
« Respuesta #7 en: Mayo 17, 2009, 12:31:29 pm »
muy buenooooo
Esta es mi firma :)
yo firmo asi,

:P

jaajja

Desconectado Xnet

  • Me das tu IP?
  • *
  • Mensajes: 13
  • Sexo: Masculino
    • Ver Perfil
Re: Cómo proteger tu programa by karmany
« Respuesta #8 en: Mayo 25, 2009, 07:29:21 am »
Muchas gracias me viene de gran utilidad!




Saludos a Todos! , Xnet!

Desconectado cibergolen

  • Incultura es ley
  • Moderador
  • *****
  • Mensajes: 1516
  • Danger: Mind OverFlow
    • Ver Perfil
    • OverSec.org, escrituras diarias
Re: Cómo proteger tu programa by karmany
« Respuesta #9 en: Agosto 01, 2009, 09:20:33 am »
Macho.... Eres un genio :toma:
Por navidad, vuelve a C.P.H[/size]
¿Aprender Ingeniería Inversa es complejo? Antes de preguntar...
You are not allowed to view links. Register or Login
You are not allowed to view links. Register or Login
You are not allowed to view links. Register or Login
You are not allowed to view links. Register or Login

You are not allowed to view links. Register or Login

You are not allowed to view links. Register or Login

Desconectado Borras

  • Me das tu IP?
  • *
  • Mensajes: 19
    • Ver Perfil
Re: Cómo proteger tu programa by karmany
« Respuesta #10 en: Agosto 03, 2009, 07:32:11 am »
esta cojonudo....mis felicitaciones!!!!!
Un enamorado de la informatica.

You are not allowed to view links. Register or Login

You are not allowed to view links. Register or Login

Desconectado Stryker

  • Me das tu IP?
  • *
  • Mensajes: 9
  • Sexo: Masculino
  • perfect shot!
    • Ver Perfil
Re: Cómo proteger tu programa by karmany
« Respuesta #11 en: Agosto 24, 2009, 08:31:15 pm »
Grande, bravo bravoooo... He estado buscando este tipo de info desde hace tiempo ya que me interesa mas la parte de seguridad del software que otra cosa... esta recojonudo tu post muy muy explicativo y entendible felicitaciones karmany de verdad... ya lo voy a agregar a mi plan de estudio personal!!!! gracias!
Mide dos veces, y dispara una!

Desconectado cemasmas

  • Usuario VIP y
  • Colaborador
  • ****
  • Mensajes: 2258
  • Sexo: Masculino
  • Mediador de CPH
    • Ver Perfil
Re: Cómo proteger tu programa by karmany
« Respuesta #12 en: Noviembre 27, 2009, 12:06:12 am »
Hola gracias proton6 y coincido 100 % con tus conclusiones personales.
Los mensajes privados no sé que son por eso no los respondo. Aprende Hacking You are not allowed to view links. Register or Login Lee una Noticia de la Red You are not allowed to view links. Register or Login y si no sabes donde pner tu post You are not allowed to view links. Register or Login

Desconectado juliojafeth2000_

  • Me das tu IP?
  • *
  • Mensajes: 98
  • Sexo: Masculino
  • Facility-War3z!
    • Ver Perfil
    • Pixicity
Re: Cómo proteger tu programa by karmany
« Respuesta #13 en: Enero 05, 2010, 06:30:56 pm »
Muchas Gracias!!... me sirvio bastante
Sitio Warez: You are not allowed to view links. Register or Login

Desconectado Alexey-Volkov

  • Me das tu password?
  • **
  • Mensajes: 335
  • Victoria, o muerte
    • Ver Perfil
Re: Cómo proteger tu programa by karmany
« Respuesta #14 en: Febrero 20, 2010, 03:10:14 am »
muxas fracias, pero respecto a lo del nod 32, tiene una gran debilidad, que es que compara al final 2 números, asiq solo t basta buscar en internete "seriales nod 32" y te saca 100 o 200
__..··~~""| Ante la ignorancia, imaginacion |""~~··..__

||"`--..__GOTO FOR EVER__..--´"||


question
¿Como proteger mi pc?

Iniciado por albertoceba

3 Respuestas
1655 Vistas
Último mensaje Junio 05, 2009, 04:16:22 pm
por Nicholas_gb
question
Cómo proteger mi ordenador?

Iniciado por marat

4 Respuestas
1522 Vistas
Último mensaje Octubre 03, 2007, 01:00:00 am
por tomas_conte06
xx
como proteger mi contraseña WEP?

Iniciado por djhendir

12 Respuestas
6898 Vistas
Último mensaje Mayo 16, 2007, 06:41:35 pm
por djhendir
xx
Como proteger los datos

Iniciado por PortalCiberGate

20 Respuestas
7365 Vistas
Último mensaje Junio 07, 2013, 08:43:48 pm
por OnTheCore
xx
Como proteger mi equipo?

Iniciado por MagicKreator

4 Respuestas
2283 Vistas
Último mensaje Agosto 15, 2009, 09:58:59 pm
por wanm28
xx
como puedo proteger

Iniciado por chochi22

6 Respuestas
2004 Vistas
Último mensaje Junio 03, 2009, 11:25:38 pm
por KapoElite
xx
Como proteger carpetas web con PHP

Iniciado por shevchenko

0 Respuestas
3044 Vistas
Último mensaje Agosto 01, 2008, 09:38:22 am
por shevchenko
question
Como proteger mi skype de los reslovers

Iniciado por LionSec

5 Respuestas
1670 Vistas
Último mensaje Diciembre 18, 2013, 02:24:05 pm
por LionSec
resuelto
[solucionado] ¿Como Proteger los Codigos de un BAT?

Iniciado por SpyX

37 Respuestas
17062 Vistas
Último mensaje Febrero 13, 2011, 11:58:04 am
por ryan parker
xx
¿como puedo proteger mi ordenador ?

Iniciado por javmax

1 Respuestas
4292 Vistas
Último mensaje Diciembre 12, 2011, 11:05:33 am
por .:KazEx:.