если кто нибудь встречался, подскажите , пожалуйста куда копать ключ и драйвера (с) к а т р а н на ключе наклейка акулы фирма производительсофта- партнёр аладдина , но на hasp не похоже прога общается с драйвером через deviceiocontrol но обратно ничего не получает, однако если всегда возвращать True, программа не работает если кто сталкивался, помогите пожалуйста, никакой документации по subj нету
ага вот ещё что "Ключи защиты PKEY являются аппаратным компонентом системы защиты конфигураций платформы 1С:Предприятие. Ключи специально разработаны для задач защиты авторских конфигураций на базе 1С:Предприятия и поставляются только как часть системы защиты."
stayer Правильно. Для того, чтобы ключ стал отвечать, его надо проинициализировать : послать ключевую последовательность. А как бы иначе можно бы было работать через LPT-ключ с принтером. Теперь правда ключи USB, но это как в старом анекдоте : "мотоцикл угнали, а привычка осталась". Кроме того - это неплохая защита от примитивного дампера, если конечно нет купленной программы ,из которой этот "ключик" извлекается без проблем.
по - моему это всё- же наконец-то тот ключ, который считает какую-то математику и драйвер выдаёт её потом в адресное пространство программы , минуя device io control
так же просьба, говорить только по делу, философия меня не интересует в данный момент, я и сам могу рассказать , какие ламеры писатели защит и как я без проблем чего - то делаю. если кто - то встречался с этим ключом дайте знать , pls!
stayer Это не философия. Я исследовал реальный ключ и пока не задал правильный "ключик" все DeviceIOControl не получали ответа. Сам DeviceIOControl вызывается из подпрограмм более верхнего уровня : они имеют имена HL_LOGIN и т.п. Драйвер не должен писать в память приложения - это противоречит идеологии Виндов и создает много проблем. Я конечно не утверждаю, что у тебя именно ХАСП, но выводы ты неверные делаешь.
это не хасп я уверен почтина 100 % я прехватитл вызов DeviceIOControl из него ничего не возвращается никогда ключ у меня есть, пока так что программа работает но когда я просто возвращаю true и не передаю реальному DeviceIOControl - програма не работает
stayer Блин! Неужто непонятно. И у меня был ключ. Пока ты в ключ не передашь определенную последовательность байт, он будет сидеть и ждать ее. И только после нее начнет отвечать. Но вообще-то это было давно - я не помню точно. Вот скоро другой принесут - обязательно проверю свои "вымыслы". Но вот, что я точно знаю - я не эмулировал ключ на уровне DeviceIOControl , да и никто вроде этого не делает. Есть другие функции, которые гораздо удобнее. В моем случае все свелось к ответу ОК для функции HL_LOGIN и HL_Verify и выдаче правильного массива после вызова HL_DECODE ( точно имя не помню). LOGIN шлет 10 или 16 байт - замучишься брейки смотреть.
stayer Может быть, есть еще другие каналы. Например, для lpt-ключа (1с 7.7, etc) используется в качестве основного канала исключение #UD. Попробуй почитать мою статью про хасп-ключ (часть 1 и 2). Также может быть передача данных по указаетелю из пакета DeviceIo или же ты не все вызовы DeviceIo перехватил (надежнее хватать входную точку драйвера а не апи). Также интересно: - какой драйвер используется (на что вызывается CreateFile) ? - используются ли hardlock.sys(vxd) и hasp95dl.vxd (или его аналог в nt) ?
stayer Ты бы хоть драйвера выложил или дал ссылку на них c производителя - посмотрим, что это за ключ такой.
ага, спасибо , что ответили 1.это не хасп , повторяю 2.на сайте производителя, катран софт ничего нету 3.так как это не хасп(hl),то и никакого hl.sys там нету 4.CreateFile(pkey.sys)-xpsp2 5. насчёт того что не все deviceIoControl прехватил, возможно , конечно , но врядли, я сначала сделал статический анализ кода , не должно там больше нигде оно быть вызвано , кроме того повторяюсь a) если я передаю всё в Deviceiocontrol он возвращает true и всё -outbuffer=nil, noutputbytes=0; b) если я не передаю в Deviceiocontrol? но возвращаю true программа работает на этапе инициализации , но не работает потом, говорит , ключ не обнаужен ----> делаем вывод , я перехватил тот DeviceIoControl если кому интересно взглянуть на дрова , то могу заслать дайте почту
>>Также может быть передача данных по указаетелю из пакета >>DeviceIo вот это похоже на правду , щас реверсну структуру буфера входного и посмотрю, что там происходит
stayer Посмотрел дравера - да это не хасп, но тем не менее проблем быть не должно драйвера все открыты, общается с ключем она блоками по 16 байт которые передаются через порт 378 в режиме bidirectional. Каждый байт стробируется 3-м битом порта 37A. В каждом блоке контрольная сумма. Попробуй банально выделить пакеты общения с ключем и подставить ответы эмулируя обращение к порту. Почитай действительно статьи Сhingacguka как это делать.
Очень похоже на Hardlock, только видать заточенная версия. Хочется посмотреть на два 8-ми байтовых параметра у HL_LOGIN, если они конечно там есть. Ну и если есть ответы на HL_CODE то тоже сюда их, хотя бы две пары запрос-ответ. Сразу будет понятно - HL или нет.
Maxi ты прав , есть общение через writefile прога сама в себя пишет код >>Почитай действительно статьи Сhingacguka как это делать. "когда ничего не получается, прочти наконец инструкцию" так и сделаю
Простите, не дочитал все посты... раз 16 байтовые пакеты, раз контрольная сумма, раз драйвер зовется pkey.sys и самое главное это конфигурация для 1C то ключик этот зовется SmartKey и оригинальное название файла keyp.sys =) У нее есть функция Open ('O') которой передается login/passw и есть функция scramble ('S'), которая оперирует 64 битным параметром. Одной пары запрос-ответ достаточно что бы подтвердить догдку.