dievus/threader3000

always return 0 result

dickieku opened this issue · 9 comments

dickieku commented

socket connect always returned me a timeout while nmap returned results. No clue about it.
Did anyone report that issue ?

dievus commented
dickieku commented
Unibrighter commented

Hi @dievus , first a big thanks to you on providing such a great tool.

I bumped into this issue faced by @dickieku today while trying https://tryhackme.com/room/relevant written by you.

I am using a Parallel Kali machine on my Mac, both can access TryHackMe room. and nmap can give success response if I do a full port range cover by
sudo nmap -Pn -p 80 -sC -sS -O -sV -T4 $IP

However, when running threader3000, I don't have any result coming back.
I tested on my Mac and Kali, both of these two have the same result, and that is, no ports reported as open but nmap can give success result if I do nmap manually.

It could be a limitation from the ISP network service provider in my office today. but not so sure about it. Will test again when I have fibre access home.

Will put my update there and see if I can set a breakpoint in home when having time.

Unibrighter commented

Forget to mention that sometimes the very first port in the full scanning range will be reported open but the rest of them just came back as negative. Could be a network throttle thing on my network. I am still trying to look into this.

dievus commented

@Unibrighter I'm guessing it is a network issue, either with your adapter or the VPN. It still works fine here for me, and I just tested it in a couple scenarios.

Unibrighter commented

Hi @dievus , thanks for getting back to me.

After some investigation and a read-through of the python script, I did found the cause of the issue. It's a result of both the throttle (probably set by my InternetServiceProvider) of my internet connection, and the time-out setting set by the program itself.

socket.setdefaulttimeout(0.30)

I am currently using TryHackMe service from Australia and using the CDN with the Australian node. However, the connection is still "comparably" laggy even with CDN.

➜  tryhackme ping $IP -c 3
PING 10.10.180.208 (10.10.180.208) 56(84) bytes of data.
64 bytes from 10.10.180.208: icmp_seq=1 ttl=125 time=308 ms
64 bytes from 10.10.180.208: icmp_seq=2 ttl=125 time=307 ms
64 bytes from 10.10.180.208: icmp_seq=3 ttl=125 time=305 ms

--- 10.10.180.208 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2004ms
rtt min/avg/max/mdev = 305.028/306.694/308.124/1.275 ms

So I am wondering what's the usual ping lag for you when connecting to TryHackMe victim machine via VPN?

If I am not mistaken, the max time consumed for a full port range cover is:
0.3 * 65535 / 200 / 60 ~= 1.6 mins

  • 0.3 - default time-out
  • 65536 full port range
  • 200 threads in the worker pool
  • 60 seconds to mins.
    Hence,

A full port scan can take as little as 15 seconds, but at max should take less than 1 minute 30 seconds depending on your internet connection.

So I increased the limit from 0.3 to 0.5 and it starts working for me instead of only returning flaky result / 0 result. Simple but straight forward.

If I make this time-out a configuration item for the user but defaults to 0.3 if not set, would it be considered as a pull request that could potentially be accepted? :)

Once again, this gives a great concept that multi-thread can accelerate the port scanning that could be time-consuming. And time management could be a real pain in OSCP as you mentioned before!!

Anyway, thanks in advance for getting back to me. Looking forward to your reply so that I can check if you are open to such an idea or I should just fork it to keep it on my own.

Also hope this could be helpful to anyone who experience similar issue in the future.

dievus commented

Hi there. I haven't used TryHackMe in some time, so I am unsure what connection quality may be.

Generally speaking, all of the tools on my Github are developed and maintained for my use and I simply make them available for others to use. I usually don't accept pull requests or requests for changes unless it fixes an issue I couldn't figure out or adds something great to the QoL of the tool that I would find useful. So, I probably wouldn't accept the pull request, and certainly encourage you to fork it and make it work best for you. If you look hard enough, you'll probably find versions of it called things like Threader6000 and variations that implement multiple hosts in one scan. In the end, T3000 was a project I used to learn some Python, and I still use it all the time for work.

That said, I think it's really great that you spent the time to troubleshoot the problem and find a solution. I definitely encourage you to keep up that energy. I appreciate you taking a bit of time to reach out. Thank you.

Unibrighter commented

Thanks again for your reply and your kind encouragement, it means a lot to me @dievus .

dievus commented

Of course @Unibrighter. Feel free to reach out anytime.