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

[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)