1) stall is needed to create an incomplete USB transaction. You are right – this is necessary to prevent request completion, as a result of which you can create a request queue. The delay does not matter. Further requests can be executed even with a sufficiently long pause after the stall (for example, 10 seconds). In fact, the USB bus does not go into the STALL state (the STALL handshake packets are not sent, only NACK). At the same time, the controller is working in such a way that it always processes SETUP packets, which is why it is possible to create a request queue.
2) No additional requests are needed. As it turned out, in the presented version of the exploit, even a single stall request is enough – it will be overwritten with new "callback" and "next" values. Apparently, this is possible because before overflowing while executing the USB_REQ_SET_CONFIGURATION request (libusb1_no_error_ctrl_transfer(device, 0, 9, 0, 0, t8010_overwrite, 50)), another request will be created and it will remain in the heap (see SecureROM sources). It will play the role of a heap barrier and will prevent access to corrupted metadata of an overflowed request during further work with the heap. If you use a request from the original code (libusb1_no_error_ctrl_transfer(device, 0, 0, 0, 0, t8010_overwrite, 50)), then the second request is needed as a heap barrier.
На устройствах без SEP такое возможно. На устройствах с SEP (iPhone 5s и далее) без знания PIN не получится расшифровать данные. Сама уязвимость позволяет исполнять код в SecureROM и никак не влияет на SEP, который препятствует bruteforce-атакам на PIN. Возможны сценарии, когда в устройство с помощью данной уязвимости будет встроен бекдор, отправляющий данные злоумышленнику, но подобные атаки требуют физического доступа к устройству
Не знаю почему, но символы для большого количества модулей из рассматриваемой версии Windows действительно отсутствую на серверах публичных символов Microsoft.
Thank you for your reply and good question!
1)
stallis needed to create an incomplete USB transaction. You are right – this is necessary to prevent request completion, as a result of which you can create a request queue. The delay does not matter. Further requests can be executed even with a sufficiently long pause after the stall (for example, 10 seconds). In fact, the USB bus does not go into theSTALLstate (theSTALLhandshake packets are not sent, onlyNACK). At the same time, the controller is working in such a way that it always processesSETUPpackets, which is why it is possible to create a request queue.2) No additional requests are needed. As it turned out, in the presented version of the exploit, even a single
stallrequest is enough – it will be overwritten with new"callback"and"next"values. Apparently, this is possible because before overflowing while executing theUSB_REQ_SET_CONFIGURATIONrequest (libusb1_no_error_ctrl_transfer(device, 0, 9, 0, 0, t8010_overwrite, 50)), another request will be created and it will remain in the heap (see SecureROM sources). It will play the role of a heap barrier and will prevent access to corrupted metadata of an overflowed request during further work with the heap. If you use a request from the original code (libusb1_no_error_ctrl_transfer(device, 0, 0, 0, 0, t8010_overwrite, 50)), then the second request is needed as a heap barrier.Не знаю почему, но символы для большого количества модулей из рассматриваемой версии Windows действительно отсутствую на серверах публичных символов Microsoft.
Однако, мне удалось найти пакет символов для данной сборки, который включает также и символы для компонентов Edge. Найденный пакет я и использовал при отладке. Скачать его можно по ссылке: https://download.microsoft.com/download/6/9/C/69C86A1F-C8E9-4F28-B6FC-9FA2BCE98BC0/Windows_Rs2.15063.0.170317-1834.x64FRE.Symbols.msi