Re: Does size matter?

[Michael Silk <michaelslists () gmail com>]

Why buy a book when you have:
http://board.win32asmcommunity.net/viewforum.php?f=5. Common sense
would suggest it's best to get something for free than pay for it :)

-- Michael

On Tue, 8 Mar 2005 00:33:12 -0500, Bas Alberts
<bas.alberts () immunitysec com> wrote:
> Sure, whatever gets you off. I tend to get into trouble for having
> a really broad definition of 'common sense', so I'm a bit jaded when it
> comes to things people think are 'art' or 'special', including payload
> cuteness. However, on the subject of cute little hacks..if you're into that
> kind of fun I'd recommend getting 'hackers delight'
>
> http://www.amazon.com/exec/obidos/tg/detail/-/0201914654/qid=1110259692/sr=8-1/ref=sr_8_xs_ap_i1_xgl14/102-2973275-9526560?v=glance&s=books&n=507846
>
> Which is an awesome little book full of fun little algo hacks, and not
> some bullshit bingo infosec rip off as the title would have you suspect.
>
> Regards,
> Bas
>
> On Mon, Mar 07, 2005 at 09:12:34PM -0800, vlad902 wrote:
> > On Mon, 7 Mar 2005 21:15:35 -0500, Bas Alberts
> > <bas.alberts () immunitysec com> wrote:
> > > Hrmm..personally I'm more of a functionalist, as long as it A) fits
> > > B) is reliable C) when in a bruting situation, does not foul up
> > > a sensible brute step..I really don't care about 100 bytes more or
> > > less. Ofcourse I'm of the school that thinks all this 'programming
> > > is art' nonsense is umm..nonsense. As a journalism grad I got
> > > into CS to get away from the hippies...oh how foolish I was.. :/
> >
> > While programming may or may not be an "art" I don't think many people
> > can deny the fact that optimizing shellcode is very interesting. Being
> > able to do more in less is interesting if only to see just what odd
> > hacks you'll get that will actually execute to save a single byte. :>
> > Some of the slightly interesting stuff I've found:
> >
> > 1. Saving a byte when determining the position of the shellcode
> > (without NULLs) by not doing:
> >
> > jmp foo
> > __foo: jmp start
> > foo: call __foo
> >
> > But instead if the case allows (and it does in the case of my windows
> > bind/reverse shells) instead using a one-byte instruction instead of
> > jmp foo that takes a one byte argument and the offset from __foo to
> > foo in the encoded jmp instruction execute as an instruction. For
> > example:
> >
> > > ./msfpayload win32_bind R | ndisasm -u - | head -n 5
> > 00000000  FC                cld
> > 00000001  6AEB              push byte -0x15
> > 00000003  4F                dec edi
> > 00000004  E8F9FFFFFF        call 0x2
> > 00000009  60                pusha
> > > ./msfpayload win32_bind R | ndisasm -u -e 2 - | head -n 3
> > 00000000  EB4F              jmp short 0x51
> > 00000002  E8F9FFFFFF        call 0x0
> > 00000007  60                pusha
> >
> > 2. Self chaining function finding. In a windows shellcode that just
> > called 2 functions (WinExec() and
> > (ExitProcess|ExitThread|SetUnhandledExceptionFilter)) I decided to
> > have the exit function just take a bogus argument (specifically the
> > first argument to WinExec()) and have find_function chain itself. The
> > way I did this was I set-up a stack frame to something like this:
> > [ Arguments to WinExec() ]
> > [ Hash for exit function ]
> > [ Hash for WinExec() ]
> > [ &find_function ]
> > [ &find_function ]
> > then you can just ret and it magically works. find_function would
> > replace the hash for the function it found with the pointer to it so
> > you can develop payloads that chain themselves. Saved a couple of
> > bytes so I'm satisfied. :)
> >
> > 3. There are tons of different hacks about proper register usage/stack
> > usage depending on the case. A very simple example is doing:
> >
> > o16 push      byte 0x64
> > push  word 0x6d63
> >
> > to push cmd\0 on the stack in 7 bytes rather then clearing other regs
> > and pushing a null value, or putting a string in null reg and doing
> > lots of useless modifications. Or if the situation allows, set-up your
> > registers properly so that a pusha can save some space, etc, etc, etc.
> > I can go on forever with lots of little hacks, but I just wanted to
> > share some of the more interesting ones.
> >
> > > And if you're guessing on a single shot, you need to rethink your
> > > approach ;) Ofcouse when it's a single shot in the sense where you
> > > can't repeat your bug primitive at _all_ (even in 'crash once and it's
> > > gone' scenerios you can often come up with a sensible approach that
> > > rules out guessing to a fair extent), a smaller payload does have
> > > significant advantages.
> > >
> > > Now having said that, in practice it's always a game of adaptation,
> > > so if your 600 byte super fancy overengineered socket recycling rc4
> > > shellcode doesn't make the cut..you stage it..if the generic first
> > > stage
> > > is too big, you special case it abusing specific quirks in your target
> > > software that allow for smaller code (knowing a certain fd is always
> > > your socket, being able to assume there's only 1 active connection..etc.
> > > etc.)
> > >
> > > As far as platforms go, traditionally Win32 payloads have always
> > > been a bit of a pain in the ass size wise, requiring hashing routines
> > > etc. to be portable. Now there's a whole bunch of people who've done
> > > some neat research into making that less of an issue, most notably
> > > Oded's (I believe he was the first to go 'public', correct me if
> > > I'm wrong) ordinal work. Also the metasploit folk have done some
> > > cute work with regards to optimised win32 payloads.
> > >
> > > Ok my mailinglist quota for 2005 is almost full \o/
> > >
> > > Regards,
> > > Bas
> > >
> > > On Tue, Mar 08, 2005 at 01:07:27AM +0100, Gigi Sullivan wrote:
> > > > Greetings,
> > > >
> > > >    it's not my intention to send spam, despite the email's subject :)
> > > >
> > > >    What I'm referring to is related to shellcode (or call it whatever you
> > > >    want) size; it's common knowledge -- or at least it used to be so, IMHO --
> > > >    that it may be possible to experience size constraints while trying to
> > > >    overflow a buffer (just think about plain stack-based overflows without any
> > > >    kind of protection/mitigation techniques) so that one is unable to find
> > > >    enough space to store his fancy executable stuff... directly into the
> > > >    overflowable buffer.
> > > >
> > > >    So I was just curious: does size really still matters nowadays or we have
> > > >    enough space to do whatever we want in order to execute our shellcode [1]?
> > > >
> > > >    Are there any difference between OSes? (i.e. usually Windows apps offer (as
> > > >    a feature? :)) just enough space to do our job)
> > > >
> > > > TIA, bye
> > > > Lorenzo
> > > >
> > > > [1] yes, syscall proxying and other cool methods could help us developing more
> > > >     complex shellcode without worring too much about size, but I was thinking
> > > >     about old shellcode contests where the winner was who had it more
> > > >     little (always shellcode buddies, always shellcode :))
> > > >
> > > > --
> > > > Lorenzo Cavallaro `Gigi Sullivan' <sullivan () sikurezza org>
> > > >
> > > > Until I loved, life had no beauty;
> > > > I did not know I lived until I had loved. (Theodor Korner)
> > > >
> > > > See the reality in your eyes, when the hate makes you blind. (A.H.X)
> > >
> > > > _______________________________________________
> > > > Dailydave mailing list
> > > > Dailydave () lists immunitysec com
> > > > https://lists.immunitysec.com/mailman/listinfo/dailydave
> > >
> > >
> > > _______________________________________________
> > > Dailydave mailing list
> > > Dailydave () lists immunitysec com
> > > https://lists.immunitysec.com/mailman/listinfo/dailydave
> >
> > -vlad902
> > _______________________________________________
> > Dailydave mailing list
> > Dailydave () lists immunitysec com
> > https://lists.immunitysec.com/mailman/listinfo/dailydave
>
>
> _______________________________________________
> Dailydave mailing list
> Dailydave () lists immunitysec com
> https://lists.immunitysec.com/mailman/listinfo/dailydave


-- 
Please adjust the reply-to address.
_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
https://lists.immunitysec.com/mailman/listinfo/dailydave