Eliminar ciertos datos de la memoria RAM

[dec]

Hola,

Gracias a todos, de verdad. Estaba a punto de escribir esto porque me parecía haber encontrado una posible solución, pero, me quedo corto al lado vuestro.

Como dices Seoane el problema está en manipular variables en la función "Resultado". Si no lo hacemos, es decir, si "calculamos" el resultado ya dentro de la función "StrLCopy" entonces desaparece el problema. Es decir, que puedo decir que el problema está resuelto gracias a vosotros. Acabo de comprobarlo y volverlo a comprobar.

Dices Seoane que dejar el Serial como constante no es buena idea... pero no se hace así. Lo que se tiene como constante es un número "base". Con este número base y la clave del usuario se genera un "Serial", pero esto se hace con cierto algoritmo (luego más sobre esto) que no puede conocerse así como así.

Ahora bien. Parece (y digo parece porque he hecho pruebas pero tengo que hacer alguna más aún) que conseguimos hacer desaparecer el "Serial" correcto de la memoria RAM. Ahora lo que me deja perplejo es el tema de la pila... ¿ya no basta con la memoria RAM? ¿Acaso puede buscarse el "Serial" en la pila incluso cuando digo que ya no aparece en la memoria RAM?

Definitivamente me queda mucho más por aprender de lo que aprenderé nunca.

Para quien esté interesado, estoy utilizando una clase para todo esto que está basada en el componente "JvSerialMaker" de la Jedi Library. Evidentemente ya sabéis que este componente "deja" en la memoria RAM el número de serie que genera y puede comprobar...

En fin voy a asegurarme con más pruebas de que el número de serie no aparece en la memoria RAM y luego acaso me ponga con el tema de la pila que apunta el compañero basti (gracias basti). Pero estoy de acuerdo con Seoane... probablemente estas cosas habría que tomarlas bastante más en serio de lo que estoy dispuesto a hacer para evitar que alguien "piratee" un programa como se empeñe en hacerlo...

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

Veo que habéis avanzado en el tema mientras yo escribía, o mejor dicho, me enrollaba...

Empezado por dec

Ahora lo que me deja perplejo es el tema de la pila... ¿ya no basta con la memoria RAM? ¿Acaso puede buscarse el "Serial" en la pila incluso cuando digo que ya no aparece en la memoria RAM?

Como he comentado más arriba, no debería estar ni en la pila ni en los registros; Y eso significa que no se puede asignar a una variable, que no se puede pasar como parámetro y no debe ser devuelto por ninguna función (hablamos del serial correcto completo).

[dec]

Hola,

Muchas gracias Neftalí. Gracias a todos.

Yo me doy cuenta de lo poco que sé de todo esto... ¡me pierdo enseguida! Y como me pierda no me encuentro. ¡¿Pues no resulta ahora que tras haber comprobado con estos ojos que se han de comer la tierra, me pongo a implementar el asunto en el programa de marras y todo sigue igual?!

Igual. El número de serie correcto aparece en memoria. Pero ahora el número no está en ninguna variable como antes. Yo no sé si estoy comprendiendo lo que hablamos, porque, ahora mismo el número de serie "se calcula" dentro de la propia función "StrLCopy"...

Es decir, que pasa a la variable "destino" de la función "StrLCopy", directamente, variable que luego es destruída tal como Seoane ha explicado...

No sé. ¿Acaso me queda entonces por hacer lo que apunta el compañero basti? ¿No basta entonces con liberar dicha variable (única que llega a contener el número de serie correcto)?

No sé... voy a probar a ver...

Y en todo caso pelear con lo que menciona Neftalí: pero me temo que voy a dar unos cuantos palos de ciego... ¡Ay!

[dec]

Hola,

Yo de nuevo.

Oyes Neftalí... ¿sabes que lo de comprobar el número de serie por partes puede acaso ser una solución? Pero no se me ocurre cómo... de momento... y puede que nunca.

El caso es que, efectivamente, ni siquiera quitando del medio la función "Resultado", es decir, comparando el número de serie del usuario con la cadena resultante del cálculo del número de serie... es decir, comparando una variable con "un valor" (no una variable) que se conforma en el momento... aun así el número de serie, o sea el "valor" queda en la memoria...

Así que como no sea partiendo el número de serie, de modo que quede... pero irreconocible, pudiera ser una buena opción. Ahora toca averiguar cómo demonios hago esto, porque no se me ocurre... no sé...

[dec]

Hola,

Joroba... ahora me doy cuenta de que no he terminado de probar el asunto del modo que lo planteaba el compañero basti, es decir, lo hize como Seoane explicó, pero, no llegué a "actualizar" a lo que basti comentaba... y ahora no sé si hacerlo, puesto, que, llegando a estar el número de serie correcto en memoria incluso aunque no esté en una variable... ¿no invalida esto el método propuesto por el compañero basti?

Quiero decir, si tras intentar del mejor modo que he sabido lo que propone Seoane llego a la conclusión de que, efectivamente, el número de serie sigue permaneciendo en memoria (si estoy metiendo la pata me corregís por favor), puesto que en algún punto del programa ha de componerse para poderlo comparar con el que propone el usuario...

Parece que de todas formas la posible solución pasa (sin ir más allá...) por lo que dice Neftalí (¿o me equivoco?), es decir, no llegar nunca a formar el número de serie completo, sino hacerlo por partes... para que aunque aparezcan estas partes sea complicado reunirlas a todas y conocer así el número de serie.

Ahora bien, quedaría entonces cómo comparar el serial del usuario (por partes) con el serial correcto que hemos de generar (también por partes...)...

¡jo, jo, jo, jo!

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

Empezado por dec

Ahora bien, quedaría entonces cómo comparar el serial del usuario (por partes) con el serial correcto que hemos de generar (también por partes...)

Bueno, como he dicho, esta es una de las primeras cosas a hacer y que evita encontra el serial de forma trivial.

Lo siguiente es evitar comparaciones directas; Simplemente, porque no siempre se necesita encontrar el Serial, a veces basta con "Parchear".

Es decir, si yo no encuentro el Serial, pero veo tres comparaciones que dicen:

Código Delphi [-]
if A!='aasd' then ...
if B!='khgk' then ...
if C!='grfeu' then ...

En este caso optaría por "parchear" los tres != por tres =.

Ya se que el tema se va complicando, pero son cosas que hay que tener en cuenta; La mayoría de sistemas anticopia (serios) ya hechos tienen en cuenta estas cosas y muchas más...
En ese caso a la hora de comparar dos valores, podemos utilizar por ejemplo la resta para saber si da cero, funciones del tipo CHAR y Ord (aplicándolas a los dos) para no comparar los valores exactos, sumar y restar a ambos un valor,...
Aunque desde delphi parece una tontería hacer esto:

Código Delphi [-]
// en lugar de...
if ('A' = Str[1]) then
// usar...
if (char('A') = Char(Str[1])) then

Para el que está revisando el código en ensamblador supone uno o varios saltos, cosa que dificulta mucho a la hora de seguir el código (las llamadas a funciones); Pensad que si se van aplicando diferentes a cada comparación, al final la cosa se hace muy compleja para el que está revisando la pila y los registros.

[[ArdiIIa]]

Empezado por Neftali

Para el que está revisando el código en ensamblador supone uno o varios saltos, cosa que dificulta mucho a la hora de seguir el código (las llamadas a funciones); Pensad que si se van aplicando diferentes a cada comparación, al final la cosa se hace muy compleja para el que está revisando la pila y los registros.

Comenzó el hilo buscando y encontrando una cadena en memória y finalmente acabamos hablando de ingeniería inversa.
Llegados a este punto, creo que el menor de los problemas sería el como ocultar la forma y el modo de como cotejar una clave, dado que llegados a ese nivel y si resulta de interés, el invasor no se iba a preocupar de la clave, sino que se preocuparía de ver cual es el procedimiento que le hace salir del programa (por ejemplo) y que otras alternativas o saltos de programa tiene para que este funcione adecuadamente, para a continuación parchear y a disfrutar.... Creo yo...

[[seoane]]

Y si cambias el planteamiento. Hasta ahora estas comprobando lo que inserta el usuario, tal cual, con un numero "generado". Pues bien yo te propongo lo siguiente: tomar el valor que introduce el usuario y calcular su hash (md5 por ejemplo), entonces comparamos su hash con el que tenemos guardado, en una constante porque no nos importa que lo vean en la RAM. Y no nos importa porque aunque alguien conozca el hash nadie puede saber que numero tiene que introducir para obtener ese hash. Sencillo y efectivo, esta es la magia del Hash

[[seoane]]

Y para continuar mi mensaje anterior un poco de código:

Código Delphi [-]
uses Hashes;

function Comprobar(Str: String): Boolean;
begin
  Result:= AnsiSameText(StrCheckSum(Str),'e885d567f57b0f87333c25f7f3a1e381');
end;

// Por ejemplo
ShowMessage(BoolToStr(Comprobar(Edit1.text),TRUE)); // Pepe es la clave

La clave correcta en este caso es "Pepe" pero como ves no aparece por ninguna parte, ni en el código, ni en memoria, ni en ningún sitio. Solo aparece su hash, pero a partir de su hash no podemos obtener la clave.

PD: La unit hashes se puede encontrar aquí
http://www.clubdelphi.com/foros/show...22&postcount=4

[[ArdiIIa]]

Seoane, como siempre, es brillante la visión de la jugada que aportas....

He estado leyendo el hilo y no me ha dejado hacer la digestión en condiciones.

Estuve pensando sobre el tema en un planteamiento relativamente parecido.

La idea en sí, es tener un valor previo codificado... Por el sistema que fuera. En este caso mis pocas neuronas pensaron en un algoritmo de movimientos o/y complementos de bits hasta hallar una serie mas o menos complicada, y con la clave introducida, realizar el mismo movimiento y posterior comparación. En definitiva, la codificación por el método que sea. Obviamente la serie codificada e885d567f57b0f87333c25f7f3a1e381 tendría que ser previamente tratada antes de ser introducida en el propio código del programa.
Creo que mas o menos el planteamiento tuyo pero obviamente mas sencillo y versátil.

Hace años y basándome en esto mismo que digo, hice un pequeño código en ensamblador, pero realmente esta codificación afectaba al propio código del programa, de tal manera que dejaba dentro de la rutina espacios de memoria a cero (NOP), la rutina se auto-descodificaba y se movía a esa porción de memória para seguidamente dar un salto al nuevo código...