Eliminar ciertos datos de la memoria RAM

[[basti]]

Hola, he visto este hilo y me parece interesante. Creo que tanto 'Pepe' como la fecha pueden aparecer en el volcado de memoria del programa de Seoane por dos razones, espero no equivocarme.

'Pepe' está escrito de manera estática en la función Resultado, por lo tanto no hay manera de quitarlo de la memoria. Esto no sería un problema para tu aplicación, ya que la clave del cliente no estaría escrita en el código de la aplicación.

El otro problema que veo es la pila del programa, cuando se hace la siguiente llamada:

Código Delphi [-]
  StrLCopy(Str,PChar('Pepe'+DateToStr(Time)),L);

El valor 'Pepe'+DateToStr(Time) se copia en la pila de llamadas de la aplicación, y permanecerá ahi hasta que otras llamadas sobreescriban estos datos en la pila.

Puedes comprobarlo de la manera siguiente:
En el código de Seoane haces una implementación de StrLCopy, algo así

Código Delphi [-]
Procedure StrLcopy(dest, org : PChar; len : Integer);
begin
  while org^ <> #0 do
  begin
    dest^ := org^;
    Inc(dest);
    Inc(org);
  end;
  dest^ := #0;
end;

de manera que uses esta función en vez de la original de delphi. Pones un punto de ruptura dentro de la función, vas a la ventana "Call Stack". Ahí verás el valor tanto de 'Pepe' como la fecha.

La solución, creo que podría ser una llamada a una función recursiva, justo después de la llamada a StrLCopy, para que sobreescriba la pila. La función debe ser llamada las veces que hagan falta para borrar los datos de la pila. Algo así:

Código Delphi [-]
procedure Resultado(Str: PChar; L: Integer);
  procedure VamosAContarAlReves(n : integer);
  begin
    if n > 0 then
      VamosAContalAlReves(n - 1);
  end;
begin
  // Pues yo si que uso DateToStr ¿que pasa?
  StrLCopy(Str,PChar('Pepe'+DateToStr(Time)),L);
  VamosAContarAlReves(100);
end;

[[seoane]]

Ingenioso método de borrar la pila Basti

Entonces ya tenemos los 3 pasos: no usar constantes, borrar las variables y borrar la pila.

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

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