improve upon the algorithm used in macchanger

[feitoi]

If offset is non-negative, the offset'th digit of the MAC Address, counting from 1. 1 = first digit, 0 = MAC changer disabled.

If offset is negative, the offset'th digit from the end of MAC Address. -1 = last digit.

[rofl0r]

i applaud your effort to improve upon the ultra-naive algorithm used in macchanger, however this can be easily solved without changing/complicating command line option. the solution i was planning to do in the coming days is something like this:

void set_next_mac() {
uint32_t last4bytes;
unsigned char newmac[6];
memcpy(newmac, get_mac(), 6);
memcpy(&last4bytes, newmac+2, 4);
++last4bytes;
memcpy(newmac+2, &last4bytes, 4);
set_mac(newmac);
}

[feitoi]

Nice! I liked! The first 3 bytes of the MAC address are more significant, changing one of those 3 is fine. And passing the ultra-naive algorithm to a function, it got even better. I didn't know that the order to copy the bytes from unsigned char to uint32_t with memcpy () is like this. Another new knowledge for me, thank!

[rofl0r]

i used last 4 bytes because there's no 3-byte integer type on which to do arithmetics upon (here: increment). in the end, it doesn't matter at all which values are used, we could just as well use rand(). the first 2 bytes should just stay simply for the purpose that there are some reserved mac prefixes like, iirc 0100 and similar things for broadcasts and all types of things. regarding that, maybe we should prevent the last byte from being 0 and or 255 for the same reason, so the code should, after incrementing last4bytes, do something like while(l4b & 0xff == 0 || l4b & 0xff == 0xff) l4b++;. i didn't test above code yet, it may well be that we need to do a switch from bigendian to little and vice versa before and after the increment to achieve the intended effect. (see end_be32toh and end_htobe32 in endianness.h)

[feitoi]

Did it missing parentheses around (l4b & 0xff)?

do {
    l4b++;
} while ((l4b & 0xff) == 0 || (l4b & 0xff) == 0xff);

[rofl0r]

Did it missing parentheses around (l4b & 0xff)?

yeah, this is pseudo code so far...

[feitoi]

After learning a little about little endian and big endian, when doing arithmetic with 1 byte, we don't have to worry about endianness. I modified it to don't change the first 2 bytes, use rand() to choose the 1 of the last 4 bytes and prevent the last byte from being 0 and or 255.

[rofl0r]

what would be the advantage of incrementing a random byte, rather than just the entire mac address (or last 4 bytes of it, which gives 2**32 possible values)?

After learning a little about little endian and big endian, when doing arithmetic with 1 byte, we don't have to worry about endianness.

yeah, but if we want to just increment the mac and start from least significant byte, we'd have to, afaics.

[feitoi]

what would be the advantage of incrementing a random byte, rather than just the entire mac address

Nothing. Just an naive thinking.

Reserved mac, broadcasts, multicast and all types of things should be treating in option -m (lowercase).

So, I simply modified it to increment by 1 and to prevent the last byte from being 0 and or 255. I believe this is good.