Le agregarias un toque mas interesante si no hubieras usado StrCmp.
Se podria haber hecho una rutina subliminal con nexo propio
Se podria haber hecho una rutina subliminal con nexo propio
- Bienvenido a Test Foro de elhacker.net SMF 2.1.
Esta sección te permite ver todos los mensajes escritos por este usuario. Ten en cuenta que sólo puedes ver los mensajes escritos en zonas a las que tienes acceso en este momento.
#512
Ingeniería Inversa / Re: Descompiladores de aplicaciones..
8 Octubre 2011, 22:16 PM
En esta página hay un excelente decompilador de javascript
JavaScrDecompiler
JavaScrDecompiler
#513
Ingeniería Inversa / Tips para dificultar el crackeo de un programa
8 Octubre 2011, 15:53 PM
Aqui un par de tips que pude recompilar y tambien de mi propia experiencia.:
1>Evita los mensajes como "Te tengo lamer... jajaja, estas re mal"
2>Intenta usar encriptacion asimetrica
3>Nunca uses archivos con significado como licencia.dat
4>No alertes que la clave es erronea al momento de chequear la clave, si es erronea, espera, haz algunas cosas mas y luego alerta.
5>Añade delays cortos, como pausas, antes, en el medio y despues de la comprobacion....
6>Usa checksums en todo, dlls, exe, etc...
7>Parchea tu propio software, haz distintas rutinas de validacion para el mismo programa.
8>Guarda serials en lugares poco comunes
9>Guarda nros de series en varios lugares, luego comprueba si son iguales, pero no lo hagas todo junto, sino de a partes... al final, si alguno es difierente... alerta, pero tampoco en el momento.
10>No uses cadenas literales, en lo posible, las cadenas como "chico malo" o "chico bueno" tenelas encryptadas antes de enviar el mensaje, las desincriptas al momento, las usas, y las vuelves a cifrar.
11>Codigo basura, mete mucho codigo de
basura en el medio de la rutina de comprobacion, codigo parecido al que viene antes y despues de comprobacion, camuflalo.
12>Juega con codigo con muchas condiciones inutiles, je, jne, jz por todos lados antes, en el medio y despues de la rutina de comprobacion
13>Usa buena encryptacion, simple XOR no basta.
14>Usa serials largos, no 32 caracteres, sino varios Kb.
15>Evita usar la common runtime library de tu compilador (msvcrt, msvbcrt, etc...) para cosas que puedes programar tu mismo, como strlen, strcpy, strncat, etc...
16>No confies solamente en enpaquetadores
17>Usa ventanas de carga (es imagen que aparece mientras el programa carga), en esa dll, mete codigo de comprobacion tambien, muchas veces se saltaran esa pantalla porque molesta.
18>En la generacion de llaves, usa RCR y RCL, y si logras, trata que el Carry Flag este puesto con una rutina matematica pseudo aleatoria, de esa manera es dificil saber si rotar_si_acareo va rotar los bits o no.
19>Usa parte del codigo, (bytes de la ejecutable) como parte de la tabla de numeros magicos, asi si parchean el codigo, los numeros magicos ya no son los mismos.
20>Juega con la mente del cracker, si detectas un debugger, no termines el programa, que continue, pero haz la rutina de comprobacion distinta, en otro lugar... cosa que si el cracker logra detectar tu rutina y hace un keygen, no le servira al menos que ejecute el programa dentro del depurador.
21>No te gastes en escribir codigo para matar depuradores
22>cifra serials y nombres y comprueba si coinciden con tu manera.
encrypt the name/serial and check if it matches YOUR way of registering the program.
23>NUNCA, NUNCA pongras la rutina de generacion de llaves dentro de tu programa. Debes crear la rutina inversa, tomate el tiempo.
(NO HACER ESTO: if(generarllave(usuario)==serial_ingresado){ registro ok }
cifra todo el texto en el programa, o la mayoria de el.
Se les ocurre algun otro? o tambien si alguno esta mal?
Saludos
Enko
1>Evita los mensajes como "Te tengo lamer... jajaja, estas re mal"
2>Intenta usar encriptacion asimetrica
3>Nunca uses archivos con significado como licencia.dat
4>No alertes que la clave es erronea al momento de chequear la clave, si es erronea, espera, haz algunas cosas mas y luego alerta.
5>Añade delays cortos, como pausas, antes, en el medio y despues de la comprobacion....
6>Usa checksums en todo, dlls, exe, etc...
7>Parchea tu propio software, haz distintas rutinas de validacion para el mismo programa.
8>Guarda serials en lugares poco comunes
9>Guarda nros de series en varios lugares, luego comprueba si son iguales, pero no lo hagas todo junto, sino de a partes... al final, si alguno es difierente... alerta, pero tampoco en el momento.
10>No uses cadenas literales, en lo posible, las cadenas como "chico malo" o "chico bueno" tenelas encryptadas antes de enviar el mensaje, las desincriptas al momento, las usas, y las vuelves a cifrar.
11>Codigo basura, mete mucho codigo de
basura en el medio de la rutina de comprobacion, codigo parecido al que viene antes y despues de comprobacion, camuflalo.
12>Juega con codigo con muchas condiciones inutiles, je, jne, jz por todos lados antes, en el medio y despues de la rutina de comprobacion
13>Usa buena encryptacion, simple XOR no basta.
14>Usa serials largos, no 32 caracteres, sino varios Kb.
15>Evita usar la common runtime library de tu compilador (msvcrt, msvbcrt, etc...) para cosas que puedes programar tu mismo, como strlen, strcpy, strncat, etc...
16>No confies solamente en enpaquetadores
17>Usa ventanas de carga (es imagen que aparece mientras el programa carga), en esa dll, mete codigo de comprobacion tambien, muchas veces se saltaran esa pantalla porque molesta.
18>En la generacion de llaves, usa RCR y RCL, y si logras, trata que el Carry Flag este puesto con una rutina matematica pseudo aleatoria, de esa manera es dificil saber si rotar_si_acareo va rotar los bits o no.
19>Usa parte del codigo, (bytes de la ejecutable) como parte de la tabla de numeros magicos, asi si parchean el codigo, los numeros magicos ya no son los mismos.
20>Juega con la mente del cracker, si detectas un debugger, no termines el programa, que continue, pero haz la rutina de comprobacion distinta, en otro lugar... cosa que si el cracker logra detectar tu rutina y hace un keygen, no le servira al menos que ejecute el programa dentro del depurador.
21>No te gastes en escribir codigo para matar depuradores
22>cifra serials y nombres y comprueba si coinciden con tu manera.
encrypt the name/serial and check if it matches YOUR way of registering the program.
23>NUNCA, NUNCA pongras la rutina de generacion de llaves dentro de tu programa. Debes crear la rutina inversa, tomate el tiempo.
(NO HACER ESTO: if(generarllave(usuario)==serial_ingresado){ registro ok }
cifra todo el texto en el programa, o la mayoria de el.
Se les ocurre algun otro? o tambien si alguno esta mal?
Saludos
Enko
#514
Ingeniería Inversa / Re: Consulta: Como hacer más dificil el crackeo?
8 Octubre 2011, 15:50 PM #515
Noticias / Re: El CERN encuentra partículas que se mueven más rápido que la luz
29 Septiembre 2011, 21:47 PM
Aquí un artículo en el Discovery Magazine que explica mejor la cosa:
http://blogs.discovermagazine.com/badastronomy/2011/09/22/faster-than-light-travel-discovered-slow-down-folks/
La distancia es de 730Km, el tiempo en que tarda la luz es 2.43 milisegundos, y estos neutrinos han llegado 60 nanosegundos antes.
Segun el que escribió el articulo, comenta que al leer la publicación, sus bases de medición parecen solidas, pero tampoco es para tomarlo demasiado en serio; el margen de error es demasiado amplio, estamos hablando de recorrer 730Km y la distancia no necesariamente esta bien medida. con un par de metros el resultado ya cambia. Y el tiempo es de 0,000000006 segundos mas rapido que la luz.
http://blogs.discovermagazine.com/badastronomy/2011/09/22/faster-than-light-travel-discovered-slow-down-folks/
CitarNo hay que tomarlo demasiado en serio de momento.
The distance from the detector in Italy to the source in Geneva is about 730 km. The travel time at the speed of light is about 2.43 milliseconds, and the neutrinos appear to have outraced that speed by 60 nanoseconds. If true, that means they were traveling just a scosh faster than light, by about 1 part in 40,000. The
La distancia es de 730Km, el tiempo en que tarda la luz es 2.43 milisegundos, y estos neutrinos han llegado 60 nanosegundos antes.
Segun el que escribió el articulo, comenta que al leer la publicación, sus bases de medición parecen solidas, pero tampoco es para tomarlo demasiado en serio; el margen de error es demasiado amplio, estamos hablando de recorrer 730Km y la distancia no necesariamente esta bien medida. con un par de metros el resultado ya cambia. Y el tiempo es de 0,000000006 segundos mas rapido que la luz.
#516
ASM / Re: como instalar tasm 5 en windows 7
29 Septiembre 2011, 21:39 PM
Y si hay mucha necesidad de usar ese ensamblador arcaico...
puedes usar el emulador de D.O.S DosBox o una maquina virtual tipo wmware, virtual pc, virtualbox e instalarle el FreeDOS .
(dos box es la opcion mas rapida)
puedes usar el emulador de D.O.S DosBox o una maquina virtual tipo wmware, virtual pc, virtualbox e instalarle el FreeDOS .
(dos box es la opcion mas rapida)
#517
ASM / Re: Existe algun IDE para ASM
27 Septiembre 2011, 15:30 PM
Yo utilizo Crimson Editor.
Tiene los template de sintaxis personalizables. (se pueden agregar keywords por grupos)
Y en Tools, se pueden agragar compiladores/ensambladores, Debuger con Shortcuts.
Asi que queda como un RAD:
F7 fasm/masm para ensamblar,
F6 Ejecutar (se ejecuta un bat que lo unico que hace es "start %1")
Ctrl+F6 OllyDbg
Alt+F6 WinDbg
Ctrl+F7 rc.exe... para compilar recursos
Por supuesto los shortcuts son los que le puse, es totalmente personalizable.
¿Estan cansados de esos Editores que solo sirven para una tarea sola?
¿Estan cansados de abrir multiples programas para tener que ensamblar un archivo?
¿Estan cansados de esperar horas para que habra el VC++ porque tienen un pentium III y no pueden comprar el octa-core?
No se cansen más!!!!! Usen Crimson Editor.
Crimson Editor, marca spameada by Enko.
Saludos.
pd: lo unico que tiene de distinto crimson con los shortcuts estandar, es CTRL+R es para "Buscar y Reemplaza".
Cuando en la mayoria de los casos se usa Ctrl+H (me gusta mas con R)
Tiene los template de sintaxis personalizables. (se pueden agregar keywords por grupos)
Y en Tools, se pueden agragar compiladores/ensambladores, Debuger con Shortcuts.
Asi que queda como un RAD:
F7 fasm/masm para ensamblar,
F6 Ejecutar (se ejecuta un bat que lo unico que hace es "start %1")
Ctrl+F6 OllyDbg
Alt+F6 WinDbg
Ctrl+F7 rc.exe... para compilar recursos
Por supuesto los shortcuts son los que le puse, es totalmente personalizable.
¿Estan cansados de esos Editores que solo sirven para una tarea sola?
¿Estan cansados de abrir multiples programas para tener que ensamblar un archivo?
¿Estan cansados de esperar horas para que habra el VC++ porque tienen un pentium III y no pueden comprar el octa-core?
No se cansen más!!!!! Usen Crimson Editor.
Crimson Editor, marca spameada by Enko.
Saludos.
pd: lo unico que tiene de distinto crimson con los shortcuts estandar, es CTRL+R es para "Buscar y Reemplaza".
Cuando en la mayoria de los casos se usa Ctrl+H (me gusta mas con R)
#518
Ingeniería Inversa / Re: ASM ....utilidad en reversing?
19 Septiembre 2011, 16:14 PMEste rollo de aprender o no aprender asm para el reversing me tiene algo cansado.
Voy a explicarlo con una analogía facil.
Seguramente, en algun momento de su vida han tratado de aprender un segundo idioma (ingles lo mas probable). Durante ese tiempo, se tendrían que haber dado cuenta que aprender a entender un segundo idioma, es mucho mas facil que aprender a hablarlo, y aun mas complicado escribirlo.
Otro ejemplo, es saber leer en español, y tratar de escribir una novela interesante en el mismo idioma.
A lo que voy es, cuando se aprender Ingenieria inversa, forzozamente se esta aprendiendo a entender instrucciones/mnemonicos de cpu. Lo que se aprende, en si, es entender ASM. Luego tambien vienen los tipos de proteccion, empaquetados, formatos etc... pero un 50% del trabajo esta en entender los mnemonicos.
Un ejemplo seria:
saber leer en español (saber mnemonicos)
entender un libro/texto (entender que hace el programa)
escribir novela/poesia (programar)
Finalmente como Conclusión:
Para ingenieria inversa, no hace falta saber PROGRAMAR en asm, si hace falta ENTENDER el asm que no es lo mismo. Es como entender un texto en ingles, y saber hablar ingles:
si se habla bien ingles, se entiende un texto en ingles (sabiendo leer)
si se entiende un texto en ingles, no necesariamente se sabe hablar bien ingles.
si se sabe programar bien en asm, se entiende asm (programador)
si se entiende asm, no necesariamente se saber programar bien asm. (reverser)
en ambos casos, puede pasar que ni sabiendo asm, ni entendiendo asm, se sea un buen reverser; uno puede saber leer, pero no necesariamente al leer algun libro complicado uno lo entienda.
bonus track
Y como un bonus, no es sobre asm, sino el hecho de seguir tutoriales específicos.
Tomen este ejemplo:
Curso de Matematica by _Enko:
Capitulo A: 1 + 1 = 2
Capitulo B: A * 2 = 2A
Programa MathCrackMe 1 by _ilCapo
1 + 1 = SERIAL VALIDO
Ya se, en el tutorial de _Enko capitulo A, esta la respuesta... voy a seguir esa guia.
Programa MathCrackMe 2 by _ilCapo
2 + 2 = SERIAL VALIDO.
Ya se, combinando el capitulo A y B del tutorial de _Enko puedo saber la respuesta.
Programar MathCrackMe 3 by _ilCapo
8 / 3.5 = SERIAL VALIDO
Mh.... _Enko en sus tutoriales no explica "/"... que hago!!!!
Ya se!!!!!! Pregunto en el Foro!!!!!!!
uy.... no, el foro esta caido!!!!!!! Ahora no lo puedo resolver!!!!!
La respuesta correcta, no es preguntar en el foro... no sean ese tipo de noobs/lamers....
La respuesta correcta, desde el principio es aprender matematica, y asi pueden hacer la analogia con un monton de cosas asm, pe coff format, winapi, drivers, etc...
#519
ASM / Re: Pequeña duda (BIOS y el Mouse)
17 Septiembre 2011, 15:48 PM
http://wiki.osdev.org/USB
y aqui la documentacion oficial del usb 2.0
http://www.usb.org/developers/docs/usb_20_071411.zip
lo unico que he visto que anda usb en la bios es el teclado. Para mouse creo que tendras que hacer tu propio controlador inicializando el dispositivo usb.
y aqui la documentacion oficial del usb 2.0
http://www.usb.org/developers/docs/usb_20_071411.zip
lo unico que he visto que anda usb en la bios es el teclado. Para mouse creo que tendras que hacer tu propio controlador inicializando el dispositivo usb.
#520
Seguridad / Re: se abren ventanas solas
16 Septiembre 2011, 03:47 AM
Si tienes winxp, y tambien se te baja el Volumen Wave... casi seguro que tienes un bootkit.