@RSnake

Um.. it was a typo, :) i had few beers to much while typing i guess.

@dveditz

did not looked into it that much, but that's ugly.

Still the issue lies not in they way how they should blacklist and it's equations or implementing issues, that's the next level. Still it's about flaws in it's matching against that list that bothers me.

I followed some links on the post on ha.ckers.org to some spanish/mexican site just now, and i saw that they have made a patch for it: https://bugzilla.mozilla.org/attachment.cgi?id=244261

Little too late imo, have to wait until the next update.

Well, i guess until then i surely have a few more free days to poke some holes into that one :)

Interesting to read some of these... I hadn't seen this form of obfuscation before:

testing["12.0x12.01234"] = "12.18.2.156";

What format is that last string "01234"?

- RSnake
Gotta love it. http://ha.ckers.org

I think DWORD?

Like: 69.12.144.65 is in DWORD: 1158451265

Though on your IP it doesn't seems to work? :)

http://www.mcse2000.com/urlconvert.php

edit to add: Info page
http://searchlores.org/obscure.htm



Edited 1 time(s). Last edit at 11/06/2006 11:12AM by jungsonn.

No, it's not a dword... that's all covered on the cheatsheet. In that case it's a tritet (as opposed to a quotet I guess). It's something strange. It doesn't appear to be base 8 or base 6. But I also might be doing something wrong.

- RSnake
Gotta love it. http://ha.ckers.org

Yeah i allready thought why doesn't he remebered that... :))

Indeed i can't see what 01234 has todo with 2.156, tryed many conversions back and forth, but doesn't add up...

it is base 8 .. as the octet 1234 == decimal 668

and 668 mod 256 = 156 ..
and floor(668 / 256) = 2

thus the 2.156

so it'd prolly be called a WORD, rather than DWORD

-maluc

Interesting. That really is a completely new form of URL obfuscation I hadn't seen before. Tricky. I love it.

- RSnake
Gotta love it. http://ha.ckers.org

Does it work when you convert it backwards?

RSnake, woudn't this be a nice article, or cheatsheet to make? like all forms of encoding an url? could come in handy now and then.



Edited 2 time(s). Last edit at 11/07/2006 10:25AM by jungsonn.

What do you mean "backwards"?

- RSnake
Gotta love it. http://ha.ckers.org

From base8 to decimal gives me this: 234 -> 156

so you get:

testing["12.0x12.2.234"] = "12.18.2.156";

think that doesn't work?

Right, that wouldn't work. I bet it makes an assumption about it being in decimal unless it can't be. The real question is why would they bother coding this into browsers at all? How many people are writing URLs like this, and even if they are, why allow it? It just makes it harder for everyone downstream.

This is something I'm not sure most browser companies really understand (or put enough thought into) - every change or addition that they make to their browser effects every website that accepts data, because the website has to know what can and can't be used against it's own users when the information is reflected. (And don't get me started on the effects on every plugin that uses that information.)

If there aren't standard libraries to deal with the information being displayed back to the user that match what the browser companies allow and render there really is no way to get ahead of the arms race.

- RSnake
Gotta love it. http://ha.ckers.org

Yeah it reads it in octets (base8), so it was a silly post.
Had my fun, and i'm in need of a very long sleep

~_~ ha.

> The real question is why would they bother coding this into browsers at all?

It's standard inet_addr(), it's happening below the browsers.

http://www.opengroup.org/onlinepubs/007908799/xns/inet_addr.html
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/winsock/inet_addr_2.asp

That makes sense, but I'm still not sure why it would even be coded into that library other than having it as an academic exercise. It doesn't have any actual value. MSDN had a funny comment that they are only allowing it to be compatible with Berkley. Since when are they worried about compatibility of obscure non-useful IP encoding methods? I think it's time to break that code, otherwise every web application that takes IPs will have to normalize it in the same obscure way.

- RSnake
Gotta love it. http://ha.ckers.org

got my first phishing email that use hex dword obfuscating today..
http://0x3b3c06ce/security/paypal/

there really is no reason for browsers to support these encodings =.= .. especially now that they're all in the business of anti-phishing

i wonder if the department of defense can be convinced to lend me 11.0.177.53 for the ultimate nerd-pron website http://0xBO0B135 ..

-maluc

hahahahahahah!

Okay, whew... But yah, that's a really bad thing for browsers to support. As it is all coming from the base class, I think it's about time to start a new class that doesn't do all this overhead. I wonder how much memory it would save in not bothering to do translations or having it compiled and in memory?

- RSnake
Gotta love it. http://ha.ckers.org

lol.