Mensajes

antes que nada... vos sabés en que dirección de memoria se guarda el valor correspondiente a la vida del personaje??? digo.. destripás el programa y... miles de direcciones de memoria... vos sabes cual es la que contiene ese valor que queres modificar o leer? Me intriga como lo encontraste, lo podrias decir si no es mucha molestia 

Esto:

Código (vb) [Seleccionar] Expandir


    Open fname For Binary As #fnum
        num_bytes = LOF(fnum)
            ReDim bytes(wed To wsd)
        Get #fnum, wed, bytes
    Close fnum


No tendira que ser asi?

Código (vb) [Seleccionar] Expandir


    fnum = freefile
    Open fname For Binary As #fnum
        num_bytes = LOF(fnum)
            ReDim bytes(1 To num_bytes)
        Get #fnum, num_bytes, bytes
    Close fnum


y para verlos en hex y en ascii seria (muy basicamente) asi:
(tendrias que no convertir a ascii a los caracteres como el retorno de carro, el avance de linea, tab y quizas otros que van a alterar la forma en que se muestren los demas caracteres)

Código (vb) [Seleccionar] Expandir

text1.text= vbnullstring
text2.text = vbnullstring
for i = 1 to num_bytes
   text1.text = text1.text + hex$(bytes(i))
   text2.text = text2.text + chr$(bytes(i))
next i


Gracias cobein, creo que es eso justo lo que busco, voy a tener que explorar un poco las clases porque no tengo mucha experiencia en programacion de clases, pero ya exploréotras que pasé a modulos casi igual de prácticos.

[P]

EON seguro que no se cargan en direcciones aleatorias, pero las direcciones que se cargan en la tabla de importacion (las de las apis que usa el programa) son diferentes en diferentes versiones de windows. Si el mismo programa lo ejecutas en un windows XP sp1 y despues lo ejecutas en un Windows XP sp2 o en español e inglés, la tabla de importacion se va a cargar con diferentes valores, porque en diferentes versiones de windows las direcciones de las apis varian, este es el problema precisamente al intentar encontrar las direccines de las apis cuando se usa una shellcode. Los valores de estas direcciones no pueden ser modificados en el binario, precisamente porque se cargan al ejecutarse el programa, en direcciones, que como dicìs, no son aleatorias.

Con respecto al formato PE y las shelcodes universales lo hice con el masm32 y lo entiendo, con el texto de RaiSe pero la tabla de importacion de los programas en VB son el problema, solo los hechos en VB son como extraños, incluso para hacer practicas de craking son rebuscados, son distintos. Por lo menos asi lo veo yo XDDDD sobre todo por ese modo que tiene de usar las apis, como eso de reventarse cuando usan threads en vb6, evidentemente no hace un uso normal de las apis.

Si los valores (direcciones de las apis) en la tabla de importacion fuesen valores estaticos y se pudiesen leer en el binario directamente, serian como las shellcodes hardcodeadas, no se pordrian "Portar los Ejecutables" a otras versiones de windows.

Si, es lo que estoy intentando, vi que muchos ejemplos de redireccion de apis en los que buscaban en las tablas de importacion del programa la direccin de la funcion que se queria controlar, pero no pude ni encontrar la direccion la funcion MessageBoxA o alguna referencia a la libreria user32.dll, solo funciones y librerias que usa siempre VB6.

mira, esto es hasta donde llegué:

http://foro.elhacker.net/programacion_vb/crear_un_pe_editor_simple-t229389.0.html;msg1093622#msg1093622

(hay un codigo fuente, pero no es el del programa con la llamada a MessageBoxA)

¿Alguien me podria dar una mano?¿Alguien consiguio hookear una api en VB6 o aunque sea rastrear las direcciones de las APIs en memoria?

[¿Alguien sabe como llegar a obtener esas direcciones?]

No funciona leyendo el archivo en modo binario, porque si, por ejemplo, queres  explorar la estructura del formato PE para acceder a las Tablas de importacion para conocer las direcciones de memoria de las apis que llama el programa no vas a poder. Porque estas direcciones se cargan en memoria antes de que el programa empiece a correr. Para explorarlo y modificarlo hay que hacerlo mienntras el programa esta funcionando.

Te recomiendo este texto:

http://goodfellas.shellcode.com.ar/docz/bof/UN-shellcodes_1.txt

y para explorar la memoria de un programa en funcionamiento hice este codigo de un programa que explora su propia memoria, para no tener que hacer una "DLL Injection" ni nada parecido.

Código [Seleccionar] Expandir

'PEGAR EN UN FORMULARIO Form1
'el proyecto necesita los siguientes componentes:
'un textbox Text1 para ingresar la direccion de memoria que se quiere leer
'(&H400000 seria la Direccion Base de la Imagen)
'un textbox Text2 para ingresar la cantidad de bytes a leer
' "    "    Text3 para mostrar los bytes en Hexadecimal (Font = Fixedsys)
'                 (Font = Fixedsys, Multiline = True, ScrollBars = 2-Vertical)
' "    "    Text4 para mostrar los bytes en Ascii
'                 (Font = Fixedsys, Multiline = True, ScrollBars = 2-Vertical)
'un boton Comman1 para iniciar la lectura
'
'   los bytes en Ascii no se ven bien por los caracteres no imprimibles, como
'   el retorno de carro, el tab, y el salto de linea.

Option Explicit

Private Const PROCESS_ALL_ACCESS = &H1F0FFF

Private Declare Function GetCurrentProcessId Lib "kernel32" () As Long
Private Declare Function OpenProcess Lib "Kernel32.dll" (ByVal dwDesiredAccessas As Long, _
                                                         ByVal bInheritHandle As Long, _
                                                         ByVal dwProcId As Long) As Long
Private Declare Function ReadProcessMemory Lib "kernel32" (ByVal hProcess As Long, _
                                                           ByVal lpBaseAddress As Any, _
                                                           lpBuffer As Any, _
                                                           ByVal nSize As Long, _
                                                           lpNumberOfBytesWritten As Long) As Long

Private Sub Command1_Click()
    LeerMemoria Text3, Text4, CLng(Trim$(Text1.Text)), CLng(Text2.Text)
End Sub

Private Sub LeerMemoria(T_Hex As TextBox, T_Ascii As TextBox, Direccion As Long, CantidadDeBytes As Long)
    Dim PID                             As Long
    Dim hProc                           As Long
    ReDim Buffer(1 To CantidadDeBytes) As Byte
    Dim ret                             As Long
    Dim Contador                        As Long
    Dim i                               As Long
    Dim ByteX                           As String
   
    PID = GetCurrentProcessId
    hProc = OpenProcess(PROCESS_ALL_ACCESS, False, PID)
    ReadProcessMemory hProc, Direccion, Buffer(1), CantidadDeBytes, ret
   
    T_Hex.Text = vbNullString
    T_Ascii.Text = vbNullString
    Contador = 0
   
    For i = 1 To CantidadDeBytes
        Contador = Contador + 1
        ByteX = Hex$(Buffer(i))
        If Len(ByteX) = 1 Then ByteX = "0" + ByteX
        T_Hex.Text = T_Hex.Text + ByteX + " "
        T_Ascii.Text = T_Ascii.Text + Chr$(Buffer(i))
        If Contador = 16 Then
            T_Hex.Text = T_Hex.Text + vbCrLf
            T_Ascii.Text = T_Ascii.Text + vbCrLf
            Contador = 0
        End If
    Next i
   
End Sub

Private Sub Form_Load()
Text1.Text = "&H400000"
Text2.Text = "100"
Command1.Caption = "Leer Memoria"
Text4.Text = vbNullString
Text5.Text = vbNullString
End Sub



Agregue, en cierta ocacion, una llamada a la api MessageBoxA para ver si podia obtener la direccion de mememoria de la funcion en la tabla de importacion, para poder cambiarla pero ni siquiera la encontré. VB hace cosas que supongo extraña, en la tabla solo encontre librerias de VB y nada mas. ¿Alguien sabe como llegar a obtener esas direcciones? seria una especie de intento por hacer "API Hooking" modificando la tabla de importacion con VB.

Por ahora demoniox12 te adelanto que si lees los primeros bytes a partir de la direccion &H40003c vas a encontrar la direccion de memoria donde empieza la cabecera PE, y 80 bytes mas adelante de la direccion donde empieza la cabecera PE esta almacenada la direccion donde empiezan las iTables (Tablas de Importacion), importantes en temas como Api Hooking y Shellcodes Universales.

Lamentablemente creo que no hay muchos expertos en estos temas en el foro de VB6, no es por ofender a nadie, seguro que hay gente que sabe y mucho de esto, pero no creo que sean muchos por aca. Debe haber mas en los que frecuentan foros de de C o Malware, pero en esos casos vi que a gente que habla de VB los tratan como si habaran de resolver matrices con un ábaco.

Mi duda es la siguiente: con eiframe.dll se pude hacer un sencillo browser en VB, yo quisiera poder manipular las cabeceras http, para esto pense en hacer un proxy y manipularas ahi, pero si pudiera hookear la funcion send de winsock solamente en el browser que programe seria mejor, porque no estaria usando tantos sockets abiertos. Qisiera saber si es posible, hacerlo solo sobre este programa o si tendria que hookear la funcion en la libreria ws2_2.dll y luego separar los paquetes q me interesan.

Gracias por leer.

no siempre se puede llegar a un acuerdo, lo importante ese no crear una bronca, discutiste como un caballero, fue un gusto.

[disminuian la corriente]

No me termina de entrar en la cabeza ¿porqué decís que la resistencia es nula cuando hay corriente alterna? sin ánimo de ofender creo que tenés algún concepto mal. Un foco de un velador o una plancha común para quitar las arrugas de la ropa funciona con corriente alterna y una resistencia que se calienta transformando la energía de la corriente alterna en calor (en el caso del foco el calor perdido en forma de radiación alcanza las longitudes de onda visibles como puede suceder con las brasas de carbón). Es más, en su época, Tesla se enfrentó fuertemente con Edison porque la corriente continua (la que defendia Edison) tenia muchas perdidas para ser tranmitida por cableado a larga distancia, porque para transminir una potencia decente habia mucha corriente en los cables (las perdidas son proporcionales al cuadrado de la corriente, duplicar la corriente cuadriplica las perdidas). Como todos sabemos gano Tesla con su corriente alterna porque tenia la ventaja de poder usar transformadores (que no funcionan con corriente continua) que aumentaban el voltaje y disminuian la corriente manteniendo constante la potencia (V*I), entonces podia llevar electrcidad a lugares distantes con largos cables sin mucha perdida, nunca se penso que la resistencia de los cables era nula, sino que la corriente alterna podia ser modificada para tener menos perdidas. Creo que el error que tenes es creer que la resistencia es un concepto de la corriente continua y no es aplicable a la corriente alterna, pero la impedancia es un concepto mas complejo que la resistencia, pero que la tiene en cuenta. La resistencia no desaparece en la corriente alterna, solo que se tiene en cuenta junto con otros conceptos dentro de la impedancia.
Nuevamente perdon por no usar tildes, me sacan  no puedo ponerlos todos.

un link, sobre perdidas y corriente alterna
http://www.electricidadbasica.net/ca1.htm

[Las pérdidas causadas por los cables RG-58 y RG-59 son bastantes más notorias en las bandas de VHF y UHF especialmente si la línea es más larga de 15 metros]

1) La resistencia de un conductor depende de la longitud
2) estos cables son capacitores de tipo coaxiales (dos conductores separados por un aislante, confinando un campo eléctrico entre ellos) donde su capacitancia también depende de su longitud
3) la impedancia característica depende de la capacitancia y de la resistencia de los conductores entre otras cosas.

4) La impedancia característica de los cables coaxiales es generalmente de 50, 52, 75, o 93 Ω pero tiene que ser por metro, no puede ser un valor fijo independiente de la longitud del cable porque sus componentes varian con la longitud

La impedancia va a variar definitivamente al cortar el cable.


y me faltaba un cita:

Los cables coaxiales más gruesos (RG-8) tienen menos pérdida de señal en comparación con los más delgados (RG-58). Los radioaficionados probablemente no tienen la información de la pequeña pérdida de señal si su línea es menor de 30 metros de largo, al menos en las bandas de HF. Muchos operadores de HF encuentran más adecuados a sus necesidades y mejor los coaxiales delgados  debido a su peso y flexibilidad, sin mencionar el costo que es cerca de la mitad o más por metro de cable de los más gruesos.

Las pérdidas causadas por los cables RG-58 y RG-59 son bastantes más notorias en las bandas de VHF y UHF especialmente si  la línea es más larga de 15 metros.

la cita la saqué de esta página
http://www.federachi.cl/Comisiones/Dx/lineas_alimentacion.htm

si miran la parte en negrita y estos van a ver que en realidad el problema es la longitud y no el tipo de cables por la frecuencia que se esta manejando:

Las pérdidas causadas por los cables RG-58 y RG-59 son bastantes más notorias en las bandas de VHF y UHF especialmente si  la línea es más larga de 15 metros

RG-58/U    50 ohms
RG-59/U    75 ohms

UHF (Ultra alta frecuencia Ultra high frequency) de 300 a 3000 MHz
por lo tanto los 2,4GHz usados en wifi son UHF

los nombres de los cables (rg-58, etc..) aparecen aca:
http://es.wikipedia.org/wiki/Cable_coaxial

Creo que hice mi tarea jajajajaj