Немного о активации(лицензии) JLR SDD

Эта заметка будет интересна владельцам автомобилей компании JLR желающим самостоятельно диагностировать свои машины с помощью программы JLR SDD.
JLR SDD это программа для диагностики автомобилей компании JLR выпущенных в десятилетие с середины 2000-х, для более свежих автомобилей JLR используется ПО Pathfinder, а ему на смену уже пришел TOPIx Cloud Diagnostic.
Актуальная версия программы SDD доступна для бесплатного скачивания по ссылке "SDD Manual Software Download" на сайте TOPIx-a.
Несмотря на то, что программа SDD бесплатна для скачивания, для ее использования необходим TOPIx-аккаунт и платная подписка на использование программы. Без наличия актуальной подписки нельзя пройти проверку пользователя (аутентификация) при запуске программы SDD и пользоваться программой.
До недавних событий подписку для SDD можно было приобрести на сайте topix-a, но сейчас из-за отключения РФ от банковской системы всего мира при оплате подписки возникает ошибка.

А если срок имеющейся подписки истек, то вариант использования программы SDD только один — это альтернативная аутентификация пользователя в программе или как говорят в народе активация(лицензия). Ниже представлено краткое повествование о личном опыте изучения, как работает аутентификация в программе SDD, поэтому те кому интересен процесс, то могут читать дальше, а кому интересны готовые решения, то они в конце заметки.
Для меня первопричиной разобраться с SDD был не работающий механизм обновления базы прошивок с интернета. Обновление прошивок не работало в обеих виртуальных машинах с SDD, с версиями 131 и 139 SDD. Эти виртуальные машины с уже предустановленными SDD я нашел в интернете, к их работе у меня не было замечаний кроме как не работающего обновления базы прошивок.
Т.к. версии 131 и 139 были выпущены несколько лет назад, то я подумал, что нужна более свежая версия программы SDD. При поиске более свежей версии SDD и немного ознакомившись с вопросом активации SDD, у меня сложилась следующая картина, что большинство пользователей SDD разбились на два лагеря:
— используют SDD с бесплатной(китайской) активацией
— используют SDD с какой-либо платной активацией
Активация называется китайской или китайским патчем, так из-за того что поставлялся в комплекте адаптером JLR Mongoose с aliexpress.
В ситуациях когда у пользователей из первого лагеря возникают какие-либо проблемки с SDD, то пользователи из второго лагеря первопричиной этих проблем называют китайскую активацию, приводя в аргументы отличие внешнего вида приложения и размеров файлов после китайской активации. А пользователи из первого лагеря аргументируют, что в принципе то SDD работает и нет смысла платить за воздух(активацию). Классическая картина священных войн, но и те и другие используют активаторы, поэтому первым делом надо разобраться какую функцию выполняют активаторы.

Чтобы понять, что из себя представляют активаторы, с сайта rutracker.org можно скачать активаторы из раздач для разных версий SDD(131,139,145 и т.д.). При этом можно заметить, что в версиях SDD свежее 145 используется активатор, применяемый для версии 144 SDD.
Далее запуская по очереди активаторы совместно с монитором процессов, который позволяет отслеживать все действия программ в процессе своей работы, можно узнать что же делает активатор. В окне монитора процессов, для удобства можно настроить фильтр, чтобы отображались события только от активатора и тогда можно увидеть, что в процессе работы активаторов создается файл app.war, в каталоге C:\Program Files\JLR\SDD\SDD.
Так на следующем скриншоте монитора процессов видно, что активатором производится попытка создания файла app.war в каталоге C:\Program Files\JLR\SDD\SDD\, а каталог C:\Program Files\JLR — это каталог установки SDD по умолчанию. Но в моем случае для экспериментов использовалась чистая windows7 и каталога C:\Program Files\JLR не существует, поэтому файл в этом каталоге создаться не может, и из-за этого создание файла app.war завершается с ошибкой "PATH NOT FOUND". Но если перед запуском активатора создать данный каталог, то файл app.war в этот каталог успешно запишется.

В обычной ситуации активатор запускают уже после установки SDD, и активатор перезаписывает файл app.war из состава SDD, т.е. активаторы производят подмену файлов app.war. Поэтому если активатор заменит файлы не от той версии для которой он был создан, то тогда SDD может работать некорректно, поэтому счет 1:0 в пользу пользователей платной активации, т.к. самый последний китайский активатор был сделан для версии 144.05 SDD и для актуальной версии SDD китайского активатора нет.

Cобрав коллекцию файлов app.war от различных активаторов, можно сравнить их между собой и проанализировать изменения которые сделаны активаторами внутри app.war.
Файл app.war, это обычный архив с java классами, war — это сокращение от Web Archive, его можно открыть в любой программе-распаковщике архивов, даже в встроенном в windows zip-распаковщике. Файлы Java-классов предназначены для непосредственного исполнения компьютером в среде JAVA и не пригодны для анализа человеком. Для преобразования java классов в читаемое представление понадобится декомпилятор java, декомпилятор позволяет преобразовать все java классы из war файла в текстовые файлы, которые можно сохранить отдельно для каждого app.war. Полученные в результате декомпиляции текстовые файлы от различных активаторов можно сравнить между собой в программах для сравнения файлов, например winmerge.

Для анализа файлов не обязательны знания программирования, т.к. буквы в тексте латинские, а слова английские и в большинстве случаев передают смысл запрограммированных операций. После сравнения текстовых файлов от разных активаторов, можно понять, что основные изменения всех активаторов сделаны вокруг одних и тех же функций в классе AppConfiguration: isSdd2OfflineAuthenticationEnabled(), isSdd2AuthenticationEnabled() и getAuthenticationTopixAddress(). Целью этих правок является смена значений по умолчанию у соответствующих параметров SDD: sdd.authentication.sdd2.offline.enabled, sdd.authentication.sdd2.enabled и sdd.authentication.topix.address.

Странно, что эти изменения сделаны в app.war, т.к. эти параметры могут быть изменены в файле настроек SDD, C:\Program Files\JLR\SDD\SDD\app.properties. Файл app.properties как раз и предназначен для задания различных параметров работы SDD. На что влияют перечисленные выше параметры можно легко выяснить поиском нужного текста по всем файлам.
Изменение значения параметра sdd.authentication.topix.address на любой несуществующий адрес приводит к недоступности topix сервера и SDD переключается на оффлайн аутентификацию. А изменение значений параметров sdd.authentication.sdd2.offline.enabled и sdd.authentication.sdd2.enabled приводит к выбору одного из двух типов оффлайн аутентификации пользователя в SDD. Выбор типа оффлайн аутентификации в зависимости от состояния параметров sdd.authentication.sdd2.offline.enabled и sdd.authentication.sdd2.enabled задан в классе OfflineAuthenticationCommand, если оба этих параметра установлены в true, то используется аутентификация с помощью оффлайн сертификата(performOfflineCertificateAuthentication), а иначе используется аутентификация с помощью локального файла offid.exml(performGenericOfflineUserAuthentication).

Если загуглить названия этих параметров, то можно найти упоминания этих параметров в теме "Самостоятельная диагностика Д3" на lr-club.com, т.е. информация о влиянии этих параметров на работу SDD давно известна и общедоступна.

Аутентификация пользователя с помощью файла offid.exml осуществляется проверкой на соответсвие введенных логина и пароля и данным записанных в локальном файле C:\Program Files\JLR\SDD\Runtime\offid.exml. Для успешной аутентификации введенные в форме программы логин и пароль должны совпадать с данными, хранящимися в файле offid.exml, а также должна совпадать версии программы SDD, эти проверки осуществляются в функции performGenericOfflineUserAuthentication в тоже классе OfflineAuthenticationCommand,

Содержимое файла offid.exml, хоть он и зашифрован, тоже не является секретом и было выложено в той же теме "Самостоятельная диагностика Д3" на lr-club.com.

До 131 версии SDD, включительно, файл offid.exml был в составе SDD и все кто знал его содержимое, могли использовать пару Login:JLRQ5013 и Password:L405X152 для оффлайн авторизации. В следующих версиях файла offid.exml уже не было в составе SDD, но механизм аутентификации через файл offid.exml сохранялся до версий 15x SDD — если самостоятельно добавить файл offid.exml, то можно пользоваться SDD как и раньше в версии 131.

Поэтому для не актуальных версий SDD(13x-14x), какие-либо активаторы и не нужны, и здесь правы пользователи не желающие платить за воздух поэтому счет сравнялся 1:1.
Особенно примечательно, что некоторые создатели активаторов для SDD в своем желании заработать пошли еще дальше чем компания JLR, сделав в app.war модификации, чтобы активация SDD работала только на одном конкретном компьюторе или чтобы с SDD не работала в виртуальной машине, создав дополнительный vendor lock

Начиная с версий 15x SDD механизм аутентификации через файл offid.exml был удален из программы SDD и в SDD осталась только возможность аутентификации по оффлайн сертификату.

Оффлайн сертификат создается в момент аутентификации пользователя в topix-е, если есть подключение к topix-у и есть действующая подписка. Сертификат сохраняется на накопителе и в нем сохраняется информация о пользователе и времени действия подписки. В дальнейшем оффлайн сертификат позволяет использовать SDD во временном диапазоне действия подписки даже при отсутсвии связи с topix.
Чтобы понять, что из себя представляет оффлайн сертификат достаточно ознакомиться с функцией decrypt из класса EncryptedOfflineAuthenticationMessage и выяснить следующее.
— сертификат это файл в каталоге C:\ProgramData\JLR\IDS\Users, название файла это hash от имени пользователя
— у сертификата состоит из цифровой подписи и зашифрованных данных
— цифровая подпись создается на стороне сервера с помощью частного RSA-1024 ключа
— данные шифруются с помощью алгоритма AES-128
— при проверке сертификата, SDD проверяет цифровую подпись и зашифрованные данные с помощью публичного RSA ключа, который встроен в app.war как ресурс(publickey.bin)
— сигнатура цифровой подписи представляет из себя контрольную сумму данных(hash) и AES ключ
— данные зашифрованы AES ключом содержащимся в сигнатуре цифровой подписи

Пара из публичного и частного ключей уникальны, поэтому аутентификация с помощью оффлайн сертификата обладает хорошей защитой, т.к. создать оффлайн сертификат может только владелец частного RSA ключа, т.е. только сервер topix-a.

Механизм декомпиляции/компиляции java программ позволяет легко модифировать java классы, обзор очередности вызовов функций подсказывает простой способ обойти аутентификацию с помощью оффлайн сертификата, для этого можно модифицировать класс OfflineAuthenticator в котором в функции authenticate всегда будет возвращаться положительный результат и задать любой диапазон действия подписки.

Модифицированный класс OfflineAuthenticator неоходимо встроить в app.war,
последовательность операций для модификации приведена на следующем скриншоте Makefile.
Для компиляции класса надо использовать JDK той же версии, что использовался для сборки app.war из скриншота видно, что в данном случае используется версия JDK 1.6.0.45.

Результатом данной модификации будет актуальная версия SDD с подпиской до 2070 года, внешний вид соответствут — кнопка OEM есть.

Но у такой модификации есть один минус — после обновления SDD на новую версию, модифицированный файл app.war скорее всего будет заменен и необходимо будет заново модифицировать app.war.

Поэтому чтобы найти возможные пути решения без правки app.war я запустил монитор процессов совместно с SDD, чтобы выяснить какие файлы SDD загружает в процессе своей работы. Увидев то что представлено на следующем скриншоте я был сильно удивлен, т.к. начиная с какого то момента времени SDD пробует загружать все классы и ресурсы содержащиеся в app.war с диска C. На скриншоте видны попытки загрузки и упомянутого выше файла OfflineAuthenticator.class и публичного ключа publickey.bin.

Такое поведение программы больше походит на отладочный или ненормальный режим работы, но такое поведение программы наблюдается и в старых версиях SDD 13x. Предположу, что разработчики SDD специально не делали загрузку классов с накопителя, а это происходит случайным образом из-за использования сторонних классов в SDD, коих в SDD огромное количество.

Но раз SDD самостоятельно загружает классы с накопителя, то уже достаточно поместить файл OfflineAuthenticator.class в каталог c:\com\cognitran\topix\client\sdd\v3_0\security\ и правка app.war уже не нужна. При таком решении SDD самостоятельно будет загружать модифицированный класс OfflineAuthenticator.class с накопителя и обновление SDD уже не приведет к пропаданию подписки, по крайней мере до тех пор пока разработчики SDD не отключат загрузку классов с накопителя.

Но и это решение не идеальное, т.к. при новом обновлении SDD потенциально возможны изменения в классе OfflineAuthenticator.class из состава SDD, которых нет в локальном классе OfflineAuthenticator.class. Поэтому лучшим решением будет создание оффлайн сертификатов с помощью своей пары ключей с сохранением публичного ключа как c:\com\cognitran\topix\client\sdd\v3_0\security\publickey.bin. При таком решении модификации никаких классов не производится, при аутентификации пользователя SDD самостоятельно будет загружать локальный файл publickey.bin и проверять сертификат, если сертификат создан с помощью частного ключа из той же пары что и publickey.bin, то в результате будет действующая подписка.
Механизм создания сертификата обратен рассмотренной выше функции decrypt из класса EncryptedOfflineAuthenticationMessage.

В процессе анализа app.war из активаторов или из состава SDD, в app.war можно обнаружить готовый к использованию дешифратор exml файлов и почти готовый калькулятор кодированного доступа.

Часть конфигурационных xml файлов в составе SDD зашифрована и хранится в exml файлах, дешифратор exml файлов может потребоваться как минимум для редактирования файла offid.exml.

Редактирование exml файлов
— извлечь из архива C:\Program Files\JLR\SDD\SDD\app.war файл sdd-tools-1_0.jar
— запустить в командной строке sdd-tools-1_0.jar для расшифровки exml:

java -cp sdd-tools-1_0.jar com.jlr.sdd.cipher.CipherTool -decrypt offid.exml

Должна быть такая реакция:
Decrypt output: offid.exml-decrypted
Decrypting file: offid.exml

— запустить в командной строке sdd-tools-1_0.jar для зашифровки exml:

java -cp sdd-tools-1_0.jar com.jlr.sdd.cipher.CipherTool offid.xml

Должна быть такая реакция:
Encrypt output: offid.xml-encrypted
Encrypting file: offid.xml

Часть функционала в SDD недоступна даже при наличии подписки и защищена механизмом кодированного дуступа привязанного к VIN-у и времени операции, алгоритм кодированного доступа(CodedAccess) можно подсмотреть в файле CodedAccessHelper.class

Кодированный доступ
— запустить в командной строке codeaccess.jar с двумя параметрами VIN и SEED

Например, для VIN SAJWA06B49HR11917 и SEED T778A87AL7:
java -jar codedaccess.jar SAJWA06B49HR11917 T778A87AL7
Должна быть такая реакция:
PASS(01 lr(ccf_edit)/jg(vin_pypass)):AANPPP92P9CPCP
PASS(02 lr(l316_odo)/jg(block_editor)):AANPPP92P9CLCL
PASS(04 lr(thai)/jg(x150_odo)):AANPPP92P9CACA
PASS(08 lr(swdl)/jg(ccf_edit)):AANPPP92P9CRCR
PASS(10 lr(l322_odo)/jg(x250_odo)):AANPPP92P9PCPC
PASS(20 lr(l322_recover_keys)/jg(swdl)):AANPPP92P9LCLC
PASS(40 lr(l322_erase_keys)/jg(x351_odo)):AANPPP92P9ACAC
PASS(80 lr(opt8)/jg(x351_recover_keys)):AANPPP92P9RCRC

Решение для версий SDD 13x-14x
— включить офлайн аутентификацию через offid.exml, добавив в файл C:\Program Files\JLR\SDD\app.properties следующие строки:
sdd.authentication.topix.address=offline
sdd.authentication.sdd2.offline.enabled=false
sdd.authentication.sdd2.enabled=false
— Отредактировать файл C:\Program Files\JLR\IDS\Runtime\offid.exml, указав в поле dvdbaselevel используемую версию sdd

Решение для версий SDD 15x-16x с модификацией класса OfflineAuthenticator
— включить офлайн аутентификацию через сертификат, добавив в файл C:\Program Files\JLR\SDD\SDD\app.properties строку:
sdd.authentication.topix.address=offline
sdd.authentication.sdd2.offline.enabled=true
sdd.authentication.sdd2.enabled=true
— скопировать модифицированный файл OfflineAuthenticator.class в c:\com\cognitran\topix\client\sdd\v3_0\security\

Решение для версий SDD 15x-16x с созданием сертификата
— включить офлайн аутентификацию через сертификат, добавив в файл C:\Program Files\JLR\SDD\SDD\app.properties строку:
sdd.authentication.topix.address=offline
sdd.authentication.sdd2.offline.enabled=true
sdd.authentication.sdd2.enabled=true
— запустить в командной строке cert.jar для создания сертификата

java -jar cert.jar

Должна быть такая реакция:
username:sdd
Try create filename:aa3b39f875924856d6cc1149673abe3eaed2ea6dded4703beedd811fac436fa2 …
FirstName:
LastName:
UsernameHash:aa3b39f875924856d6cc1149673abe3eaed2ea6dded4703beedd811fac436fa2
DeviceIdHash:8ce3195b0379c80aa7ce3906d4f30d14f6efef37b64abe476eca8837b58bcd47
ValidFrom:Thu May 05 15:55:18 YEKT 2022
ValidTo:Sun May 02 15:55:18 YEKT 2032
AllowdOffline:true

— Скопировать в каталог c:\com\cognitran\topix\client\sdd\v3_0\security\ файл publickey.bin
— Скопировать сертификат в каталог C:\ProgramData\JLR\IDS\Users\

Особенности разных версий SDD
SDD v131.03
— не скачиваются обновления прошивок
— предлагает обновить прошивку адаптера, после использования адаптера с другими версиями SDD
SDD v139.17
— не скачиваются обновления прошивок в Windows7, а в WinXP скачивание работает
— В SoftwareDownload.htm некорректное отображение в Windows7, а в WinXp нормальное
SDD v144.08
— Не доступна функция программирования ЭБУ через SoftwareDownload.htm
SDD v152
— Не работает offline авторизация по логину и паролю через offid.xml

Особенности разных версий активаторов
В SDD v131.03 взятая с rutracker.org/отсюда имеет лекарство от SDD v129.
В SDD v139.17 взятая с rutracker.org имеет лекарство от SDD v138.
В SDD v144.08 взятая с rutracker.org имеет лекарство от SDD v144.05
Насколько критичны на работу SDD отличия в версиях app.war от оставшейся части SDD я не могу судить.

Проблема с обновлением прошивок
Если иконка сети красная, то необходимо провести процедуру активации сетевого соединения.

Дополнительные настройки в app.properties

sdd.display.autovin.readiness=true
sdd.dtcviewer.advanceview.enabled=true
sdd.dtcviewer.untested.enabled=true
sdd.online.campaigns.enabled=false
sdd.datacollect.pagmcp.parallel.min.year=10
ids.feedback.switch=true
sdd.lost.comms.dtc.enabled=true

Отключение обновлений SDD
Удалить файл в каталоге C:\ProgramData\JLR\IDS\Log Files\InstallationLog.txt

По итогу у меня обновление прошивок в SDD версии 139.17 заработало только в WindowsXP, как оказывается обновление не работало из-за Windows 7 — индексные файлы никак не могли скачаться. Причем когда подменил программу для обновлений(SoftwareManager) из состава SDD версии 160, то обновление прошивок сразу же заработало в SDD 139 версии. Также в Windows7/SDD139 было некорректное отображение в SoftwareDownload.htm. Механизм обновления у SDD версии 139 такой же как и у 16x версий — используются одни и теже сервера и индексные файлы, а вот у SDD 131 механизм другой и уже не работает. Поэтому для старых автомобилей, к которым относится и мой Freelander2 2009 года выбор очевиден — это WindowsXP и SDD139, т.к. для старых автомобилей от новых версий SDD пользы нет, только проблемы с активацией.

PS Информация о работе аутентификации в SDD предоставлена в общеобразовательных целях, активаторы для SDD не продаю и активацией не занимаюсь.