I put this in Security, as I thought it would more likely attract people knowledgeable about the subject, than in the general slack 12.0 forum.

Anyway, as is indicated, I'm using slack 12.0 and kernel 2.6.21.5-smp.
I am a C programmer and I like to experiment with various exploitation techniques, such as buffer overflows and format string vulns and et cetera. However, due to various reasons, I haven't been using linux for almost, well, 6 months now, and therefore haven't really been playing around with those techniques.

I decided to start again, as I just got a new laptop, and downloaded and install slack 12.0.

During my endeavors to exploit a simple application locally, I've run into nothing but trouble. First, I noticed that the kernel used stack address space randomization, and found out how to disable that. However, I also noticed how sometimes, the little-endianness(this is the only way I can describe it really) was strange. Like it reverse the bytes in two-byte words instead of 4 byte words.

An example would be the following:

I have shellcode which spawns a shell when executed. On the disk, for some reason, it looks like this:

but disassembles to

As you can see, all two byte words are reversed. 31c0 on disk becomes c031, and 46b0 becomes b046.

This is bad, because one of the exploitation techniques is, for example, to cat the shellcode from the disk into an environment variable and then retrieve the address of it, then overwrite a buffer and make it execute the code in the variable.

However, if the code is wrong in the environment variable, I can't really do that.

So I ask: What is causing this? Is this the kernel using some optimized memory management that wasn't in slack 11.0's default kernel, or is it the file system? I'm using ext3, by the way.


All help _greatly_ appreciated. I've just promised to hold a lecture on the subject in an irc channel I frequent, and I can't really do that if I can demonstrate the techniques.

You can always install slack 11 and compare... your lecture shows that the technique used to work but not any more and why.
You mean: this is good because a common and well-documented exploit has been blocked?

Presumably you can reverse the byte order in the command to compensate...

However - you'll see the reversal is not restricted to the 2-byte words. In fact each consecutive pair is reversed. Look:

Dump:
c031 46b0 db31 c931 80cd 16eb 315b 88c0 0743 5b89 8908 0c43 0bb0 4b8d 8d08 0c53
Decomp:
31c0 b046 31db 31c9 cd80 eb16 5b 31c0 884307 895B08 89430c b00b 8d4b08 8d530c
regroup (compare with top):
31c0 b046 31db 31c9 cd80 eb16 5b31 c088 4307 895b 0889 430c b00b 8d4b 088d 530c

This a quirk of the representation ... the hex-dump representation does not list the bytes in the address order.

addr:byte
00 31
01 c0
02 b0
03 46
04 31
... etc.

remember that 00 is to the right, and the bytes are just a long row of 1's and 0's written as one number, like this: 3156b0c031, see?

When you dump that, you list the zeroth-order pair first: c031, then the first-order pair 46b0 ... etc. This gives you the reversal you see.

If you still don't get it - do it in binary: bit0 of the code is bit0 of byte0, bit8 of the code is bit0 of byte1, etc. It is written as one number, then divided up into 16-bit blocks for ease of reading. Then the hexdump just lists the blocks in order from lowest to highest.