Juego (buscar Clave)
#41
Escrito 22 febrero 2010 - 10:04
Maestro seoane, que maravilla. Haz alimentado mi curiosidad, no tendras algun documento que explique ensamblador para casi mortales.
creo que voy a intentarlo para satisfacer mi curiosidad jejejejeje
Saludos
Kafastoforman
#43
Escrito 11 julio 2013 - 04:58
Aunque ya hace tiempo de este tema, justo ayer lo conocí.
Lo hemos comentado aquí y se ha solucionado muy didácticamente
Muy bien documentada la solución de neftali.
Aunque viene siendo la misma que ya dimos aquí en su día, la nuestra con menos fotos y explicaciones, pero con algo mas de código
#44
Escrito 11 julio 2013 - 07:52
Una explicación excelente del nuestro amigo Germán (neftalí) y un excelente código de nuestro amigo Domingo (seoane), así hasta se le quitan las ganas a uno de proteger sus desarrollos.
....... Sana envidia Domingo, sana envidia.
¡Ya quisiera tener la mitad de tu cerebro!......
jajajaja, me vino a la mente Hannibal
Saludos
#45
Escrito 11 julio 2013 - 08:09
Que bien,
Una explicación excelente del nuestro amigo Germán (neftalí) y un excelente código de nuestro amigo Domingo (seoane), así hasta se le quitan las ganas a uno de proteger sus desarrollos.
....... Sana envidia Domingo, sana envidia.
¡Ya quisiera tener la mitad de tu cerebro!......
jajajaja, me vino a la mente Hannibal
Saludos
¿Será que no has desayunado brother?
#46
Escrito 11 julio 2013 - 08:24
¿Será que no has desayunado brother?
Ya desayuné bro, pero pues me recordó la serie de hannibal.
Saludos
#47
Escrito 12 julio 2013 - 01:14
-Desensamblar el exe y tratar de entenderlo, las claves podrían no estar presentes como constantes (eso espero, sería muy fácil) sino ser generadas con un algoritmo (digamos la vlave es el log(i) con i 1, 2 o 3 formateado el resultaod a 3 decimales). Se necesitaría localizar ese generador.
-Usar un gestor de memoria que pueda volvarme toda la memoria usada por el exe mientras se ejecuta. Se toman dos "fotos" una en el primer intento y otra en el segundo, y se comparan, entre las diferencias estará la clave, o si se genera en tiempo de comparación, aparecerá solo en un instante -coo varialbe temporal- y necesitaremos estudiar ese instante preciso -tras pulsar el intro que es cuando se lanza la comrobación.
Es muy avanzado para mis conocimientos de ensamblador y de hackear el sistema de alloc de memoria, seguro que escafandra estaría ya ideando como hacerlo!
#48
Escrito 12 julio 2013 - 01:43
Me pregunto yo ¿entonces como le hacemos para determinar si hacemos una cosa u otra sin hacer uso de un IF? ¿Que otra opción tenemos?
Porque hasta donde llega mi capacidad de inventiva, me digo que la única posibilidad que veo posible es la utilizar ofuscación de código y llenar de varias sentencias dummys por aquí y allá... esconder al if dentro de cientos de ellos y/o de no hacer una comprobación total y tan directa sino a por partes. Es decir en lugar de hacer:
if ClaveEntradaCifrada = ClaveEsperadaCifrada then Habilitar;
Entonces hacer esto:
Part1 = Trocear1(ClaveEntradaCifrada); // algo más en el medio para despistar... Part2 = Trocear2(ClaveEntradaCifrada); // PartN = TrocearN(ClaveEntradaCifrada); Habilitar(Part1, ... PartN);
Y ahora si en Habilitar se debería de llevar a cabo una operación a fin de determinar la consistencia entre dichas partes a fin de que luego se proceda (o no) con la habilitación definitiva.
La otra posibilidad, a modo de complementar con todo esto, y que no utiliza un IF (al menos de forma directa) es que se proceda a habilitar el acceso o uso de algo como resultado de una operación directa. Un ejemplo burdo y simple:
BotonAceptar.Enabled := Boolean(Habilitar(Part1, ..., PartN));
Y de este modo Habilitar devuelva un valor 0 o 1 para el caso.
En lugar de un
if Resultado then ...
Así en vista a todo esto me pregunto, al día de hoy. ¿De que otra forma podemos evitar un IF?
Saludos,
#49
Escrito 12 julio 2013 - 03:05
El cracker (que no, hacker) no encuentra ningún 'if' ni nada que le dé pistas. Tendrá que ejecutar todas y cada una de las opciones del programa para encontrar dónde se comprueba la clave y cómo.
No es ninguna maravilla, pero pone algo más complicado el trabajo.
#50
Escrito 16 julio 2013 - 04:39
Ya que estamos reviviendo al hilo, me quedé pensando sobre algo que el gran maestro nos dijo: no se debe utilizar IF para determinar si se ha validado.
Me pregunto yo ¿entonces como le hacemos para determinar si hacemos una cosa u otra sin hacer uso de un IF? ¿Que otra opción tenemos?
Porque hasta donde llega mi capacidad de inventiva, me digo que la única posibilidad que veo posible es la utilizar ofuscación de código y llenar de varias sentencias dummys por aquí y allá... esconder al if dentro de cientos de ellos y/o de no hacer una comprobación total y tan directa sino a por partes. Es decir en lugar de hacer:
delphi
if ClaveEntradaCifrada = ClaveEsperadaCifrada then Habilitar;
Entonces hacer esto:
delphi
Part1 = Trocear1(ClaveEntradaCifrada); // algo más en el medio para despistar... Part2 = Trocear2(ClaveEntradaCifrada); // PartN = TrocearN(ClaveEntradaCifrada); Habilitar(Part1, ... PartN);
Y ahora si en Habilitar se debería de llevar a cabo una operación a fin de determinar la consistencia entre dichas partes a fin de que luego se proceda (o no) con la habilitación definitiva.
La otra posibilidad, a modo de complementar con todo esto, y que no utiliza un IF (al menos de forma directa) es que se proceda a habilitar el acceso o uso de algo como resultado de una operación directa. Un ejemplo burdo y simple:
delphi
BotonAceptar.Enabled := Boolean(Habilitar(Part1, ..., PartN));
Y de este modo Habilitar devuelva un valor 0 o 1 para el caso.
En lugar de un
delphi
if Resultado then ...
Así en vista a todo esto me pregunto, al día de hoy. ¿De que otra forma podemos evitar un IF?
Saludos,
hola amigos, ¿y que pasaria si usamos un "CASE" para hacer las validaciones en ves de un if?, ¿al verlo en el debuger sera facil de cambiar la condicion como se ha hecho con el if?
#51
Escrito 16 julio 2013 - 08:55
Ummm. No lo he probado, sería interesante de ver que sucede en realidad dentro un Case. Aunque algo me dice que si se diseña el case con la cláusula opcional else muy seguramente eso se termine traduciendo en una instrucción del tipo salto (y sea cual fuese) bastaría con alterar en esta parte por el tipo de salto contrario para quebrar el algoritmo.hola amigos, ¿y que pasaria si usamos un "CASE" para hacer las validaciones en ves de un if?, ¿al verlo en el debuger sera facil de cambiar la condicion como se ha hecho con el if?
Saludos,
#52
Escrito 17 julio 2013 - 01:26
Ummm. No lo he probado, sería interesante de ver que sucede en realidad dentro un Case. Aunque algo me dice que si se diseña el case con la cláusula opcional else muy seguramente eso se termine traduciendo en una instrucción del tipo salto (y sea cual fuese) bastaría con alterar en esta parte por el tipo de salto contrario para quebrar el algoritmo.
hola amigos, ¿y que pasaria si usamos un "CASE" para hacer las validaciones en ves de un if?, ¿al verlo en el debuger sera facil de cambiar la condicion como se ha hecho con el if?
Saludos,
Habria que ver si algunos de los maestros tiene tiempo para ver este caso
Saludos!