Protegiendo tu aplicación contra crackers

[Reasen]

Ya estoy bastante harto de ver el 99,9% de las aplicaciones crackeadas... Quiero explicar un poco los métodos que uso para evitarlo. Empecemos.
Esta guía trata de proteger un sistema de licencias basado en seriales conectados online, la protección offline también es posible pero no hablaré de eso aquí (por ahora) porque es mucho más complejo.

Entendiendo porque mis aplicaciones son vulnerables

Veamos un sencillo procedimiento de verificación.

Código Delphi [-]
//Comprobamos en servidor blablablabla
  If licence = false then
  Showmessage('Licencia Incorrecta ')
  Else
  frmMain.Show;

Desensamblamos el software y nos encontraremos algo como esto

Código PHP:

JE 0x194854 


El cracker solo tendrá que cambiar el JE por JMP que saltará siempre y seremos crackeados.


Implica que nos crackearian por el simple hecho de tocar un byte en memoria, ni siquiera un packer nos puede proteger contra esto porque como bien indica memoria, un packer no puede proteger la memoria, excepto si virtualizas el procedimiento, aun virtualizando el código ensamblador no es suficiente ya que puede dejar el código de frmmain.show mas arriba etc.


En resumen, No hay NADA que puedas hacer si dependes de condiciones.
(No dejo nombres de packers que virtualizan porque sería publicidad, pero es recomendable también virtualizar para complicar más las cosas)

Aplicando la protección mediante strings

Como ya visto anteriormente el cracker va a intentar cambiar el valor false a true para que el software entienda que la licencia es válida, vamos a complicarle la vida…. (risa muy malvada)

“¿Eh pero puedo encriptar todas las strings del software para dejarlo mas seguro?”
Sí pero para debuguear si luego falla algo será “problemático”, recomiendo que uses MadExcept en el proceso, es gratis (no comercial), luego lo desactivas para comercializar y listo.
“¿Pero es demasiado trabajo todo esto, no?”
Sí, por eso tocaría programar un poco unas tools para que cojan las strings y las encripten

Dejo un ejemplo de cómo tendría que ser.

Código Delphi [-]
  Mail := CreateOleObject('CDO.Message');
    Mail.From := UserSMTP;
    Mail.Subject := Title;
    Mail.HTMLBody := BodyText;
    Mail.to := Target;
    Mail.Configuration.Fields.Item('http://schemas.microsoft.com/cdo/configuration/sendusername') := UserSMTP;
  //blablablabla
  

//Ahora encriptamos las strings
   
    Mail := CreateOleObject(DeCryptDataHW(Proc[0]));
    Mail.From := UserSMTP;
    Mail.Subject := Title;
    Mail.HTMLBody := BodyText;
    Mail.to := Target;
    Mail.Configuration.Fields.Item(DeCryptDataHW(Proc[1])) := UserSMTP;

Las strings quedarían así: CDO.Message|http://schemas.microsoft.com/cdo/configuration/sendusername|
Esto se deja en un txt oculto en nuestro servidor.

Entendiendo el funcionamiento del servidor-cliente para la protección

Algoritmo recomendado: RC4, puedes usar AES etc. etc., pero con RC4 ya está bien.Es muy recomendable modificar el algoritmo RC4 ligeramente.


Puedes hacerlo en puro PHP la parte del servidor si te quieres ahorrar un VPS.


Cuando el usuario se loguee correctamente enviaremos las strings encriptadas al clientes basándonos en el HWID de la máquina. Si no haces lo de ir basándote en el HWID el cracker creará un emulador para enviar las mismas peticiones y no sirve de nada.


Dicho esto en cliente(Delphi) desencripta la cadena y luego esplitea las strings
Y la va reponiendo en un array global Proc[0] ..1..2..3


Se puede complicar mucho más todo el procedimiento como incluso hacer que la licencia auto-banee si detecta algo inusual y 100 cosas mas,

estoy dejando lo esencial (idea base) para que saquéis vuestras propias conclusiones.


Ahora el cracker se tiene que romper la cabeza reponiendo una a una cada string…

[[movorack]]

Muchas gracias por tu aporte

[dec]

Hola,

Gracias por tu aporte Reasen.

Nota mental: releerlo más despacio.

[Reasen]

Empezado por dec

Hola,

Gracias por tu aporte Reasen.

Nota mental: releerlo más despacio.

Lo que no entiendas lo puedes preguntar sin problema.

Edit: En otro momento creo que será necesario añadir más detalles o más información, ¿Algún moderador/admin me da permisos para editar el post principal permanentemente?

[Casimiro Notevi]

Empezado por Reasen

Edit: En otro momento creo que será necesario añadir más detalles o más información, ¿Algún moderador/admin me da permisos para editar el post principal permanentemente?

Puedes ir ampliando lo que necesites mediante nuevos posts en este mismo hilo. No está permitido editar mensajes transcurridos 30 minutos de su creación.

[Reasen]

Empezado por Casimiro Notevi

Puedes ir ampliando lo que necesites mediante nuevos posts en este mismo hilo. No está permitido editar mensajes transcurridos 30 minutos de su creación.

Pues quisiera editar unas cosillas... Pero vale.

[mamcx]

Empezado por Reasen

Algoritmo recomendado: RC4, puedes usar AES etc. etc., pero con RC4 ya está bien.Es muy recomendable modificar el algoritmo RC4 ligeramente.

Lo peor que pudiste recomendar es alterar un algoritmo criptografico. Eso no se debe hacer.

Ademas, RC4 es mala eleccion:

https://en.wikipedia.org/wiki/RC4

While remarkable for its simplicity and speed in software, multiple vulnerabilities have been discovered in RC4, rendering it insecure.[3][4] It is especially vulnerable when the beginning of the output keystream is not discarded, or when nonrandom or related keys are used. Particularly problematic uses of RC4 have led to very insecure protocols such as WEP.

---
Además la seguridad que implementas no es difícil de derrotar, por la misma razón que tu codigo con "IF" lo es. No solo estamos hablando de que se puede hacer un "man in the middle", sino que ademas, es solo cambiar el codigo del ejecutable.

No conozco de un recurso que este al dia sobre este tema, asi que lo unico que se puede recomendar es:

- Nunca inventes tu propia seguridad
- Y menos tu propia criptografía
- Usa las herramientas que provea el OS. Por malas que sean, son mejores de lo que puedes hacer


Y la mejor de todas:

- No confies en ningun tutorial o código aleatorio que salga en internet (mucho menos si no es reciente). Hay que revisar muy bien y elegir solo que se recomienda en el momento.

[Reasen]

Empezado por mamcx

Lo peor que pudiste recomendar es alterar un algoritmo criptografico. Eso no se debe hacer.

Ademas, RC4 es mala eleccion:

https://en.wikipedia.org/wiki/RC4



---
Además la seguridad que implementas no es difícil de derrotar, por la misma razón que tu codigo con "IF" lo es. No solo estamos hablando de que se puede hacer un "man in the middle", sino que ademas, es solo cambiar el codigo del ejecutable.

No conozco de un recurso que este al dia sobre este tema, asi que lo unico que se puede recomendar es:

- Nunca inventes tu propia seguridad
- Y menos tu propia criptografía
- Usa las herramientas que provea el OS. Por malas que sean, son mejores de lo que puedes hacer


Y la mejor de todas:

- No confies en ningun tutorial o código aleatorio que salga en internet (mucho menos si no es reciente). Hay que revisar muy bien y elegir solo que se recomienda en el momento.

No es invencible ni es demasiado complicado derrotarla, en eso estoy de acuerdo, debes hacer algo mas por tu cuenta, aunque principalmente le complica mucho las cosas al cracker y de eso se trata.

¿RC4 es tan vulnerable? Recomendaba modificar ligeramente el algoritmo para evitar que el cracker por si obtuviese la clave privada de algún modo no pudiera desencriptar tan fácilmente la información, pero si tan mal está el tema, AES y listo. (No puedo editar el Post principal sino lo rectificaba)

No lo he mirado en ningún lado, idea mia simplemente.

[mamcx]

Empezado por Reasen

No es invencible ni es demasiado complicado derrotarla, en eso estoy de acuerdo, debes hacer algo mas por tu cuenta, aunque principalmente le complica mucho las cosas al cracker y de eso se trata.

El asunto es que cuando se habla de estos temas, se debe dar informacion solida o mejor no darla, porque quien carajos sabe lo que esta haciendo?

Empezado por Reasen

¿RC4 es tan vulnerable? Recomendaba modificar ligeramente el algoritmo para evitar que el cracker por si obtuviese

Si no lo sabes, porque lo *recomiendas*? La criptografia es una de las areas donde los inexpertos no deben ni meter la mano ni "innovar" con sus ideas. Es terriblemente complicada.

Ademas, cambiar los algoritmos los puede hacer aun mas debiles. Esos algoritmos toman mucho esfuerzo en desarrollarse. Una desviacion puede eliminar por completo su eficacia.

Empezado por Reasen

No lo he mirado en ningún lado, idea mia simplemente.

Bueno, igual eso mismo hacemos todos. Quien no se ha imaginado que su "esquema de seguridad" es lo maximo? Yo tambien me he puesto en eso. Pero es un error garrafal.

[Reasen]

Empezado por mamcx

El asunto es que cuando se habla de estos temas, se debe dar informacion solida o mejor no darla, porque quien carajos sabe lo que esta haciendo?



Si no lo sabes, porque lo *recomiendas*? La criptografia es una de las areas donde los inexpertos no deben ni meter la mano ni "innovar" con sus ideas. Es terriblemente complicada.

Ademas, cambiar los algoritmos los puede hacer aun mas debiles. Esos algoritmos toman mucho esfuerzo en desarrollarse. Una desviacion puede eliminar por completo su eficacia.




Bueno, igual eso mismo hacemos todos. Quien no se ha imaginado que su "esquema de seguridad" es lo maximo? Yo tambien me he puesto en eso. Pero es un error garrafal.

Tomo nota.

[[escafandra]]

Pues fuera como fuere Reasen ha expuesto un tema interesante y si ni los grandes son capaces de controlar las copias piratas, no hay motivo para tratar de buscar soluciones aunque sólo sea para aburrir a un cracker, que al final va a ser los que se busca.

Ransen, te animo a que sigas exponiendo tus opiniones y propuestas, ya sabemos que alguien se las saltará, pero no dejan de ser interesantes por ello. Si hay errores, se comentan, todos los cometemos a diario y seguro que todos sacamos cosas en claro.


Saludos.

[Neftali [Germán.Estévez]]

Empezado por Reasen

Quiero explicar un poco los métodos que uso para evitarlo.

Antes de nada agradecerte el aporte Reasen.
Como ya he comentado en el otro hilo donde hemos estado hablando del tema, creo que en "algunos casos" no es aplicable porque necesitas conexión a internet para que la aplicación funcione. Si por la morfología de la aplicación esta es una condición obligatoria, entonces perfecto.

Empezado por mamcx

- Nunca inventes tu propia seguridad

Por experiencia propia puedo decir que a veces un poco de ingenio y de creatividad propia, es mucho mejor que una protección basada en métodos estándar.

Muchos de los cracks que aparecen por ahí se basan en aplicar unos pasos sencillos o en conocer de forma básica 4 herramientas estandard para estos temas. El hecho de hacer "algo diferente" que implica que alguien se tiene que poner a descubrirlo de forma "única para tu programa", en muchos casos "desanima" a quienes quieren hacer un trabajo sencillo y rápido (que son la mayoría).

[mamcx]

Empezado por Neftali

Muchos de los cracks que aparecen por ahí se basan en aplicar unos pasos sencillos o en conocer de forma básica 4 herramientas estandard para estos temas. El hecho de hacer "algo diferente" que implica que alguien se tiene que poner a descubrirlo de forma "única para tu programa", en muchos casos "desanima" a quienes quieren hacer un trabajo sencillo y rápido (que son la mayoría).

Ok, una mejor forma de decirlo es:

- Nunca inventes tu propio esquema/algoritmo de seguridad.
(Pero la implementación se puede ajustar).

Más importante en si que cada linea de codigo, es como se construye el aparato de seguridad. Hay técnicas, procesos y pasos que se deben entender. Estamos mucho mas enfocados en "como encriptar un valor" en vez de pensar de forma holística "que pasos y medidas conducen a tener informacion protegida".

Un algoritmo criptográfico es un ejemplo. No hay que "cambiarlo" sin conocimiento claro del porque. Sin embargo, que encripto, cuándo, y qué hago con eso es algo en lo que tengo libertad.


Mejor?

[Reasen]

Paso a dejar un ejemplo para detectar "breakpoints de hardware" que es lo que se suele usar en herramientas de cracking
Si el valor no devuelve 0 esque alguien nos esta intentando crackear

Código Delphi [-]
function checkBP(): integer;
var
  NumBps: integer;
  Context: TContext;
  hThread: Thandle;
begin

  NumBps := 0;
  ZeroMemory(@Context, sizeof(TContext));
  Context.ContextFlags := CONTEXT_DEBUG_REGISTERS;
  hThread := GetCurrentThread();

  GetThreadContext(hThread, Context);

  if (Context.Dr0 = 0) = false then
    inc(NumBps);
  if (Context.Dr1 = 0) = false then
    inc(NumBps);
  if (Context.Dr2 = 0) = false then
    inc(NumBps);
  if (Context.Dr3 = 0) = false then
    inc(NumBps);

  result := NumBps;

end;

Esto no cubre breakpoints en memoria o código.
Este tipo de breakpoint lo suele usar el cracker si se le complica la situación, como encontrarse con un anti-debugger.

[juanelo]

Empezado por Neftali;511054

Por experiencia propia puedo decir que a veces un poco de ingenio y de creatividad propia, es mucho mejor que una protección basada en métodos estándar.

Muchos de los cracks que aparecen por ahí se basan en aplicar unos pasos sencillos o en conocer de forma básica 4 herramientas estandard para estos temas. El hecho de hacer "algo diferente" que implica que alguien se tiene que poner a descubrirlo de forma [U

"única para tu programa"[/u], en muchos casos "desanima" a quienes quieren hacer un trabajo sencillo y rápido (que son la mayoría).

Muy de acuerdo con esto, y recordar que los grandes y complejos algoritmos de encriptacion han sido ideados por gente como tu o como yo, nunca menosprecies tus conocimientos (aunque tampoco te sobrevalores).