Go to file
EmaMaker 0bd11846db update README.md 2021-08-21 03:34:21 +02:00
__pycache__ Get credentials from qwiklabs 2021-08-21 03:27:19 +02:00
README.md update README.md 2021-08-21 03:34:21 +02:00
colab_automator.sh Get credentials from qwiklabs 2021-08-21 03:27:19 +02:00
gui.py Get credentials from qwiklabs 2021-08-21 03:27:19 +02:00
main.py Get credentials from qwiklabs 2021-08-21 03:27:19 +02:00
requirements.txt Get credentials from qwiklabs 2021-08-21 03:27:19 +02:00

README.md

Google Colab Automator, without Selenium!

What is this

Google Colab is a Google service which gives free, temporary, use of virtual machines with powerful NVIDIA Tesla GPUs. Normally this is used to train ML and other AI models, but nothing impedes the use of the service for other purposes, such has password cracking with hashcat or crypto mining (at least in the free version - in Google Colab Pro crypto mining is forbidden). The downside is that the account gets temporary blocked when a too andlong intense use is detected. Qwiklabs (qwiklabs.com) is a third-party service which gives temporary Google Accounts for training in Google Cloud Shell use. Their first course (https://www.qwiklabs.com/focuses/2794?parent=catalog) is completely free, others require some in-site credits to be purchased. Combining the two services, infinite temporary and disposable Google Accounts can be obtained from qwiklabs and used for mining on colab, until the qwiklabs session expires or the miner gets blocked by Colab. At such point, a new session can be started. That's basically free money. Obviously this can also be used to automated non-malicious tasks, as long as the Colab notebook is publicly available (e.g. as a github gist). After a certain time number of times repeating the course, the qwiklabs account might reach it's quota for that course and a new one needs to be created. I'll will look into a way of automating account creation in the future. For now, use temp mails from temp-mail.org when creating accounts

Why no selenium

Selenium carries some javascript and other stuff which can easily be detected by most websites - GColab and Qwiklabs included - and get the session blocked, especially if captchas are involved (There are workarounds to captchas for selenium - https://github.com/ohyicong/recaptcha_v2_solver - but often the captcha doesn't even get presented to the user if an automated browser session is detected)

The workaround

Use a plain chrome/firefox session, and automate by programmatically controlling mouse and keyboard. Basic anonimizing of the web session is still needed (spoof ip/mac, change useragent/geolocation/timezone). Actions need to be done at a human speed, or the bot could be recognized as an actual one. This type of use seems to be detected as legit enough to not even display a captcha when starting a Lab.

Mouse and Keyboard control

Mouse and keyboard are controlled using https://pyautogui.readthedocs.io/en/latest/
For simpicity, and to avoid messing up the OS by clicking on the wrong stuff, both chrome and pyautogui can be started in a separate Xephyr (https://wiki.archlinux.org/title/Xephyr) window, where they can harm no one. This also gives consistent screen coordinates to the elements on the screen: Google chrome will always be fullscreen inside Xephyr. Mouse coordinates are relative to the X server the script is started in. Using a nested X server with Xephyr requires copyq to share the clipboard with the main X server