Voy a tratar de mirarlo ni bien haga un poco de tiempo libre (estoy saturado de trabajos de todas clases!
).
Saludos!
EDIT: Para ver la parte que descifra:
1) Correr el proggie en Olly (en una VM por las dudas y con StrongOD para evitar detecciones).
2) Parado en el EP, poner un BP en el punto magico de VB6 (buscar los bytes D1E98BFCF3A5FFD0). El CALL EAX es el punto magico.
3) Ejecutar. Cuando el BP salta, poner un BP en CallWindowProcA. Ejecutar 2 veces. La tercera vez que para, mirar que los parametros no tienen sentido para esa API. Es el famoso metodo para llamar codigo ASM desde VB6. Esa API llamará a la direccion del primer parametro (identificado como PrevProc. La dir. está en el heap). Poner un BP en esa dirección y dar F9.
4) Para en un PUSHAD y un CALL.
Desde ahi obtiene la base del kernel y resuelve las APIs necesarias para ejecutar el programa original SUSPENDIDO (con CreateProcessW). Luego lo modifica con WriteProcessMemory (entre tanto hace otras cosas, pero hay que poner BPs sólo en los CALL EAX ya que asi llama a las APIs). Esto lo hace por cada sección.
Luego le setea el contexto del proceso y lo termina ejecutando con un ResumeThread.
Hasta ahí pude mirar. Obtener el EXE original debería ser una pavada ya que está completito en memoria (aunque no lo probé)...
EDIT 2:
Un método más rapido para obtener el EXE original: Poner un BP en 4BB337. Los 4 parámetros de esa función, tienen todo lo que necesitan para analizar esta cosa.
EDIT 3: después e tracear hasta el final, el crypter (si se lo puede llamar así) no hace mas nada. No veo comportamiento raro ni malicioso. Lo único que veo es que el autor del proggie original (SadFud) no sabe que el OCX de skins no está en todas las máquinas y que compilar en P-CODE hace que sea más sencillo reversear su código...
Y con esto me despido de este tema...