как ломануть 1C 8.3 for Linux

[Pependos]

Умерло все, выложите еще раз, заранее спасибо

https://dropmefiles.com/wYVYB

[HPDX2300]

Изделие также прекрасно падает если hasplm поднимается на Linux, а на сратых виндах если поднять hasplm, тоды не падает.
Может я чего не догоняю?

Есть подозрение, что hasplm для Linux оч.старый и не все функции реализованы - изделие обнаруживает неправильный ответ и делает себе сепуку.
Вчера дебажил HASP-API при обмене с виндовым hasplm+multikey, обнаружил отсутствие в унипатче реализации сервиса 68h, там делов-то на пару часиков и унипатч начнет правильно эмулировать сетевой HASP-API (он и щас его эмулирует ,но в диалоге "About" не отображается число спартанцев сетевого ключа - за это в сетевом HASP-API отвечает сервис 68h).
По ходу дела возникает идейка - внедрить унипатч в hasplm для Linux-x64, это гораздо проще, чем допиливать эмулятор VHCI_HCD.
Прям щас копаю в направлении "заменить в линуксовом HASP-API функции работы с локальным USB-ключём на чтение из дампа ключа"

[holmes]

Надеюсь хорошее изделие сделаешь из hasplm

[HPDX2300]

Небольшое наблюдение за изделием в IDA-7.7:
сборка 8.3.8-2137-linux-x64 когда общается с эмулем VHCI_HCD падает через 120сек из-за "нарушение защиты памяти при чтении по адресу 0000000000000000".
На одной из функций, назовем её wrp_HASPAPI64_L3, поставлена BP, которая не останавливает дебагер, а только выполняет небольшой IDC-скрипт (в поле Condition):

Exec ("date +%s.%N > /tmp/mytime.tim");
auto h = fopen("/tmp/mytime.tim", "r");
auto time = readstr(h);
fclose(h);
msg("time=%s  event:call wrp_HASPAPI64_L3; arg SvcID=%d; event_tid=%d\n", time, edi, get_event_tid());

Оно выводит системное время в формате "секунды.наносекунды", затем "HASP4 ServiceID" (в рег. edi) и номер потока выполнения.
На закладке "Выхлоп" ("Output") читаем:

7FBAA8591711: thread has started (tid=4465) 1cv8
time=1657393695.130697342
  event:call wrp_HASPAPI64_L3; arg SvcID=1; event_tid=4456
time=1657393695.150832721
  event:call wrp_HASPAPI64_L3; arg SvcID=5; event_tid=4456
time=1657393695.166035010
  event:call wrp_HASPAPI64_L3; arg SvcID=50; event_tid=4456
time=1657393695.177592245
  event:call wrp_HASPAPI64_L3; arg SvcID=50; event_tid=4456
time=1657393695.188610014
  event:call wrp_HASPAPI64_L3; arg SvcID=6; event_tid=4456
time=1657393695.201090411
  event:call wrp_HASPAPI64_L3; arg SvcID=50; event_tid=4456
time=1657393695.212710415
  event:call wrp_HASPAPI64_L3; arg SvcID=50; event_tid=4456
time=1657393697.051191723
  event:call wrp_HASPAPI64_L3; arg SvcID=60; event_tid=4456
time=1657393697.089376602
  event:call wrp_HASPAPI64_L3; arg SvcID=6; event_tid=4456
time=1657393697.151858096
  event:call wrp_HASPAPI64_L3; arg SvcID=50; event_tid=4456
time=1657393697.166814231
  event:call wrp_HASPAPI64_L3; arg SvcID=6; event_tid=4456
time=1657393820.024077498
  event:call wrp_HASPAPI64_L3; arg SvcID=60; event_tid=4490
7FBA74A4DD79: got SIGSEGV signal (Segmentation violation) (exc.code b, tid 4490)

падение на втором вызове SvcID=60 и в другом потоке (event_tid=4490) - в нём же и крах (tid 4490)
есть в "Basic HASP API Services" два сервиса 60 и 61, взаимно обратные:
Service 60: HaspEncodeData; Description: Encodes data via a connected HASP key.
Service 61: HaspDecodeData; Description: Decodes data via a connected HASP key.

потом посмотрю на подробности (входные и выходные данные) и сравню их при работе через унипатч.
Есть подозрение, что грабельки лежат в реализации Service 60 HaspEncodeData.

[HPDX2300]

Предвидя замечание "а чё такую древность 8.3.08-2137.lnx64 дебажить???", докладываю: есть причины, но тут не хочу писать (сектанты же читают это)
Если посмотреть в бэкбейс на реализацию "Service 5 HaspStatus"
(цитата о нём из мануала "HASP Programmer’s Guide":
Description: Check the type of HASP connected to the computer. Also check to which port the key is connected.
...Return Values:
...Par4: HASP Object Version – The current API version.)
, то увидим

8.3.08-2137.lnx64
398BCD: 41 C7 40 34 3C 23 00 00  mov dword ptr [r8+34h],233Ch ; 233Ch = 9020. HASP API version

8.3.20-1363.lnx64
5B83BD: 41 C7 40 34 3C 23 00 00  mov dword ptr [r8+34h],233Ch ; 233Ch = 9020. HASP API version

8.3.20-1710.lnx64
5C379D: 41 C7 40 34 3C 23 00 00  mov dword ptr [r8+34h],233Ch ; 233Ch = 9020. HASP API version

8.3.20-1838.lnx64
5C4E1D 41 C7 40 34 3C 23 00 00   mov dword ptr [r8+34h], 233Ch ; 233Ch = 9020. HASP API version

8.3.16-1296.lnx64
50CD3D: 41 C7 40 34 3C 23 00 00  mov dword ptr [r8+34h],233Ch ; 233Ch = 9020. HASP API version

8.3.21-1140.lnx64
5F054D: 41 C7 40 34 3C 23 00 00  mov dword ptr [r8+34h],233Ch ; 233Ch = 9020. HASP API version

8.3.22-1368.lnx64
5EDE4D: 41 C7 40 34 3C 23 00 00  mov dword ptr [r8+34h],233Ch ; 233Ch = 9020. HASP API version

и в винде и в макоси "всё те же куриные яйца, тока вид сбоку" - HASP API не менялся от 8.3.08 до 8.3.22

8.3.08-2137.macos x64
39105D: 41 C7 40 34 54 24 00 00  mov dword ptr [r8+34h],2454h ; 2454h = 9300. HASP API VERSION

8.3.22-1368.macos x64
59273D: 41 C7 40 34 54 24 00 00  mov dword ptr [r8+34h],2454h ; 2454h = 9300. HASP API VERSION

8.2.19-130.win64
offset=18AB1D: C7 43 34 54 24 00 00  mov dword ptr [rbx+34h],2454h ; 2454h = 9300. HASP API version

8.3.20-1479.win64
offset=8128Dh: C7 43 34 54 24 00 00  mov dword ptr [rbx+34h],2454h ; 2454h = 9300. HASP API version

[HPDX2300]

Как я предположил ранее - реализация Service 60 HaspEncodeData в эмуляторе VHCI_HCD "кривая", ниже показано что я увидел в отладчике на входе и выходе Service 60.

Первый вызов по содержанию буфера памяти для входных данных (24h байт) не отличается от второго.
Эмулятор VHCI_HCD на первом вызове Service 60 HaspEncodeData также выдаст неверный результат в буфере, но это не будет иметь последствий в виде быстрого краха.
Последующие вызовы Service 60 HaspEncodeData идут без повторений вх.данных, и размер данных в буфере немного больше - 0х30.

вот что делает унипатч:
2-й вызов Service 3Ch=60

BEFORE CALL
аргументы функции hasp()
7FE27F31B200: 00 00 00 00 ; 000000000=Par1 - must be 0 (not used)
7FE27F31B204: 24 00 00 00 ; 00000024h=Par2 - Buffer size. The size in bytes of the buffer to be encoded.
7FE27F31B208: E2 7F 00 00 ; 00007FE2h=Par3 - high dword address of the buffer
7FE27F31B20C: 00 EF B6 70 ; 70B6EF00h=Par4 - low dword address of the buffer

данные в buffer: (8-2137-lnx64 basic.so+0x01AB84E0)
7FE270B6EF00: 49 33 F6 33 DF 6B AB 1C 34 3F 51 71 F4 E7 EF 4E
7FE270B6EF10: 39 E7 AF C7 59 64 C9 8E 44 B0 4E 3D 6C 23 C7 B6
7FE270B6EF20: 56 BD E9 35

AFTER CALL
аргументы функции hasp()
7FE27F31B200: 00 00 00 00 ; 000000000=Par1
7FE27F31B204: 24 00 00 00 ; 00000024h=Par2
7FE27F31B208: 00 00 00 00 ; 000000000=Par3 (return value) Status. A code indicating the status of the operation (0==success)
7FE27F31B20C: 00 EF B6 70 ; 70B6EF00h        

данные в buffer: (8-2137-lnx64 basic.so+0x01AB8504)
7FE270B6EF00: 75 B3 DF 68 A5 2D F5 23 71 76 D8 85 0D 93 2E AF
7FE270B6EF10: 21 1B CF 94 43 6D B4 38 BE C2 08 FD C3 04 1D 58
7FE270B6EF20: AD A9 40 8E

вот эти записи в скобках:
buffer: (8-2137-lnx64 basic.so+0x01AB84E0)
buffer: (8-2137-lnx64 basic.so+0x01AB8504)
означают, что входные данные в буфере, и выходные данные в буфере находятся рядом (сперва вх.данные, сразу после них выходные) в модуле "васик" - после плюса указано смещение в файле

вот что делает VHCI_HCD:
2-й вызов Service 3Ch=60

BEFORE CALL
аргументы функции hasp()
7F0D04781220: 00 00 00 00 ; 000000000=Par1 - must be 0 (not used)
7F0D04781224: 24 00 00 00 ; 00000024h=Par2 - Buffer size. The size in bytes of the buffer to be encoded.
7F0D04781228: 0D 7F 00 00 ; 00007F0Dh=Par3 - high dword address of the buffer
7F0D0478122C: 10 13 75 44 ; 44751310h=Par4 - low dword address of the buffer

данные в buffer:
7F0D44751310: 49 33 F6 33 DF 6B AB 1C 34 3F 51 71 F4 E7 EF 4E
7F0D44751320: 39 E7 AF C7 59 64 C9 8E 44 B0 4E 3D 6C 23 C7 B6
7F0D44751330: 56 BD E9 35

AFTER CALL
аргументы функции hasp()
7F0D04781220: 00 00 00 00
7F0D04781224: 24 00 00 00
7F0D04781228: 00 00 00 00 ; 000000000=Par3 (return value) Status. A code indicating the status of the operation (0==success)
7F0D0478122C: 10 13 75 44

данные в buffer:
7F0D44751310: 53 5C 98 B5 9A ED DE D8 01 A0 AC E7 6A E0 BF 0C
7F0D44751320: 27 87 78 D4 DF E2 3A 82 EE 30 DA C9 73 9E 4D D2
7F0D44751330: E8 1D 2E A5

входные данные для Service 60 HaspEncodeData в модуле "васик" найдены с помощью МС - поиском по всем файлам цепочки байт (надо включить "Search for content" и "Regular expression", а цепочку байт писать так \x49\x33\xF6\x33\xDF.......)

Можно сделать последнее предположение - неправильные результаты работы Service 60 HaspEncodeData могут быть связаны с опечатками в дампе ключа - ошибка в одном символе может быть фатальной, хотя, я не знаю алгоритма шифрования т.к. не анализировал код исходников.

[ZevSua]

Налабала по приведенной инструкции патчер https://dropmefiles.com/ICbTJ описание внутри, юзайте на здоровье

По какой именно?? А то здесь инструкций последнее время от каждого утюга, - мама не горюй.

мне просто надо чтоб заработало и на 8.3.16 и на новых. А по ним то одна там не работает то вторая на другом , то через некоторое время виснет я хз

[HPDX2300]

Сделала всё как в мануалах нарисовано, а 1С падает в разных местах "Ключ больше не доступен" или вообще в "Process 3554 (1cv8) of user 1000 dumped core", с родным USB ключом ничего не вываливается, значит вывод надо USBHASP пилить который что-то не так отвечает, есть в природе что рабочее, чтобы не падало?

Посмотрел исходники USBHASP (a.k.a. usb_vhci_hcd) - возникает вопрос: "этот эмулятор ваабче используется кем-то для изделия секты 'АднаСекта' ?"
Только у holmes не получилось его попользовать, или все остальные просто промолчали о своих неудачах?

[HPDX2300]

По какой именно?? мне просто надо чтоб заработало и на 8.3.16 и на новых.

надо было пару страниц назад почитать, т.е. сбыча твоих мечт на 85 стр. упомянута

[HPDX2300]

Посмотрел исходники USBHASP (a.k.a. usb_vhci_hcd) - возникает вопрос: "этот эмулятор ваабче используется кем-то для изделия секты 'АднаСекта' ?"
Только у holmes не получилось его попользовать, или все остальные просто промолчали о своих неудачах?

всётаки USBHASP (a.k.a. usb_vhci_hcd) у некоторых работает месяцами и не жужжит. Придется мне погрузиться в реализацию Service 60 HaspEncodeData в унипатче, чтобы понять "от каких данных в дампе ключа зависит результат?"