Къде е емулаторът на ключове Katran

Проучване на софтуер, пълни ключови емулатори HASP, Hardlock, Guardant, Novex, Eutron SmartKey, Baskakov Key. 1C-Analit: Счетоводство за медицински услуги 1C-Businessproject: Оторизиран сервизен център 1C-VDGB: Заложна къща 1C-InAgro: Счетоводство. Общо взето всички плюят от тези 'катрански'. Наистина ли никой не се опита да напише емулатор на ключ? В резултат на това ще постави файловете за актуализация във временна папка, ще отвори readme и ще прочете къде да търсите драйверите на донгъла.

Анти. HASP: Емулиране на HASP хардуерен ключ за сигурност Тази статия описва как да заобиколите хардуерните системи за сигурност. Като пример разглеждаме технологията HASP (Hardware Against Software Piracy), разработена от Aladdin Knowledge Systems Ltd. В миналото тази технология беше една от най-популярните хардуерно базирани софтуерни системи за защита. Силата на HASP хардуерната защита се използва от много сериозни разработчици на софтуер, които не желаят техният продукт да се разпространява неоторизирано. Hasp, например, защитава пакети „1. В. Счетоводство“ или „1.

S. Enterprise”, без който не може да живее повече или по-малко организиран бизнес. Популярен правен справочник „Консултант. Плюс“ също защитава достъпа до данни чрез електронни ключове. За да използвате горния или друг също толкова скъп софтуер, без да плащате на никого нито стотинка, не е достатъчно просто да сърфирате в мрежата в търсене на txt файл с ключове. Хакерът обаче винаги ще разбере какво да прави със защитата, дори и да е хардуерна. И той не се нуждае от поялник за това.

Нека да разгледаме. Преувеличавайки, можем да кажем, че HASP се състои от две части: хардуер и софтуер. Хардуерната част е електронен ключ под формата на USB ключодържател, PCMCIA карта, LTP устройство или дори вътрешна PCI карта. Инсталираният софтуер ще работи само наавтомобила, в който е поставен електронният ключ. Всъщност би било хубаво софтуерът да се откаже от такъв неприятен навик за портфейла. Софтуерната част са драйверите за ключове и различен софтуер, който свързва ключовете с техните драйвери директно към защитения продукт или към някои криптирани данни. В статията ще разгледаме и заобиколим защитата с помощта на USB ключодържател - може би най-популярният електронен ключ днес.

Механизмът на защитната система. Самият ключодържател почти не ни интересува, за разлика от софтуера в комплекта му.

За нас най-голям интерес представлява хардлок модулът. Без да навлизам в подробности, отбелязвам, че този драйвер е отговорен за взаимодействието с хардуерния ключ. Той има два обекта устройство, единият от които е символично наречен Устройство. FNT0. Използвайки този обект, защитеното приложение проверява лиценза за използване на този софтуер чрез I/O мениджъра. Основният недостатък на такава система за защита е възможността за прихващане на повиквания към I / O мениджъра и емулиране на хардуерен ключ.

Има и опция за разработване на драйвер за виртуален ключ, но това е много по-техническо предизвикателство от прихващането на разговори. Както знаете, моделът на драйвера е описан в структурата DRIVER.

С други думи, като имате дъмп на ключ за сигурност, можете да го предадете на програма, която проверява коректността на данните за лиценза! Друг метод също изисква изхвърляне на ключ, но заместването на данни се извършва по различен начин, а именно в софтуерна емулация. Тоест драйверът за защита ще може да се справи с виртуалния ключ по същия начин, както с физическия. Прихващане и емулация. Както вече беше отбелязано, идеята за прихващане е да пренапише манипулаторите на IRP пакети.

Устройство (LPWSTRlp. Устройство)g. шофьор. Обект= устройство. Обект- > шофьор. обект; ж. устройство.

Контрол = g. шофьор. Обект- > майор. функция. Това трябва да се направи, за да разтоварите правилно драйвера, така че да няма изтичане на ресурси и подобни грешки. Тъй като указателят към обекта на драйвера за защита е запазен, за да премахнете куката, просто трябва да възстановите старите манипулатори на IRP пакети: void Unhook. Устройство (празно)g. шофьор. Обект- > майор. функция. Тъй като по някаква причина системата за защита може да завърши работата си преди нашия драйвер, за да избегнем системен срив поради невалидни указатели, ние ще обработим това събитие във функцията Hook.

1. В ключа се регистрират клиентски лицензи за Катран, с доставка в ключа на лиценз за едно работно място. Това е мястото, където дерят смукателите на катала.
2. Същността му е следната: в началото на conf се зарежда сложен DLL, който проверява за наличието на ключа Katran, ако го няма, тогава. Купете платен емулатор (когато го видях в откритите пространства на тирнета, изглежда струваше 50 долара).

DesKey, PortLock, SoftLock, Katran, Eutron Pyo R

Разтоварване: празна кука. Unload(PDRIVER. Трябва само да освободите заловените ресурси и да не извиквате запазените g. Hook. Unload. Принципът на емулатора.

Прехващач. Познавайки основните принципи на най-простото прихващане на IRP пакети, нека започнем да прилагаме досега само самия прихващач за по-нататъшен анализ. За да направим това, нека създадем обект на драйвер, който съдържа символно име (например Dos. Devices. Hook) и входни точки CREATE, CLOSE, READ.

io. създавам. Устройство (Драйвер. Обект, 0, & нас. Устройство. Име, ФАЙЛ.

При тази реализация на обмен на данни между приложението и прихващача е невъзможно незабавното им изпращане към потребителската програма, така че трябва да създадете някаква структура за съхраняване на необходимитеинформация за заснетия пакет. Например единично свързан списък, както е реализиран от мен. Сега трябва да решим каква информация трябва да бъде буферирана. Това е обща информация за пакета (тип, флагове и т.н.) и, разбира се, буферите.

Можете също да добавите време за прихващане. Когато копирате съдържанието на буферите, трябва да запомните техния тип, в противен случай - срив.

Гледайки напред, отбелязвам, че драйверът за защита използва буфериран I/O, което малко опростява кода. Код на куката. Dispatchif(idl.Tail->Irp.Data.Input.Length). Тъй като пакетът съдържа буфери, чието съдържание представлява интерес, размерът на съобщенията не е известен предварително. Затова ще процедираме по следния начин: при първото четене получаваме обща информация за пакета и размера на буферите; когато препрочитаме съдържанието, премахнете връзката от списъка с пакети и не забравяйте за блокиране на въртене за последователна работа с данни: драйвер за код.

Изпращане. Дължина = Io. SL- > Параметри.

Прочети. дължина; if (Length == sizeof(IRP. От получените регистрационни файлове става ясно кои контролни кодове са изпратени и резултатите от тях. Можете също така да видите, че заявките и отговорите на два различни кода (9c. Изглежда, че е възможно да се изгради емулатор на таблица, но след поредица от стартирания се убеждаваме, че това е невъзможно, тъй като съдържанието на буферите е различно и не е известно как се формира. Уловени пакети без ключ. Уловен пакет ets с ключ След това са възможни няколко варианта за по-нататъшни действия: изучаване на дебрите на драйвера за защита, използване на информацията на самите разработчици на системата.

И двата варианта предоставят необходимата информация. И така, оказва се, че съдържанието на пакетите е криптирано с публичния симетричен алгоритъм AES (Advanced Encryption Standard). Логичната цел е да се получи ключът за криптиране. Но ако се задълбочим в изследванетоустройство на системата за сигурност се оказва, че хардуерният ключ има уникален номер и съдържа цялата необходима информация, но за достъп до него са необходими софтуерни ключове. Пример за изхвърляне на ключ. Така че първото нещо, което трябва да направите, е да вземете ключа. Задачата може да бъде решена чрез обичайната груба сила: неподписан кратък ключ; unsigned char Ref.

ключ. За да направите това, има функции, определени от разработчиците. HL функции. Това са прототипи на стари версии на HASP SDK, но работят и с нови типове ключове, тъй като разработчиците са осигурили обратна съвместимост. Новият API се различава малко от стария и това по никакъв начин не засяга принципа на грубата сила. Подробна документация за Hasp API, готови реализации на brute force и key dumper могат да бъдат намерени на диска. Манипулатор. Сега има всичко необходимо за правилната работа на модула.

Остава да се приложи подмяната на лицензионната информация. Освен това само някои IRP пакети могат да бъдат прихванати. Тук вече всичко зависи от конкретната версия на донгъла и защитената програма. По-добре е да не вграждате дъмпа на ключа в драйвера, а да го зареждате динамично от системния регистър.

По-добре е да разчитате на готов прихващач на заявки, така че ще бъде по-лесно да отстраните грешките на драйвера, като изпратите прихванатите / заместени пакети за анализ към потребителското приложение. По принцип логиката на прихващача ще изглежда така: NTSTATUS Hook.

Изпращане (): PIO. Възниква въпросът: какъв алгоритъм и какъв ключ се използва за криптиране? След като се разровите в източниците от създателите на системата, можете да получите следния първичен алгоритъм за криптиране на пакета: Code Encrypt()void Encrypt(BYTE * Buffer). И ето алгоритъма за дешифриране: Code Decrypt()void Decrypt(BYTE* Buffer).

Тук не можете без разглобител, трябва да се ровите в кошчето и да вземете назаем код от създателите. Не е лесно, защотокодът на драйвера за защита е силно объркан, но не включва различни трикове. Ще бъде достатъчно да декомпилирате драйвера не напълно, а само някои части от кода. В заключение, отбелязвам, че изграждането на емулатор на маса, базиран на устройството.

io. Контролът е доста трудна задача. Но този принцип на емулатора може да се използва и на друго ниво на взаимодействие: създаване на виртуална USB шина. Заключение. Това не е единственият начин да се отървете от защитната система.

Има и други, по-напреднали методи. Принципите, описани в статията, могат да се използват и за анализ на работата на драйверите чрез прихващане на IRP пакети. Така можете да добавите добър инструмент към вашия комплект, направен на коляно.

---