«

On Wed, 15 Dec 2010 15:16:48 -0800 (PST), RayLopez99 wrote:

> On Dec 16, 12:48*am, Dustin <bughunter.dus...@gmail.com> wrote:
>
>>
>> buffer overflow can be a code or database exploit. Damn, just check
>> microsofts december patch list for several. Some of the information is
>> pretty detailed; but I think if you quit with the high horse nonsense you
>> can pick it up. and, if you don't understand something; You'll have a
>> better chance of getting a useful answer.
>>
>
> Why don't you please explain it then, instead of just saying "it's
> pretty detailed"? Most of Microsoft's patch list and breaking code
> list stuff to me sounds pretty cryptic, then again I don't belong to
> their MSDN subscriber package, which costs a couple of thousand a
> year, so maybe I don't get the detailed explanation.
>
> RL

Yeah, Dustin why not do all the work for this lazy bastard.

*LOL*
--
http://tr.im/1fa3

RayLopez99 <> wrote in
news:72789ea2-a4e9-4346-a195-:

> Well perhaps you are correct, as by definition a run-time error like
> overrunning a buffer will not be caught by the compiler. But of
> interest is the claim in this thread that even though a program
> infected (or attacked) will crash, the vector (virus) program will
> continue in memory--that was news to me. Further explanation is
> requested--don't see how that can be possible--I would think Windows
> would have a protected memory space and if a program crashes
> everything in that space is zeroed out, but I guess such sandboxing
> is not done by Windows.

Depending on how you achieve the buffer overflow; you're intended
instructions *may* get executed. It's not a guarantee. Google likely has
many user friendly explanations for a buffer overflow situation. I'd
recommend reading one or two articles and come back if you have specific
questions on it. They are runtime errors; thanks to (imo) poorly written
code. IE: lacking a string check to ensure the data your fixing to put in
the buffer will fit.


--
Hackers are generally only very weakly motivated by conventional rewards
such as social approval or money. They tend to be attracted by
challenges and excited by interesting toys, and to judge the interest of
work or other activities in terms of the challenges offered and the toys
they get to play with.

RayLopez99 <> wrote in
news:701744dc-1c32-412e-a187-:

> On Dec 16, 12:48*am, Dustin <bughunter.dus...@gmail.com> wrote:
>
>>
>> buffer overflow can be a code or database exploit. Damn, just check
>> microsofts december patch list for several. Some of the information
>> is pretty detailed; but I think if you quit with the high horse
>> nonsense you can pick it up. and, if you don't understand
>> something; You'll have a better chance of getting a useful answer.
>>
>
> Why don't you please explain it then, instead of just saying "it's
> pretty detailed"? Most of Microsoft's patch list and breaking code
> list stuff to me sounds pretty cryptic, then again I don't belong to
> their MSDN subscriber package, which costs a couple of thousand a
> year, so maybe I don't get the detailed explanation.

To be honest, I'm of the mindset that you need to have done your homework
as best as you could before asking general questions about the subject.
IE: you would already know the answer and then you can ask specific
questions you might not know, AND, you'll understand my and others
replies to them. I'm not trying to come across as a wiseass or anything
like that nor do I intend to insult you.


--
Hackers are generally only very weakly motivated by conventional rewards
such as social approval or money. They tend to be attracted by
challenges and excited by interesting toys, and to judge the interest of
work or other activities in terms of the challenges offered and the toys
they get to play with.

RayLopez99 wrote:
> On Dec 15, 11:52 pm, FromTheRafters<erra...@nomail.afraid.org> wrote:
>
>> You might want to investigate heap spray techniques as well. Sometimes,
>> the attacked vulnerable program does indeed fall over, but the attacker
>> has enough control to corrupt the heap (in multiple places, and with NOP
>> sleds) so that another program *might* run the code that was sprayed there.
>
> Why doesn't Windows have a sort of sandbox, so if a program crashes,
> everything in that memory space is erased (zeroed)? That would make
> sense. Don't see why NOP (no operation?) should work in a crashed
> program.

Another program running along might eventually hit the code that
corrupted their memory space and run it, but it would have to hit that
code right at its starting point. If you lead in to the starting point
with NOPs it provides a bigger surface and a greater likelihood that the
program flow (when it is its turn to run) steps into the corrupted area.
The NOPs act like a sled sliding the execution path right up into the
malicious code's starting point. While the NOP doesn't actually do
anything, the instruction pointer will still be incremented.

Ant wrote:
> "FromTheRafters" wrote:
>
>> You might want to investigate heap spray techniques as well. Sometimes,
>> the attacked vulnerable program does indeed fall over, but the attacker
>> has enough control to corrupt the heap (in multiple places, and with NOP
>> sleds) so that another program *might* run the code that was sprayed there.
>
> That's not correct. Each program has its own isolated memory space
> even if it's the whole of memory. That's why it's called virtual
> memory. Only the kernel has access to physical memory (in theory!)
>
> Heap spraying in one program's address space can't corrupt memory
> used by others.

I stand corrected.

I was trying to point out that execution of the malicious code's payload
is not guaranteed - sometimes just a DoS and sometimes more.

On Wed, 15 Dec 2010 21:12:25 -0500, FromTheRafters wrote:

> Another program running along might eventually hit the code that
> corrupted their memory space and run it, but it would have to hit that
> code right at its starting point. If you lead in to the starting point
> with NOPs it provides a bigger surface and a greater likelihood that the
> program flow (when it is its turn to run) steps into the corrupted area.
> The NOPs act like a sled sliding the execution path right up into the
> malicious code's starting point. While the NOP doesn't actually do
> anything, the instruction pointer will still be incremented.

Nope.
--
"When the Sicilians put out a contract, it's usually limited to the
continental United States, or maybe Canada or Mexico. But with the
Corsicans, it's international. They'll go anywhere. There's an old
Corsican proverb: 'If you want revenge and you act within 20 years,
you're acting in haste.' " ~Lou Conein

On Dec 16, 2:56*am, Ari Silverstein <AriSilverst...@yahoo.com> wrote:

> Yeah, Dustin why not do all the work for this lazy bastard.
>
> *LOL*
> --http://tr.im/1fa3

All you do is "laugh out loud" like the loudmouth crazy you are. LOL.

RL

On Dec 16, 4:00*am, "Ant" <n...@home.today> wrote:
> "RayLopez99" wrote:
> > But of
> > interest is the claim in this thread that even though a program
> > infected (or attacked) will crash, the vector (virus) program will
> > continue in memory--that was news to me. *Further explanation is
> > requested--don't see how that can be possible--I would think Windows
> > would have a protected memory space and if a program crashes
> > everything in that space is zeroed out, but I guess such sandboxing is
> > not done by Windows.
>
> I should have been clearer - the malware can't continue in the memory
> space of the program it overflowed after it has crashed. The program
> won't crash until the malware has done its dirty work because in
> effect, the injected code has become part of that program. While the
> malware is running, the original program code is not. The program will
> probably crash if the injected code hands control back to it.
>
> Sometimes the malicious code will terminate the original program
> anyway by calling, say, ExitProcess. I've seen this with infected
> PDFs, where the shellcode first drops and runs the payload, drops a
> clean PDF, but before killing the PDF reader, starts a new instance
> of it to display the clean file. The user may not notice anything is
> amiss.

You sound knowledgeable. Or you're a good faker. In either event,
what language would this virus stuff be running at, what API? Is this
some Javascript, or something unique to Adobe's API (whatever language
they use, probably Java or some variant), or is this virus stuff based
on the Windows API that back in the days I played around with in the
MFC, or all of the above or something else? Perhaps this virus stuff
is done in assembly language, or IL pseudocode for .NET that is
injected in with the good code? It's all very confusing how such
apparently piggybacking is done, especially since at least with .NET
all assemblies are cryptographically signed so you cannot introduce (I
think) bogus or extraneous executables with your package.

RL

Ari Silverstein wrote:
> On Wed, 15 Dec 2010 21:12:25 -0500, FromTheRafters wrote:
>
>> Another program running along might eventually hit the code that
>> corrupted their memory space and run it, but it would have to hit that
>> code right at its starting point. If you lead in to the starting point
>> with NOPs it provides a bigger surface and a greater likelihood that the
>> program flow (when it is its turn to run) steps into the corrupted area.
>> The NOPs act like a sled sliding the execution path right up into the
>> malicious code's starting point. While the NOP doesn't actually do
>> anything, the instruction pointer will still be incremented.
>
> Nope.

You are correct, I miswrote. (

My point was that the overflow does not *always* cause an immediate
result, nor does it guarantee a particular result.

On Thu, 16 Dec 2010 12:52:55 -0500, FromTheRafters wrote:

> Ari Silverstein wrote:
>> On Wed, 15 Dec 2010 21:12:25 -0500, FromTheRafters wrote:
>>
>>> Another program running along might eventually hit the code that
>>> corrupted their memory space and run it, but it would have to hit that
>>> code right at its starting point. If you lead in to the starting point
>>> with NOPs it provides a bigger surface and a greater likelihood that the
>>> program flow (when it is its turn to run) steps into the corrupted area.
>>> The NOPs act like a sled sliding the execution path right up into the
>>> malicious code's starting point. While the NOP doesn't actually do
>>> anything, the instruction pointer will still be incremented.
>>
>> Nope.
>
> You are correct, I miswrote. (
>
> My point was that the overflow does not *always* cause an immediate
> result, nor does it guarantee a particular result.

Yep.
--
If you really must fellate me,
Though the thought appalls;
Remember work the shaft
And cup the balls.
http://tr.im/1f71