Skip to content
This repository has been archived by the owner on Oct 17, 2022. It is now read-only.

Processing hangs/dies on larger input files #1

Open
tatanus opened this issue Sep 18, 2018 · 2 comments
Open

Processing hangs/dies on larger input files #1

tatanus opened this issue Sep 18, 2018 · 2 comments
Labels
bug Something isn't working

Comments

@tatanus
Copy link

tatanus commented Sep 18, 2018

I have tried running atomizer.py several times and for input userfiles > 597, it starts behaving oddly.

  • For userfiles < 597, it appears to run and terminate as expected.
  • For userfiles > 597, it will process to around 597, then hang indefinitely.
  • For very large userfiles (>100000) it will process a few hundred then die. I am not sure what is causing the process to die, there is no error message. I have even enabled the "-d" flag to see if there was any debug messages of use. Nothing. I simply get the message "Killed".

This is the commandline I have used (obviously I actually entered my correct and ).
python3.7 atomizer.py lync <domain> <password> --userfile users.txt

I have tried running this on both Kali Rolling 2018.3 and on Ubuntu 16.04.3 LTS. Same results on both.

@byt3bl33d3r byt3bl33d3r added the bug Something isn't working label Sep 18, 2018
@byt3bl33d3r
Copy link
Owner

byt3bl33d3r commented Sep 18, 2018

hmm i think i've figured this out, the only thing i can think of is possible memory exhaustion cause of the large file when we allocate the user accounts to the thread pool here:

blocking_tasks = [
self.loop.run_in_executor(self.executor, self.sprayer.auth_O365 if self.sprayer.O365 else self.sprayer.auth, email.strip())
for email in users
]

Could you run htop/top and look at the memory consumption while running atomizer with that large userfile on your system?

Thanks!

byt3bl33d3r pushed a commit that referenced this issue Aug 18, 2019
@alxbl
Copy link
Contributor

alxbl commented Oct 5, 2019

This could probably be fixed by reading the user file line by line instead of slurping it. I guess it would also have the added bonus of being able to dynamically add users to a spray session because the file would be re-read on each spray interval (when using --interval).

The same issue could occur with large password files and could be handled in the same way.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants