Mensajes

Lo ideal seria (en Cramel):

Código (vb) [Seleccionar] Expandir

Var hSock:Entero
Repetir
    hSock = TCPConectar("ip/host",666)
    Si hSock Entonces
        Repetir
            Var Datos:Cadena
            Datos = TCPRecibir(hSock,1024)
            Seleccionar Datos
                Caso "mostrar mensaje"
                    Mensaje("Se ha recibido un mensaje del cliente!")
                Caso Otro ' Si los datos son equivocados o nulos salimos del bucle.
                   TCPDesconectar(hSock) ' Cerramos por si las moscas...
                   Salir Repetir
             FinSeleccionar
        PorSiempre
    FinSi
PorSiempre

Creo que es obvio, pero por si no se entendió, intentamos conectar desde un bucle infinito, si se conectó recibimos datos hasta que estos sean equivocados o nulos, si esto ultimo sucede, salimos del segundo bucle y se intentará conectar automáticamente.

De esta manera no vas a necesitar que el cliente este enviando o verificando si el servidor sigue vivo ya que el estado es absoluto.

no solo de minería las cryptomonedas tienen más que eso

+1

Estoy totalmente de acuerdo, sin animos de ofender, seria muy bruto crear un foro sobre cryptomonedas para unicamente discutir/informarse de como minarlas.

+1

Bueno, hace unos años logre realizar las bases de un sueño mio que era tener mi propio lenguaje de programación funcional, hoy dia ese sueño se cumplió gracias a mis esfuerzos y se compartió gracias a una increible comunidad, pero a pesar de que logre crear algo realmente potente y simple (lo suficiente como para poder desarrollar el programa que desee) no estoy satisfecho.

Hoy me estoy planteando volver a desarrollar un nuevo compilador, y el hecho de que este acá es para preguntarles ¿que les gustaria de un lenguaje de programación? ¿que cosas les molesta o disgusta? ¿tienen detalles que compartir?

¡Saludos!

¿Cualquiera? Yo tengo entendido que los exploits son errores de programación que pueden ser vulnerados para realizar nuevas funciones.

Por ahí mal entendí, corrijanme.

Muy interesante, supongo que como trabaja con ntdll debe ser más rápido que usar OpenProcess de Kernel32, para un servidor de rat de otro foro use varias funciones de NT para administrar los procesos (suspender, resumir, destruir, etc), como siempre una librería muy interesante.

Gracias por mostrarlo!

Ese es uno de los problemas mas generales al usar sockets, en Windows cuando un socket se cierra por lo general se puede detectar de varias maneras, como por ejemplo cuando se deja de recibir datos de una conexión o estos son inválidos.

Si estas usando un lenguaje de alto nivel (como VB.NET, C#, Java, Python) podrías llegar a encontrar un evento especifico para este trabajo (socket_close).

Y por tu mensaje puedo entender que estas escribiendo un RAT de conexión directa, te recomendaría hacerlo de conexión inversa, pero cada quien con sus gustos.

También te dejo un poco de información extra.

[físico]

Información

Las funciones predeterminadas de la API de Windows para cargar bibliotecas externas en un programa (LoadLibrary, LoadLibraryEx) sólo funcionan con archivos del sistema. Por lo tanto, es imposible cargar un DLL de memoria. Pero a veces, necesitas exactamente esta funcionalidad (por ejemplo, si no quieres distribuir muchos archivos o quieres hacer el des-ensamblado más difícil). Soluciones comunes para estos problemas son escribir el DLL en un archivo temporal primero e importarlo desde ahí. Cuando el programa termina, el archivo temporal se elimina.

En este tutorial, describiré primero cómo se estructuran los archivos DLL y se presentará código que se puede utilizar para cargar una DLL completamente desde la memoria, sin tocar el disco.

Ejecutables de Windows - Formato PE

La mayoría de los binarios de Windows que pueden contener código ejecutable (.exe, .dll, .sys) comparten un formato de archivo común que consta de las siguientes partes:

Código [Seleccionar] Expandir

DOS Header
DOS Stub
PE Header
Sección Header
Sección 1
Sección 2
. . .
Sección #

Todas las estructuras que se dan a continuación se pueden encontrar en el archivo Estructuras.cml

Cabecera DOS (DOS Header) - STUB

El encabezado DOS sólo se utiliza para la compatibilidad con versiones anteriores. Precede al stub de DOS que normalmente sólo muestra un mensaje de error acerca de que el programa no se puede ejecutar desde el modo DOS.

Microsoft define el encabezado DOS de la siguiente manera:

Código [Seleccionar] Expandir

Estruct IMAGE_DOS_HEADER,_
       e_magic,_       ' Número mágico.
       e_cblp,_         ' Bytes en la última página del archivo.
       e_cp,_           ' Paginas en el archivo.
       e_crlc,_          ' Relocalizaciones.
       e_cparhdr,_    ' Tamaño del encabezado en el apartado.
       e_minalloc,_    ' Tamaño extra mínimo del apartado.
       e_maxalloc,_   ' Tamaño extra máximo del apartado.
       e_s,_              ' Valor SS inicial (relativo).
       e_sp,_            ' Valor inicial SP.
       e_csum,_        ' Checksum.
       e_ip,_             ' Valor inicial IP.
       e_cs,_             ' Valor CS inicial (relativo).
       e_lfarlc,_         ' Dirección en el archivo de la tabla de relocaciones.
       e_ovno,_        ' Número de superposición.
       e_res[4],_       ' Reservados.
       e_oemid,_       ' Identificador OEM (para e_oeminfo).
       e_oeminfo,_    ' Información OEM.
       e_res2[10]:Word,_ ' Reservado.
       e_lfanew:Entero ' Dirección en el archivo de la nueva cabecera.

Cabecera PE (PE Header)

La cabecera PE contiene información acerca de las diferentes secciones dentro del ejecutable que son usados para almacenar códigos y datos o también para definir importaciones de otras librerías o exportaciones que esta proporciona.

Esta se define como la siguiente estructura:

Código [Seleccionar] Expandir

Estruct IMAGE_NT_HEADERS,_
       Signature:Entero,_
       FileHeader:IMAGE_FILE_HEADER,_
       OptionalHeader:IMAGE_OPTIONAL_HEADER

El miembro 'FileHeader' describe el formato físico del archivo. Por ejemplo: contenidos, información sobre símbolos, etc.

Código [Seleccionar] Expandir

Estruct IMAGE_FILE_HEADER,_
       Machine,_
       NumberOfSections:Word,_
       TimeDateStamp,_
       PointerToSymbolTable,_
       NumberOfSymbols:Entero,_
       SizeOfOptionalHeader,_
       Characteristics:Word

El 'OptionalHeader' contiene información sobre el formato lógico de la librería, incluyendo la versión requerida del SO, los requisitos de memoria y los puntos de entrada.

Código [Seleccionar] Expandir

Estruct IMAGE_OPTIONAL_HEADER,_
       Magic:Word,_ ' 0
       MajorLinkerVersion,_ ' 2
       MinorLinkerVersion:Byte,_ ' 3
       SizeOfCode,_    ' 4
       SizeOfInitializedData,_ ' 8
       SizeOfUnitializedData,_ ' 12
       AddressOfEntryPoint,_ ' 16
       BaseOfCode,_ ' 20
       BaseOfData,_ ' 24
       ImageBase,_ ' 28
       SectionAlignment,_ ' 32
       FileAlignment:Entero,_ ' 36
       MajorOperatingSystemVersion,_ ' 40
       MinorOperatingSystemVersion,_ ' 42
       MajorImageVersion,_ ' 44
       MinorImageVersion,_ ' 46
       MajorSubsystemVersion,_ ' 48
       MinorSubsystemVersion:Word,_ ' 50
       W32VersionValue,_ ' 52
       SizeOfImage,_ ' 56
       SizeOfHeaders,_ ' 60
       CheckSum:Entero,_ ' 64
       SubSystem,_ ' 68
       DllCharacteristics:Word,_ ' 70
       SizeOfStackReserve,_ ' 72
       SizeOfStackCommit,_ ' 76
       SizeOfHeapReserve,_ ' 80
       SizeOfHeapCommit,_ ' 84
       LoaderFlags,_ ' 88
       NumberOfRvaAndSizes:Entero,_ ' 92
       DataDirectory[16]:IMAGE_DATA_DIRECTORY ' 96

El 'DataDirectory' contiene 16 (IMAGE_NUMBEROF_DIRECTORY_ENTRIES) entradas que definen los componentes lógicos de la librería:

Nota: Las descripciones en rojo no pudieron ser traducidas.

Indice-	Descripción
0	Funciones exportadas
1	Funciones importadas
2	Recursos (resources)
3	Información de excepciones
4	Información de seguridad
5	Tabla de reubicación base
6	Información de depuración
7	Datos de arquitectura especifica
8	Puntero global
9	Thread local storage
10	Configuración de carga
11	Importaciones vinculadas
12	Tabla de direcciones de importación
13	Delay load imports
14	COM runtime descriptor

Para importar una DLL nosotros solo necesitamos las entradas que describen las importaciones y la tabla de reubicaciones. Para proporcionar acceso a las funciones exportadas, se requiere la entrada de las exportaciones.

Cabecera de secciones (Section Header)

La cabecera de secciones es almacenada después de la estructura 'OptionalHeader' en la cabecera PE. Si usted usa C. Microsoft le provee la macro 'IMAGE_FIRST_SECTION' para obtener la dirección de inicio basado en la cabecera PE.

Actualmente, la cabecera de secciones (Section Header) es una lista de información acerca de cada sección en el archivo.

Código [Seleccionar] Expandir

Unión Misc,_
     PhysicalAddress,_
     VirtualSize:Entero

Estruct IMAGE_SECTION_HEADER,_
       Name[8]:Byte,_
       Misc:Misc,_
       VirtualAddress,_
       SizeOfRawData,_
       PointerToRawData,_
       PointerToRelocations,_
       PointerToLinenumbers:Entero,_
       NumberOfRelocations,_
       NumberOfLinenumbers:Word,_
       Characteristics:Entero

Una sección puede contener código, datos, información de reubicaciones, recursos, definiciones de importación/exportación, etc.

Cargando la librería

Para emular la carga PE, nosotros primero debemos entender cuales son los pasos necesarios para cargar un archivo en la memoria y preparar las estructuras para que puedan ser llamadas por otros programas.

Al invocar a la API LoadLibrary, básicamente, Windows realiza estas tareas:

• Abre el archivo dado y analiza las cabeceras DOS y PE.
• Trata de almacenar 'PEHeader.OptionalHeader.SizeOfImage' bytes en la posición 'PEHeader.OptionalHeader.ImageBase'.
• Analiza las secciones de cabecera y copia cada sección a sus respectivas secciones de memoria. La dirección de destino de cada sección, relativa a la base del bloque de memoria asignado, se almacena en el miembro 'VirtualAddress' de la estructura IMAGE_SECTION_HEADER.
• Si el bloque de memoria alojado difiere del miembro 'ImageBase', varias referencias en las secciones de código y/o datos deben ser ajustadas. Esto es llamado reubicación base (base relocation).
• Las importaciones necesarias para la DLL deben resolverse cargando las librerías correspondientes.
• Las regiones de memoria de cada sección deben ser protegidas dependiendo de las características de la sección. Muchas secciones son marcadas como descartables y por lo tanto se pueden liberar a partir de este punto. Estas secciones normalmente contienen información temporal que solo es requerida durante la importación. Como la información para la reubicación base.
• Nuestra librería esta cargada completamente, Se debe notificar sobre esto llamando al punto de entrada (Entry Point) usando la bandera (flag) DLL_PROCESS_ATTACH.

En los siguientes párrafos, cada paso es descrito.

Almacenando memoria

Toda la memoria requerida por la libreria debe ser reservada/alojada usando VirtualAlloc, como Windows provee funciones para proteger estos bloques de memoria. Esto es requerido para restringir el acceso a la memoria, como bloquear el acceso a escritura del código o datos constantes.

La estructura 'OptionalHeader' define el tamaño del bloque de memoria requerido por la librería. Si es posible, esta debe ser almacenado en la dirección especificada por 'ImageBase'.

Nota: En el siguiente mini-ejemplo se asume que usted hizo apuntar 'PEHeader' a la librería en memoria.

Código [Seleccionar] Expandir

Var Mem:Entero
Mem = VirtualAlloc(PEHeader.OptionalHeader.ImageBase,PEHeader.OptionalHeader.SizeOfImage,MEM_RESERVE,PAGE_READWRITE)

Si la memoria reservada difiere de la dirección dada en 'ImageBase', se debe realizar la reubicación de base como se describe mas adelante.

Copiar secciones

Una vez que la memoria ha sido reservada, el contenido del archivo debe ser copiado al sistema. Las secciones de cabecera (Section Headers) deben ser evaluadas para determinar la posición en el archivo y el área de destino en la memoria.

Antes de copiar los datos, el bloque de memoria debe estar comprometido.

Nota: Se aloja nueva memoria con la bandera 'MEM_COMMIT'.

Código [Seleccionar] Expandir

Var Destino:Entero
Destino = VirtualAlloc(DirecciónBase + Sección.VirtualAddress,Sección.SizeOfRawData,MEM_COMMIT,PAGE_READWRITE)

Secciones sin datos en el archivo (como secciones de datos para ser usadas como variables) tienen un 'SizeOfRawData' de 0. Entonces puedes usar la 'SizeOfInitializedData' o 'SizeOfUninitializedData' de 'OptionalHeader'. Cada uno debe ser elegido dependiendo de las banderas de bits 'IMAGE_SCN_CNT_INITIALIZED_DATA' e 'IMAGE_SCN_CNT_UNINITIALIZED_DATA' que se pueden establecer en las características de la sección (miembro 'Characteristics').

Reubicación base

Todas las direcciones de memoria en las secciones de código/datos de una libreria son almacenadas relativamente a la dirección definida por 'ImageBase' de 'OptionalHeader'.

Si la librería no puede ser importada de esta dirección de memoria, las referencias deben ser re-ajustadas (reubicadas). El formato de archivo ayuda a esto almacenando información sobre todas estas referencias en la tabla de reubicación de base, la cual puede ser encontrada en el directorio 5 de la 'DataDirectory' en la 'OptionalHeader'.

Esta tabla consta de una serie de esta estructura:

Código [Seleccionar] Expandir

Estruct IMAGE_BASE_RELOCATION,_
       VirtualAddress,_
       SizeOfBlock:Entero

Contiene (SizeOfBlock - IMAGE_SIZEOF_BASE_RELOCATION) / 2 entradas de 16 bits cada una. Los 4 bits superiores definen el tipo de reubicación, los 12 bits inferiores definen el desplazamiento en relación con el VirtualAddress.

Los únicos tipos que pueden ser usados en librerías son:

IMAGE_REL_BASED_ABSOLUTE (0)
Ninguna operación de reubicación.

IMAGE_REL_BASED_HIGHLOW (3)
Agregue el delta entre ImageBase y el bloque de memoria asignado a los 32 bits encontrados en el offset.

Resolviendo importaciones

La entrada de directorio 1 del 'DataDirectory' en 'OptionalHeader' especifica una lista de bibliotecas para importar símbolos. Cada entrada en esta lista se define de la siguiente manera:

Código [Seleccionar] Expandir

Estruct IMAGE_IMPORT_DESCRIPTOR,_
       OriginalFirstThunk,_
       TimeDateStamp,_
       ForwarderChain,_
       Name,_
       FirstThunk:Entero

El miembro 'Name' describe el offset a una cadena terminada en nulo con el nombre de la librería (ej: KERNEL32.DLL). El miembro 'OriginalFirstThunk' apunta a una lista de referencias a los nombres de las funciones a importar de la librería externa. 'FirstThunk' apunta a una lista de direcciones que se llenó con punteros a los símbolos importados.

Cuando nosotros resolvemos las importaciones, nosotros recorremos ambas listas en paralelo, importando la función definida en la primera lista y almacenando el puntero en los símbolos de la segunda lista.

Código [Seleccionar] Expandir

Var @NameRef,@SymbolRef:Entero
NameRef@ = BaseAddress + ImportDes.OriginalFirstThunk
SymbolRef@ = BaseAddress + ImportDes.FirstThunk

Mientras NameRef <> 0
   Var @ThunkData:IMAGE_IMPORT_BY_NAME
   ThunkData@ = CodeBase + NameRef
   SymbolRef = GetProcAddress(Handle,CadDePtr(ThunkData.Name))
   NameRef@ = NameRef@@+4
   SymbolRef@ = SymbolRef@@+4
FinMientras

Protegiendo la memoria

Cada sección especifica los indicadores de permiso en su entrada de características. Estas banderas pueden ser una o una combinación de

IMAGE_SCN_MEM_EXECUTE (&20000000)
Esta sección contiene datos que pueden ser ejecutados.

IMAGE_SCN_MEM_READ (&40000000)
Esta sección contiene datos que solo pueden ser leídos.

IMAGE_SCN_MEM_WRITE (&80000000)
Esta sección contiene datos que pueden ser escritos.

Estos indicadores deben asignarse a las banderas de protección

• PAGE_NOACCESS (&1)
• PAGE_WRITECOPY 8
• PAGE_READONLY (&2)
• PAGE_READWRITE (&4)
• PAGE_EXECUTE (&10)
• PAGE_EXECUTE_WRITECOPY (&80)
• PAGE_EXECUTE_READ (&20)
• PAGE_EXECUTE_READWRITE (&40)

Ahora, la función VirtualProtect puede ser usada para limitar el acceso a la memoria. Si el programa trata de escribir algo en un camino no autorizado, una excepción es generada por Windows.

Además de los indicadores de sección anteriores, se puede agregar los siguientes:

IMAGE_SCN_MEM_DISCARDABLE (&02000000)
Los datos en esta sección pueden ser liberados después de importar. Usualmente esta es especificada por los datos de reubicación.

IMAGE_SCN_MEM_NOT_CACHED (&04000000)
Los datos de esta sección no deben ser almacenados en caché por Windows. Agregue el indicador de bits PAGE_NOCACHE a los indicadores de protección anteriores.

Notificar librería

La ultima cosa que hacemos es llamar el punto de entrada de la DLL (definido por 'AddressOfEntryPoint') y por lo tanto notificar a la biblioteca acerca de estar conectado a un proceso.

La función de punto de entrada es definida como:

Código [Seleccionar] Expandir

Prototipo EntryPoint(hInstance,dwReason,Reserved):Entero

Entonces el código que nosotros debemos ejecutar es:

Código [Seleccionar] Expandir

Prototipo EntryPoint(hInstance,dwReason,Reserved):Entero

Var Entry:EntryPoint
Entry@ = BaseAddress + PEHeader.OptionalHeader.AddressOfEntryPoint
Entry(BaseAddress,DLL_PROCESS_ATTACH,0)

Después podemos utilizar las funciones exportadas como con cualquier biblioteca normal.

Funciones exportadas

Si usted quiere obtener acceso a las funciones que la librería exporta, necesita buscar el punto de entrada del simbolo, por ejemplo. El nombre de la función a llamar.

El directorio de entrada 0 de la 'DataDirectory' en la 'OptionalHeader' contiene información acerca de las funciones exportadas. Esta es definida como la siguiente estructura:

Código [Seleccionar] Expandir

Estruct IMAGE_EXPORT_DIRECTORY,_
       Characteristics,_
       TimeDateStamp:Entero,_
       MajorVersion,_
       MinorVersion:Word,_
       Name,_
       Base,_
       NumberOfFunctions,_
       NumberOfNames,_
       AddressOfFunctions,_ ' RVA de Base.
       AddressOfNames,_     ' RVA de Base.
       AddressOfNameOrdinals:Entero ' RVA de Base.

Lo primero que debemos hacer es referenciar el nombre de la función al número ordinal del símbolo exportado. Por lo tanto, sólo sondear las matrices definidas por 'AddressOfNames' y 'AddressOfNameOrdinals' en paralelo hasta que encuentre el nombre necesario.

Ahora puede utilizar el número ordinal para leer la dirección evaluando el n-ésimo elemento de la matriz 'AddressOfFunctions'.

Liberando la libreria

Para liberar la librería cargada de manera personalizada, realice los siguientes pasos:

• Llamar al punto de entrada para informar que la vamos a liberar.

Código [Seleccionar] Expandir

Entry(BaseAddress,DLL_PROCESS_DETACH,0)

• Liberar las librerías requeridas por la DLL que queríamos importar en realidad.
• Liberar la memoria alojada por VirtualAlloc.

Este manual fue escrito por Joachim Bauch, traducido por Yuki para Underc0de y traído a ustedes por amor a la información libre.

Código fuente de ejemplo (escrito en Cramel)

El código fuente de la librería se puede encontrar acá.

El código de ejemplo puede ser visto en PasteBin.

¡Saludos!

Yuki el problema es cuando tienes que hacer una aplicacion para el mundo real... es decir...

-intenta hacer un programa, que lea un pagina web y extraiga un dato especifico

-intenta hacer una aplicación que haga ping

-Has una aplicación que revise el espacio ocupado por los archivos de una carpeta que el usuario  indique

-Has una aplicacion que calcule el MD5 de un archivo indicado pro el usuario

Es verdad, no se puede esperar escribir con éxito un programa de alto nivel en ensamblador, aunque es posible, no es lo más fácil, rápido o correcto, esto ultimo por la dificultad de mantener el código.

Entonces, n1sen, te dejo este post que te explica lo mas BASICO para entender ensamblador, también te recomiendo que ignores ese tipo de ejemplos de código ensamblador, ya que nadie (y te digo, NADIE) usa exclusivamente INT 21h para escribir programas. Si escribis para linux, busca sobre la api de linux, si es para Windows, las apis de Windows.

Como dicen nuestros compañeros, ensamblador no es difícil, puede ser si, un poco complicado de aprender, especialmente con los manuales mediocres que existen en internet.

Sin embargo, difiero con lo que dijo engel lex, hacer algo funcional en ensamblador es un poco más complicado, pero si sabes comentar bien no deberías tener problemas, yo personalmente prefiero programar en ensamblador, lo aprendí para realizar el proyecto que podes encontrar en mi firma.

Me gustaria señalarte un post que hice en otro foro que trata sobre unos tips para entender ensamblador fácil, pero como dije, es de otro foro y no creo que se permita.

No he programado en Java, pero puedo asumir que al entrar en el bucle/ciclo el programa deja de procesar los mensajes de las ventanas.

Tal vez esto te sirva:

https://stackoverflow.com/questions/3310023/application-doevents-equivalent-function-in-java
https://stackoverflow.com/questions/12626952/in-java-is-there-something-like-doevents-from-vb6
http://www.lawebdelprogramador.com/foros/Java/833556-doevents-para-java.html

Sino, lo que podes hacer es modificar tu código para que el bucle se ejecute en un nuevo hilo de tal manera que no detenga el código principal.