So I was thinking of writing a irc bot/bot extension that lets users play certain text based games by starting the game,
sending parts of certain lines they enter(regexp match for game signal if not in bots channel ex. rbot gamename enter the forest . sends "enter the forest) to std in of game,
while standard out of game is cached by bot and the piped to the channel (ex.
"let us rejoice for
the duck has been defeated"
gets read into a line cache inside the bot and then
the bot sends it to the appropriate channel as
gamename: let us rejoice for
gamename: the duck has been defeated"
)
But I'm sort of worried about the tricky things people on irc might do, would stripping all non printable characters be enough safety? If a program quits (say they enter the quit command for the game) what happens when you try writing to the file descriptor for that programs std in(error)? Any other potential problems?
Note I'm going to run this on linux or *bsd so I don't need to worry about windows specific things.
Some basics you might want to consider:
It's much safer to allow text through that you know is safe, than to try and filter out text that you think might not be safe. The games probably accept only alpha-numeric characters, so check to see if the input contains only those values, and deny anything else.
Run the bot under an account that has the lowest permissions possible, and as limited access to the rest of the machine as possible. If you can sandbox or virtualize it completely, even better.
You should be watching the PID of the child process for termination, and decide what to do if it exits, restart it or fail further commands, exit the bot, etc.
There are any number of possible security issues whenever exposing services to the network, you would do well to read about general secure programming topics, a quick google search turns up this how-to for example.
It pays to be paranoid. Without following proper secure programming practices, the most you can hope for is that nobody gives an honest try at breaking it.
escaping quotes and pipe will keep you safe from most stuff
" ' |
It doesn't matter where the user input is coming from, it matters how its used.
The one attack that affects IRC is CRLF injection. This will come up for you if you echo back user input over IRC. An attacker could try and inject a carrage return (\r) line feed (\n). This type of injection affects many protocols including HTTP and SMTP. In the case of IRC the attacker would be able to force your bot to send a command to the IRCD (like /join or /kick or /ban :). Make sure to look at an ASCII table and filter out all 0x0A (\n) and 0x0D (\r). In most cases the new line is enough, so make sure you filter for both.
Make sure you read over OWASP A1: Injection. Especially if you are using user input in a sql query or invoking a process on the commandline.
Related
Is it possible to close the mic without closing the app?
Or any suggestions to the below explained situation are very welcome:
I've found some posts already asking for this, but they have about a year old so I wonder whether there's something new.
I'm using conv.close('some message not prompting');. That closes the mic, but also closes the app, which is not what I need.
The functionality I need is the same that AOG takes by default when showing a browsing carousel: it automatically closes the mic (but not the app), and the user can re-open the mic or tap on a suggestion chip to interact with your app directly, without the need to invoke it again.
I was suggested to add a tail saying What else can I do for you? after each reply that doesn't prompt the user for new information, so I can keep the mic open, but that sounds so unnatural that I really think it kills the purpose of trying to sound natural with a bot.
There are many situations where you can expect the user to say something, even though you're not asking for anything. A simple example is when telling a joke: you can expect the user to laugh, criticize, ask for another joke or make whatever comment. In this case, closing the mic (and the app) is nonsense, and adding a Do you want to hear another joke? tail doesn't sound good after the joke, specially if you're telling one after another.
The purpose here is not to be rejected by the AOG review team because I'm leaving the mic open.
Any ideas are welcome. Thanks in advance.
You don't need to explicitly prompt for "what next", but you do need to make clear if you're expecting something further from the user. The easiest way to do that is to rotate through some prompts. (Libraries like multivocal make this easier.)
The notion of "closing the microphone without closing the conversation" leads to the question of "ok, how do they close the conversation?" And for simple one-off scenario that you've described, that isn't always obvious.
That said, there are a few thoughts about how you can approach it depending on your needs.
If there is a reason you need to close the microphone, yet still allow the user to issue a command while still in the Action, you can consider sending a Media object as part of your response. When the playback finishes, your Action will be triggered to let you know, and you can either prompt the user again (and play more audio) or eventually agree to close the conversation. Users would interrupt the audio with "Hey Google" prompted by a command in your Action.
Another approach for things that are truly "one off", but where they may want to followup in rarer cases, is to keep track of user state (if you need to reference it in a followup) and close the conversation. The user would be able to "re-start" the conversation if they need to, either through normal invocation or through a deep-linking invocation. This does close the conversation - but makes it easy to restart.
I have written 2 google home apps now and had them initially rejected if any of my intents did not ask a follow-up question. I agree that it can sound a little unnatural always asking a follow-up question. I get my answer logic (on my endpoint) to append a random follow-up question from a pre-defined list to try and vary things up a bit.
On linux, console applications have the ability to format their output. They can set font color, set background color and can place signs everywehre on the console. Using that it is, for example, possible to implement a tetris game right into the console.
I´m wondering how one can do that. I think they use a output markup language or something else. Can anyone tell me where I can learn more about this?
Thanks very much!
Most console applications involving a lot of motion or color are built using the ncurses library. Some very common examples would be irssi (IRC client), mc (Midnight Commander, the console file browser), mutt (POP3/IMAP mail client)
It seems like you are already aware of the escape codes used to modify console colors. A good list of console color escape sequences (for Bash) can be found here.
You obviously need to get a hold of those every-popular Unix video games, rogue, srogue, larn, hack, and/or nethack. They have a long and venerable history.
Notably, these all use the standard curses — or more recently, ncurses — library. Here’s a screen shot.
Since they have no joystick, motion is with vi commands. They are hands-down the very best way to hone your vi motion skills ever invented: no more two-finger typing for you! You stop thinking about motion; it just becomes a part of your fingers’ muscle memory. You really have to play them to get a feel for the awesome “Zen” state you can get into playing them:
After enough practice, it feels as though your fingers themselves remember how to play the piece. You don’t even watch them. They've a job to do, and once they’ve learned it, can go about that job remarkably free of direct supervision. The key to clearing the mind of the outside world, so that the program becomes the dominant reality, is what a musician would call “finger memory”. (You might have heard athletes or dancers refer to it as muscle memory, but when we’re talking about using the computer, it really is the fingers that count.)
[...] Of course, that's not really what’s going on; it only seems to be. Your fingers don’t really remember. But a part of your brain that controls them does, even though “you” don’t realize it. What’s happened is that you've so successfully assimilated the moves needed that conscious direction is no longer required. The little lighthouse keeper behind your forehead can worry about other things, assured that your fingers will do the job you’ve trained them to do. Your eyes are on the screen, the program in your head, and your head is in the program. Your fingers become an unnoticed extension of your will. [...]
[...] There’s no question that, for certain tasks, the keyboard is clearly the optimally efficient input device. Consider the game of rogue or one of its more recent incarnations. You wouldn’t want to use anything but a keyboard there. The command set is just too rich. Trying to play the game with a mouse‐and‐menu interface instead of a keyboard one would slow you down by at least two orders of magnitude.
The rogue family of video games are also notable for showing how to write a video game for a regular terminal like a vt100 or an xterm, which I believe is what you are looking for. I’d probably use a more modern language than C these days, but all the same principles still apply. Both Perl and Python have good interfaces to these standard libraries.
It's not so much a markup language as a series of escape sequences that trigger the terminal viewer to format in a certain way.
You can send ANSI escape sequences before your output to indicate that the following output should be a certain color, weight, background. You can also send sequences that jump the cursor to specific locations to continue writing output.
If you are going to do a full blown app you should consider using some library such as ncurses which makes these manageable.
The POP3 client is an homework assignment at one of my courses. It has to be done in Qt from scratch. Target platform: Linux (Ubuntu).
What solution would you recommend when it comes to mail storage ? Since it is a homework assignment it has to be done "right"...
P.S. For now I think I would go with plain text, each message in a separate .txt and another file as an index. I'm not sure how this will be handled when the folder with the messages will get really big.
If my options where totally open, I'd pick a database tool (MySQL is overkill, SQLite would be perfect) because the tool can deal with sorting, IO access, file locks (if multiple instances are possible), deleting, defragmenting/cleaning/vacuuming.
On the other hand... there's a pair of standards for storing mail: MBOX and maildir (nice primer here) which it wouldn't be too hard to adopt into your programme.
What of attachments, text encoding and transfer encoding? That's where the real work's going to lie (unless it's out of scope of the assignment).
This is one of my assignments and I need some help in getting started. The basic idea behind the assignment is that I have to design a self destructible email program that is capable of destructing the message after (n) time duration.
Speaking about self destructible emails, there are quite a few ones on the internet offering the same service. But what they do is, they just convert the email message into an image and store them on their servers. Now, they send the message attaching the image inline with it. After they receive a hit on that image (which means that the message was being opened), they simply delete the image and the inline image link breaks! BOOM!
IMO, that's not what a self destructing email should be like. Nevertheless, in my case, I have to take care of following points:
I have to do it for TEXT. No image, nothing else.
I have to assume that the systems used throughout the process will be UNIX based (I don't know how that is going to make a difference).
There are also some hints regarding the usage of various network layers in solving the problem.
This isn't supposed to be done "in general". What I mean by that is, I have to do that ONLY for one/two UNIX systems. Let me put it this way, all I have is two UNIX systems and nothing else. Now I want to create a program (in UNIX itself) that would do that self-destructing thing. I have total control of protocols and the network layers and I have to code anything and everything required at any level.
This is more geared towards the StackOverflow side of things but I have no problem getting you started.
The first thing I'd like to point out is that you seem to be heavily over-analyzing this. The services that have self-destructing e-mails which are image based are simply deleting a file after it is viewed. All you need to do differently is put that text in a file and get it's contents before deleting it. This fits well with the UNIX philosophy since so many programs already make use of flat files.
The part you seem to have left out is how you are building this. You describe it as an e-mail program and then talk about web services. Is this a web-based project or a program you are designing for Linux? Do you have to code everything from scratch or can you parse output from Linux utilities to grab the mail? These kinds of things really would simplify the process.
I want to code a trading bot for Magic: The Gathering Online. This bot should wait until someone offers to trade, accept, look through the cards available from the other trader (the information is shown on screen), and perform other similar functions. I have several questions:
How can it know that someone is offering a trade?
How can it know that the other trader has some card (the informaion is stored in pictures)?
I just cannot imagine right now how to do it, I have no experience with it, until now I've been coding only console programs for my physics neсessities.
First, you should note that some online games forbid bots, as they can give certain players unfair advantages. The MTGO Terms of Service do not seem to say anything about this, though they do put restrictions on anything that might negatively impact the service. They have also said that there is a possibility they will add an API in the future, so they don't seem to be against the idea of automation, but are not supporting it at the moment. Tread carefully here, but it looks like it should be OK to write a bot as long as it is not harmful or abusive. This is not legal advice, and it would be a good idea to ask the folks who run MTGO for permission. edit since I wrote this, it has been pointed out that there are lots of bots already, so there should be no problems writing bots.
Assuming that it is not forbidden by the terms of service, but they do not have an API, you will have to find a way to detect what's going on, and control the game automatically. There's a pretty good series of articles on writing poker bots (archived copy), which has some good information on how to inject a DLL into an application, scrape the screen, and control the application. That might provide you with a starting point for doing this sort of thing.
You might also want to look for tools that other people have already written for doing this. It looks like there are several existing MTGO bots, but they all seem a bit sketchy (there have been some reports of them stealing passwords), so be careful there.
Edit
Since this answer still seems to be getting upvotes, I should probably update it with some more useful information. Since writing this, I have found a great UI automation system called Sikuli. It allows you to write programs in Python that automate a GUI. It includes image recognition features which make it very easy to recognize buttons, cards, and other UI elements; you just take a screenshot, crop it down to include just the thing you're interested in, and do fuzzy image matching (so that changing backgrounds and the like doesn't cause the match to fail). It even includes a custom IDE that allows you to embed those screenshots directly in your source code, so you can see exactly what the code is looking for. Here's an example from the documentation (apologies for the code formatting, doing images inline in code is not easy given StackOverflow's restricted subset of HTML):
def resizeApp(app, dx, dy):
switchApp(app)
corner = find(Pattern().targetOffset(3,14))
drop_point = corner.getTarget().offset(dx, dy)
dragDrop(corner, drop_point)
resizeApp("Safari", 50, 50)
This is much easier to get started with than the techniques mentioned in the article linked above, of injecting a DLL into the process you are debugging. Sikuli runs entirely at the UI level, so you never have to modify the program you are automating or worry about changes to the internals breaking your script.
One thing it is a bit poor at is handling text; it has OCR features, but they aren't all that good. If the text is selectable, however, you can select the text, copy it, and then look directly at the clipboard.
If I were to write a bot to automate something without a good API or text-based interface, Sikuli is probably the first tool I would reach for.
This answer is constructed from my comments.
What you are trying to do is hard, any way you try and do it.
Arguably the easiest way to do it is to totally mimic the user. So the application presses buttons, moves the mouse etc. The downside with this is that it is dependant on being able to recognise the screen.
This is easier if you can alter the games files as you can then just skin ( changing the image (texture)) the required cards to a single unique colour.
The major down side is you have to have the game as the top level window or have the game running in a virtual machine. Neither of which is ideal.
Another method is to read the processes memory. You may be able to find a list of memory locations, which would make things simpler, otherwise it involves a lot of hardwork, a debugger to deduce the memory addresses. It also helps (a lot) to be able to understand assembly.
The third method is to intercept the packets, and alter them. This is easier that the method above as it (at least for me) is easier to reverse engine the protocol as you have less information to deal with. It is just a matter of setting up a packet sniffer and preforming a action with one variable different (for example, the card) and comparing the differences.
The thing you need to check are that you are not breaking the EULA. I don't know how the game works, but most of the games I have come across have a EULA that prohibits (i.e. You get banned) doing any of the things I have mentioned.