Hardware UO Pilot, Аппаратный UO Pilot Опции

[Александр85]

Всем привет =)
Предлагаю на рассмотрение аппаратную клавиатуру UOkeyboard - usb устройство эмулирующее нажатие клавиш клавиатуры.

(IMG:http://img-fotki.yandex.ru/get/9089/211554415.0/0_10f302_e4c1343e_L.jpg)
UOkeyboard, это usb устройство гаджет которое работает как usd-hid клавиатура и посылает нажатия клавиш, по заданному алгоритму. UOkeyboard довольно полезная штука в ситуациях, когда нужно долго и монотонно кликать по одним и тем же кнопкам.
Теперь не требуется судорожно жать на все кнопки! Стоит просто подключить данное устройство в свободный USB разъем компьютера, и нажатие клавиш клавиатуры будет автоматическое по заданному вами алгоритму!
Одной из приятных особенностей является то, что UOkeyboard не "палится" системой защиты.
Поскольку он не требует драйвера, и определяется как обычная клавиатура. Для HID-устройств USB не нужны драйвера в операционных системах Windows, драйвер находиться уже в самой ОС.
При первом подключении, ПК автоматически распознает UOkeyboard, занимает несколько секунд.


(IMG:http://img-fotki.yandex.ru/get/9164/211554415.0/0_10f2ef_2930a705_M.jpg)
(IMG:http://img-fotki.yandex.ru/get/9153/211554415.0/0_10f2f0_3d1dbc81_M.jpg)
В дальнейшем при использовании UOkeyboard, гаджет начинает сразу же работать при подключении в USB.
Возможные варианты использования UOkeyboard:
I.Отлично помогает в пвп.
II.Прокачивать персонажа.
III.Cпам сообщений в чат.
Схема UOkeyboard

(IMG:http://img-fotki.yandex.ru/get/9090/211554415.0/0_10f301_2d3939c9_L.jpg)
Данный девайс UOkeyboard был разработан на основе МастерКидовского набора MP1505 - Клавиатурная шутка Мастер Кит. Был перепрограммирован микроконтроллер написанной мною программой, задан алгоритм нажатия клавиш клавиатуры.
Теперь по порядку:
1. Описание схемы:
Основой данного девайса является микроконтроллер фирмы Atmel AVR - ATtiny45, ножки которого 5 и 7 подключены через резисторы 68 Ом к USB разъему. Эти резисторы 68 Ом несут защитную функцию. Диоды D2, D3 необходимы для согласования требования стандарта USB по уровням сигналов. Светодиод D1 нужен для индикации работы устройства UOkeyboard. Для программирования микроконтроллера стоит разъем ISP. (в Мастер Китовском наборе его нет.)
2. Описание программы для прошивки UOkeyboard:
Прошивка для UOkeyboard основан на коде AVR USB и доступен на условиях лицензии GNU (Универсальная общественная лицензия). Микроконтроллер ATtiny45 не поддерживает аппаратного USB протокола, поэтому пришлось писать программный интерфейс USB. Из-за этого программа выросла в размерах. Я выкладываю исходник прошивки с комментариями.
При написании программы использовались программа AVR Studio — интегрированная среда разработки (IDE) для разработки 8-ми и 32-х битных AVR приложений от компании Atmel, работающая в операционных системах Windows NT/2000/XP/Vista/7. А также программный пакет WinAVR — включающий в себя кросс-компилятор и инструменты разработки для микроконтроллеров серий AVR и AVR32 фирмы Atmel. Прошивка для UOkeyboard написана на язике Си для AVR микроконтроллеров.
Желающих ознакомиться с основами программирования на язике Си под AVR микроконтроллеры советую почитать тут.
3. Как прошить UO keydoard.
После того как готова прошивка с заданным алгоритмом работы UO keydoard нам понадобиться программатор для микроконтроллера ATtiny45. Я использую вот этот AVR программатор . Вы можете использовать любой другой. Думаю с прошивкой микроконтроллера проблем не будет, там все тривиально.

Теперь все готово, подключаем UO keydoard в свободны разъем USB и наслаждаемся работой =)

Эта разработка абсолютно бесплатная (Freeware), распространяется "как есть" ("As is"),
то есть вы используете ее на свой страх и риск! И я, как автор, не несу никакой ответственности
за последствия, связанные с использованием этого устройства на Вашем компьютере.

Жду ваших отзывов о данной разработке, замечаний, предложений ....

Желающих собрать схему самостоятельно, выкладываю полный список комплектации:
1. МК ATtiny45
2. макетная плата
3. USB разъем
4. 2 резистора 68 Ом (0.25 Вт)
5. 1 резистор 2.2к Ом и 1 резистор 470 Ом (0.25 Вт)
6. 2 диода DL4148 (или любой другой маломочный)
7. 1 светодиод (любой по вашему желанию)
8. Конденсатор 0.1 мкФ
9. Разъем ISP
10. Панелька под контроллер если будете брать в корпусе DIP8.

Схему лучше собрать на монтажной плате, и вкинуть в подходящий корпус.
Выглядит это примерно так =)

(IMG:http://img-fotki.yandex.ru/get/9110/211554415.0/0_10fbb6_bcad132a_M.jpg)

Выкладываю прошивку которую, я брал за основу. Исходный код прошивки распространен на условиях лицензии GNU (Code and Life=) Данная прошивка эмулирует USB-клавиатуру и генерирует нажатия на кнопки. Файл для прошивки микроконтроллера Haunted-USB.hex находиться в папке default.
СКАЧАТЬ
Тут прошивка, исходный код программы на Си, весь проект в AVRstudio. (архив желательно распаковать на диск С в корневик)

ПОСТ ЕЩЕ НЕ ДОПИСАН.....

[DarkMaster]

Не путайте прошивку с исходным кодом, кто сказал что исходный код будет открытым? Даже если файл прошивки (.hex) будет открытым, он нигде в системе не фигурирует, это бинарный код, понятный только микроконтроллеру, да и притом не каждому, и никаких зацепок к алгоритму, имея его, защита иметь не будет.

Тогда несколько непонятно в чем смысл шитья. Ты говоришь, что сам сможешь шить что хочешь. Ну сможешь, но ведь вся прелесть в существующей прошивке и в том, что ее можно модифицировать было бы. Если исходник закрытый, то либо писать с нуля, либо реверс инжиниринг. Более того, если ты выложишь свежую прошивку, то будет сразу же вагон девайсов-клонов у которых не понятно как менять ид, ведь код то закрыты. Не очень понятный момент... противоречие... Кстати первая же зацепка, как можно задетектить устройство улетает к тебе в личку.

А смысл кому-то получить девайс с каким-то "левым" ID, который все равно не будет возможности изменить в дальнейшем?

А смысл его менять, если он рандомно сгенерированный и не палит явным образом девайс?

Во-вторых, такой системы детекции еще нет и неизвестно, будет ли и когда..

По части инновы думаю, что это дело времени и относительно небольшого. Забугорный сегмент вряд ли дойдет до этого, а вот местные на ура.


А в чем собственно проблема в уникальных ид? Поратить 2 минуты на изменение циферок и перекомпиляции?

[WKnight]

или отработало событие второго скрипта и.т.д

о нескольких Dll-ках и одном usb2kbd (нескольких пилотах и одном usb2kbd).

Есть вероятность, что каждый скрипт одного и того же пилота, грузит свою копию длл.

чем больше кол-во активных копий DLL

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

При вызове функции из DLL она считает ini файл и поймет, с какой парой ей работать.

Тут подумать надо, при вызове функции или всетаки при загрузке длл. обращение к винту каждые 25мс не есть хорошо, поверь мне, я знаю (IMG:style_emoticons/default/smile.gif)

[usb2kbd]

Тогда несколько непонятно в чем смысл шитья. Ты говоришь, что сам сможешь шить что хочешь. Ну сможешь, но ведь вся прелесть в существующей прошивке и в том, что ее можно модифицировать было бы. Если исходник закрытый, то либо писать с нуля, либо реверс инжиниринг. Более того, если ты выложишь свежую прошивку, то будет сразу же вагон девайсов-клонов у которых не понятно как менять ид, ведь код то закрыты. Не очень понятный момент... противоречие...

Как менять ID конечному пользователю при этом не имея доступ к исходному коду прошивки? Просто.
Он просто может заливать в девайс готовые прошивки .hex с разными id (их может быть много и даже очень). Где он их возьмет - думаю, ясно. Еще есть 2 варианта более перспективных, но более ресурсоемких - 1) онлайн-генерация прошивки. Например, вводишь на сайте желаемый id - сервак тестит его на валидность, сам компилит, и на выходе можно скачать .hex (нужен хостинг windows как я представляю) 2) создание урезанной версии компилятора или даже консольного приложения (программы) - чтоб рутину по компиляции и созданию .hex брала на себя без палева исходного кода. Править можно будет только ID в единственном файле конфигурации usb.

А смысл шитья конечным пользователем в том, что он все-таки как-никак должен иметь возможность обновлять firmware (обновления, смена того же id и т.д. - это кстати, одно из твоих пожеланий выше по топику). Это раз. Второй смысл шитья именно конечным юзером - что за любые изменения в девайсе, созданные не мной - я ответственности нести не буду, не хочу, не могу и не обязан по определению. Поэтому как говориться - хозяин-барин. Я думаю я понятно объяснил.. (IMG:style_emoticons/default/smile.gif)

Кстати первая же зацепка, как можно задетектить устройство улетает к тебе в личку.

Если кидаете возможный детект, сразу кидайте идеи как реализовать в девайсе на рассмотрение. Я тоже могу, зная тонкости девайса, тонну зацепок придумать - мыслимых и не мыслимых на уровне атомов... (IMG:style_emoticons/default/smile.gif)

Как я уже говорил выше, в принципе, ничего не возможного нет - это относится как с нападению, так в равной степени и к защите. Вопрос лишь во времени и желанием обеих сторон. И возможность адаптироваться друг к другу - вот основная суть вопроса. Вспомните, сколько раз тот же uopilot переписывался/дописывался с связи с изменениями окружающей среды?

А смысл его менять, если он рандомно сгенерированный и не палит явным образом девайс?

Любой id не палит девайс, пока его "например" выборочно не заблочили защиты (хотя пока это фантазия). Это одно. Второе - тут речь идет не только об id, а о возможности обновления firmware в целом.

А в чем собственно проблема в уникальных ид? Поратить 2 минуты на изменение циферок и перекомпиляции?

Причины выше.

Есть вероятность, что каждый скрипт одного и того же пилота, грузит свою копию длл.

так и есть. dll1.dll dll2.dll dll3.dll dllN.dll

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

Это уже сверх тонкости программирования, я к сожалению не имею таких глубоких познаний в программировании и тем более в с++ (несколько месяцев опыта программирования в нем). Более того, буфер для нескольких загруженных Dll это по-моему уже прероготива уже ПО - тут уж Вам карты в руки. Пусть данные из ПО поступают в этот буфер, а буфер последовательно уже кидает все накопленное в одну DLL. С такой схемой даже мой кольцевой буфер FIFO в девайсе не понадобиться.

Тут подумать надо, при вызове функции или всетаки при загрузке длл. обращение к винту каждые 25мс не есть хорошо, поверь мне, я знаю (IMG:style_emoticons/default/smile.gif)

Ну тут согласен на 100%. Постоянное "мигание" винта пусть даже на считывание - будет необоснованной потерей производительности. Подумаю (есть некоторые мысли уже сейчас) + предлагайте идеи.

[DarkMaster]

По поводу защиты можно сделать очень простой вариантик. Помимо пидов в инишник добавить пароль девайса. При посылке нажатия отсылать так же параметром пароль. Пароль естественно должен быть опять же уникальным.

[usb2kbd]

По поводу защиты можно сделать очень простой вариантик. Помимо пидов в инишник добавить пароль девайса. При посылке нажатия отсылать так же параметром пароль. Пароль естественно должен быть опять же уникальным.

Отписал в личку почему все это неэффективно.

[WKnight]

Цитата(WKnight @ 4.2.2014, 9:58) Есть вероятность, что каждый скрипт одного и того же пилота, грузит свою копию длл. так и есть. dll1.dll dll2.dll dll3.dll dllN.dll

Нет, имелось ввиду одну и ту же.
Один пилот, одна длл, но каждый скрипт загружает в память отдельную копию этой длл.

[usb2kbd]

Нет, имелось ввиду одну и ту же.
Один пилот, одна длл, но каждый скрипт загружает в память отдельную копию этой длл.

Можно и так, но придется я так понял дорабатывать uopilot. По-моему, проще и понятнее схема - один uopilot на один скрипт и на одну Dll. Кроме того, все равно прийдется уже для Uopilot дописывать кольцевой буффер того же FIFO...
Но все же, по-моему проще грамотно настроить паузы. К тому же будет индикация на уровне девайса (писал выше).
В общем, на Ваше усмотрение уже - паузы никто не отменяет, их можно и не использовать если FIFO на уровне Uopilot будет.

[DarkMaster]

Можно и так, но придется я так понял дорабатывать uopilot.

Если я правильно понял, то кнайт как раз говорит об обратном. Т.е. оно сейчас уже в режиме 1 вкладка = 1 копия длл.

[usb2kbd]

Если я правильно понял, то кнайт как раз говорит об обратном. Т.е. оно сейчас уже в режиме 1 вкладка = 1 копия длл.

Ну я вот, например, не представляю, каким образом реализовать такой буфер в пределах Dll-ки, да еще при этом чтоб учесть возможность ее функционирования если ПО грузит несколько копий Dll и чтоб это со всех копий вливалось в один буфер, который уже будет последовательно с заданными паузами кидать в девайс. К сожалению не мой уровень с++. На уровне железки - реализовано, регулировка паузами в скрипте - дело элементарного подбора "под себя". Двойная буферизация - слишком круто ИМХО, а главное, НЕ жизненно важно.

[usb2kbd]

Ну я вот, например, не представляю, каким образом реализовать такой буфер в пределах Dll-ки, да еще при этом чтоб учесть возможность ее функционирования если ПО грузит несколько копий Dll и чтоб это со всех копий вливалось в один буфер, который уже будет последовательно с заданными паузами кидать в девайс. К сожалению не мой уровень с++. На уровне железки - реализовано, регулировка паузами в скрипте - дело элементарного подбора "под себя". Двойная буферизация - слишком круто ИМХО, а главное, НЕ жизненно важно.

Приступаю к разработке возможности интеграции в девайс USB bootloader'а - BootloadHID. В теории должен влезть в АТmega8. Посмотрим...

[usb2kbd]

Приступаю к разработке возможности интеграции в девайс USB bootloader'а - BootloadHID. В теории должен влезть в АТmega8. Посмотрим...

В usb2kbd успешно интегрирован бутлоадер и проверен на Windows 7. Это позволит прошивать usb2kbd непосредственно через Usb-порт без использования специального устройства - программатора.

[usb2kbd]

Итак, почти все предложения по девайсу в пределах его и моих возможностей были максимально учтены и внедрены. Также были проведены все необходимые полевые испытания. Всю необходимую информацию можно будет почитать на сайте продукта usb2kbd.info в разделе "Новости".

[usb2kbd]

Добрый день! Новости от проекта usb2kbd:

03.08.2014. Разработана программа Usb2Kbd Remote. Программа позволяет управлять удаленным копьютером с подключенным Usb2Kbd через RealVnc. На сайте добавлен соответствующий раздел+видео.

05.09.2014. Для повышения гарантий проекта мною получен аттестат продавца в системе Webmoney.

[usb2kbd]

18.10.2014. Добавлено видео Usb2kbd и РуОфф.

youtu.be/TiP2QSaiaPE

[usb2kbd]

25.10.2014. В раздел сайта "Программное обеспечение" добавлен пример подгрузки DLL в Visual Basic

[usb2kbd]

02.11.2014. Добавлена возможность протестировать девайс на Вашем компьютере не выходя из дома! Подробнее на сайте продукта usb2kbd.info

[usb2kbd]

16.11.2014г. Добавлена статья "Usb2kbd и АСТЕР"

[usb2kbd]

30.11.2014. Для владельцев девайса версии v2.0 и выше появилась возможность самостоятельной генерации .hex файла прошивки. Подробнее - в разделе "Прошивка usb2kbd" навигации сайта. Сервис доступен после 19-00 МСК.

30.11.2014. Usb2kbd теперь в фабричной сборке на основе SMD-компонентов! Внешний вид - на главной странице сайта.

usb2kbd.info

[usb2kbd]

Добрый день! Важная информация! С 23.04.2015 г сайт продукта usb2kbd будет доступен по ссылке usb2kbd.ru
Также задавайте все вопросы на e-mail usb2kbd@gmail.com

[Лайнейджер]

(IMG:style_emoticons/default/rolleyes.gif) Всем привет, выражаю благодарность создателю такой замечательной программы как uopilot!
К сожалению защита "фрост" блокирует полностью эмулируемые нажатия клавиш и мыши, поэтому я решился на покупку девайса usb2kbd. Проверил девайс в связке с пилотом, пилот определяет цвет пикселя в окнах и посылает желаемые команды уже на сам девайс и все отлично работает, даже нажатия мышью работают, пример скрипта на нажатие мышью в пилоте:
wait 2s
set #b1 mydll.Send (3,0,100,200,$VPID)
wait 250
set #b1 mydll.Send (3,1,100,200,$VPID)
set linedelay #linedelayLast
Проверил под запущенным фростом в активном окне работают все клавиши клавиатуры и мыши! (IMG:style_emoticons/default/cool.gif)