1. я тоже не смотрел ключи(их просто нет в наличии у меня) 2. произведенные мною действия - внес исправления в нетмемо(тип ключа 0xFD) и ответ в чек-пасс 0x1A. после этого сразу после конекта к ключу хасп-эдитом всплывают фукции, специфичные тайм-ключу. т.е функция гэт-тайм-хасп-ид получается именно через запрос 0x9C... логирование произвожу юзб-сниффом. Тоже произвел из брайн-студии - логи те-же. сейчас нужно просто разобраться в кол-ве воспринимаемых байт ответа на каждую функу. 3. Замечено следующее - может конечно я и ошибаюсь, но, функции SetTime & SetDate идут НЕ через 0xC0 : -------------------SetTime.log-------------------- reqv c0 80 66 8c 00 00 07 00 - set_chiper_key's answ 25 88 62 0f 50 23 8e reqv c0 81 09 86 6d ee 05 00 - check_pwd answ e6 f2 03 d1 41 reqv 40 1d 95 3f 79 b8 01 00 - ?????? -------------------------------------------------- в данном случае сеансовые ключи разрушаются не из-за этого а из-за неправильной длинны ответа. если в статус вставить ошибку то демон при анализе остановит изменение сеансовых ключей на втором байте и соответственно ключ будет таким-же как и в муле.
> сейчас нужно просто разобраться в кол-ве воспринимаемых байт ответа на каждую функу Можно перебором конечно... Потом проверять на известных функциях - если они отработают корректно, значит - ok ? > reqv 40 1d 95 3f 79 b8 01 00 - ?????? А что при этом передается в драйвер (пакет из DeviceIoControl) ? > в данном случае сеансовые ключи разрушаются не из-за этого а из-за неправильной длинны ответа. если в статус вставить ошибку то демон при анализе остановит изменение сеансовых ключей на втором байте и соответственно ключ будет таким-же как и в муле. Согласен. Просто никак не разберемся что такое 0xA0 - появляется в новых драйверах. PS Если не секрет, какую версию пользуешь и на какой OS ? PPS Интересна также проблема неработоспособности с новыми драйверами (>4.95).
после данных функций обычно сразу приходит чек-пасс. если пред ответ бл неправильным - чек-пасс будет битый из-за потери сеансовых ключей - все что надо - подобрать только длнны ответа а не его содержимое для получения правильного последующего запроса. щас разбираюсь.... ответ - похоже ничего т.к. информационных полей нет. а оригинал(старый юзб-ключ) все-таки отвечает на этот запрос. свою HW. ессно ОС - любая. не знаю - нашел гык в дровах псах - не с первого раза ставятся - во время инстала последних дров забери из темпа каб файл - там кроме аксюзб ставится еще несколько. и кроме этого в списке юзб устройств кроме аладин хасп появится аладин юзб. может это тебе чем-то поможет. З.Ы. столкнулся с толи траблом толи гыком - ситуация след - похоже если при сборке протекченного приложения ЯВНО указывается что ключ ЛПТ - то в тело вкладываяется код аппаратного обращения к лпт. это еще не 100% - сегодня все проверю. в связи с этим у меня вопрос - чтоб не терять времени на изобретение колеса - может пробегал протокол обмена дров на лпт? З.З.Ы. и не в тему - ты задавал вопрос по жсм-модемам. вопрос еще актуален?
>> „Согласен. Просто никак не разберемся что такое 0xA0 - >> появляется в новых драйверах. “ > ответ - похоже ничего т.к. информационных полей нет. а > оригинал(старый юзб-ключ) все-таки отвечает на этот > запрос. Фишка в том, что такой запрос дают только новые драйвера(>4.95). Они вроде бы ничего не делают с ответом, и более того - никак его не используют (bpm). Такое ощущение, что не нужно ничего делать, возможно даже не шифровать ответ теряя таким образом сеансовые ключи. >> „PS Если не секрет, какую версию пользуешь и на какой >> OS ? “ > свою HW. ессно ОС - любая. Я спрашивал про версию мулятора, а что такое HW ? >> „PPS Интересна также проблема неработоспособности с >> новыми драйверами (>4.95).“ > не знаю - нашел гык в дровах псах - не с первого раза > ставятся - во время инстала последних дров забери из > темпа каб файл - там кроме аксюзб ставится еще > несколько. и кроме этого в списке юзб устройств кроме > аладин хасп появится аладин юзб. может это тебе чем-то > поможет. Ну наш муль с ними не работает. При установке (или же загрузке системы) приходит 0x80, потом 0xA0. И в муле и в аксусе сеансовые ключи в порядке - одинаковые. Затем если сделать любой HASP API, то (далее - 98 OS) hardlock.sys вызвает через NTKERN akscls9x, тот также через NTKERN вызвает какую-то ерунду и blue screen (на муль больше ничего не приходит). Если ключ настоящий, то все то же самое, только вызов из akscls уже работает и все благополучно попадает в usbhub.vxd. > в связи с этим у меня вопрос - чтоб не терять времени > на изобретение колеса - может пробегал протокол обмена > дров на лпт? Я не очень понял. Разобрался в свое время с пакетами DeviceIoControl для hardlock.sys. Или ты работу с hasp4 lpt через in/out в драйвере ? Кое-что выдернул реверсируя hardlock.sys - тоже тут где-то на форуме валяется... > З.З.Ы. и не в тему - ты задавал вопрос по жсм-модемам. > вопрос еще актуален? Спасибо, вопрос не особо актуален - скорее даже пофигу Там была такая история - при передаче по обычному модему скорость передачи была, допустим, 250 байт/сек от хоста на терминал. Передача шла по ZMODEM, те пакеты слегка кодированные причем хост отправлял их с подтверждением получения (терминал на каждый пакет говорил типа ~ACK пакета). Если то же самое но по жсм модему то все становилось плохо - скорость падала до 150 байт/сек причем с большим числом коррекций (повтороный запрос неверно полученного пакета). Все это интересно еще тем, что получение файлов от терминала на хост по тому же жсм'у шла просто на ура без сбоев. Но разница только одна - терминал передавал данные пакетами без подтверждения, те хост не должен был подтверждать каждый принятый пакет, а высылать повторный запрос только в случае сбоя.
это вызывается только после сет_чипер_кей. мое предположение - это зарелиженая функа изначально, но неюзаная в драйверах(ключи поддерживают). т.е. предпологаю что она юзается только для синхры новых сеансовых ключей. HW=HardWare вот моё формирование ответа на 0хА0: ................................................... ;store key's lds el, UHASP_ChiperKey + 0 lds eh, UHASP_ChiperKey + 1 lds dl, UHASP_ChiperKey + 2 lds dh, UHASP_ChiperKey + 3 ldi al, _def_KEY_OPERATION_STATUS_OK ; Operation status OK sts buff_AnswerArray + 0, al lea Y, buff_AnswerArray ldi al, 1 rcall UHASP_ChiperBuff lea Z, buff_AnswerArray ;sending is value from AnswerArray ldi al, 0x81 ;RAMREAD=1 - reading from RAM mov RAMread, al ldi al, 1 ;answer PKT size ;restore prev key's sts UHASP_ChiperKey + 0, el sts UHASP_ChiperKey + 1, eh sts UHASP_ChiperKey + 2, dl sts UHASP_ChiperKey + 3, dh ................................................... я имел ввиду сигнальный уровень, формирование и прием-передачу пакетов по "последовательному" интерфейсу - типа там запитка девайса по 16-й и еще какой-то, DAT , CLK... etc. ------ОФФ_ТОП-------------------------------------------- на данное заявление возможен на мой взгляд один ответ - в жсм кодеке существуют две премерзопакостнейшие вещи - 1. Voice Active Detection - т.е. при тишине в линии чтоб не нагружать канал линия ложится в даун - и ессно модему приходится пересинхронизиться. 2. там была какая-то фигня(не помню как называлась) короче - тоже из кодека - предыидущий фрейм накладывается на текущий - чтоб избавиться от "эффекта тишины" на конечных абонентах. я так понял вы цепляли модемы через голосовой канал а не через дата. вообще у меня где-то валялась дока по работе сети жсм и именно части выделения каналов, способов уплотнения и сигнализации MS-BTS-MSC. ---------ЕОФТО------------------------------------------
>> „Я спрашивал про версию мулятора, а что такое HW ? “ > HW=HardWare Да Вы халявщик, Сэр ! Вот оно в чем дело... И почему у тебя нет проблем с новыми драйверами ... > вот моё формирование ответа на 0хА0: > ................................................... > ;store key's Я пока поступил точно также - сохраняю ключи, шифрую ответ и восстанавливаю ключи после всего. > я имел ввиду сигнальный уровень, формирование и прием- > передачу пакетов по "последовательному" интерфейсу - > типа там запитка девайса по 16-й и еще какой-то, DAT , > CLK... etc. Не, я хоть асм и знаю, но на таком уровне никакой. На уровне in/out команд мог бы что-то еще сказать... За модемы спасибо. Собственно, один парнишка в одном из регионов, который соображает в технике все настроил и они у него лучше обычных работают. А из других ноют что плохо работает. PS Ты вот такую вещь может знаешь. Какое время выполнения 3c/3d (HashDWORD) ну или других команд на реальном usb-ключе ? Хотя бы примерно. И какое время трансфера данных из ключа в комп (оно же через DMA ?) ? Насколько время трансфера зависит от длины (скажем, передать 4 байта насколько быстрее 8) - ? У нас получается на HashDWORD примерно 4 ms, время трансфера около 2-х ms (туда и обратно). Спасибо.
ЗДРАСТЕ!, ПРИЕХАЛИ! НУ нелюблю я не ВыньАПИ и ничего из-под нее. а по поводу проблем - нету . как бы нетак. может софт канэшна чото делает. но на нем пока его не видно. самое интересное - смотрю я на логи снифера и вижу - если новые драйвера - то при втыкании ключа - сразу проходит сетап_чипер_кей + эхо_реквест. если старые - то такой связки нету.ничего нету. так вот - при запуске софта - поидее должен пройти хотя-бы сетап ключей - ан-нет. ничего. вот щас воюю с этой хренью. отсюда и было предположение о аппаратном доступе к лпт ежели таковой имеется. возможно детектица VendorStringDescriptor или DevNameStringDescriptor. хз. почему тогда и псах-эдит и псах-диаг говорят что все ок и никаких вздр. ну да я именно это и имел ввиду - что-то типа: ............................ send_byte_ch: ..........mov cl, 8 loop_bits: ..........mov al, 0 ..........rcr ch ..........jc loc_not_hi ..........or al, 1 loc_not_hi: ..........out dx, al ;DAT ..........or al, 2 ..........out dx, al ;CLK ..........call delay_0 ;dTime sig ..........and al, 1 ..........out dx, al ..........jmp $+2 ;SYNC dTime ..........dec cl ..........jnz loop_bits ............................. попробуй покрутить в жсм-модеме EFR - кажись так оно называлось... возможно в нем кратится и настройка кодэка. это все применительно к конкретным моделям и заводские устоновки соответственно разные. поэтому и видешь разницу на разных производителях. тыж говорил что типа ключ у тя есть... если есть - то все намного проще - берешь SniffUSB втыкаешь ключ, запускаешь дампер - и в дампе все видешь с точностью до мкс. [70 ms] >>> URB 5 going down >>> -- URB_FUNCTION_VENDOR_DEVICE: .... [73 ms] <<< URB 5 coming back <<< -- URB_FUNCTION_CONTROL_TRANSFER: .... вот те и 3 мкс (на хаб воткнута еще и флэшка на которой находится примонтированный образ диска)на данную команду(в данном случае проходила команда сет_чипер_кей). а вообще - если вникнуться в спецификацию - никакой драйвер юзб устройства не сможет точно определить время исполнения команды на внешнем устройстве согласно задержки на ответ от устройства - а тем паче на интерфейсе юзб2 когда в нем воткнуты и юзв2 и юзб1 типы устройств. так что если у вас какие-то неувязки - я недумаю что это связано с тайм-аутами т.к. если я на время работы с ключом(юзб 1.1 контрол) дуну что-нить с флэшки или подключу вэб камеру на тот-же хаб - то типа - оппа... как ты думаешь - какой-нить драйвер что-то сможет посчитать? вообще у меня получилось на физическом уровне допустимое время ответа (до первого фронта сигнала) на запрос около 4мкс - это чтоб устройство не было потеряно хабом. а так - я могу и задерживать ответ просто передать нак. рассмешил. юзб 1.1 гы.
[Быстрый ответ на часть поста] Насчет In/out: http://www.wasm.ru/forum/index.php?action=vthread&forum=5&topic=4180&page=2 Там я прикреплял фрагменты реверсинга hardlock'а.
legion_ua Есть исчо вариант "Оладьин" Если можно - такая просьба. Нет ли у тебя кодов на уровне in/out команд чтобы можно было в досе ну или из драйвера читать Usb-ключ ? Те чтобы работать независимо от драйверов вообще ? Или это сложно так как для каждой шины USB (-?) нужен свой драйвер для транспорта ? Спасибо.
когда-то что-то было тута - только почему-то сейчас ресурс закрыт... http://www.cybertrails.com/~fys/usb.htm есть что-то на пас под дос... из драйвера??? ты имеешь ввиду оригинальный. небось для вычитки ST или чтобы просмотреть все возможные команды? 1300862977__Usb4pas.zip
> небось для вычитки ST или чтобы просмотреть все возможные команды? Не, вычитка ST может быть сделана запросами ф.2 HASP API. Это для измерения времени. Большое спасибо, буду разбираться.
ты меня не слышишь... Слышу и нюхаю очень внимательно. Просто я всегда "хочу руками пошшупать". Про таймауты и аки читал.
))))))))))))))))) проверить отличие реализации от спецификации интерфейса на каждой машине... 99.9% таймаутов идет с шины... ну да ладно...
Ключ не таймовый, счас вообще ключа нету ;( Попробую спросить. А в чем idea ? Установить время и мерять его через ключ ?
>когда-то что-то было тута - только почему-то сейчас ресурс закрыт... >http://www.cybertrails.com/~fys/usb.htm Ее перенесли просто... найти можно. > ты меня не слышишь... Это точно =( Но уже поздно.
