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

[Pependos]

Господа-коллеги, неожиданно столкнулся сейчас с проблемой запуска, причём ещё в пятницу всё стартовало без проблем, но там наверняка были какие-то обновления (Kubuntu 22.04). Запускаю 1С:

• /opt/1cv8/common/1cestart

Получаю ошибку:

• /opt/1cv8/common/1cestart: /opt/1cv8/common/libstdc++.so.6: version `GLIBCXX_3.4.30' not found (required by /lib/x86_64-linux-gnu/libicuuc.so.70)

Как это победить?

Выхлоп команды strings /usr/lib/x86_64-linux-gnu/libstdc++.so.6 | grep GLIBCXX:
Скрытый текст

GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
GLIBCXX_3.4.3
GLIBCXX_3.4.4
GLIBCXX_3.4.5
GLIBCXX_3.4.6
GLIBCXX_3.4.7
GLIBCXX_3.4.8
GLIBCXX_3.4.9
GLIBCXX_3.4.10
GLIBCXX_3.4.11
GLIBCXX_3.4.12
GLIBCXX_3.4.13
GLIBCXX_3.4.14
GLIBCXX_3.4.15
GLIBCXX_3.4.16
GLIBCXX_3.4.17
GLIBCXX_3.4.18
GLIBCXX_3.4.19
GLIBCXX_3.4.20
GLIBCXX_3.4.21
GLIBCXX_3.4.22
GLIBCXX_3.4.23
GLIBCXX_3.4.24
GLIBCXX_3.4.25
GLIBCXX_3.4.26
GLIBCXX_3.4.27
GLIBCXX_3.4.28
GLIBCXX_3.4.29
GLIBCXX_3.4.30
GLIBCXX_DEBUG_MESSAGE_LENGTH

[redhat2020]

...неожиданно столкнулся сейчас с проблемой запуска, причём ещё в пятницу всё стартовало без проблем, но там наверняка были какие-то обновления (Kubuntu 22.04).

обновлять что-либо, не почитав предварительно "1)какие изменения? 2)оно мне надо?", оч.плохая практика т.к. часто является причиной fuck-up.
в вашем конкретном случае - надо научиться смотреть по логам "что обновилось и какая версия была до обновления?", затем научиться делать откат обновления (я умею и делал это в CentOS, но как в там убунте - х.3.)

[Pependos]

Господа-коллеги, неожиданно столкнулся сейчас с проблемой запуска, причём ещё в пятницу всё стартовало без проблем, но там наверняка были какие-то обновления (Kubuntu 22.04). Запускаю 1С:

• /opt/1cv8/common/1cestart

Получаю ошибку:

• /opt/1cv8/common/1cestart: /opt/1cv8/common/libstdc++.so.6: version `GLIBCXX_3.4.30' not found (required by /lib/x86_64-linux-gnu/libicuuc.so.70)

Как это победить?

Отвечу сам себе, может, кому пригодится:

sudo cp /lib/x86_64-linux-gnu/libstdc++.so.6 /opt/1cv8/common/libstdc++.so.6
sudo cp /lib/x86_64-linux-gnu/libstdc++.so.6 /opt/1cv8/x86_64/8.3.21.1302/libstdc++.so.6

[ZX Fan]

Отвечу сам себе, может, кому пригодится:

sudo cp /lib/x86_64-linux-gnu/libstdc++.so.6 /opt/1cv8/common/libstdc++.so.6
sudo cp /lib/x86_64-linux-gnu/libstdc++.so.6 /opt/1cv8/x86_64/8.3.21.1302/libstdc++.so.6

Советую немного по-другому:
[/CODE]sudo mv /opt/1cv8/x86_64/8.3.21.1393/libstdc++.so.6 /opt/1cv8/x86_64/8.3.21.1393/libstdc++.so.6.BAK
sudo ln -s /lib/x86_64-linux-gnu/libstdc++.so.6 /opt/1cv8/x86_64/8.3.21.1393/libstdc++.so.6
sudo mv /opt/1cv8/common/libstdc++.so.6 /opt/1cv8/common/libstdc++.so.6.BAK
sudo ln -s /lib/x86_64-linux-gnu/libstdc++.so.6 /opt/1cv8/common/libstdc++.so.6[/CODE]

так правильнее: и сохраним резервные копии библиотек от 1С, и на верные библиотеки сделаем символьную ссылку - поможет потом при обновлении.

[Sailas]

Добрый день. Появилась идея сделать резервную машину с дампами ключей, которые будут пробрасываться на сервера с 1с. Но идея наткнулась на суровую реальность. Процесс установки по инструкции ув. localhost2005 прошел корректно, устройства видны.
Вывод lsusb

Bus 003 Device 005: ID 0529:0001 Aladdin Knowledge Systems HASP copy protection dongle
Bus 003 Device 004: ID 0529:0001 Aladdin Knowledge Systems HASP copy protection dongle
Bus 003 Device 003: ID 0529:0001 Aladdin Knowledge Systems HASP copy protection dongle
Bus 003 Device 002: ID 0529:0001 Aladdin Knowledge Systems HASP copy protection dongle
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 0e0f:0002 VMware, Inc. Virtual USB Hub
Bus 001 Device 002: ID 0e0f:0003 VMware, Inc. Virtual Mouse
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

Проблема как у tormozok

не подскажете, где задается максимальное количество ключей, которое можно раздать. По дефолту только 4

Испробовано на нескольких версиях Debian и Ubuntu, на различных ядрах. Все безрезультатно. Например, текущая машина, с ограничением в 4 устройства

uname -a

Linux hasp-test 5.10.0-15-amd64 #1 SMP Debian 5.10.120-1 (2022-06-09) x86_64 GNU/Linux

uname -r

5.10.0-15-amd64

Кто-нибудь реализовывал подобную схему с использованием более четырех дампов? Есть какие-нибудь идеи? Спасибо

[localhost2005]

TEST HASP 1C v8.3!

lsusb | grep Aladdin
Bus 007 Device 004: ID 0529:0001 Aladdin Knowledge Systems HASP copy protection dongle
Bus 007 Device 003: ID 0529:0001 Aladdin Knowledge Systems HASP copy protection dongle
Bus 007 Device 002: ID 0529:0001 Aladdin Knowledge Systems HASP copy protection dongle
Bus 006 Device 004: ID 0529:0001 Aladdin Knowledge Systems HASP copy protection dongle
Bus 006 Device 003: ID 0529:0001 Aladdin Knowledge Systems HASP copy protection dongle
Bus 006 Device 002: ID 0529:0001 Aladdin Knowledge Systems HASP copy protection dongle
Bus 005 Device 004: ID 0529:0001 Aladdin Knowledge Systems HASP copy protection dongle
Bus 005 Device 003: ID 0529:0001 Aladdin Knowledge Systems HASP copy protection dongle
Bus 005 Device 002: ID 0529:0001 Aladdin Knowledge Systems HASP copy protection dongle
Bus 004 Device 004: ID 0529:0001 Aladdin Knowledge Systems HASP copy protection dongle
Bus 004 Device 003: ID 0529:0001 Aladdin Knowledge Systems HASP copy protection dongle
Bus 004 Device 002: ID 0529:0001 Aladdin Knowledge Systems HASP copy protection dongle

systemctl status hasplm

hasplm.service - Sentinel LM
Loaded: loaded (/lib/systemd/system/hasplm.service; enabled; vendor preset: enabled)
Active: active (running) since Tue 2022-06-28 15:53:59 MSK; 1h 33min ago
Process: 336 ExecStart=/usr/bin/hasplm -c /etc/hasplm/hasplm.conf (code=exited, status=0/SUCCESS)
Main PID: 345 (hasplm)
Tasks: 1 (limit: 1149)
Memory: 2.1M
CGroup: /system.slice/hasplm.service
345 /usr/bin/hasplm -c /etc/hasplm/hasplm.conf

июн 28 15:53:59 haspkey systemd[1]: Starting Sentinel LM...
июн 28 15:53:59 haspkey hasplm[345]: HASP LM v8.30 loaded
июн 28 15:53:59 haspkey systemd[1]: Started Sentinel LM.

systemctl status haspd

haspd.service - LSB: Hasp keys support
Loaded: loaded (/etc/init.d/haspd; generated)
Active: active (running) since Tue 2022-06-28 16:48:50 MSK; 38min ago
Docs: man:systemd-sysv-generator(8)
Process: 1430 ExecStart=/etc/init.d/haspd start (code=exited, status=0/SUCCESS)
Tasks: 10 (limit: 1149)
Memory: 13.9M
CGroup: /system.slice/haspd.service
1435 aksusbd
1446 hasplmd -s

июн 28 16:48:50 haspkey systemd[1]: Starting LSB: Hasp keys support...
июн 28 16:48:50 haspkey aksusbd[1435]: loaded, daemon version: 8.23.1.119312, key API (USB) version: 3.88 (parallel driver not available)
июн 28 16:48:50 haspkey haspd[1430]: Running aksusbd... [ DONE ]
июн 28 16:48:50 haspkey hasplmd[1446]: HASP LM v25.2.1.119312 loaded
июн 28 16:48:50 haspkey haspd[1430]: Running hasplmd... [ DONE ]
июн 28 16:48:50 haspkey systemd[1]: Started LSB: Hasp keys support.

Делаем раз, два и так далее...
usbhaspd /root/usbhaspd-001.conf
usbhaspd /root/usbhaspd-002.conf
usbhaspd /root/usbhaspd-003.conf
usbhaspd /root/usbhaspd-004.conf

[Sailas]

Вывод основных команд

sailas@hasp-test01:~$ lsusb | grep Aladdin
Bus 003 Device 005: ID 0529:0001 Aladdin Knowledge Systems HASP copy protection dongle
Bus 003 Device 004: ID 0529:0001 Aladdin Knowledge Systems HASP copy protection dongle
Bus 003 Device 003: ID 0529:0001 Aladdin Knowledge Systems HASP copy protection dongle
Bus 003 Device 002: ID 0529:0001 Aladdin Knowledge Systems HASP copy protection dongle
sailas@hasp-test01:~$ systemctl status hasplm
● hasplm.service - Sentinel LM
   Loaded: loaded (/lib/systemd/system/hasplm.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2022-06-29 07:11:40 UTC; 2min 6s ago
  Process: 809 ExecStart=/usr/bin/hasplm -c /etc/hasplm/hasplm.conf (code=exited, status=0/SUCCESS)
 Main PID: 889 (hasplm)
    Tasks: 1 (limit: 2283)
   CGroup: /system.slice/hasplm.service
           └─889 /usr/bin/hasplm -c /etc/hasplm/hasplm.conf

Jun 29 07:11:40 hasp-test01 systemd[1]: Starting Sentinel LM...
Jun 29 07:11:40 hasp-test01 systemd[1]: Started Sentinel LM.
Jun 29 07:11:40 hasp-test01 hasplm[889]: HASP LM v8.30 loaded
sailas@hasp-test01:~$ systemctl status haspd
● haspd.service - LSB: Hasp keys support
   Loaded: loaded (/etc/init.d/haspd; generated)
   Active: active (running) since Wed 2022-06-29 07:11:42 UTC; 2min 27s ago
     Docs: man:systemd-sysv-generator(8)
  Process: 777 ExecStart=/etc/init.d/haspd start (code=exited, status=0/SUCCESS)
    Tasks: 10 (limit: 2283)
   CGroup: /system.slice/haspd.service
           ├─890 aksusbd
           └─954 hasplmd -s
sailas@hasp-test01:~$ systemctl status usbhaspd.service
● usbhaspd.service - Usbhasp daemon
   Loaded: loaded (/lib/systemd/system/usbhaspd.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2022-06-29 14:25:54 UTC; 25min ago
 Main PID: 895 (usbhaspd)
    Tasks: 2 (limit: 2283)
   CGroup: /system.slice/usbhaspd.service
           ├─895 /bin/bash /usr/bin/usbhaspd
           └─960 /usr/bin/usbhasp /etc/usbhaspd/keys/app03clients.json /etc/usbhaspd/keys/app03server.json /etc/usbhaspd/keys/app04clients.json /etc/usbhaspd/keys/app04server /etc/usbhaspd/keys/app05clients.json /etc/usbhaspd/keys/app05server.json /etc/usbhaspd/keys/app06clients.json /etc/usbhaspd/keys/app06server.json

Jun 29 14:25:56 hasp1991 usbhaspd[895]: usbhasp[960]: Set device on port 2 address = 3
Jun 29 14:25:56 hasp1991 usbhasp[960]: Set device on port 2 address = 3
Jun 29 14:25:56 hasp1991 usbhaspd[895]: usbhasp[960]: Port 3 is disabled.
Jun 29 14:25:56 hasp1991 usbhasp[960]: Port 3 is disabled.
Jun 29 14:25:56 hasp1991 usbhaspd[895]: usbhasp[960]: Set device on port 3 address = 4
Jun 29 14:25:56 hasp1991 usbhasp[960]: Set device on port 3 address = 4
Jun 29 14:25:57 hasp1991 usbhaspd[895]: usbhasp[960]: Port 4 is disabled.
Jun 29 14:25:57 hasp1991 usbhasp[960]: Port 4 is disabled.
Jun 29 14:25:57 hasp1991 usbhaspd[895]: usbhasp[960]: Set device on port 4 address = 5
Jun 29 14:25:57 hasp1991 usbhasp[960]: Set device on port 4 address = 5

Jun 29 07:11:40 hasp-test01 systemd[1]: Starting LSB: Hasp keys support...
Jun 29 07:11:40 hasp-test01 aksusbd[890]: loaded, daemon version: 8.23.1.119312, key API (USB) version: 3.88 (parallel driver not available)
Jun 29 07:11:40 hasp-test01 haspd[777]: Running aksusbd... [ DONE ]
Jun 29 07:11:41 hasp-test01 haspd[777]: Running hasplmd... [ DONE ]
Jun 29 07:11:41 hasp-test01 hasplmd[954]: HASP LM v25.2.1.119312 loaded
Jun 29 07:11:42 hasp-test01 systemd[1]: Started LSB: Hasp keys support.

Вывод при запуске usbhaspd

usbhasp[1863]: Loaded key 0: '1С:Предприятие 8.3 КОРП. Клиентская лицензия на 500 рабочих мест (USB)', Created: 12/05/2022 10:00
usbhasp[1863]: Loaded key 1: '1С:Предприятие 8.3 КОРП. Лицензия на сервер (x86-64)(USB)', Created: 12/05/2022 10:00
usbhasp[1863]: Loaded key 2: '1С:Предприятие 8.3 КОРП. Клиентская лицензия на 500 рабочих мест (USB)', Created: 12/05/2022 10:00
usbhasp[1863]: Loaded key 3: '1С:Предприятие 8.3 КОРП. Лицензия на сервер (x86-64)(USB)', Created: 12/05/2022 10:00
usbhasp[1863]: USB device created usb_vhci_hcd.1 (bus# 4)
usbhasp[1863]: Port 1 is powered on -> connecting device.
usbhasp[1863]: Port 1 connected.
usbhasp[1863]: Port 2 is powered on -> connecting device.
usbhasp[1863]: Port 2 connected.
usbhasp[1863]: Port 3 is powered on -> connecting device.
usbhasp[1863]: Port 3 connected.
usbhasp[1863]: Port 4 is powered on -> connecting device.
usbhasp[1863]: Port 4 connected.
usbhasp[1863]: Port 1 is disabled.
usbhasp[1863]: Set device on port 1 address = 2
usbhasp[1863]: Port 2 is disabled.
usbhasp[1863]: Set device on port 2 address = 3
usbhasp[1863]: Port 3 is disabled.
usbhasp[1863]: Set device on port 3 address = 4
usbhasp[1863]: Port 4 is disabled.
usbhasp[1863]: Set device on port 4 address = 5

Меня смущает вывод ls /sys/devices/platform/ | grep vh
как будто я не могу создать больше контроллеров

usb_vhci_hcd.0

Но больше всего смущает вывод nano /usr/bin/usbhaspd
Из того, что можно разобрать

USB (usb_vhci_fetch_work) failed: %s.
Port %d is powered on -> connecting device. USB (usb_vhci_port_connect), port %d failed: %s.
USB (usb_vhci_port_reset_done) port %d failed: %s.
USB (usb_vhci_port_resumed), port %d failed: %s.
USB (usb_vhci_fetch_data) port %d failed: %s.
Set device on port %d address = %d
USB (usb_vhci_giveback), port %d failed: %s.
Got invalid work for port, type %d
Wrong port number %hhu
Port %d is powered off.
Port %d connected.
Port %d is suspended.
Port %d is disabled.
Wrong device address %hhu
Received signal to stop.
?hd^@usbhasp^@Error %s loading keyfile %s.
Error parsing key file %s
Can't catch SIGINT
Unable to setsid.
Usage: #%s [-d] keyfile1.json ... keyfile%d.json
Loaded key %d: '%s', Created: %s
Unable to create USB device. Is vhci_hcd driver loaded?
USB device created %s (bus# %d)
Unable to fork off parent process.
Unable to fork for the second time.
USB device removed %s (bus# %d)
No keys loaded. Nothing to emulate.

Извиняюсь за стену текста, но устал бороться с проблемой. Самое обидное, что один раз все собралось и работало на vm без ограничений и лишнего шаманства, но машина благополучно похерена в истории

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