Цитата(DarkMaster @ 4.2.2014, 1:11)
Тогда несколько непонятно в чем смысл шитья. Ты говоришь, что сам сможешь шить что хочешь. Ну сможешь, но ведь вся прелесть в существующей прошивке и в том, что ее можно модифицировать было бы. Если исходник закрытый, то либо писать с нуля, либо реверс инжиниринг. Более того, если ты выложишь свежую прошивку, то будет сразу же вагон девайсов-клонов у которых не понятно как менять ид, ведь код то закрыты. Не очень понятный момент... противоречие...
Как менять ID конечному пользователю при этом не имея доступ к исходному коду прошивки? Просто.
Он просто может заливать в девайс готовые прошивки .hex с разными id (их может быть много и даже очень). Где он их возьмет - думаю, ясно. Еще есть 2 варианта более перспективных, но более ресурсоемких - 1) онлайн-генерация прошивки. Например, вводишь на сайте желаемый id - сервак тестит его на валидность, сам компилит, и на выходе можно скачать .hex (нужен хостинг windows как я представляю) 2) создание урезанной версии компилятора или даже консольного приложения (программы) - чтоб рутину по компиляции и созданию .hex брала на себя без палева исходного кода. Править можно будет только ID в единственном файле конфигурации usb.
А смысл шитья конечным пользователем в том, что он все-таки как-никак должен иметь возможность обновлять firmware (обновления, смена того же id и т.д. - это кстати, одно из твоих пожеланий выше по топику). Это раз. Второй смысл шитья именно конечным юзером - что за любые изменения в девайсе, созданные не мной - я ответственности нести не буду, не хочу, не могу и не обязан по определению. Поэтому как говориться - хозяин-барин. Я думаю я понятно объяснил.. (IMG:
style_emoticons/default/smile.gif)
Цитата(DarkMaster @ 4.2.2014, 1:11)
Кстати первая же зацепка, как можно задетектить устройство улетает к тебе в личку.
Если кидаете возможный детект, сразу кидайте идеи как реализовать в девайсе на рассмотрение. Я тоже могу, зная тонкости девайса, тонну зацепок придумать - мыслимых и не мыслимых на уровне атомов... (IMG:
style_emoticons/default/smile.gif)
Как я уже говорил выше, в принципе, ничего не возможного нет - это относится как с нападению, так в равной степени и к защите. Вопрос лишь во времени и желанием обеих сторон. И возможность адаптироваться друг к другу - вот основная суть вопроса. Вспомните, сколько раз тот же uopilot переписывался/дописывался с связи с изменениями окружающей среды?
Цитата(DarkMaster @ 4.2.2014, 1:11)
А смысл его менять, если он рандомно сгенерированный и не палит явным образом девайс?
Любой id не палит девайс, пока его "например" выборочно не заблочили защиты (хотя пока это фантазия). Это одно. Второе - тут речь идет не только об id, а о возможности обновления firmware в целом.
Цитата(DarkMaster @ 4.2.2014, 1:11)
А в чем собственно проблема в уникальных ид? Поратить 2 минуты на изменение циферок и перекомпиляции?
Причины выше.
Цитата(WKnight @ 4.2.2014, 9:58)
Есть вероятность, что каждый скрипт одного и того же пилота, грузит свою копию длл.
так и есть. dll1.dll dll2.dll dll3.dll dllN.dll
Цитата(WKnight @ 4.2.2014, 9:58)
самое правильное, это общий буфер у всех загруженных экземпляров длл с одинаковой парой ид. Тогда и с задержками мудрить не придется.
Это уже сверх тонкости программирования, я к сожалению не имею таких глубоких познаний в программировании и тем более в с++ (несколько месяцев опыта программирования в нем). Более того, буфер для нескольких загруженных Dll это по-моему уже прероготива уже ПО - тут уж Вам карты в руки. Пусть данные из ПО поступают в этот буфер, а буфер последовательно уже кидает все накопленное в одну DLL. С такой схемой даже мой кольцевой буфер FIFO в девайсе не понадобиться.
Цитата(WKnight @ 4.2.2014, 9:58)
Тут подумать надо, при вызове функции или всетаки при загрузке длл. обращение к винту каждые 25мс не есть хорошо, поверь мне, я знаю (IMG:
style_emoticons/default/smile.gif)
Ну тут согласен на 100%. Постоянное "мигание" винта пусть даже на считывание - будет необоснованной потерей производительности. Подумаю (есть некоторые мысли уже сейчас) + предлагайте идеи.