hackers in SL!!

When I hacked your machine, did I not hack it because you bet me that I couldn't? See, I'm not understanding why you bet me to hack it and you give me permision to hack it, and then you come in here and cry about it.

What kind of person are you TiamaT? Weren't you the one that stole a LOT of money off of Ama's game(s) and were reluctant to give it back?

My purpose was to show you the flaw in your machine so that you can better it. It was not to rip you off, otherwise I wouldn't have told you I could do it, I wouldn't have gotten your permission first, and I wouldn't have given your money back.

YES! I have great knowledge on finding/doing exploits (as all of your are so quick to call it "hacking". But I am NOT using my knowledge/skill to rip people off. I am trying to make the game more secure for everyone, that's all.

You don't like it? Then when you see me, tell me you don't like my presence, and I'll leave. I don't want to be around if you don't want me around. But I do want to help you if you are at danger of being the victem of any kind of exploit/hack.

That's all I have to.

I'm inclined to believe Chance here for obvious reasons.

Yes, I was going to say, wasn't TiamaT the one who gained $30,000 from a bug on one of Ama's machines, and refused to give it back for a while? In fact, I don't think Ama EVER got back the full amount. *sigh* What a hypocrite...

TiamaT's exploit was the trial user bug in LSL. A trial user might not even realize what is happening if they keep getting money. All they see is they are getting money, which is good so they keep trying.

If the Linden's gave Ama a hard time about the money she lost because of a bug in their software, I agree I would be upset also.

Chance, I saw the chat log. You showed the exploit to TiamaT with a small, amount of money, then you left on good terms. It was the next day the money went missing.

So you or someone with your hacking backpack visited TiamaT's machines after TiamaT was offline and took the money.

I could be way off, the chat log could have been forged. But I'm going to believe the guy who's trying to run a business, not the guy who makes hacking backpacks.

First off, Ama is male.

Second, without going into details, the bug in question that is being referenced above was not the trial user bug... I was hit with the original one, then he was hit with a similar but different trial user bug a week or so later. He was quite vocal during my ordeal as well as his because, for obvious reasons, he looks out for me.

The bug in question was a totally separate bug that happened between the two, and was partially a linden issue as well, but... hmm I really don't want to go there. Someone else can if they want.

These issues are the reason Ama is just now expanding after taking down all his arcades except for Taber... there are now controls in all our games that Ama created to block a large loss from bugs (our fault or a LSL bug). I suggest everyone else do the same to mitigate things like this from happening.

His "hacking" backpack is probably just an innocent litle command like this:
for(channel=1;channel<64;channel++)llListen(channel,"","","";

That allows you to listen on 60+ channels and is entirely legitimate code.
People who script should keep in mind that channels are NOT private and if two scripts are using the same channel they WILL interfere. It's up to you to secure the channels. Ama has explained in the scripting forum a number of tricks you can use to secure your scripts so go there and read about it
Also with regards to the "honest businessman" thing werent you the one who talked to me a month or so ago about TiamaT's seemingly bottomless money pit?

I think chances actions speak for them selves, he gave back the cash plus 1k and the slots got robbed again because they didnt get turned off or whatever. Another point is that chance notified the lindens and another prominent SL player who was vulnerable to a similar attack. I would think that its in the interest of the community to have white freelance hackers floating about creativly testing the world around them. It's good for everyone the lindens and slotmachine owners.

Jack O

Eggy: I believe the number of listens is limited far below 60 - closer to 6 actually. And its not the issue he would have used. The code he was 'hacking' is essentially open source. It was the "generic" slot script. He wasn't listening, I'm fairly sure, but rather llSay'ing a command and watching for a response.

As for the bug I experienced, that time it was not the trial bug, it was in fact about 4 or 5 days after the trial bug was patched. The bug involved timming issues of events in a state - they don't happen as advertised. I did get all my money back eventually - from Lindens. It was not volunteered by the perpetrater.

The second bug I had was another form of the trial user bug, and it cost me twice as much as the previous hacking. And I am still missing $10k from it.

Oh and my security tips are actually in this thread, just up a bit. Although consolidating and reposting them in the script forum is probably not a bad idea.

Really? Andrew Linden said the limit was 64 in the following thread

/invalid_link.html

but of course there are no guarantees.

The very reason that I put "<64" in that for is because from my own experience it will give you an error at the 64th llListen call (IIRC). I dont know if its absolute or throttled to match present server performance.
I mentioned llListen because I thought he was "portscanning" the slots to see in what channel they were communicating, and then getting the slot commands from there and issuing them himself.

Your right Eggy... from what i read in the chatlog the backpack was doing just that. Chance was working on the portscanning after he gave the demo and there was a stack heap error for too many Listens. There's nothing wrong with that. In fact Chance was just giving him a security audit at the time, helping him out. Maybe after the chat log ended there were words exchanged, I dont know.... But Chance had the tool, and made the decision to use it the wrong way later on.

Jack yes you are way off. First, yes, I did show him, but that was a pretold channel. He then told me I couldn't do it without knowing the channel. I said yes I can, I was working on it, he took off, he knew i was gonna do it then return his money, and I had it done before the next morning. When he came on the next morning, I gave him his money back and he knew that I was right and that he needed to fix it; Very plain and simple.

I tried helping him out to have him aware that his slots were insecure, I didn't keep the money, nor did I intend to. I get pride out of helping people, not screwing them over. Anyone else want to talk head about this topic, and throw a simple thing of me wanting to help people not get ripped off, by misconscrewing it past the limits, then help yourself, but I said my piece, all the Lindens got into this, and investigated, I'm still here, still playing the game, so I MUST be telling the truth.

Why did TiamaT withhold the WHOLE story from this thread? I honestly don't know, nor do I care, but THIS is the WHOLE story, so let's just drop it and get on with our lives already. If any of you need some scripting/security help, hit me up, and let me know, I'll be glad to help you, but stop hitting me up about why I tried to screw TiamaT over, because I didn't.

Yes, you tested and gave back using a small amount, yes he had to tell you which channel to use. You started working on listen-scanner _after_ you showed him the exploit. That was all in the chatlog.

A much larger sum went missing when TiamaT was not around, which you did return the next morning after involving the Linden's.

Jack,

I don't know if you're blind, you can't read, or what.

After he told me about the channel the first time and i showed himn, he said that it couldn't be done unless I knew the channel from the start. I told him he was wrong, and I then started workin on another way. He told me that he had to go, I told him, okay, I'm going to keep working on it, that I'll see him tomorrow. I did my thing, took his cash, he was on the next morning wiggin out (which I would expect him to), I told him to chill, relax, I give his money back via donation box.

I'm assuming he made the first post before I paid him back, because he was paniced, I just which he would have then followed up on it.

When you're done adding more gas to the fire, let me know, cause I'm kinda tired of this soap operah already, how about you?

security through obscurity really isn't. All the chat channels are available to the public so it's purely a matter of brute force to find out which ones are in use. Using better filters would make more sense. All things, if my box is listening for my very own dulcet tones, it doesn't matter if I'm doing my chatterbox impression in channel 0 or channel 19238, I'm safe.

That adage refers to the belief that a system is secure as long as no one else knows the algorithm being used. That's not what's being suggested; no one is suggesting concealing the fact that the slot machines use chat channels. What we're suggesting is using a channel number that is hard to guess. This is akin to keeping your password confidential, which no one considers an example of "security through obscurity."

As far as slot machines are concerned, one easy fix (assuming the slot machine objects are linked)

llMessageLinked(integer linknum, integer num, string str, key id);

and

link_message(integer sender_num, integer num, string str, key id)

Now if you have a game to where it would in no way work by being linked, then you can make it so that they respond only to specific object UUID/Key which can no way currently be spoofed.

That's all that needs to be done. If you can get away with having them linked and the object needs to be secure, then I'd prefer MessageLinked, because it's easier, and just as secure as the UUID/Key authentication.

The security is only one-way, but it's a lot easier than having an object chat its key and pasting it into the code.

Rez the object that needs to talk to you, use the object_rez(key id) callback to get the key of the object you need to get secure messages from, and then only listen to that key.

The following example gets secure messages, even on channel 0 -- no matter what you try, you won't be able to get it to listen to anything but the child object.

// Example of truly secure communication between objects
// John Linden

// Pick any number here.  I use the chat channel to demonstrate that
// this script is, indeed, secure
integer COMM_CHANNEL = 0;

// Used to hold the key of the object we rezzed
key gChildKey;

default
{
    on_rez(integer num)
    {
        llResetScript();
    }
    
    state_entry()
    {
        llSay(0, "Hello, Avatar!");
        // Rez the thing we need to communicate with
        llRezObject("Secure Thing", 
                    llGetPos() + <0.0, 0.0, 1.0>, 
                    ZERO_VECTOR, ZERO_ROTATION, 
                    0);
    }
    
    object_rez(key id)
    {
        // Get key of object we rezzed
        gChildKey = id;
        // Listen only to that key
        llListen(COMM_CHANNEL, "", gChildKey, "");
    }

    listen(integer chan, string name, key id, string msg)
    {
        llSay(0, "Got secure message: " + msg);
    }
}

The child object has no requirements at all, it can simply chat and the llListen() will do the security for you. Here's an example script for the child object (named "Secure Thing" in the above code):

// Secure Thing script
// communicates with the Secure Ball
// Note that it does nothing special: the ball does the work of figuring
// out whether the chat is coming from the right object.

integer COMM_CHANNEL = 0;

list    gPhrases = [ 
"one", "two", "three", "four", "five", "six", "seven", "eight", 
"nugatory", "exiguous", "spatula"
];

default
{
    on_rez(integer arg)
    {
        llResetScript();
    }
    
    state_entry()
    {
        llSetTimerEvent(5.0);
    }

    timer()
    {
        integer index = llFloor(llFrand((float)llGetListLength(gPhrases)));
        string  babble = llList2String(gPhrases, index);
        
        llSay(0, babble);
    }
}

Note that this child object cannot get secure messages from the parent, even though it can send them.

There are plenty of ways to make a message in SL *effectively* secure, if not truly secuer ; I'll go through some examples if there is demand.

replace "algorithm" with "channel" and you can see how easy it is to call using a "secret" chat channel as your only security *is* relying on obscurity to protect your flawed script.

I'm not sure what you're arguing.

Using passwords is protection through obscurity of a sort, though through a MUCH larger bank of possibles than a single serial integer possibility.

Every single security 'algorithm' is subject to brute force. Thus, you can say that there is actualyl no such thing as security, there is ONLY obscurity. But in some cases, brute force will take a zillion lifetimes to get an answer. You have to draw a line somewhere and call it secure.

So, anyhow I'm also not sure what we're argueing about.

PS: Celerity get back to work.

Edit:
In the case of SL where you dont have control over all the parameters of the brute forcing (ie: your object's key) maybe it IS security.

Ok I waffled.. sorry.

I disagree on Zen terms. The key to security is non-existance. You can't brute force an object that doesn't exist. Therefore I win. And I'm a homeless begger to prove it.



man, I'm TIRED of looking at transsexuals. Can't I at least have a small break?



I think you'd not taste good with whiped cream or maple syrup.

Are you sure you're a waffle?

Chance, it's only a soap opera if thats how you are thinking about it. Taking a large sum of currency from someone without permission is not cool. You could have given it back right away and told TiamaT to check his stats the next time you saw him. I didn't see any sort of "permission" given in the chatlog.

Just trying to promote consistent usage of terminology. The phrase "security through obscurity" has a commonly understood usage. When a company advertises unbreakable crypto, but won't reveal their algorithm because keeping it secret is essential, they are relying on security through obscurity. Widely used crypto systems like DES, RSA, and PGP don't rely on keeping their algorithms secure; their algorithms have all be published. As a result, they are not commonly said to be relying on security through obscurity, even though they rely on passwords being kept secret.

Ummm... This turned into an interresting topic.

Is it just me or are there like 4 seprate conversations going on in this thread?