Василий Банников

OpenGL - Open Graphics Library.
Это - открытая библиотека работы с графикой. И в ее API содержатся только функции работы с графикой.
Для обработки коллизий нужна отдельная библиотека обработки коллизий, в зависимости от мировой системы координат. Простую библиотеку можно и самому сделать.
Для обработки коллизий используют библиотеки коллизий и физические движки.

В юнити можно писать только на C#

Почитайте про События «click» и addEventListener и event.target.

А еще про циклы типа forEach и то как найти элементы в DOM например querySelectorAll.

Алгоритм примерно такой:
Нужно найти все кнопки (см. querySelectorAll) циклом повесить обработчик событий на каждую кнопку (см. addEventListener) и при событии клика вешать нужный класс на нажатую (см. event.target)

А если хочеца готовое решение, на ютубе масса примеров и гайдов на эту тему. Тема довольно простая на самом деле. Удачи!

вы же сами написали

потом надо перевести их в байты (8,25 байт, округлить в большую сторону = 9 байт)

то есть на самом деле на слово уходит 72 бита
72*60 паролей / 8 = 4320/8 = 540

внимательно надо читать что в учебнике написано, пункт 4 "целое количество байтов" на слово

Перепрошить, официальную прошивку, для этого не нужен ни рут ни какие то телодвижения

Такие трояны легко получить если покупаешь с рук на площадках типа Авито, АлиЭкспресс, геарбест и т.п.

Гугл использую. А еще - не ищу библиотеки, а ищу "как сделать такой то функционал" - и уже там будет либо код, либо библиотека. Где сама библиотека лежит глубоко все равно.

как раз "новые инструменты" и использует для решения нерешенных задач

Здесь другое. Задача трёх тел не относится к нерешённым математическим проблемам. https://ru.wikipedia.org/wiki/Открытые_математичес...
С этой задачей математикам всё ясно. Примерно как с задачей квадратуры круга. Типа: придумать новый математический инструмент для вычисления (наконец-то) всех цифр числа Пи. :) Вот и невозможность аналитического решения в общем случае задачи трёх тел - вполне доказанный математически факт. Никакие новые методы не отменяют старых доказательств. В этом принципиальное отличие математики от естественных наук.

Брунс и Пуанкаре доказали, что систему дифференциальных уравнений для движения трёх тел невозможно свести к интегрируемой. https://ru.wikipedia.org/wiki/Задача_трёх_тел

Но численные методы - это раздел математики. Решение численными методами (приближённое) - теоретически возможно. Практически - крайне затруднительно.

К несчастью, как показал Д. Белорицкий, по крайней мере в случае Лагранжа для нужд вычислительной астрономии в сходящихся рядах Зундмана нужно брать как минимум 10^(8*10^6) членов. https://ru.wikipedia.org/wiki/Задача_трёх_тел

Вот здесь - в численных методах - и остаётся возможность "придумать новый математический инструмент". Здесь никто не запрещает. Повторю: даже при открытии такого инструмента (а это стало бы важным открытием) он будет давать лишь приближённое решение.
И ещё раз повторю: невозможность получения точного решения - доказана и неоспорима.

Если вы под "багом" подразумеваете то, что четко описано в ТЗ и не выполнено, то нет, платить не должны. Но если вы подразумеваете под "багом" что-то вроде "так это же очевидно, что оно должно так работать", но не описали в ТЗ, то да! Это будет не баг со стороны программиста, а баг со стороны вас, как ПМ-а. Ибо, что не сказано, то есть ложь! Если вы не удосужились описать четкий функционал, что должно вводится, что должно получиться на выходе, как это должно работать, то не ждите "очевидных" для вас решений, так как все, что очевидно для вас, не очевидно для других.

Не платите. Тогда все разработчики просто уйдут туда, где платят. А вы останетесь изучать теорию, объясняющую почему и как появляются баги, пока не осознаете их неизбежность.

У меня примерно так:
1. Если задание выполнено строго по ТЗ и принято - любой вновь найденый баг - это уже новая работа которая должна быть оплачена.
2. Если задание не выполнено по ТЗ и баги при приемке не принимать - то это ошибка разработчика, пусть исправит.
---
3. ТЗ должно быть составлено так чтобы не могло быть двойного трактования - если ТЗ позволяет трактовать задачу размыто и компания может предполагать одно, а исполнитель другое - ошибка того кто дал это задание разработчику - соответственно это не проблема разработчика, он не знает что у вас в голове и работа по переделке будет оплачена.
---

А вообще никаких общих правил не существует - как договоритесь так и будет.

Разработчику оплачивается время работы.
Если он работает в определённое время, то оно должно быть оплачено.
Задача, выполняемая разработчиком, может быть принята, либо не принята. Если не принята, то она не оплачивается.
Процесс принятия работы - это отдельная тема.
Всё это прописывается в трудовом договоре, детки.

Отлично, теперь вам надо написать загрузчик бинарников для вашей ОС

Если программа реально консольная а не собственное текстовое окно стилизованное под консоль.
stdin - передача в программу
stdout - получение из программы

from subprocess import Popen, PIPE, STDOUT

p = Popen(['passwd', 'root'], stdout=PIPE, stdin=PIPE, stderr=STDOUT)    
out = p.communicate(input=b'MyPass111\nMyPass111\n')[0]
print(out.decode())