Results 1 to 9 of 9

Thread: Basic transport and portability formats for the Internet?

  1. #1
    Junior Member
    Join Date
    May 2004
    Posts
    2

    Basic transport and portability formats for the Internet?

    Hello there

    I'm looking for simple techniques for obscuring website sources and rendering them unreadable by humans.

    I'm using php to make scripts to help protect websites against reverse engineering. I'm a newb to all this and this is my first 'project' so any input would really help me out!

    So far the only useful thing I've come across is devolution. Where you'd use Hex to display a URL or ascii codes in place of markup text. Do you know of any other way I can approach the project?

    Currently I'm leafing through dns papers and browser specs but can you suggest any other areas I can look into? A similar opensource project or something would be great!

    Hope nobody minds if I post in here. Even tho it' dosn't really involve cryptology. Wasn't sure where else I might find advice on the topic.

    Cheers,
    ~ Archie.

  2. #2
    I'd like to see some of the links you have already. Reverse engineering websites doesn't sound right to me... I just view the source. If the source was encrypted, the browser wouldn't be able to read it.

    I'm currently messing around with encryption a bit, maybe you can fill me in on what you are doing a lil' bit better, doesn't sound like I'm up to speed.

  3. #3
    HeadShot Master N1nja Cybr1d's Avatar
    Join Date
    Jul 2003
    Location
    Boston, MA
    Posts
    1,840
    check this thread out...you might get some Ideas:

    http://www.antionline.com/showthread...te+source+code

  4. #4
    Junior Member
    Join Date
    May 2004
    Posts
    2
    There's an interesting link in there for the HTML Protector app. Downloading it now for a look

    It mentions keeping links and email addresses in a central file or database. Then the ones that get marked up on a broswer must reference it with encrypted versions. So when you rotated the key all the referances would fail! That would really get up the nose of contact/ link harvesters...

    It'd be well cool to encrypt your own internal markup language in the same way!

    Soda, I'll see if I can find some links to examples (my bookmarks are a mess!) This is a good page on some of the things you can combine together to obscure links and urls;
    http://www.pc-help.org/obscure.htm

    I was thinking of using a document.write() script as a server plugin to allow the sourcecode to be transmitted in Hex
    (%61 for A)
    and ascii (& followed by #65; for A).
    The browser can interpret it just fine but the code is far from readable.

    Just found THIS example of what I mean. Check out the sourcecode. I've yet to find a free one but the methods used are so simple that everyone should have acess to it.

    Thanks a lot for your help guys!
    ~ Archie.

  5. #5
    Thats pretty interesting, I've never heard of transferring html in hex, but although it would be unreadable to someones eye, it wouldn't be unreadable to a bot. I checked out some other methods, such as using a javascript algorithm to encrypt the source-

    I remember Tiger Shark had an email a while ago encrypted this way. When you viewed the source, it would only show a crazy algorithm. Instead of decrypting it, I used activeX to output the script to a text file instead of a browser window. Then it showed me the html. Although it did hide it from the browser, and would possibly do the same to some gathering bots. The problem with this, is that javascript is client side programming, and php tags wouldn't be passed as they are server side.

  6. #6
    Senior Member
    Join Date
    Jul 2003
    Posts
    634
    I dont know whether this would work as Im not really into my website developement stuff, basically you could have you website pages encrypted and a CGI script to de-crypt them. basically all this is server side, then you have a basic HTML page to pass arguments to the html script to decode them,

    I can think of quite a few weaknesses in this but you might be able to do something with this....

    you could just make a php script to convert everything to an image, and display this instead of the page, if you see what i mean....not that nice though really maybe to slow

    i2c

  7. #7
    I dont know whether this would work as Im not really into my website developement stuff, basically you could have you website pages encrypted and a CGI script to de-crypt them. basically all this is server side, then you have a basic HTML page to pass arguments to the html script to decode them,
    I think you just defined the "password"

    you could just make a php script to convert everything to an image, and display this instead of the page, if you see what i mean....not that nice though really maybe to slow
    A buddy of mine is using images generated on the fly, and it slows down the page a lot. And you wouldn't be able to link anywhere without image maps, which requires you to show HTML

  8. #8
    Senior Member
    Join Date
    Jul 2003
    Posts
    634
    Heh, oh yea...it does look very much like a password....Wasnt what I intended but can't think of a better way to explain in.

    i2c

  9. #9
    Senior Member
    Join Date
    Oct 2001
    Posts
    786
    I have run into many JavaScript encryption type pages, and I'm quite sure they are effective against bots collecting links. The simplest one I've run into was one that had an extreamely long hex-encoded string passed to a function to write it to the page. Unless the bot can read through the hex string, I doubt they'd execute the JavaScript code to get the decrypt functions working. So these methods can be considered somewhat safe against harvesters.


    The "LockCode HTML Encryption" is quite simple. (Security through obscurity) I've already managed to peek into its main decryption engine, but I will stop working on fully exposing the source since I must go to sleep for school tomorrow. Basically, the unescape is the first thing the browser can understand. After that, it has the decryption engine to decrypt everything else. With the unescape part, they even "encrypted" indentation of the code in their own decryption engine to make it fairly easy to read upon decryption...

    It shouldn't be too difficult to reverse-engineer it to produce something that can encode in it's specific format, but I'll keep away from that since it is only the decoding that I'm worried about, and the only thing that requires "compatibility." (Also, it would be illegal to recreate their exact encryption engine, or at least they would sue those who do it)

    It is perfectly legal to use the JavaScript unescape function and its corresponding function (don't have time to look it up, but escape maybe?) to create your own thing. Infact, I had started work on something like this nearly a year ago to protect IE-specific HTML code...

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •