Reversing bit order in delphi ? (unmoderated)
in [ASM]
|
Prev: Apple II Debugger
Next: TMA Assembler?
From: Skybuck on 22 Aug 2006 16:24 f0dder schreef: > Skybuck wrote: > > > I have already seen this code/algorithm. I consider it obfuscated. > > It's not obfuscated, it just happens to do "trickery bit magic". Just like > things like agner fog's strlen implementation. > > > Furthermore the compiler generates wacky assembler instructions which > > do not represent the C or Delphi code. > > Really? > > > Furthermore it's difficult to tell how the C/Delphi code works. > > A bit (hehe). I haven't bothered to do it, but it might help if you look at > the hex numbers in binary notation. I tried that. I didn't help much. It almost seems like the shifting isn't really what's happening it almost seems like a trick to fool compilers. But then again it could be shift magic and or magic ;) and probably a little bit of compiler magic. Whatever the case. No magic allowed in my competitions lol. It will be bench-marked and tested and verified but you won't get a cookie ! =D Bye, Skybuck.
From: Andreas Kochenburger on 23 Aug 2006 02:44 On 22 Aug 2006 08:29:38 -0700, "Skybuck" <skybuck2000(a)hotmail.com> wrote: >> unsigned int >> revere (register unsigned int x) >> { >> x = (((x & 0xaaaaaaaa) >> 1) | ((x & 0x55555555) << 1)); >> x = (((x & 0xcccccccc) >> 2) | ((x & 0x33333333) << 2)); >> x = (((x & 0xf0f0f0f0) >> 4) | ((x & 0x0f0f0f0f) << 4)); >> x = (((x & 0xff00ff00) >> 8) | ((x & 0x00ff00ff) << 8)); >> return((x >> 16) | (x << 16)); >> } >I have already seen this code/algorithm. I consider it obfuscated. Then all encryption algos are obfuscated? Wake up! Andreas ------- 1 + 1 = 3, for large values of 1.
From: Skybuck on 23 Aug 2006 18:36 Andreas Kochenburger schreef: > On 22 Aug 2006 08:29:38 -0700, "Skybuck" <skybuck2000(a)hotmail.com> > wrote: > > >> unsigned int > >> revere (register unsigned int x) > >> { > >> x = (((x & 0xaaaaaaaa) >> 1) | ((x & 0x55555555) << 1)); > >> x = (((x & 0xcccccccc) >> 2) | ((x & 0x33333333) << 2)); > >> x = (((x & 0xf0f0f0f0) >> 4) | ((x & 0x0f0f0f0f) << 4)); > >> x = (((x & 0xff00ff00) >> 8) | ((x & 0x00ff00ff) << 8)); > >> return((x >> 16) | (x << 16)); > >> } > > >I have already seen this code/algorithm. I consider it obfuscated. > > Then all encryption algos are obfuscated? > Wake up! Irrelevant. Please stay on topic. Bye, Skybuck.
From: Jamie on 23 Aug 2006 23:54 Skybuck wrote: > Andreas Kochenburger schreef: > > >>On 22 Aug 2006 08:29:38 -0700, "Skybuck" <skybuck2000(a)hotmail.com> >>wrote: >> >> >>>>unsigned int >>>>revere (register unsigned int x) >>>>{ >>>> x = (((x & 0xaaaaaaaa) >> 1) | ((x & 0x55555555) << 1)); >>>> x = (((x & 0xcccccccc) >> 2) | ((x & 0x33333333) << 2)); >>>> x = (((x & 0xf0f0f0f0) >> 4) | ((x & 0x0f0f0f0f) << 4)); >>>> x = (((x & 0xff00ff00) >> 8) | ((x & 0x00ff00ff) << 8)); >>>> return((x >> 16) | (x << 16)); >>>>} >> >>>I have already seen this code/algorithm. I consider it obfuscated. >> >>Then all encryption algos are obfuscated? >>Wake up! > > > Irrelevant. > > Please stay on topic. > > Bye, > Skybuck. > you guys are nuts, i've coding Assembler with various processors over the years and all i had to worry about was byte order!, (big endian/little endian). the only time bit ordering had to be worked with is when you may receive data from some sort of serial device or encryption code to get it in the correct order. this has nothing to do with the platform your on... i have copied over piles of source code that was originated on Big Endian platforms over to little Endian that contain all kinds of bit operations etc.. never had a problem and never had to change anything other than byte order coding .. -- Real Programmers Do things like this. http://webpages.charter.net/jamie_5
From: jukka@liimatta.org on 24 Aug 2006 04:07
> Also the code does not seem to make much sense, at first glance anyway, > and even after further inspection it's unclear what it does, how it > works, or how it can be extended to more than 8 bits. I don't understand what is so unclear about how it works. > Obfuscating is not allowed in my competitions, so this algorithm/code > is disqualified ! ;) =D It is not obfuscated, the method name clearly states what the intent is, if the name doesn't work out for you rename it to reverseBits() and it should make more sense. That's why we NAME functions so that you can determine what they are supposed to do. > Thank you for participating, you are free to try again and this time in > clearity, and then you can come again =D lol, have a nice day ! =D What you mean? The code is quite clear, let's rehash: > > v = ((v >> 1) & 0x55555555) | ((v << 1) & 0xaaaaaaaa); > > v = ((v >> 2) & 0x33333333) | ((v << 2) & 0xcccccccc); > > v = ((v >> 4) & 0x0f0f0f0f) | ((v << 4) & 0xf0f0f0f0); > > v = ((v >> 8) & 0x00ff00ff) | ((v << 8) & 0xff00ff00); > > v = (v >> 16) | (v << 16); Look this from bottom-up, what does the LAST statement do? v = (v >> 16) | (v << 16); It swaps the lowest and highest 16 bits. Then what does the statement BEFORE that do? Yes, it swaps the 8 bit quantities within each 16 bit quantity. And so on, until single bits are changing position inside 2 bit groups. In the end, well, the bits are reversed. It's so painstakingly obvious when you read the code that I was taken completely by surprise that such basic bit operations could be considered obfuscated! I'm baffled, I really am. G'day to you aswell sir. |