Cita:
|
Empezado por dec
Una de ellas comprueba que el número de serie proporcionado por el usuario resulta válido para la clave de usuario que también se especifique. Esta función no me parece tan crítica como la siguiente: la función que se encarga de obtener un número de serie válido realmente para el usuario, precisamente, para compararlo con el que el usuario proporciona.
|
Bueno, no es mi intención "desmontar" la teoría inicial, pero aquí el fallo está en el planteamiento.
De todas formas el problema de la memoria RAM es interesante también.
Aunque cada uno programa los sistema de registro como desea, normalmente los programas no suelen utilizar el sistema mencionado, porque es muy sencillo detectar el número correcto utilizando un Debugger. No hace falta "rebuscar" en la memoria RAM, basta con ejecutarlas instrucciones del programa y revisando los registros y la pila.
Por ejemplo, "debuggando"(¡qué mal suean esto!) el programa mencionado por dec, con OllyDBG podemos llegar fácilmente (y eso que yo no soy experto en estos temas, pero con un par de minutos me ha bastado...) a este punto:
imagen
En la parte izquierda se ven las instrucciones y en la derecha la pila y los registros.
Normalmente en estos casos (crackendo un programa, cosa que yo nunca he hecho...
) se busca un punto de partida (1); Si este es acertado, a partir de ahí se ejecutan las instrucciones hasta llegar a los procedimientos donde se evalua y calcula el número de serie.
(1) Para comenzar se buscan los formularios de Registro, prodecimientos con nombres sospechosos (TestID, Register, RegisterOK,...), Strings "sospechosos" como "El número de registro es incorrecto", "El número de serie no es válido",...
¿Por qué comento esto? Porque sabiéndolo, alguien que diseñe un sistema de protección debe tener en cuenta:
(a) Los procedimientos que tienen que ver con el registro y números de serie nunca deben llamarse: Registro, CalcularSN, TestRegistro,... ni cualquier otro nombre que de pistas sobre olo que están haciendo.
(b) Los mensajes de error relativos al registro deben estar codificados y nunca directamente en el código; La codificación no importa, basta un XOR, o cambiar una letra por otra, lo importante es que si revisas la memoria no aparezcan directamente.
(c) Algunas cosillas más....
Si "cuesta" encontrar en punto de entrada para comenzar a "debuggar" las cosas se hacen un poco más complicadas.
En cuanto al número de registro o números de serie, la premisa es que en ningun momento el número de serie debe estar completo en memoria. En una variable o en una cadena ni debe ser devuelto por una función.
Lo lógico es hacerlo "a partes" y una vez particionado no hacer comparaciones directas.
Un ejemplo sencillo es no hacer esto:
Código Delphi
[-]
if (SN = '1234') then
...
Y en su lugar hacer esto:
Código Delphi
[-]
j := Ord('Q') - Ord('N');
if (SN[1] = '1') and (SN[2] = (4 DIV 2)) and (SN[3] = j) and ... then
...
Comparar las partes desordenadas,....
Hay infinidad de técnicas, que van complicando el tema más... Pero algunas son básicas como las comentadas antes.
Sobre todo ¡Nunca debe estar el SN correcto almacenado de forma contigua en memoria!
Porque si no pasan
cosas como esta. LLegado al punto de la comparación te puedes encontrar el nombre del registro, el SN incorrecto y el SN correcto con el que se está comparando...
AÑADO: En esta última imagen tampoco es muy afortunado el nombre del procedimiento
ChessRk (contando que el programa se llama Chess); ¿Qué os sugiere ChessRk, sabiendo que el programa está en inglés?
