Protegiendo tu aplicación contra crackers

[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.

[mamcx]

Claro, no hay problema con ir exponiendo lo que se sabe. Este es un tema que tiene una representación muy baja entre los desarrolladores y honestamente se requiere mejorar en esto.

Es solo que hay que informarse bien y pisar de a poco.

----

Un area relativamente facil para explorar y que un lenguaje tipado como Delphi trae ventaja es el area reducir las inyecciones de datos. Como en el caso del SQL INJECTION.

Y lo bueno es que es una de las vulnerabilidades mas comunes:

https://www.owasp.org/index.php/Top_10_2013-Top_10
https://www.toptal.com/security/10-m...ulnerabilities

(Estas estan mas enfocados a la web, pero tiene principios generales).


---

El punto clave es que todos las entradas debe validarse y/o convertirse a una estructura de datos mas rigida, en especial si viene de un tipo abierto como una cadena.

[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).