Describe Strcpy buffer overflow.

First we must consider that built-in machine architecture decisions impact the way you exploit these issues. For example, in the classical writing Smashing the stack for fun and profit by Aleph One, we can see that an x86 stack typically grows downward (i.e. the base for the stack is the highest address, and as we push onto it, the stack pointer decreases in value)...

Depending on the implementation the stack will either grow down (towards lower memory addresses), or up. In our examples we'll use a stack that grows down. This is the way the stack grows on many computers including the Intel, Motorola, SPARC and MIPS processors.

So for example, assuming your compiler doesn't rearrange the order in which bufferA and bufferB are pushed onto the stack, Aleph One describes an architecture where-by bufferB actually has an address which is lower than that of bufferA. I'm pretty sure this explains your observations correctly; when you overflow bufferB, you're not actually overwriting the return address, but a part of bufferA (or some padding before bufferA). You could verify this by codifying your assertion, such that your runtime will validate it (by either succeeding or generating an error message), like this:

assert(bufferB < bufferA>

Now having said all of this, there are many, many other issues standing in the way of successfully demonstrating a stack-based buffer overflow. Various protections have been created, such that the only reliable reproduction is typically referred to as a ret2libc attack, and that requires quite intimate knowledge of the specific hardware and OS configuration. As such, I recommend that after reading the paper by Aleph One (linked to above) and before attempting to reproduce that experiment, I highly recommend watching this DEFCON video entitled "(un)Smashing the Stack: Overflows, Countermeasures, and the Real World". Once you've reviewed these two resources, I'm sure you'll have a much better chance of reproducing a strcpy buffer overflow.