Curious about how the handle STDERR works? Lets keep it down to say Batch Files to keep it simple and focused? I know that many programming languages accept STDERR, so I don't know if maybe uses are different across the board or maybe there is a common function for all programming languages?
If anyone can provide some examples on common usage that you have seen or an explanation of why someone may utilize it for ??? situation that would be awesome.
Thanks in advance!
Usually you would use stderr for error messages.
If you run a program on the command line, you can capture its stdout and/or stderr
For example:
myprogram.exe > stdout.txt
will capture anything written by myprogram.exe to stdout and place it in stdout.txt. However, stuff written to stderr will not be put into stdout.txt. Thus you can capture the program's regular output without capturing error messages.
STDERR stands for Standard Error. It, as the name suggests, primarily used for reporting erroneous behavior. By default, on every system I know of, I points to the terminal just like STDOUT. These entities are represented separately, however, allowing the user to print only normal output to the terminal and redirect errors to a log (just one example).
Related
I am trying to write a C program that uses Linux system calls to emulate the behaviour of the more command in the Linux terminal. Since the users might enter commands such as q to finish the execution, I am trying to find a way in which to read keystrokes from the standard inout without using read(...), as I don't want the pressed key to appear on the standard output.
In other words, I want to be able to detect pressed keys without them being written.
I have read that ioctl() and the termios struct can somehow be used for this purpose, but I am not sure how they are used (I find the man pages somewhat cryptic).
I have found a few answers to the use of those functions, but all of them seem too complicated. There must be an easier way to detect simple keystrokes, isn't there?
man 3 termios, tcsetattr, disable ECHO on stdin.
For a longer explanation see: Hide password input on terminal
Alternatively, you could go through below termios abstraction, use input layer, /dev/input/*, but I think you'll need to disable forwarding events from your input devices to upper layers then.
My knowledge on terminal emulators is a little sketchy, and in an effort to learn more about them, I thought I could experiment with some of the escape sequences and see what I can do. One of the things I thought of to try was (pseudo-code):
pushTerminalState()
writeSomeDataToTheScreen()
popTerminalStateToRestoreItToTheWayItWasBefore()
In researching how to do this, I came across two control functions
DECTSR - terminal state request
DECRSTS - restore terminal state
However, I am unsure how to use them. For the DECTSR function I am trying process.stdout.write('\x1B1$u'). According to the note on the DECTSR page, this should give a "response", but I am unaware as to where I should "read" the response from? I naively attempted to read from STDIN, but as expected I only received keys from my terminal.
Any tips on what I am doing wrong?
In many programs, including many brute-forcers and the output of many commands, text which has already been printed to the screen is altered in front of you.
Using the brute-force example; the password which the program is currently attempting is cycled through extremely fast.
My question is: How to alter text which has already been printed?
Is there perhaps a function, or specific method by which this can be achieved? I have never encountered any code like it and it doesn't even seem possible from a programming perspective, however i am counting on being wrong.
Thank you in advanced.
A carriage return char should be printed (\r), and the output should be flushed.
In python, this can be accomplished specifying the end flag to \r and flush to True.
print("sample text", end='\r", flush=True)
In a more generic way, any language should be able to access sys functions, in which case the \r should be added manually, and then the flush() function should also be called manually.
Is it possible to print to console in color from the kernel's version of printf? Can I see the same escape codes that I can in userland? Does the kernel understand the console well enough to be able to provide termcap style APIs and constants for specific color? If so, which header are they defined in?
You can certainly print arbitrary escape sequences from kernel. It would happily put whatever bytes out on a terminal. Whether those bytes would be interpreted as color, kernel, generally speaking, has no idea.
So, it is possible to print and you can see the same escape codes once you read kernel messages (i.e. if kernel prints XTERM-style colors and you happen to look at them via serial port with a terminal program that either uses XTERM or emulates XTERM escape sequences itself)
As for whether kernel knows much about your terminal type and able to use termcap info, the answer is, in general, no.
In userland terminal type is a matter of convention. Login script tries to figure out what kind of terminal you may be connected to and then sets TERM to appropriate type in the shell's environment. Forked processes inherit it and use the type in order to figure out how to do certain things on specific terminal. Usually it involves some sort of curses library.
Kernel, on the other hand is fairly minimalistic beast that does not really give much of a damn what's on the other end of whatever happens to be its console -- serial port, firewire or video card. For all practical purposes, console may not even be connected to anything at all.
Practically, you will need to solve two problems:
Have a way to configure terminal type for particular TTY device you want to use.
Provide kernel with som sort of termcap/terminfo data for that terminal type and an API to produce appropriate escape sequences for output on specific TTY. In other words -- in-kernel curses library.
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.