El inicio del fichero no se toca.
Pero no es el unico offset que detectan los antivirus busca en offsets mas altos.
Suerte

porque no intentas primero cambiandole el entry point al server eso da muy buenos resultados con algunos AVs

Es cierto....Estoy encontrando más offsets que piyan el antivirus.
Seguiré probando, lo que no se es como comprobar si funcionan o no.

¿¿Podría infectarme yo mismo con este Bifrost 1.102 al ser de Conexion Inversa???

Una info adicional es que cambiando el primer offset de cualquier troyano a parte de cargarte el troyano no te lo va a detectar ningun antivirus por el mero hecho de que ese offset es el que identifica ese archivo como un ejecutable. Si te fijas bien todos los exes tienen ese offset "MZ". Si cambias ese offset te cargas el server de cualquier troyano asi como cualquier archivo exe.

EL Post es muy bueno y explica bastante el Método Rit, a ver si me hago con ese artículo o revista completo y pruebo.

También voy a probar con encriptadores y demás. El caso es aprender, que algo bueno tendrá.

Gracia a tod@s por vuestra ayuda, sois.....

Pues tienes razón, eso es una errata, y si te fijas en el hilo de HxC que he comentado unas lineas más arriba verás que hay alguna más...

A pesar de todo, yo he hecho esas mismas modificaciones y el servidor me funcionaba perfecto. No se si has visto ese trozo de código en el olly directamente, pero si lo haces comprobarás que el olly no lo interpreta de manera fiable. Es probable que no se trate de código ejecutable sino de simples datos y por eso el error que has encontrado no afecta al funcionamiento del troyano...

Lo de ir con cuidado con el código que se mueve también lo pone el mismo articulo, se le habrá pasado por alto ese salto corto al autor 

Otra solución para este caso concreto sería mover una instrucción más al hueco, de esa manera el salto corto quedaria dentro del codigo movido con lo cual no habría problema.


Salu2

Pues no se, quizas si pruebas con otro desensamblador, el Sice por ejemplo... De todas formas, salvo algunas excepciones, el Olly no suele equivocarse. Si ves una zona con instucciones absurdas o incomprensibles lo mas seguro es que realmente no se trate de codigo ejecutable sino de otra cosa.

Lo que pasa es que el Olly lo intenta interpretar TODO como código ensamblador (a no ser que le digas lo contrario como se puede hacer con la cabecera, etc). Si te vas a la zona de 'resources' que es donde se guarda la info sobre iconos y demás verás que el Olly tambien intenta interpretarlo como codigo ASM, aunque en realidad se trata de los bytes que componen el BMP que hace de icono, por ejemplo.

A veces, sobretodo en estos exes fabricados 'al gusto del consumidor' como son los troyanos, puedes encontrarte datos  embebidos en el código de ejecución, quizas pertenecientes a algun icono para un mensaje de 'fake error' o algo similar...

En definitiva, si el troyano al final acaba funcionando a pesar de tocar esos bytes, es que no eran necesarios para su correcta ejecucion, con lo cual no hay problema.

Yo todavia no me he encontrado con el caso contrario, que el Olly no me interpretara bien una zona que luego SI fuera imprescindible para la ejecucion, al menos no en troyanos, asi que cuando me la encuentre ya veré que pasa ...

En cuanto a lo del hueco, creo (no estoy seguro) que el topo hace una búsqueda de las zona continua con mayor numero de ceros posible. Ademas te da a elegir si buscar solo dentro de la sección de ejecucion del PE o en todas las secciones. Es recomendable usar solo la sección de ejecucion porque alguna heurística se activa  cuando detecta que el flujo de ejecucion del programa se sale de su sección.

En principio puedes usar cualquier zona que te aparezca con series de 4 ceros (2 bytes nulos) en el Olly, por supuesto cualquier zona rellenada con NOPs, y si sabes bastante de ensamblador pudes buscar código inutil y eliminarlo (los compiladores no son perfectos y a veces generan ese codigo inutil).


Salu2