What bots can and cannot do

I don't think there is any need to speculate on what those inventory boxes may or may not do, you have presented nothing but speculation that is completely outside the scope of the thread, and I question your motives for bringing it up.

I can tell you with 100% certainty that I could write a bot that searches the entire grid for "for-sale" items without ever resorting to putting questionable scripts inside of SLB (or any other) inventory boxes.

This thread was about what bots can or cannot do. It did not become such a thread, that is in fact the name of the thread, so please try to keep it on topic rather than resorting to FUD tactics, hmmmm?



.

Well, how about you go take a look at the code and judge for yourself? It's easy to find, certainly.

You can go get the open source viewer (alternate instructions and documentation here), first of all. That is not typically used to make bots, but it is terrifically informative about how the network packets are structured.

Then, you can go to libsecondlife.org and get the libsl code. It comes complete with a project for a simple bot that performs limited tasks like following the owner, sitting on stuff, etc.

Then, go find GhettoSL on Google Code and check out the code (probably old and abandoned, but fully functional at one time) for a camper bot.

And, if you find a way to make such bots have thier memory explode, please share it with everyone here. There are a great many people who would be interested in that



.

Look, I've wrote drivers, I've wrote libraries, I've wrote self modifying code before MMUs made this impossible, I've wrote a lot of bugs and even programs that worked, I've coded on the TI 57, VIC 20, the C64, the Amiga series, Atari ST, PC XT, AT, HP UX and many more other computers, I've broke the 100k lines of code long time ago, I've had projects that took me 6 years to achieve, I've coded in PHP, Perl, Pascal, C, C++, Basic, Fortran, Cobol, Forth, PL/SQL, I've coded in NUM for automated processing, many assembly languages and even LSL. I have nothing to prove or demonstrate. Now when I say "memory explodes" I meant make the program run out of memory. So please now go flame someone else or go write your bot code, I have no interest in continuing this discussion.

I didn't question your programming skills, and I'm not trying to starting a pissing contest about that. It's completely irrelevant either way.

But did you forget that you wrote a post about a method to foil bots? One that was completely ineffectual? This was my response to that and your follow up post which speculated on the code quality of the bots, and I responded with where to go find out without resorting to speculation.

And, if you come up with a way to foil them *at all*, you should post it. The part about people being interested in that was not sarcastic, as you seem to have taken it to be. That was a smiley face, not a sarcastic smiley face. Do you doubt people would be interested in a real method of protection against bots? Hell, even I would be interested in that.

If you just want to spread opinion and jettison at the first hint of someone implying that your post in a thread about what bots can and cannot do is not actually factual, then I wonder why you posted in the first place.

So.... Okay, apparently the thread has run out of steam and is degrading into FUD and speculation like all the others.

Time to go out and play, I guess


.

Which leads on to what I think is a more interesting notion. Some kind of honey pot that would exploit the predictable behaviour of a bot.


For example, a trivial exploit has already been suggested that hosting a L$0 object with an 'attractive' name might increase traffic.

If you could lure a landbot to a low priced piece of land and increase its price between its initial detection and its purchase by the bot, you might be able to make a couple of bucks and/or bankrupt every landbot-runner on the grid.

I'm actually surprised there aren't already reports of bots being exploited. Automated systems have a history of having stupidly simple vulnerabilities. Bots maybe be fast but they are also dumb.

So, where are the bot predators? Or are the meat-bags just too prolific a target?

Interesting idea, but to my knowledge there are not yet bots that actually purchase anything. The one that this thread was started about only lists things that *can* be purchased, but does not do any purchasing of it's own.

Gaming for traffic? That might actually work


[Edit] Oh. Missed that you said the purchasing was by landbots. Well, there is a huge gamble involved there.... There is a very very short period of time between when the bot enters the area and when it makes the purchase. It may not even be visible to you at that point. If your scanner misses that slim window, you lose your land. That is why there aren't more tales of tricking the bots


.

Well, I was not speculating but I don't want to post stuff about how to break other programs either. I shouldn't have posted this at all, I admit. About this method being ineffectual I wont discuss it further sorry.

Just a thought: wait until there are more camping bots than camping chairs and we will see if a bot can break another.

Yeah I had something like that in mind when I was mentioning endless loops, bots+profit=bot wars, the databases and the end-users will suffer from it, it's rather ineluctable.

The idea of botsploitation was something that I was thinking about earlier today, and if I could get hold of any of the code or have a good description of how the things operate, I'm sure I could work something out. It probably wouldn't make anyone any money, but it might be fun.

I wouldn't have a moment's thought about whether or not to break someone else's bot for my own amusement - assuming that that bot was not being used privately or legitimately of course. Bots which wander around the Grid poking their virtual noses into stuff are fair game for anything as far as I'm concerned (not specifically in this instance, I'm talking more about landbots and the potential spybots mentioned).

Actually, I think that is a great idea, although you have to be careful to stay within the ToS apparently.

Unless you just meant the in-fighting. If *that* happens, I think many people will get a chuckle out of it



.

Well, I can't give you landbot or searchbot code, but I did link to the building blocks in an above post and could give you the code for my bot if it really came down to it (though I hesitate to do so).


.

I wonder how LL would respond if a bot owner filed an AR on people making their bots crash?
You may not like bots, but deliberately attempting what amounts to a denial of service attack on them is skating on very thin ice legally in most places.

Anyway, back to the "exploding memory". You mean buffer overflow attacks by any chance? If you don't have the bot code, it's shooting in the dark as to what will cause an overflow. Pushing exploits over the network in a trial and error attempt to kill a bot would have LL going nuts, nevermind the harrasment angle of it.
What if I started throwing exploits down the line at somebody I didn't like? Oh noes! Look at the big bad griefer!

And that idea of a moving vendor to counter a bot is the daftest thing I've ever heard. So what, your vendor moves around. The bot is not relying on it being in any particular place for starters, it doesn't care what price it has, and it doesn't care if it runs into it again later. Any code that fell over that easily wouldn't even make it onto the grid.
Even if the bot was looking for your specific vendor, I don't know anyone who would write code that dies when it's not found instead of simply saying "not found". Even someone coding for less than a week wouldn't make that error.

/me waits for the accusations of being a bot.

If you know so much about bots, you must be a bot. Why don't you go marry a bot? And have little botkins?

There




.

If you make a script that generates a labyrinth at your land entry you could trap a bot inside it for a good while. I dont think it s against the ToS to make a labyrinth in your land so that would be fine. The bots in Lineage which are illegal but very well writtten still run into the walls at times.

Thanks, got it out the way and gave me a chuckle.


What was that thing called again? I used it earlier, made a sort of whoooosh noise with a blue bar. Oh yeah, teleport!

Not that the bot would care about your labyrinth anyway. If it's in your draw distance, it's been seen, regardless of walls in between the camera and the object.
1) Land
2) Store data on all prims seen for sale without moving a step
3) Teleport away

Well.. can we talk about something else please? I'm not a DOSer and didn't have this in mind.

Oh, what prims for sale? What if I dont rez the vendor until you get out?

If you don't rez it till the bot is gone, what would the bot care?
It's memory wouldn't "explode" because it had missed one item

A perfectly programmed, robust, though useless bot. Though it s memory wouldn't be far from "exploding" if I was doing something more.

Er, how is it useless? Unless you know what time it is coming round and feel like taking every prim into your inventory, then placing them all again, it's going to log some of your stuff.
Not that logging or not matters with one or two people. ESCs bot is designed to make a reasonable attempt at listing objects for sale, not list absolutely every object on the grid. For that, it serves its purpose whether you decide to remove all prims, or opt out.

Maybe it's an ego thing that makes the bot useless if it doesn't list your stuff?

And you still haven't explained how you would fill the memory of the bot without seeing the source code. Chances are, an attack without a specifically targeted bug in the bot that fills the memory of the bot would also fill the memory of the normal viewer, and that of the sim.

Bots tie up less memory than the regular client on account of not having to store all those textures, they use less processing power on account of not having to render the world, they need a lot less code than the regular viewer, so less code in memory. Guessing, I'd say ESC also have the bot running on a dedicated server with more processing power and memory than the average home machine.
It would be extremely hard to hit it without bringing down every client in the area and the sim. A vendor on wheels is not going to cut it. A griefers nuke might just about knock the thing offline (without killing it with a memory flood), but then you can kiss your account goodbye.

BTW, what you had in mind earlier was a DOS attack. For reference, you may wish to read http://en.wikipedia.org/wiki/Denial-of-service_attack
DOS attacks are not limited to simply flooding bandwidth. Check out point one there:

Filling the memory of a target machine so it ceases to provide its intended service is a DOS attack.

Also for reference, I have developed and patched DOS methods on a number of sites to keep them secure. Flooding bandwidth is one of the smaller worries as it doesn't actually cause any damage. Flooding memory (it is a DOS, and I have done it on an 8GB server) is worse when you cause certain processes to fail, but there is no "one size fits all" attack for that. You have to know the weaknesses of the code you are targetting, and you wont be able to do that with ESCs bot.
Maybe, unlike the bots, you actually can do magic.

Anyway, I had not the search bots in mind, I love search bots, I use google everytime i need the spaghetti carbonara recipe. A maze would get a camping bot stuck.

Now you are hammering this DOS thing, I've already mentioned I didn't want to discuss about it and I shouldn't have said that, what do you want more? If your bots hammer the databases like you hammer on the forums they are certainly a great harm to the servers. Now please give me a break.

Many posters seem to concentrate on the movement of the bots. All the bot has to do is wait for the contents of the prim info packets to be received from the sim server an put them in some db. Come to think of that, you could probably achieve that with a live av and an intercept program.

Tho program running the bot probably has no 3d display software in it at all! Being a c++ program running on your desktop, probably has huge stack/buffers and be very hard to crash.

I don't know about whether most bots have no 3D display, but so far all of the ones I've made and seen do not. They are console programs, in fact, with no GUI at all.

And for search bots, land bots, camper bots, etc, movement is a non-issue. They simply teleport to where they need to be and do their magic. In the case of a camper bot, they can teleport "close enough", since most camping chairs have a sit target defined simply the act of sending the "I want to sit there" packet is enough to move them to the final (precise) destination pretty much instantly.

Therefore, no movement required.

And even bots that *do* require movement, like mine, use flexible heuristics rather than strict mapping. And those bots are far less likely on average to be something you feel a strong need to "trap" anyways Well, at least the ones I've seen so far, I guess I can't speak for them all. Mine's just an NPC, if it gets stuck it's not the end of the world it just looks goofy


Joking: The moral of the story is that only the evil bots don't need to move


.

Absolutely. When I was first trying to figure out how to make a bot, I used the libsecondlife proxy as well as Ethereal and similar homebrewed tools to modify and track the packets being sent to and from my official client.

One of the experiments I performed was to log the key and name of EVERY avatar I met, automatically retrieve and store their group memberships, and cross-reference those in the database with everyone I had previously encountered in order to draw a social network diagram. Sort of a "six degrees" kind of thing

All this was performed in real-time just by intercepting, storing, and mining the standard viewer data.

I never did anything with that data, by the way, it was just a thought experiment that served it's purpose and no longer exists. The database doesn't even exist anymore.


.

If your bot doesn't move then it's very easy to use llVolumeDetect() or llSensor() or whatever else you want to activate the camping chair. You dont need to be at a definite location to activate a teleporter, right, except if the teleporter requires you to be there.