Del análisis del virus se puede extraer la impresión de que éste no es más que un simple vehículo empleado por su programador para hacer pública su original idea en torno a esta "engine" polimórfica. Pensando en frío es fácil deducir que, a juzgar por las características del virus, éste se limita a ser el citoplasma que transporta al núcleo, que en este caso es su polimorfismo. Llegamos así al extremo en el que los papeles se invierten: los algoritmos polimórficos, incialmente pensados para servir de protección de los virus en los que son incluídos, en este caso pasan a ser los protagonistas, desempeñando el resto del código un papel meramente secundario.

De 111 bytes de longitud, el motor polimórfico del virus "Pusher" destaca, como hemos dicho, por su originalidad. En lugar de los "decryptors" o algoritmos de desencriptado que estamos acostumbrados a ver, consistentes en un "loop" -por medio del cual el código vírico se desencripta- cuyas instrucciones aleatoriamente generadas aparecen disimuladas entre series también aleatorias de instrucciones basura (que parece que cumplen algún propósito pero que en realidad sólo despistan y hacen perder tiempo a quien analiza el virus, como pueden ser "calls" recursivos, por ejemplo), los "decryptors" del virus "Pusher" emplean una técnica novedosa y extremadamente sencilla: trabajan mediante un sólo registro (AX), en lugar de emplear varios de forma aleatoria, y se valen de operaciones aritméticas de rango limitado, en combinación con la pila, para dejar el código vírico al descubierto. Sin ser una técnica muy efectiva o muy difícil de desbaratar, y a pesar del inconveniente de aumentar el tamaño del virus a casi el doble, sí que resulta extremadamente sorprendente, lo cual, casi con toda seguridad, fue lo que el autor de este virus pretendió cuando puso a su criatura en libertad.

El truco es muy sencillo: los "decryptors" generados por el algoritmo polimórfico del "Pusher" mueven al registro AX bytes originales del código, ya sea por medio de un "mov", u obteniendo estos bytes mediante instrucciones de tipo "add", "sub", "inc"... una vez que AX contiene dos bytes originales desencriptados, el "decryptor" efectúa un "push ax", introduciendo así el código vírico en la pila, en orden inverso. Tras haber procesado de esta forma todo el código del virus "Pusher", el "decryptor" salta a la pila mediante un "jmp sp". De esta manera, encontramos que el virus está desencriptado en su totalidad y listo para su ejecución en la pila... una peculiar forma de despistar a aquellos usuarios que hayan tratado de seguir la pista del virus. Veamos qué aspecto tendrían dos de los posibles "decryptors" generados por el virus:

    mov    ax,XXXXh   /   mov    ax,XXXXh
    push   ax         /   push   ax
    add    ax,YYYYh   /   inc    ax
    push   ax         /   push   ax
    sub    ax,ZZZZh   /   mov    al,YYh
    push   ax         /   push   ax
    inc    ax         /   mov    ah,ZZh
    push   ax         /   push   ax
    [...]                 [...]
    jmp    sp         /   jmp    sp

En los ejemplos, los bytes reemplazados por los comodines de tipo "X" serían bytes originales del virus, mientras que los de tipo "Y" o "Z" serían valores que, sumados o restados al valor previamente almacenado en AX, darían como resultado en el mismo registro otra serie de uno o dos bytes originales del virus. Mediante el ejemplo de la derecha podemos observar que los "decryptors" generados por el virus "Pusher" no sólo emplean registros y valores de 16 bits (AX+palabra), sino que también se dan las combinaciones de 8 bits (AH/AL+byte). El resultado, como se puede apreciar, es realmente peculiar.