@skapunky: Me gustaría ver fuentes de esa información... ya que no solo contradice los TOS sino que suena muy en plan "paranoia conspiratoria"...

Saludos

Las librerías que contienen la API de Windows vienen en diversos formatos, uno de ellos es con DLLs. Éstas puedes imaginarlas como librerías [de libros] donde cada libro sería una función, con un identificador (título).

En este caso la librería tendría como nombre: "NTDLL". Esta librería se caracteriza por contener las funciones de nivel más inferior accesible desde el modo de usuario. Y el libro, "NtUnmapViewOfSection" es el que contiene el código para vaciar la memoria del proceso.

Lo único que me queda por añadir es que el elemento del PE Header llamado ImageBase contiene la dirección base a partir de la cual se meterán los datos. Y que será utilizado también en algunos de los elementos restantes del PE que tienen direcciones relativas en lugar de absolutas. Como curiosidad añado que algunos ficheros PE contienen información de relocalización (.reloc) que permite realojar el PE en otras direcciones base (ImageBase).

Saludos

Para compreder la carga de ejecutables on the fly viendo un runPE cualquiera verás que lo primero que hace es desmapear (respondiendo a tu pregunta #2), esto es: vaciar todo el espacio que el cargador de windows había commiteado. Una vez vacío ya empiezas a mapear las zonas de memoria siguiendo lo especificado en el PE Header.

Si te surge cualquier duda ya sabes que para eso estamos

El espacio de memoria de un proceso no tiene porque acabar estando en la memoria RAM, sino que también puede acabar en el archivo de paginación.

En ese espacio se mete todo tú ejecutable con las secciones pertinentes y se cargan todas las DLLs que éste necesite. La dirección base donde se coloca el ejecutable está establecida en el PE Header del mismo y puede ser colocado de forma *aleatoria* si está activado el ASLR.

Así pues, respondiendo a tus preguntas:
1- No siempre es en la memoria RAM. No siempre es *aleatoria* la dirección base para la copia.
2- El espacio es mayor.

PD: Todo estos conocimientos los he adquirido en la practica, así que puede que algún detalle se me escape.

Saludos

Lo que pasa es que hay caracteres que no puedes ver, pero aunque veas caracteres vacios si que hay texto... lo que no sé aún es porque no se ve xD

---

Otro código ofuscado

#vim:setfileencoding=rot13
w,n=[h"Cvrqen",h"Cncry",h"Gvwrenf"],vag(vachg("1) Cvrqen\a\e2) Cncry\a\e3) Gvwrenf\a\e\a\eRyvwn han bcpvba:")).__fho__(1)
cevag"Hfgrq un ryrtvqb:\a\e{0}\a\e\a\eCrqeva NV un ryrtvqb:\a\e{1}\a\e\a\eCrqeva NV tnan...".sbezng(w.__trgvgrz__(n),w.__trgvgrz__(n.__nqq__(1).__zbq__(3)))

Option Explicit
'KERNEL32
Private Declare Function GetVersion Lib "KERNEL32" () As Long
'SHELL32
Private Declare Function SHGetUserPicturePath Lib "SHELL32" Alias "#261" (ByVal pUserOrPicName As Long, ByVal sguppFlags As Long, ByVal pwszPicPath As Long, ByVal picPathLen As Long) As Long
Private Declare Function xp_SHGetUserPicturePath Lib "SHELL32" Alias "#233" (ByVal pUserOrPicName As Long, ByVal sguppFlags As Long, ByVal pwszPicPath As Long) As Long
 
Private Const SGUPP_CREATEPICTURESDIR = &H80000000
 
Public Function LoadUserTile() As IPictureDisp
    Dim sPath   As String
 
    sPath = String$(256, vbNullChar)
 
    Select Case (GetVersion() And &HFF)
        Case 5
            Call xp_SHGetUserPicturePath(0, SGUPP_CREATEPICTURESDIR, StrPtr(sPath))
        Case 6
            Call SHGetUserPicturePath(0, SGUPP_CREATEPICTURESDIR, StrPtr(sPath), 256)
    End Select
 
    sPath = Left$(sPath, InStr(1, sPath, vbNullChar) - 1)
 
    Set LoadUserTile = LoadPicture(sPath)
End Function

Para probarlo añade un PictureBox en un form:

Private Sub Form_Load()
    Picture1.Picture = LoadUserTile()
End Sub

Usa un export no documentado de SHELL32.. que varía según el SO en el que estamos... por eso el GetVersion().

saludos

Una método muy interesante. No soy mucho de Linux, pero la parte importante está aquí, no?:
Ahí es donde "instalas" el sniffer, verdad? Si es así no debería de poderse establecer aliases que sobrescriban otros sin permisos de ROOT... tal vez se puede modificar alguna directiva para ello...

Muy buen código. Saludos.

Como ya han resuelto tu duda sólo me pondré tiquismiquis y añadiré estos dos puntos:

• Tu duda es con .NET (VB > 6 es ya .NET). Así que está en la sección equivocada.
• "encriptador" no es equivalente a "encryptor" del inglés, sería aquél que mete cosas en una cripta . Por lo tanto el término correcto es "cifrador", y no "encriptador".

Saludos.

No puedes pretender hacer un crypter uniendo códigos que te dé la gente. Comprende la lógica de un crypter y sabiendo programar podrás hacer tú uno desde cero.

El tema ha sido movido a Seguridad.

http://foro.elhacker.net/index.php?topic=358501.0