Hola.
First and worst problem, the Radio/Modem firmware is vulnerable to remote exploitation. Could we use the Radio F/W for the Z2 or any other currently supported device in the Z series and apply it to the Z1? Or do we just rip the sim card and never ever ever use the Radio/Modem again?
http://arstechnica.com/security/2016...plete-takeover
Next, QSEE, https://bits-please.blogspot.no/2016...ility.html?m=1
A chip update might be needed as the author suggested, if a magic kernel update cant mitigate this, I'd do this in the my backports hobby projects of course, but did not touch this part last time as i've not enabled encryption myself, as i do a lot of kernel sorcery on the device and gazillions of reboots . I'll "officially" forum launch this in the coming days as i have a few goodies lined up. https://github.com/threader/kernel-c...xxx-backports/ - We could perhaps work around this by levering other encryption schemes native to the Linux kernel and just implement a light boot image and Kexec boot another kernel once the password is entered and such. Compiling a kernel w/o QSEE at all, and hammer a nail tru the chip :D .
But as this stands, the device isn't safe to use on the cell networks, as far as i know, the entire Z1 series is affected along with every other Qcom device ... One cant risk getting owned without any knowledge and no working counter measures.
This is a real shame, really, i like Qcom and their SoCks. . . ... It's where my main familiarity lies... I feel like a leprechaun working with say Exynox sources... Though their devices are sound of course, it's just a matter of familiarity of the device, code and community.
Cheers
First and worst problem, the Radio/Modem firmware is vulnerable to remote exploitation. Could we use the Radio F/W for the Z2 or any other currently supported device in the Z series and apply it to the Z1? Or do we just rip the sim card and never ever ever use the Radio/Modem again?
http://arstechnica.com/security/2016...plete-takeover
Next, QSEE, https://bits-please.blogspot.no/2016...ility.html?m=1
A chip update might be needed as the author suggested, if a magic kernel update cant mitigate this, I'd do this in the my backports hobby projects of course, but did not touch this part last time as i've not enabled encryption myself, as i do a lot of kernel sorcery on the device and gazillions of reboots . I'll "officially" forum launch this in the coming days as i have a few goodies lined up. https://github.com/threader/kernel-c...xxx-backports/ - We could perhaps work around this by levering other encryption schemes native to the Linux kernel and just implement a light boot image and Kexec boot another kernel once the password is entered and such. Compiling a kernel w/o QSEE at all, and hammer a nail tru the chip :D .
But as this stands, the device isn't safe to use on the cell networks, as far as i know, the entire Z1 series is affected along with every other Qcom device ... One cant risk getting owned without any knowledge and no working counter measures.
This is a real shame, really, i like Qcom and their SoCks. . . ... It's where my main familiarity lies... I feel like a leprechaun working with say Exynox sources... Though their devices are sound of course, it's just a matter of familiarity of the device, code and community.
Cheers
No comments:
Post a Comment