Mensajes

Deja mucho que desear....

Nada que no puedas ver con el ollydbg 

No estoy de acuerdo.
Son programas que buscan en la sección .text los recursos y eventos del programa. Muy diferente al Olly o a cualquier debugger.
El olly te muestra el desensamblado pero no te dice ni los recursos de un programa en VB ni tampoco sus eventos, ni te dice dónde están. Los tienes que buscar y en cambio programas como éstos (VB Editor v3.0 etc...) sí que te dicen dónde se encuentran los recursos, qué eventos utiliza el programa y la dirección (Offset) donde se encuentran dichos recursos o eventos.

Es mi opinión, pero el programa VB Semidecompiler, que es el primero que se ha mencionado en el post, puede resultar muy útil si se sabe utilizar correctamente...

PD. Por ejemplo si visitáis mi post sobre editar recursos (los dos últimos ejemplos son de VB), ahí muestro algo muy sencillo de cómo podémos utilizar este tipo de programas:
http://foro.elhacker.net/index.php/topic,134513.15.html

[VB Editor v3.0]

Efectivamente es un programa muy interesante y muy bueno.

Su autor es vbgamer45 y su página web es la siguiente:
http://www.visualbasiczone.com/products/semivbdecompiler/

Existen también otros programas curiosos con código fuente incluído (también en VB):
VB Editor v3.0

Su autor es Hexman y su página web donde descargarlo es la siguiente:
http://hexman.free.fr/fr/exe/vbeditor_III_opensource.php

[Ejemplo 07]

Ejemplo 07

Sobre Visual Basic 6 (II)

Viendo que hay mucha gente interesada en VB, voy a seguir con algún ejemplo más examinando un par de programas más para VB y a explicar un programa gratuito, con código fuente incluído (en VB) y realmente muy interesante que nos permitirá descubrir el offset exacto de cualquier control y nos enseñará sus propiedades...

El programa que voy a utilizar para todo este ejemplo se puede descargar (incluído su código fuente) desde el siguiente enlace, el programa se llama VB Editor 3.0 y su autor Hexman:
VB Editor v3.0

La interfaz del programa que he compilado en VB6 para este ejemplo es la siguiente:

_Imagen38

El programa lo he llamado: "ejemplo7.exe"
Como se puede observar, hay dos botones deshabilitados y un timer con un intervalo de 2553. El primer botón (Command1) está deshabilitado en las propiedades, mientras que el segundo botón (Command2) está deshabilitado en el evento Form_Load.

Importante: VB Editor v.3.0 es un programa que si se modifica en él cualquier propiedad, se modificará automáticamente en el ejecutable que hayamos abierto. Lo que quiero decir es que se haga una copia de seguridad, ya que a veces al modificar una determinada propiedad VB Editor no lo hace correctamente y NO se podrá volver al ejecutable original. Por este motivo, yo utilizo VB Editor solamente para leer los datos, pero desde él no modifico nada.

Lo que voy a hacer es habilitar los dos botones y ver también cómo se puede modificar el interval del timer modificando su valor o simplemente poniéndolo a cero, ya que de este modo lo desactivaremos permanentemente.

Bueno, pues voy a abrir ejemplo7.exe desde el programa VB Editor v3.0. Nada más abrirlo nos aparecerá la ruta de en mi caso "ejemplo7.exe".
Hay que clickear dos veces sobre ella y ya aparecerá el/los formularios con los controles que hay y con un dato muy bueno: El offset donde se encuentra dicho control. ¡Muy interesante programa y gratuito!

Habilitar "Command1"

En mi caso, voy clickar sobre el primer botón: "Command1" y veré lo siguiente:

_Imagen39

Con ese enabled = Falso ya nos está indicando que el botón está desactivado en sus propiedades. Cuando se compila un programa en VB este dato se guarda como un 0 -> deshabilitado o como un 1 --> habilitado.
También sabemos que el offset de dicho botón es: 4803 (12C3) así que ya podemos ir en un editor hexadecimal a esa zona:

_Imagen40

Ahí está efectivamente toda la información importante. Voy a analizar los bytes..
Primeramente vemos el "name" del control: "Command1", seguidamente se observa el "caption" del botón: "Deshabilitado en propiedades: Enabled == False". Y a partir de aquí voy a analizar los bytes que siguen:

0004 6801 6801 0F0F 7701 0800 1100

0004
6801 -> Left
6801 -> Top
0F0F -> Width
7701 -> Height
08
00 -> Este es nuestro byte. (00 = Desactivado.)

Ya hemos visto la forma de localizarlo así que ahora voy a modificarlo y lo voy a poner 01. Lo guardo como "ejemplo72.exe" lo ejecuto y...

_Imagen41

Hay veces que el byte 00 no coincide exactamente en ese lugar, pero sabiendo que es un 00 pues se puede probar a modificar uno a uno hasta encontrarlo.. es fácil.

Habilitar "Command2"

Este botón es diferente ya que está habilitado en sus propiedades pero se deshabilita al cargar el formulario, así que hay que "echar mano" de otro programa que nos ayude a encontrar en qué parte del código lo deshabilita... "SmartCheck"
Para este ejemplo hay que entender primeramente una cosa. Cuando se deshabilita un control, realmente podemos observar que si ponemos un BP en EnableWindow en un debugger, pues veremos cómo se detiene.
En VB, y en los programas que he analizado normalmente se hace de la siguiente forma:
Se ponen dos valores en la pila y seguidamente se llama a una subrutina (CALL) que es la que desactiva el control. El primer dato que se introduce es un cero que recordemos que es desactivado. Si lo ponemos <> cero, observaremos que se habilita, con lo cual no sólo el 1 habilita el control.
El segundo dato que se pone en la pila pienso que es la ID o un identificador que utiliza VB para identificar al control, ya que he comprobado que el handle no es. Por lo tanto con esta información podemos hacer dos cosas:
-intentar modificar el primer valor que se pone en la pila y ponerlo <> 0
-nopear la call que es la que deshabilita el control.

Sabiendo ya esto, voy a ejecutar "ejemplo72.exe" en el SmartCheck. Observo lo siguiente:

_Imagen42

SmartCheck es un programa impresionantemente impresionante para analizar programas en VB.
Nos da toda la información necesaria. Nos da el evento, nos dice que desactiva un botón, nos dice qué botón es y nos indica la subrutina donde se encuentra(offset). En definitiva: Nos dice todo.

Ahora ya es sólo cuestión de analizarlo en el OllyDBG o en vuestro debugger preferido. Y voy a ir a esa dirección (sumo 400000 al offset):

_Imagen43

El programa aprovecha que el valor de EDI es cero. Es el primer valor que pone en la pila y como ya he explicado es cero.
El segundo valor: ESI es un valor que identifica al control y que si se modifica nos dará error.
Si se modifica en ejecución ese valor de EDI y se pone distinto de cero se comprueba efectivamente que el botón se habilita. Por lo tanto de eso se trata.

Como expliqué, se puede nopear la CALL en la que (en la imagen anterior) está parado o simplemente voy a sustituir el primer PUSH EDI por por ejemplo PUSH ESI ya que ESI no será igual a cero. Para el que siga sin entender esto último se trata de modificar solamente ese byte 57 (PUSH EDI) por 56 (PUSH ESI).
Supongo que se entiende, es sencillo.

De este modo ya tengo los dos botones habilitados. :-)

Modificar el Interval del timer

Como he hecho en la parte (I) y en esta parte (II), podemos utilizar varios de los programas explicados para localizar el offset del timer y ya sabiendo el valor del interval modificarlo a nuestro gusto.
En este caso he utilizado el VB Editor v3.0 y rápidamente me ha dado el offset y el valor del intervalo = 2553 que en hex = 9F9. Por el método seguido anteriormente se localiza de forma rápida y podemos modificar ese valor a nuestro gusto.
Lo más interesante de todo es que si modificamos ese 09F9 a 0000 lo que conseguimos es desactivar el timer permanentemente (a no ser que se modifique posteriormente en el código).

Lo que tienes que hacer es saber cómo consigue esa ruta...
Por ejemplo puedes intentar poner un BP en GetModuleFileName si quieres la dirección y nombre del programa.
Puedes poner un BP en GetCommandLine si quieres la ruta.. y hay unas cuantas más.

Busca qué funciones te pueden ayudar y pruébalas a ver.

PD. PUedes intentar también saber qué va a hacer con ese archivo y si por ejemplo lo que hace es abrirlo pues puedes modificar tú también a mano uno de los datos que se da a CreateFile y que es la ruta y nombre del archivo a abrir. Hay varias ideas..

[http://ricardonarvaja.info/]

Aquí está la nueva web de Ricardo:

http://ricardonarvaja.info/

Que la disfrutéis!!

[TUTE 26 - Visual Basic]

Tutoriales de Ricardo Narvaja sobre VB:

TUTE 26 - Visual Basic

TUTE 27 -Visual Basic

TUTE 28 - Visual Basic

Tutes utilizando SmartCheck:
http://www.hackemate.com.ar/mirrors/karpoff/Psmartchec.htm
Busca en Proyectos hechos con SmartCheck

Estos tutes son un poco antigüos pero te servirán.

[SmartCheck]

Todos los programas son diferentes en su protección así que no se puede hacer un tute genérico pero sí que te pueden servir estas herramientas:

SmartCheck (impresionante):
http://80.32.232.60/soft/smartchk.zip

VB Decompiler Lite:
http://www.vb-decompiler.org/

VB Reformer:
http://www.decompiler-vb.net/

Con esos tres programas(el PDasm está también bastante bien), el OllyDBG y haber leído los tutoriales de Ricardo Narvaja de introducción al Olly en los que habla de Visual Basic... sobra
Suerte

Ciertamente pienso lo mismo que Achernar...

Yo te pongo dos ejemplos reales que me han pasado estos ultimos meses:
1) Hice un programa en VB6 en el que seleccionaba un archivo de 1MB, hacía unas operaciones y me daba el resultado en un RichTextBox. Bien, pues el programa en VB6 en un pentium II a 400 Mhz tardabá algo más de 10 minutos en dar el resultado en el RichTextBox.
Ese mismo programa lo hice en ensamblador (MASM32) y puse el cronómetro en marcha en el mismo ordenador y tardó: centésimas de segundo.
Con esto te puedes dar cuenta de la diferencia tan brutal... Yo no programaría un brute force en VB6. Segurísimo que no.

2) Viene por lo que dice Achernar... Un día intentando crackear un programa, hice un brute force en ensamblador aprovechando el mismo programa. El código bueno y único eran creo que 15 dígitos... pues bien, mi brute force al hacer cálculos como ha hecho Achernar, resultó que tardaría milenios y milenios en encontrar el código exacto...
NO quiero ni imaginar lo que puede tardar en encontrarlo en VB!!


Yo ya te he dado mi experiencia.
Un saludo

Ostras...!!
El problema pienso que es saber qué puede contener ese archivo .bin, dónde se ejecuta o quién lo ejecuta o si realmente puede ser un ejecutable o no. Si bien dices es (o emula o lo que sea...) un firmware, es posible que haya sido compilado con algún lenguaje.

Todo (pienso yo) tiene que ver en cómo trate tu NDS a ése archivo binario o dónde se ejecute.

Podrías intentar mirar si tal vez sea un archivo PE (programa, dll o driver...Microsoft Windows) por ej. con éste programa que tiene soporte incluso para plataformas Windows CE:
http://www.heaventools.com/download-pe-explorer.htm

Si éste programa no reconoce nada podrías intentar analizarlo con un editor hex pero no vas a conseguir saber qué hace o no hace. Con el editor hex. tal vez puedas encontrar algún recurso y modificarlo... no se me ocurre mucho más..

¿Y si fuese un ejecutable para Linux?
-Podría ser... comprueba eso también...

Un saludo

Riky_RD NO respondas a hilos de más de 1 AÑO...
Porque nos lías a todos!!