+- Hack Forums (https://hackforums.net)
+-- Forum: Tech (https://hackforums.net/forumdisplay.php?fid=444)
+--- Forum: Coding (https://hackforums.net/forumdisplay.php?fid=151)
+---- Forum: Software Development (https://hackforums.net/forumdisplay.php?fid=118)
+---- Thread: [Python] IRC Botnet [Python 3.5] (/showthread.php?tid=5549764)
* - 05317832892 - Feb 17, 2017
(Feb 17, 2017 03:46 AM)deadsh0t Wrote: hi im new to programming python
and think a script like this is very interesting however i had a few questions, this line:
botnick="BOT_" + str(random.randint(10000000, 99999999))
since this script is ran again at reboot the bot will get a new nickname each reboot right ?
And second it generates a random name for every bot but wouldnt that mean that if a bot somehow got the same name as another bot it would fail to connect?
you could also use this code botnick="BOT_" + urllib.request.urlopen('http://ip.42.pl/raw').read()
This should give the bot BOT_(their ip) as a nickname
However im not home to test it
Didn't think about doing it that way, it will also act as a muted because it will fail to connect twice under the same ip.
Very nice though, it like it.
* - deadsh0t - Feb 18, 2017
and also to update your bots for whatever reason like moving to another irc server or changing to another username
you could recompile your script with /AppData/Roaming/Microsoft/Windows/Start Menu/Programs/Startup/pythonfile" + ".exe" to /AppData/Roaming/Microsoft/Windows/Start Menu/Programs/Startup/pythonfile1" + ".exe"
and add this line at the top
os.remove(/AppData/Roaming/Microsoft/Windows/Start Menu/Programs/Startup/pythonfile" + ".exe")
and then compile the exe and use download and execute from the current exe so that the old exe will be removed and the new 1 will be ran
* - deadsh0t - Feb 20, 2017
how can i get pyinstaller to use 3.5 instead of 3.6 since 3.6 fails because its not supported by pyinstaller
* - 05317832892 - Feb 20, 2017
(Feb 20, 2017 06:52 AM)deadsh0t Wrote: how can i get pyinstaller to use 3.5 instead of 3.6 since 3.6 fails because its not supported by pyinstaller
Reinstall Python, install 3.5
Your not loosing anything significant.
* - obby - Feb 20, 2017
(Feb 13, 2017 10:26 AM)Goodies Wrote: Ha! There is nothing better than asyncio, you mongoloid.
Correction, I'm sorry that you're unfamiliar with the GIL but the GIL (Global Internal Limiter) limits python to an extreme so they made the multithreading and multiprocessing modules for users to attempt a bypass on this. ASYNCIO will only use one core and is very slow. Making the script simply async will not achieve optimal performance, using a process per core and threads per process with async will. Using threads without async is also more user friendly, and more optimal in terms of performance.
(Feb 13, 2017 10:29 AM)Infamia Wrote: old is gold
Fortunately the syntax is close enough for it to not really matter but I also use python2.7 where possible as python3 support still isn't as big as I'd like it to be. Proper code is usually 1:1 translation anyways. I do also agree with you that he needs to stop asslicking asyncio.
* - deadsh0t - Feb 21, 2017
so i got pyinstaller to work however it connects to the irc server succesfully but it wont join the channel
EDIT 1: I fixed it for people having this probblem paste the join line right after while true: this is because with some irc servers the handling can be too fast so you need to wait until its fully connected
* - Goodies - Feb 21, 2017
(Feb 20, 2017 12:05 PM)obiwankanobi Wrote: Correction, I'm sorry that you're unfamiliar with the GIL but the GIL (Global Internal Limiter) limits python to an extreme so they made the multithreading and multiprocessing modules for users to attempt a bypass on this.
I'm overtly familiar with the GIL (L = Lock, not Limiter, by the way). I program in C/++ with the Python API, bud, and I'm plenty familiar with how it works in the backend. The GIL is just a binary semaphore and a condition variable. And judging by the fact that you think the multithreading module is an attempt to bypass the GIL, I'd say I have a much better understanding of it than you do lol. Asyncio DOES bypass the GIL for I/O bound code because the GIL is released upon blocking I/O operations (such as network activity). Multithreading more or less does the same thing, but far less efficiently. In CPython, only one thread an access the Python API at any given time. Multithreading works by switching between threads every `sys.getcheckinterval()` ticks, OR by releasing the GIL when doing anything I/O related. If you are running CPU-bound pure Python code with multiple threads in CPython, you are guaranteed to be slower than if you only use one thread (due to the GIL).
Example, this code will always run slower in the multithreaded version in CPython so long as there is a GIL:
Spoiler (Click to View)
Quote:ASYNCIO will only use one core and is very slow.
I don't think you get how this whole async thing works... Over 90% of the time, the thread is just waiting on an I/O operation. That's not an exaggeration. It really is over 90% in a huge number of networking applications. While it's waiting for the socket to respond (which often takes several hundred milliseconds, sometimes more) it can do plenty of other things (such as spawning a new socket connection, or even dozens of concurrent ones) all without affecting the speed of the others. This DOES provide maximum efficiency. Adding multiple threads will do nothing. Especially since asyncio can only have one event loop per thread/process. If you added more processes, you could handle more connections, but you also have to add IPC and process synchronization and safety. Typically, though, the bottleneck with asyncio is the network. More often than not, asyncio can handle way more active connections than your NIC can reliably support. You'll start to get socket timeouts before you'll run out of available connections.
Quote:Making the script simply async will not achieve optimal performance, using a process per core and threads per process with async will.
Again, you completely misunderstand what async means. "Asynchronous" is just the overarching umbrella term. It does not mean "single-threaded asynchronous." It just means you're doing more than one thing at a time. True multithreading, mulitprocessing, parallel processing, etc... these are all forms of asynchronous execution.
Also, what you've recommended actually really doesn't provide any benefit in this case. Generally, what I do is have a `concurrent.futures.ProcessPoolExecutor` to which I offload any necessary CPU-bound processing, and the main thread simply runs the asyncio event loop, registers socket file descriptors, etc... Asyncio is so efficient BECAUSE it only uses one thread (except for things like DNS lookups in which case it does use another thread, but the overhead is very small overall). You don't need to incorporate thread synchronization or any extra safety. If you did, that would only make it slower.
Quote:Using threads without async is also more user friendly, and more optimal in terms of performance.
No. No it so is completely not. You're wrong about literally everything you said. If you use threads, and you don't want to be an idiotic skid about it, you have to implement thread safety. Obviously there are APIs like `multiprocessing.pool.ThreadPool` and `concurrent.futures.ThreadPoolExecutor` that can help, but you still need thread safety if you want to access the same mutable structure or something like that.
Quote:I do also agree with you that he needs to stop asslicking asyncio.
If I'm being honest, I've never eaten ass before. Doesn't appeal to me. If a girl wants to do it to me, that's fucking awesome, but I've never done it. That being said, if asyncio was a girl, I'd munch on the brown star as long as she wants.
* - 05317832892 - Feb 21, 2017
(Feb 21, 2017 11:59 AM)Goodies Wrote: If I'm being honest, I've never eaten ass before. Doesn't appeal to me. If a girl wants to do it to me, that's fucking awesome, but I've never done it. That being said, if asyncio was a girl, I'd munch on the brown star as long as she wants.
Lmao, brilliant.
* - obby - Feb 21, 2017
(Feb 21, 2017 11:59 AM)Goodies Wrote: I'm overtly familiar with the GIL (L = Lock, not Limiter, by the way). I program in C/++ with the Python API, bud, and I'm plenty familiar with how it works in the backend. The GIL is just a binary semaphore and a condition variable. And judging by the fact that you think the multithreading module is an attempt to bypass the GIL, I'd say I have a much better understanding of it than you do lol. Asyncio DOES bypass the GIL for I/O bound code because the GIL is released upon blocking I/O operations (such as network activity). Multithreading more or less does the same thing, but far less efficiently. In CPython, only one thread an access the Python API at any given time. Multithreading works by switching between threads every `sys.getcheckinterval()` ticks, OR by releasing the GIL when doing anything I/O related. If you are running CPU-bound pure Python code with multiple threads in CPython, you are guaranteed to be slower than if you only use one thread (due to the GIL).
Example, this code will always run slower in the multithreaded version in CPython so long as there is a GIL:
Spoiler (Click to View)
I don't think you get how this whole async thing works... Over 90% of the time, the thread is just waiting on an I/O operation. That's not an exaggeration. It really is over 90% in a huge number of networking applications. While it's waiting for the socket to respond (which often takes several hundred milliseconds, sometimes more) it can do plenty of other things (such as spawning a new socket connection, or even dozens of concurrent ones) all without affecting the speed of the others. This DOES provide maximum efficiency. Adding multiple threads will do nothing. Especially since asyncio can only have one event loop per thread/process. If you added more processes, you could handle more connections, but you also have to add IPC and process synchronization and safety. Typically, though, the bottleneck with asyncio is the network. More often than not, asyncio can handle way more active connections than your NIC can reliably support. You'll start to get socket timeouts before you'll run out of available connections.
Again, you completely misunderstand what async means. "Asynchronous" is just the overarching umbrella term. It does not mean "single-threaded asynchronous." It just means you're doing more than one thing at a time. True multithreading, mulitprocessing, parallel processing, etc... these are all forms of asynchronous execution.
Also, what you've recommended actually really doesn't provide any benefit in this case. Generally, what I do is have a `concurrent.futures.ProcessPoolExecutor` to which I offload any necessary CPU-bound processing, and the main thread simply runs the asyncio event loop, registers socket file descriptors, etc... Asyncio is so efficient BECAUSE it only uses one thread (except for things like DNS lookups in which case it does use another thread, but the overhead is very small overall). You don't need to incorporate thread synchronization or any extra safety. If you did, that would only make it slower.
No. No it so is completely not. You're wrong about literally everything you said. If you use threads, and you don't want to be an idiotic skid about it, you have to implement thread safety. Obviously there are APIs like `multiprocessing.pool.ThreadPool` and `concurrent.futures.ThreadPoolExecutor` that can help, but you still need thread safety if you want to access the same mutable structure or something like that.
If I'm being honest, I've never eaten ass before. Doesn't appeal to me. If a girl wants to do it to me, that's fucking awesome, but I've never done it. That being said, if asyncio was a girl, I'd munch on the brown star as long as she wants.
No one said anything about thread safety, so I'm not going to tackle these as it can be done in many ways and was never a topic to begin with. Continuing from there asyncio will allow you to get more work done, and purely using multiprocessing (side-stepping GIL) opposed to pure asyncio coroutines will result in higher performance when the task is primarily CPU-bound, however in primarily I/O-bound tasks yes asyncio will out perform both and I will concede on on my argument of threading and multiprocessing being a more efficient approach and for something like an IRC bot all would provide very similar results but asyncio would out perform. I apologize for coming across as rude and I get mixed up lock / limiter often.
* - Blackjack - Feb 26, 2017
This code is not great. Read the RFCs for the IRC protocol, learn it, and then learn how to properly do socket programming. You're doing both of those things wrong.
* - 05317832892 - Feb 26, 2017
(Feb 26, 2017 11:42 AM)Blackjack Wrote: This code is not great. Read the RFCs for the IRC protocol, learn it, and then learn how to properly do socket programming. You're doing both of those things wrong.
I'm well aware, the protocol is not amazingly documented. I have read up.
Might redo this when I have time, maybe using an IRC module instead of trying to do the socket communication manually.
* - michalmonday - Mar 1, 2017
Hi, I'm just wondering... couldn't a whole CountDown() thread be replaced by something like:
Code
global timePeriod #or "timePeriod = q.get()" using Queue module
while True:
if timePeriod:
lastClock = time.clock()
while (time.clock() - lastClock) < timePeriod:
#do stuff
timePeriod = 0placed within Attack() function?
* - 05317832892 - Mar 1, 2017
(Mar 1, 2017 07:54 AM)michalmonday Wrote: Hi, I'm just wondering... couldn't a whole CountDown() thread be replaced by something like:
Codeglobal timePeriod #or "timePeriod = q.get()" using Queue module
while True:
if timePeriod:
lastClock = time.clock()
while (time.clock() - lastClock) < timePeriod:
#do stuff
timePeriod = 0
placed within Attack() function?
That's quite a good idea, cuts down on threads and might help with variable safety.
* - The2G - Mar 6, 2017
Hi Cam,
I'm developing a variant of your given code, encrypting the messages, generating real-looking nicknames etc.. But When I try to connect to the IRC Server I get the following error:
ConnectionRefusedError: [WinError 10061]
I tried with different IRC servers and all give me that error. Why isn`t connecting to the server?
Thanks!
* - 05317832892 - Mar 6, 2017
(Mar 6, 2017 08:25 AM)Rubba Wrote: Hi Cam,
I'm developing a variant of your given code, encrypting the messages, generating real-looking nicknames etc.. But When I try to connect to the IRC Server I get the following error:
ConnectionRefusedError: [WinError 10061]
I tried with different IRC servers and all give me that error. Why isn`t connecting to the server?
Thanks!
Try the Kiwi IRC servers, IRC.FREENODE.NET I think it was.
Make sure the IP and port are correct.