Can link messages be eaves-dropped?

In order to make some of my objects more efficient, I am considering using UUIDs to set textures, instead of actually giving copies of the textures.

In order to do this the root prim of my object will use llMessageLinked to send the UUID to the appropriate prim.

Here is the question: Is there any (reasonable) danger of people being able to steal these UUIDs out of the message stream? My *assumption* would be that they are fairly safe, because there is no reason to send such messages to the client: They *should* stay on the server only, and not be readable from the client ....

but is this true? I don't want to sell an item to someone, and then when they use it with their own texture they accidentally give away their UUIDs. I also don't want to have to fool around with scrambling my messages unless it is really necessary.

Link messages can only be "sniffed" by other scripts in the destination prim(s). Thus, if your object is modifiable in some way and allows people to drop listener scripts into one or more target prims, then yes, they can easily display the contents of those messages to anyone.

There are a few ways to combat this. One way is to use a changed() event, looking for any inventory change, and immediately delete anything that doesn't belong there. Another is to make the object and all its prims no-mod, but you are at the mercy of the permissions system, and any bugs introduced which allow people to bypass it at some point (it has happened numerous times in the past; it will happen again). Yet another way is to encrypt your messages; sadly, though, strong encryption in LSL is practically nonexistant.

If all you are doing is wanting to change a texture from a static list, put the list into the script and send the index of the selected texture in the link message. However, if the texture could be anything at all, specified by you or the owner, then you will have to fall back to one of the options above or something similar.

Yes, it's definitely possible to eavesdrop, depending on who it is you don't trust. If your object is modifiable, then the buyer can stick a script in to monitor link messages. If it's not modifiable, they can still rip the script out and put it in another object, and coerce it into trying to communicate via link message and snoop the messages with another script.

Then again, there are also other ways to get any texture UUID in-world, so perhaps this isn't so big a vulnerability.

I may be wrong in this, but it's my understanding that even if they get the UUID to your texture, if you have the perms set right on the original texture in your inv, they won't be able to use it.


I think they would only be able to use the UUID if you set the perms to copy/mod/trans or some combination like that. Using the UUID is the same as clicking on the texture in your inv and dragging it onto an object. If you don't have the right perms, SL won't let you use it.

It is possible to encrypt the UUID you send by link message...

string crypt_key = "12345678-9abc-def0-1234-56789abcdef0";
string crypt_key_64;

string encrypt(string in)
{
    return llXorBase64StringsCorrect(llStringToBase64(in), crypt_key_64);
}
default
{
    state_entry()
    {
        crypt_key_64 = llStringToBase64(crypt_key);
    }

    touch_start(integer num_of)
    {
        string UUID = "your texture key here";
        llMessageLinked(LINK_SET,0,"",(key)encrypt(UUID));
    }
}

and to recieve...

string crypt_key = "12345678-9abc-def0-1234-56789abcdef0";

default
{
    state_entry()
    {
        crypt_key = llStringToBase64(crypt_key);
    }
    
    link_message(integer sender, integer num, string msg, key id)
    {
        string UUID = llBase64ToString(llXorBase64StringsCorrect((string)id,crypt_key));
        llSetTexture(UUID, ALL_SIDES);
    }
}

and to pick a crypt_key, rez a prim and find it's key, then delete it.

You can only gain the UUID of a texture in your own inventory (by right-clicking and choosing Copy Asset UUID) if you have full permissions to it.
If you gain a texture UUID by any other means (legitimate or otherwise) you can set that texture using a script.

Assuming that the user can specify their own texture UUIDs, XORing won't help at all.

All I have to do is supply a known texture UUID, see what the ID is in the linkmessage, XOR it with my UUID to get the key, then I can do the same thing with the key to any of the other textures.

XORing basically isn't a very good way of encryption, just by itself.

Wow, I wasn't aware of that. Hmm...might have to put a bit of encryption into a build I finished a week or so ago!

Thanks for the info.

Good call Talarus, I hadn't thought that through completely.

The link messages won't be sent to the client, but if you apply the textures to anything, the UUIDs have to be sent to the client.

If you have an asset's UUID, you have full access to it.