О ключах масса информации, читал много и везде, накачал много эмуляторов и дамперов. Голова кругом идёт.
Чем больше информации, тем сложнее выделить правильный подход.
Прошу подсказать правильный путь. Есть программа, вышла новая версия. Как я понял в предыдущей был HASP4. Делал всё так:
Снимал дамп с помощью h4dmp, получал один файл, далее UniDumpToReg и эмулировал с помощью haspflt.sys идущего с Компасом 7.
Новая версия говорит что не найден HASP HL. При подобном со старой версией способе эмулирования программа ключ находит, но ругается на крипто алгоритмы. Ошибку я понял, и стал использовать h5dmp для снятия дампа. Получил 2 файла. Теперь не очень пойму чем их оба hasp.dmp и hhl_mem.dmp конвертировать в reg и чем потом эмулировать. Смотрел эмуль на основе hardlock.sys для v_net который вроде работает только 20 минут, но с ним ключ вообще не найден…
Посоветуйте пожалуйста конвертор и эмулятор.

| Сообщение посчитали полезным:

Понимаешь в чем дело...
HASP4 он мулился УНИВЕРСАЛЬНО. Для него известны все алгоритмы. Поэтому достаточно с него снять дамп и скормить его правильному эмулятору.
Теперь рассмотрим HASP HL. Ключу всего года 2. Алгоритмы этого ключа не вскрыты. Что дает h5dmp?
Да просто содержимое памяти ключа (и только). Если прога юзает новые функции этого ключа, то выход один - табличный эмуль (собирается табличка вопросов/ответов, которые используются прогой и засовывается в муль).
Встает резонный вопрос - как сделать эту табличку.
Табличка формируется ручками с использованием логгера HASP HL, для надежности лучше распотрошить прогу в IDA - вытянуть из нее все возможные запросы и прогнать через ключ.
Возникает еще один вопрос - а какой муль использовать. Ну тут совет один - нет ничего лучше самостоятельно написанного муля. И не будет возникать вопросов, как туда табличку запихнуть.

| Сообщение посчитали полезным:

Если делать примитивный логгер и эмуль самому, например программа с драйверами будет работать только одна, я не буду учитывать всех возможностей ключа, а буду сохранять значения и подменять только для
hasp_read(), hasp_decrypt(), hasp_encrypt(), hasp_login().
Я не умею писать драйвера или ставить хуки. Например я захочу найти и модифицировать файл из официальных драйверов где и есть точки входа в эти функции, приаттачить свою длл и сделать переходники в официальных функциях на свои, далее писать лог и выполнять оригинальные функции и снова логгировать либо эмулировать по уже готовой табличке.
В какую сторону рыть ? С HASP HL SDK ознакомился.
В каком файле живут все функции хаспа ?
Может есть какие то шаблоны мулей или логгеров hasp hl на дельфи ? Ну и вообще, наверное многие делали так может есть готовые логгеры/эмули для hasp hl ?
Вполне возможно, что подойдут ? Посоветуйте пожалуйста !

| Сообщение посчитали полезным:

Логгер-монитор раз
http://www.dongla.net/storage/dongles/haspmon32.zip

Логгер-монитор два (чуть лучше ИМХО)
http://www.dongla.net/storage/dongles/hasploger.zip

Табличный эмулятор
http://www.exelab.ru/f/files/1900_06.11.2007_CRACKLAB.rU.tgz

| Сообщение посчитали полезным:

digger70 - большое спасибо за ссылки !

А этот табличный эмулятор будет работать если задействованы функции hasp_decrypt(), hasp_encrypt() ?

| Сообщение посчитали полезным:

Конечно. Таблички в нем под это и делались.

| Сообщение посчитали полезным:

digger70
расскажи пожалуйста (желательно с 1 примером) как добавить Q|A в reg.

| Сообщение посчитали полезным:

Ну автора бы поймать лучше На сколько я понимаю в табличку Q.. последыватльно укладываются "вопросы" программы, не зависимо от того, encrypt это или decrypt, ну а в A... в той же последоватльности ответы ключа.

| Сообщение посчитали полезным:

Итак по порядку.
Qtable & ATable есестно таблицы для вопросов и ответов... Любым удобным логером собирается инфа с hasp_encode(decode) и т.д. далее запросы последовательно один за другим ложаться как показано в примере - аналогично 1:1 делается таблица ответов. Либо данная таблица выдирается из тела файла - жертвы как ранее сказал многоуважаемый AlexVel.
Все остальные опции и параметры муля - аналогичны стандартным чинговым - кто сомневается - ИДА вам в зубы и вперет потрошите муль!.

"QTable"=hex:
01,4F,99,CB,FE,33,DC,25,05,E6,73,60,ED,16,F2,36,
20,58,C8,37,AA,4C,54,CF,F7,34,60,10,5F,0B,A7,EB,
C3,D0,F8,CD,18,9A,4F,CA,00,C5,B3,F4,DF,1F,81,02,
.....
"ATable"=hex:
B1,C7,FD,28,8F,57,56,7C,F2,0D,B3,5E,6C,8A,B3,49,
2B,55,61,EE,7E,1B,BF,11,EF,C3,D4,12,94,09,16,C6,
33,3E,14,F1,5E,FD,B6,31,90,59,D9,BE,A8,DC,4C,62,
E1,B9,89,0A,4B,3E,F7,41,DB,34,FB,19,DD,61,17,4C,
....

| Сообщение посчитали полезным:

Немного вот что не понятно. Это работает в дополнение к другому эмулю или по этим Q/A я полностью всё эмулирую ? То что было в reg файлах для эмуляции HASP4: SN, SecTable, NetMemory, Option, Data, EDStruct – уже не нужно ?
Ну и ещё такой вопрос. Как известно encrypt и decrypt работают с областью памяти разной длины, и если мне логгер выдал такие Q/A:

Q 333333
A 313131

Q 44
A 55

Q 7777777777
A 8888888888

То как будет выглядеть reg файл ?

"QTable"=hex:
33,33,33,44,77,77,77,77,77
.....
"ATable"=hex:
31,31,31,55,88,88,88,88,88

Наверное в виду разной длинны QA лучше было использовать так:

"QTable1"=hex:
33,33,33
"ATable1"=hex:
31,31,31

"QTable2"=hex:
44
"ATable2"=hex:
55

"QTable3"=hex:
77,77,77,77,77
"ATable3"=hex:
88,88,88,88,88


| Сообщение посчитали полезным:

И еще один вопрос: сколько Q(A) ПРАКТИЧЕСКИ можно засунуть в реестр?

| Сообщение посчитали полезным:

ToBad, более того, такой reg (c разной длиной) не импортируется в реестр.

| Сообщение посчитали полезным:

ToBad пишет:
То как будет выглядеть reg файл ?

"QTable"=hex:
33,33,33,44,77,77,77,77,77
.....
"ATable"=hex:
31,31,31,55,88,88,88,88,88
Истину глаголишь....

ToBad пишет:
То что было в reg файлах для эмуляции HASP4: SN, SecTable, NetMemory, Option, Data, EDStruct – уже не нужно ?
Как это не нужно - таблицы вопросов - ответов - всеголишь способ обойти пока неизвестную ф-ию шифрования Так что все остальные параметры - так же необходимы.

ToBad пишет:
Наверное в виду разной длинны QA лучше было использовать так:

"QTable1"=hex:
33,33,33
"ATable1"=hex:
31,31,31

"QTable2"=hex:
44
"ATable2"=hex:
55

"QTable3"=hex:
77,77,77,77,77
"ATable3"=hex:
88,88,88,88,88
Ну может быть и так проще кому то но ... посему ж тогда я видел реализации данных мулец со встроенными таблицами - и там разделение было всего лишь по длине вопроса/ответа - т.е. 3 таблицы 16,32,48 байт.

| Сообщение посчитали полезным:

на счет таблиц вопросов-ответов. Специально ганял ключ под логгером(от Satarona), в итоге при декрипте-энкрипте идут только блоки длиной 16,32,48 байт, независимо от того насколько большой блок идет на декрипт с самой проги. Остальные данные декриптов формирует сам драйвер ключа.

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

| Сообщение посчитали полезным:

и еще вопрос к Sataron на счет логгера. Когда запускаю HaspEdit и работаю с HaspHl как с Hasp4 в логгере ничего не отображается . Так и должно быть?

| Сообщение посчитали полезным:

sataron пишет:
"ATable"=hex:
31,31,31,55,88,88,88,88,88
Истину глаголишь....

Тогда я вообще не понимаю… Вопросов стало больше чем ответов. Нам известно, что encrypt и decrypt работают с произвольным размером буфера данных и используют несколько алгоритмов. Вполне возможно, что при снятии лога Q/A будут такими:

Q 33,44,55
A 34,45,56

Q 44
A 55

Q 66,77
A 88,99

Тогда табличка будет выглядеть так:
"QTable"=hex: 33,44,55,44,66,77
"ATable"=hex: 34,45,56,55,88,99

Но что произойдёт когда будет выдан Q 44 ? Ответ будет 45, хотя по логике должен быть 55.
Или я чего-то не догоняю ?

| Сообщение посчитали полезным:

ToBad
Интересный вопрос. С проблемой запросов разной длинны и одинаковым префиксом боротся отчасти можно - укладывать вопросы ответы по возрастанию длинны ну и следить глазами, чтоб подобных конфликтов не было. А вот на счет нескольких алгоритмов - поясни свою мысль.

| Сообщение посчитали полезным:

здесь нужно , чтоб растолковали, как именно происходит выборка этих запросов-ответов.
Например, пришел запрос, ищется эта последовательность байт в блоке "QTable", и по нахождении по найденному смещению берется ответ из "ATable"? или как?

| Сообщение посчитали полезным:

digger70 пишет:
А вот на счет нескольких алгоритмов - поясни свою мысль

Это меня проглючило. Провёл паралель с Guardant. Да, в HASP HL как я понял нет выбора алгоритма, а минимальная длина буфера должна быть 6 байт. В таком случае врядле получится так, как я сказал, к тому же алгоритм AES.

digger70 пишет:
С проблемой запросов разной длинны и одинаковым префиксом боротся отчасти можно - укладывать вопросы ответы по возрастанию длинны

Точно ! Это решение !

| Сообщение посчитали полезным:

и еще вопрос по декриптам.
в таблицы подставлять только запросы типа :

<== HaspHL_decrypt: Input Data = 75 19 2D 6F | AC A3 A9 8D | C4 74 09 90 | C7 3C 12 43
==> HaspHL_decrypt: Output Data = 96 8E 49 00 | 00 00 00 00 | CE 05 67 00 | 00 00 00 00


а запросы типа :

<== HaspDecodeData: Input Data = 34 B6 78 E2 70 D8 D7 9A
==> HaspDecodeData: Output Data = 69 12 5F B9 05 55 D7 AC

писать, или они будут обрабатываться с помощью EDStruct ?

| Сообщение посчитали полезным:

ToBad пишет:
Да, в HASP HL как я понял нет выбора алгоритма, а минимальная длина буфера должна быть 6 байт

для AES минимальная длина буфера вообщето 16 байт

| Сообщение посчитали полезным:

Tolkin
Ну я подозреваю, что исходный Муль уже был NoEDS но в целом ты прав - в таблицу идут только HaspHL_decrypt

| Сообщение посчитали полезным:

Tolkin пишет:
для AES минимальная длина буфера вообщето 16 байт

HASP_HL_Programmers_Guide_Rus:
hasp_decrypt() - размер (в байтах) дешифруемого буфера – минимально 6 байт.
hasp_encrypt() - размер (в байтах) шифруемого буфера – минимально 16 байт.

Опечатка ?

| Сообщение посчитали полезным:

а какже тогда быть с HaspDecodeData?

| Сообщение посчитали полезным:

ToBad пишет:
HASP_HL_Programmers_Guide_Rus:
hasp_decrypt() - размер (в байтах) дешифруемого буфера – минимально 6 байт.
hasp_encrypt() - размер (в байтах) шифруемого буфера – минимально 16 байт.

Опечатка ?

Скорее всего да, так как в проге toolbox для работы с HaspHl длины буферов для этих фунок можно выставить только минимум с 16 байт

| Сообщение посчитали полезным:

Tolkin
На совесть муля оставить HaspDecodeData. Уж это то он нетаблично сэмулирует. Я то к тому писал, что EDStruct ему может нужна а может и нет.

| Сообщение посчитали полезным:

Tolkin пишет:
длины буферов для этих фунок можно выставить только минимум с 16 байт

Ну тогда всё проще. Думаю врядле будет повторение и ошибка...
Хотя есть ещё hasp_legacy_decrypt() и hasp_legacy_encrypt() с минимальным буфером 8 байт.

Tolkin пишет:
а какже тогда быть с HaspDecodeData?

А это что ?

| Сообщение посчитали полезным:

HaspDecodeData - это и есть запросы к ключу при выполнении hasp_legacy_decrypt() и hasp_legacy_encrypt()

| Сообщение посчитали полезным:

А может кто то знает где нарыть шаблон логгера/эмуля для HASP HL ? На дельфях желательно....

| Сообщение посчитали полезным:

а что не вижал бейсике? =)

| Сообщение посчитали полезным: