@m0rf, el buffer del archivo y la ubicación de donde se crea el proceso están pasados como parámetros. El amigo ha explicado en base a una "función".

Gracias [Kayser].

Un saludo,
Iván Portilla.

En cuanto al SizeOfRawData:
Es la cantidad de bytes que añadirás en tu sección, Si este valor no es múltiplo del FileAlignment debes alinearlo y por tanto agregar la cantidad de bytes alineada, si alineas 0x17 con 0x200 te dará 0x200, equivalente al total de bytes a agregar, pero de esos 0x200 0x17 bytes serán los que contienen tus datos así que serán los primeros 0x17 bytes de los 0x200 en total.

En cuanto al PointerToRawData:
Tienes 4 secciones, la última con los siguientes datos:

• VirtualAddress: 0x2F000
• VirtualSize: 0xE34
• PointerToRawData: 0x2AE000
• SizeOfRawData: 0x1000

Si calculamos, el VirtualAddress de nuestra sección será: 0x2F000 + 0xE34 = 0x2FE34 Alineado a SectionAlignment (Se alinea al SectionAlignment porque ambos valores hacen referencia a memoria) = 0x30000 -> Nuevo VirtualAddress.

VirtualSize: La cantidad de datos que agregarás (0x17, esto se alinea solo en memoria).

PointerToRawData: (0x2AE00 + 0x1000 = 0x2BE00) Podemos comprobar que dicho valor está alineado ya que al hacer 0x2BE00 mod 0x200 será 0.

SizeOfRawData: Ya lo mencioné arriba.

Ahora, como te pudiste dar cuenta, hay datos justo al final de la última sección y estos corresponden a BOUND_IMPORT_TABLE. Comienza justo en: 0x278 y tiene un tamaño de 0x128. Esto lo podemos ver al ubicarnos primero al inicio del IMAGE_DATA_DIRECTORY, para esto nos basamos el donde inicia la primera sección y restamos la cantidad de directorios por el tamaño de cada uno (0x10* 0x8 =  0x80). Entonces sería 0x1D8 (inicio de primera sección) - 0x80 = 0x158 (inicio de IMAGE_DATA_DIRECTORY) + 0x58(posición del BOUND_IMPORT_TABLE). = 0x1B0 -> Aquí estarán los datos del BOUND_IMPORT_TABLE, en tu caso quedará más fácil "pisarla", entonces establece el RVA correspondiente a los primeros 4 bytes del BOUND_IMPORT_TABLE a 0, y los siguientes 4 correspondientes su tamaño también a 0.

Ahora puedes tranquilamente sobrescribir 0x28 bytes y todo andará bien.
No olvides actualizar NumberOfSectiosn y SizeOfImage.

Si quieres guiarte aquí te subo el notepad con la sección agregada.

Sigue prácticando.

Un saludo,
Iván Portilla.

Amigo,
Te felicito por lo de la primera parte. En cuanto al notepad.

Si tu VirtualAddress de la ultima sección es 0x2F000 y el VirtualAddress es Tamaño (0xE34 Alineado 0x1000 = 0x1000) = 0x30000 -> Ese es el nuevo VirtualAddress.

En cuanto a lo de tus espacios, eso se especifica en la parte del Taller llamada "We vs BOUND_IMPORT"

Un saludo,
Iván Portilla

No puedes utilizar variables para inicializar ningún tipo de arreglos. Debes usar o arreglos dinámicos o utilizar cifras numéricas para declarar los arreglos estáticos.

Un saludo,
Iván Portilla.

El código que mencionas en teoría es un ciclo que recorre todas las secciones.
Seguro esta parte no te gusta mucho:


Bueno el ciclo va desde 0 hasta el número de secciones:

(Rpidh.e_lfanew + 248 + 40* i) -> Corresponde a lo siguiente:

• l_fanew apunta al inicio de NT_HEADERS, lo reconoces por la firma PEx0x0
• +248 -> te ubica justo al inicio de la tabla de secciones.
• +40*i -> como sabes por jerarquía de operadores se hace primero la multiplicación, la i corresponde a la sección y el 40 al tamaño (40*(i=0)) = 0, l_fanew + 248 + 0 será de donde se lea la primera sección.

RtlMoveMemory constantemente cambiará el valor de la estructura Pish, esta estructura tendrá valores distintos a cada vuelta del ciclo ya que como mencionamos estamos recorriendo la declaración de las secciones.

WriteProcessMemory toma en varios de sus parámetros datos de la estructura y posteriormente copia en memoria, las secciones inician en ImageBase + VirtualAddress y tienen tamaño VirtualSize.

Así que eso, es copiar en memoria las secciones del buffer pero se hace como corresponde en memoria usando los datos del IMAGE_SECTION_HEADER. Si quieres aclarar tus dudas sobre secciones te invito a participar de este taller:

Un saludo,
Iván Portilla.

Lo que robertoht busca es encontrar binariamente los sectores firmados para posteriormente cambiarlo y pasar la detección estática. Roberto, lo que buscas es bastante tratado y se teóricamente podríamos decir que es un cercado de firmas. Te invito a utilizar el buscador por la palabra indetectable seguro encontrarás muchos casos.

Ahora no creo que encuentres un manual en todo el sentido de la palabra que cubra todo el tema, lee, investiga y practíca.

PD: El manual que mencionas es buena referencia.

Un saludo,
Iván Portilla.

Hola,
Distintos tipos de malware pueden aprovechar negocios como visitas de páginas y uso de buscadores para ganar dinero. Es muy posible que si tus navegadores han cambiado su página de inicio o buscador por defecto y te impidan reestablecerlo, puedas ser víctima de una infección.

Esto te ayudará.


Un saludo,
Iván Portilla.

Creo que lo entendiste mucho mejor.

Recuerda que todos los campos de IMAGE_SECTION_HEADER tienen un tamaño cada uno de 4 bytes con excepción del nombre de la sección que ocupa 8 y NumberOfRelocations y NumberOfLineNumers (WORD) estos últimos. (Debes tener muy en cuenta el tamaño de cada campo).

Ahora tienes un pequeño problema con las alineaciones.
NO se deben sumar, solamente un valor debe ser múltiplo del otro, cuando digo múltiplo es que al hacer la operación:

Num mod Alineamiendo = 0.

Entonces no es 0x220, mira bien que esos 2 valores que marcaste:

Son VirtualAddress y SizeOfRawData correspondientemente. Entonces para encontrar SizeOfRawData, este valor corresponde al tamaño de los datos de TU sección, y ese valor se debe alinear al FileAlignment:

FileAlignment: 0x200
Tus datos: 0x17
0x17 alineado a 0x200 = 0x200.


Estás mal, idata cubre 8 bytes, los siguientes 4 corresponden al VirtualSize que sería 0x98, los siguientes 4 al VirtualAddress, los siguientes 4 SizeOfRawData, los siguientes 4 a PointerToRawData...



Un saludo.

Expliqué los 2 métodos:

• Mover la BOUND_IMPORT_TABLE.
• Remover la BOUND_IMPORT_TABLE.

Todos los ejecutables NO tienen BOUND_IMPORT_TABLE, y para comprobar si tienen o no debes comparar el directorio de datos número 12 y ver si su RVA es 0 o no.

Un saludo,
Iván Portilla.

En cuanto a lo de la cadena me refería a su tamaño, ya lo he editado de una manera que quede más explícito.

En cuanto a lo del campo VirtualAddress de la estructura IMAGE_SECTION_HEADER, me refiero a la dirección virtual relativa(explicado al principio) donde se cargará la sección en memoria. Osea es allí donde empieza a cargarse la sección que como te darás cuenta es distinto comparandolo con la posición en disco, esto se debe a los alineamientos virtuales y físicos.

Para encontrar el VirtualAddress debe tomar como base la sección inmediatamente anterior a la que vamos a agregar, la que era la última. De aquí tomaremos los datos VirtualAddress y SizeOfRawData, los sumamos y luego alineamos al SectionAlignment -> Alineación virtual.

Cuando me refiero a alinear en teoría si, es redondear pero hacia el múltiplo de determinado valor pero mayor mayor. Ejemplo:

0x1000 + 0x05 = 0x1005 -> Múltiplo más proximo de 0x1000 es 0x2000.
Además el ejemplo que diste también es válido.

SizeOfRawData NO es lo mismo que FileAlignment aunque pueden coincidir sus valores, este corresponde al tamaño que ocupa la sección en el archivo. El FileAlignment es la base de alineamientos físicos. Osea que todo lo que que en disco deba estar alineado a este campo debe cumplir como valor mínimo, y cualquier otro valor mayor debe ser múltiplo mayor inmediato de este.

Ejemplo:
0x202 -> Alineado 0x400 (FileAlignment = 0x200).

El PointerToRawData es la ubicación de los datos de la nueva sección en disco. Igualmente debes tomar como referencia la sección inmediatamente anterior. Si el PointerToRawData de la sección inmediatamente anterior es 0x400 esa será su posición en disco, pero para llegar al final de los datos de esta sección debes sumar su tamaño SizeOfRawData, con eso estarás al final de la sección inmediatamente anterior. Así llego a 0x600.

En cuanto al valor del VirtualSize correpsonde al tamaño de los datos que mapeará en memoria el Loader, 0x98 fue un error mío de puro despiste, en realidad sería 0x17, en este caso no se alinea a ningún valor entonces pasamos el valor neto de los datos explicitos de la sección.

Espero haya resuelto tus dudas.

Un saludo,
Iván Portilla