This is a basicl explanation as to how dynamic
signatures work. A dynamic signature can be created very easily with a
little bit of knowledge in PHP and planning. To use a dynamic signature
access to an Apache based server with a GD plug-in is required; being
that the .htaccess files needs to be modified to parse a jpg type file
as a PHP, hence tricking the server to think it is displaying an image
file; jpg is commonly used as it supported by pretty much all browsers.
You simply modify the .htaccess file as mentioned above, you then
create the signature via PHP code which structures the background
images, colors, text so as to create the layout you wish.  Now when
publicly viewing a dynamic signature only the person viewing the page
will be able to see the information displayed as it is only specific to
them, thus other user A will never be able to see user B’s information
and visa versa; unless of course they are together in the same room and
are looking at each other monitors.




As well, more advanced dynamic signatures enable the possibility to
pull data from files via the remote server file and parse that data
into the displayed signature for display such as in the case of a “This
signature has been viewed by X number members since a given date”
comment sometimes seen in others signatures, or a similar random quote
feature. Though all information is processed locally on the server-side
where the files for the dynamic signature are actually contained and
then the requesting image is then passed and displayed on the remote
active server that is making the request for the image or (dynamic
signature), where then the coding syntax (PHP) included within that
image is to be converted or parsed into their appropriate values
locally for each user viewing that signature, these values contain each
users own information as passed visa vi the server they active within
locally.




PHP and JavaScript both have rules built into them which both limit
and restricts the functions they are capable of performing (i.e.
JavaScript is not able to covertly delete your files, format your
drive, etc.), this was done to prevent developers, hackers, and the
like from abusing the users of their sites, thus there is no way to
capture any of the so called “private” user information and store it,
as it basically in a read only format, i.e. it is an image that is
being displayed, or more precisely a dynamic image that changes itself
for each individual viewer. Worms and viruses can never be passed
through any form of a signature dynamic. Dynamic signatures can’t send
monitoring files to your computer, although it may be possible to set a
cookie via a dynamic signature it would never function correctly s
cookies can't portal information from one server to another. PHP does
not have that type of functionality built into it when using this type
of an application. These restrictions are known as web-standards and
semantics and are decided by the W3 or World Wide Web Consortium http://www.w3.org/.
In fact a hacker would have much better luck gaining administrative
access by either cracking the admin’s password and finding the users IP
address and other personal information or by hacking into their SQL
databases and decoding the user fields.




There are many tutorials and templates available that show you the
exact steps for creating and enabling a dynamic available, simply
Google similar to: “creating a dynamic signature”. Now your Kung Fu has
grown stronger!

Rexx Let me get this straight, are you saying that a consortium of what 500,000+ of top intenet gurus stating for the record that somethin like Cerne's little IP reflector CAN NOT have a virus or worm, or used as a hack.
and EARTH's new rule has no basis, and just like Sage,the sysop, we Have a ADMIN, that didnt do his home work and posted to everyone Cerne is infecting them with a Virus! TOTALY UNBELIVEABLE!!!!
Just another reason to get the hell out of dodge, and move to greener pastures!!!

lol

No, Earth couldn't be bothered to direct complainers (most likely the mindless UTW crowd acting under Sage's orders) to the correct solution.

All i know is I never got a Virus from Cerne's little Dynamic Signature. and I went to the place he got it from, and didnt get a virus from them, nor did i get a tracking cookie from them? and I have 2 systems, you would think one of them would show something over the last 3/4 weeks Cerne had his funny little signature up? cant belive
Just how peeps are totaly clueless, HELLO it's the super information hiway, do a micro bit of search for info. might be suprise what you find is false or truth.?

[long msg]

Cern's image DOES NOT have a virus or other hack to it, that is correct. That isn't to say it's impossible to hide a virus inside an image, it just requires a weakness in a browser (IE had one a while back) that allows it, and even then... this is very difficult (it's never been done publically, only listed as a theoretical vulnerability) to do. This is also why browsers have frequent updates, to prevent vulnerabilities from being such a problem. The thing is, there's no need for such an image to send any real output back to the viewer. It could be a single pixel image, completely invisible... and still carry the same risk. Infact no virii would ever make itself so obvious, takes the point out of it completely.

Javascript can do a number of things, and it's a little hairier in the weaknesses dept... but you don't need javascript to write cern's sig prog. I have a similar program on navhaz, except it doesn't use the gdlib and is a php file. It's intent is to give sysops an accurate account of their IP and browser settings incase they are having problems (WTH is my IP?!? comes up a lot w/ a NAT and a dynamic address).

Foreign javascript is not possible in these forums. Infact, in general, it's never a good idea to allow since it opens up the door for what's called a "cross site scripting" attack (referred to as XSS). An XSS attack would allow you to gather anyone's password and possibly gain admin access on the site. I'm sure Earth has it filtered. Javascript is client-side (ran from the browser) where PHP is server-side (ran on the server in a protected environment).

It is possible to set a cookie with the image, but this is unneccessary. It is possible for a cookie domained by one site to be accessed by another, but it requires very lax security on the part of the browser. There have been vulnerabilities in IE that permit this but I believe they have been fixed. It would be possible to make access records available thru a private XML interface, so one site could very well access another's information... but it would require the complicity of both sites. Web service APIs like that are very common, however, and pretty useful as an admin.

Most password fields in databases such as these are uncrackable. They are what are called a "hash." A cryptographic algorithm is ran on the text. It is 1-way meaning that the resultant hash cannot be reversed back to the original text. When you go to log in it hashes what you type and checks it against the DB, if it's not correct it denies access. If you forget your password it generates another temp password instead of sending you the old one (since it can't know the old one). The math required to crack most decent hash algorithms (md5, usually) is substantial and takes enough time to make it pointless. Instead if someone finds an "sql insertion" vulnerability they will simply insert another user row into the database, that user set with admin privs. That's a lot easier than trying to crack a password in most cases.

The W3C has no baring on php or other scripting languages. PHP is a privately owned language (php.net), there's also asp, ruby, python, perl, and many many others.