неделя, 17 май 2015 г.

USBCCID Dissection & B-Trust Reader/Writer ACR38T

Започвам едно разследване за което е силно вероятно да нямам никакво време да продължа, но това няма да ми попречи да документирам днешните си занимaния.

Кратка предистория:
Имам КЕП (Квалифициран Електронен Подпис) издаден от B-Trust. Като всяка институция в нашата родина тези хора са безкрайно некохерентни в използвана терминология и скачат от преводен термин на български в някакви заемки от чужд език които дори според производителя на устройството не са такива. Пример 'SO PIN' и 'Unblock PIN' са едно и също нещо според тях а на родната публика това по-скоро е известно като 'PUK'.
Понеже в случя става дума за четене на информация от SIM карта на мен ми се струва че употребата на PUK е далеч по-добра или е трябвало поне да се придъжат към терминологията на производителя 'SO PIN'. Но това е друга бира. По темата:

Рекох да си сменям пиновете на устройството и понеже съм много чевръст в пръстите успях да си сменя потребителския пас (PIN - ако се придържаме към телефонните термини) и в опит да си сменя PUK видях как attempts left полето се смалява от 3 към 0 и ме известява че видиш ли съм си блокирал картата. Добре обаче това изобщо не е вярно тъй като устройството работи, а с въведен правилен PIN даже подписва официални документи и банкови плащания.

И почвам да си мисля - SIM картата е носител на информация. Като такъв от него може да се чете. Добре обаче явно и без аутентикация от какъвто и да е тип може и да се пише (може и да е частен случай, но писането в attempts полето е възможно). Е щом е възможно аз защо не зема да си запиша там 999 и да си тествам с каквито там пароли си мисля че съм сложил.

Поразрових в нета и се оказва че тия хора в Белгия ги ползват тези устройства и за други неща и един младеж си е написал дъмпвачка:

https://github.com/xofc/Beid2html

Кода е толкова лалав че все едно аз съм го писал което не е задължително лошо понеже му разбирам какво прави. Човека ползва libusb-1.0

В неговият случай не е писано за същото устройство и съоетвено се налага да се смени usb id-то от хардкоднатото при него 1a44:0870 на 072f:90cc


След тази смяна връзката с устройството окача и той се впуска да му викне един статус:


if (libusb_bulk_transfer(udevp, 0x01, bufout, sizeof(bufout), &n, 1000) < 0)
  {
  fprintf(stderr, "bulk-out failed\n");
  perror("PC_to_RDR_GetSlotStatus");
  return;
  }

Хубаво прави ама много бързо се отказва. След като снифнах с wireshark как си говорят купешкия app и девайса се оказва, че традицията повелява не един, не два а точно 5 пъти да му искаш статус а то да се прави че не разбира. И чак след петия път да му пуснеш един пауър он:



И след пауър онът девайса вече съвсем културно връща  EJCOPv241 за Chip Operating System.

И почват да си говорят с дата блоци. Но кога ще ги разнищя те какви са...
to be continued (or not).

Няма коментари:

Публикуване на коментар