Unless you are also testing for IDS and other detection devices, I dont see
the point in changing NOPs, however, changing them from NOPS in an
environment with IDS could really help identify weaknesses in signatures.
No, EIP will still land in the new "NOP" section and execute until it
reaches your payload, unless there is a bug of it comes to a null. So no it
should make no difference to a (un)-patched system.
Truth is, many cracking are done my kiddies, and they dont bother to alter
the NOP population in their eggcode anyway. Many IDS's are deployed not only
to match for NOPs but also to match for specific binary patterns such as
CDh, 80h, unless you are also intending to XOR your payload. So IMO, its
really up to your discretion. But I may have missed out on a few crucial
points, but first, to get some form of sleep :(
Cheers
----- Original Message -----
From: "Don Parker" <dparker_at_rigelksecurity.com>
To: <vuln-dev_at_securityfocus.com>
Sent: Monday, February 02, 2004 4:38 AM
Subject: Obfuscated shellcode
> Hello all, do any of you bother using obfuscated eggs during a pentest? I
ask here for I
> got no responses elsewhere. Though changing the well known x90 sled to
some other 1 byte
> function that won't affect the egg won't work against a patched service it
will, however
> elude an IDS signature.
>
> Quite a few large corporations may get updated signatures relatively
quickly but, they
> often do not patch for sometime due to baseline rollouts. Hence using an
obfuscated egg
> to slip past the IDS. This technique is not new, but it is becoming more
well known.
> There are some mitigaing factors here which could affect this such as
application layer
> firewalls and the such. I would however be interested in your thoughts on
this. I have
> not seem much discussion anywhere on this topic.
>
> Cheers!
> Don
>
> -------------------------------------------
> Don Parker, GCIA
> Intrusion Detection Specialist
> Rigel Kent Security & Advisory Services Inc
> www.rigelksecurity.com
> ph :613.249.8340
> fax:613.249.8319
> --------------------------------------------
>
Received on Feb 02 2004