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

[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 могут быть связаны с опечатками в дампе ключа - ошибка в одном символе может быть фатальной, хотя, я не знаю алгоритма шифрования т.к. не анализировал код исходников.