Hello,
After some investigation on https://github.com/MotorolaMobilityLLC/kernel-mtk/tree/MMI-NMA26.42-113 and inside the /etc/bluetooth/btstack.conf I found out the Moto E4 device is using the BlueZ stack, with the unpatched l2cap_core.c.
Just look, this is a sample from the official Motorola github kernel site (the prototype of the function l2cap_build_conf_req)
Code:
static int l2cap_build_conf_req(struct l2cap_chan *chan, void *data);
And this one is from the official Linux kernel source:
Code:
static int l2cap_build_conf_req(struct l2cap_chan *chan, void *data, size_t data_size);
data_size, where is data size on Motorola, this is the problem!
Fix it, Mediatek! Fix it, Motorola!
I forgot to mention, NMA26.42-113 promised October 2017 security level.
More proof: Just look at https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e860d2c904d1a9f38a24eb44c9f34b8f915a6ea3
This shows exactly the spots that need to be changed!
You are dreaming if you think Motorola will release an update ....
Your answer is a custom rom with newer patches like the ones by Izaq......
Go check out the patch level of his DotOs & RR
That's why we come to XDA ..to root & flash custom roms .
KevMetal said:
You are dreaming if you think Motorola will release an update ....
Your answer is a custom rom with newer patches like the ones by Izaq......
Go check out the patch level of his DotOs & RR
That's why we come to XDA ..to root & flash custom roms .
Click to expand...
Click to collapse
True. Take time reading through pros/cons of each option (there are many); not all ROMs are equal and may lack the necessary customizations for this device. Ignore the happy extremes ("it's great"/"it sucks") as neither typically reflect reality. I generally stick with rooted stock on unlocked Moto devices enhanced with a few Magisk and Xposed modules. Everything just works and I'm not concerned with obscure vulnerabilities. Stability and solid battery life are top priorities. Very little bloatware added by Moto and most of it is useful; carrier crap is a different story (FWIW - I never purchase carrier branded phones). Responsible app selection and browsing behavior are cornerstones of good device hygiene. I also run a VPN based ad blocker and firewall which ads another virtual condom. My mobile is a productivity tool that needs to be there 7x24. For that stock is often, albeit not always, the best option. Good luck.
Thank you, but unfortunately a custom ROM is not an option. I use the Moto E4 as a daily driver, if I do this, then I lose stability. Plus Motorola says I might lose encryption if I unlock bootloader (and root the stock ROM) and I know custom ROMs often have broken encryption (not in sense of security, just doesn't work, bootloop, etc....).
iodev said:
Thank you, but unfortunately a custom ROM is not an option. I use the Moto E4 as a daily driver, if I do this, then I lose stability. Plus Motorola says I might lose encryption if I unlock bootloader (and root the stock ROM) and I know custom ROMs often have broken encryption (not in sense of security, just doesn't work, bootloop, etc....).
Click to expand...
Click to collapse
There are steps you can take to maintain data encryption on a unlocked device running a rooted Moto (stock) ROM. That said, if there is no compelling reason to root don't! There are many easy, practical ways to mitigate security concerns without resorting to paid apps & subscriptions that offer little benefit given the robust Android/Google Services security framework already in place. Rooting can undermine that model unless other precautions are taken ... most of them behavioral.
Reread my prior post. If you are loosing sleep over Blueborne simply disable the Bluetooth radio in public locations. Before doing that ask yourself why someone would target you and/or your device with a short range 'attack' that will likely yield nothing of interest. Mainstream media does a huge disservice identifying potential vulnerabilities without accompanying risk profile. Yes, Moto should fix it but they probably won't.
Davey126 said:
Reread my prior post. If you are loosing sleep over Blueborne simply disable the Bluetooth radio in public locations. Before doing that ask yourself why someone would target you and/or your device with a short range 'attack' that will likely yield nothing of interest. Mainstream media does a huge disservice identifying potential vulnerabilities without accompanying risk profile. Yes, Moto should fix it but they probably won't.
Click to expand...
Click to collapse
Yes, I am already doing that (seemed common sense to turn off Bluetooth when not using it, to ensure safety and preserve battery). Thank you anyway!
Yeah, they won't fix it ... they don't care.
iodev said:
Yes, I am already doing that (seemed common sense to turn off Bluetooth when not using it, to ensure safety and preserve battery). Thank you anyway!
Yeah, they won't fix it ... they don't care.
Click to expand...
Click to collapse
Boils down to resource management. This isn't a big threat and fixing it isn't going to sell more handsets in a world where 95% of customers/users don't weigh vendor security posture when making purchase decissions.
Davey126 said:
Boils down to resource management. This isn't a big threat and fixing it isn't going to sell more handsets in a world where 95% of customers/users don't weigh vendor security posture when making purchase decissions.
Click to expand...
Click to collapse
That's because people don't read CNET Security News
Instead they totally ignore that and when it hits them they go "Why me!?" instead of actually fixing it, so next time they also go "WHY does this happen to ME!?"
iodev said:
That's because people don't read CNET Security News
Instead they totally ignore that and when it hits them they go "Why me!?" instead of actually fixing it, so next time they also go "WHY does this happen to ME!?"
Click to expand...
Click to collapse
Surfacing potential and exposing bad behavior is a journalistic responsibility. That said, potential and reality are often distant partners that leaves the audience unsettled as risk assessment/mitigation are usually omitted. Read responsibly, my friend.
Davey126 said:
Surfacing potential and exposing bad behavior is a journalistic responsibility. That said, potential and reality are often distant partners that leaves the audience unsettled as risk assessment/mitigation are often omitted. Read responsibly, my friend.
Click to expand...
Click to collapse
Yeah, you're right, I'm sorry, I find it hard to differentiate between potential and reality (sometimes).
Related
What are the Disadvantages of Rooting ?
There are two main disadvantages to rooting and Android phone;
Rooting immediately voids your phone's warranty-Once rooted, don't try to bring your phone back for service or warranty work. You are on your own!
Rooting involves the risk of "bricking" your phone-In essence, a "bricked" phone is no better than carrying around a brick in your pocket. The phone is dead when it has been "bricked."
Other potential disadvantages, though less severe, are still worthy of consideration;
Poor performance-Though the intention of "rooting" a phone is to give the phone more performance, several users have found that, in their attempts to speed up the phone or add additional features, that their phones lost both performance speed and features. Remember that when you "root" your Android phone, you are making changes to the stock operating system.
Viruses-Yes, even phones can get viruses. A common practice that people do with "rooted" phones is to flash their ROM's with custom programs. Whenever you make changes to the code of a software, you run the risk of introducing a virus.
What are the Advantages of Rooting ?
"Rooting" your Android phone does afford you numerous benefits, including;
Running special applications-Superuser is an app that can only be run on a rooted Android phone. This allows you to control which apps have access to the "root" system. Another popular application that "rooting" affords is the ability to tether a computer to your Android phone so that the computer can access the Internet using the phone's data connection. Another program can allow your Android to be used as a WiFi Hotspot without having to pay your provider for the feature.
Freeing up memory-When you install an app on your phone, it is stored on the phone's memory. "Rooting" allows you to move installed applications to your SD card, thus freeing up system memory for additional files or apps.
Custom ROM's-This is the most powerful feature of "rooted" phones. There are hundreds of custom ROM's that can do anything from speeding up the processing speed of your phone to changing the entire look and feel of your phone.
Summary
The decision to "root" your Android phone is one that should not be rushed into. Though the allure of having an unlocked phone is powerful, having a "bricked" phone is, trust me, not very much fun.
CLOSE THIS THREAD!
you are condoning warez and should be banned
EDIT:
thank you for changing the thread,
post edited
akshay.bhat93 said:
Turn your Galaxy Y into a super power turbo
the rest is science
Click to expand...
Click to collapse
CALIBAN666 said:
whats that
are u sure u have permission for this confusin scripts.
all these u can downloading here and when an app like juicedefender is required than u becomes this from me:HAHAHA
I think its better u close this post
Click to expand...
Click to collapse
caliban look at the first part of your quote and remove the 3rd party link the website since it is warez
deathnotice01 said:
caliban look at the first part of your quote and remove the 3rd party link the website since it is warez
Click to expand...
Click to collapse
thanx bro,i have it totaly forgotten,but its done.
Explantion
Another program can allow your Android to be used as a WiFi Hotspot without having to pay your provider for the feature.
Click to expand...
Click to collapse
would u xplain these lines?? i lyk to use this feautre...
Basic Stuff
Advantage :Access to system files
Disadvantage : warranty loss
basic stuff: don't make any useless post. *ups...did I say that?*
akshay.bhat93 said:
Rooting immediately voids your phone's warranty-Once rooted, don't try to bring your phone back for service or warranty work. You are on your own!
Click to expand...
Click to collapse
Nope, flash any stock ROM, do unroot and then reset your counter, Never had any problems with service centre this way
akshay.bhat93 said:
Poor performance-Though the intention of "rooting" a phone is to give the phone more performance, several users have found that, in their attempts to speed up the phone or add additional features, that their phones lost both performance speed and features. Remember that when you "root" your Android phone, you are making changes to the stock operating system
Click to expand...
Click to collapse
This is also wrong, without rooting there would be no major development, and development indeeds boosts the performance. It never reduces speed, performance and features.
akshay.bhat93 said:
The decision to "root" your Android phone is one that should not be rushed into. Though the allure of having an unlocked phone is powerful, having a "bricked" phone is, trust me, not very much fun.
Click to expand...
Click to collapse
Soft bricks can be restored quite easily. You would never get a hard brick by following xda posts, also if they dont have the knowledge to unbrick there are load of posts on how to and a whole community to help them.
you should have seen this thread before it was edited
Thread Closed:
1. Looks like some info is wrong.
2. We already have threads like this that give a lot more info.
For those who don't know WhisperYAFFS is the encrypted filesystem used by the WhisperCore Custom Rom. The Source Code was released but I have notice not much has been done to port it over to the GNex or JellyBean/ICS for that matter.
What I want to do is port WhisperYAFFS over to ICS/JB. Since whispersys was bought by twitter they have slowly been open-sourcing their old apps but Whispercore still has not surffaced. A lot of users (myself included) don't feel comfortable with Google's implementation of encryption on android (AES-128 Bit and only 16 Char password).
The main difficulty is getting WhisperYAFFS running under ICS/JB. Once that's done we need a GUI for password entry at boot (The original was never open-sourced) and a hardened kernel for protection against exploits (Like GrSecurity or FuguMod).
If anyone is working on this or wants to help please let me know either here or via PM. I have some work in progress but I need help to make this a reality.
WhisperYAFFS: https://github.com/WhisperSystems/WhisperYAFFS
I'll second that...
I completely agree. While I am not a developer, this is the sort of project I would be more than willing to put several hundred dollars into to spur development. I think it is vital that there be an effective whole-device-encryption scheme for the Android Kernel which is based on 256 AES (or better) and utilizes a user provided key at boot time which is completely sperate from the "unlocking" functions during normal use.
While not strictly part of any WhisperYAFFS project, I would also like to see of hardening security features in the OS as well. A system with true whole-device-encryption is of course at it's most secure state when powered off. While on, even locked, there is always the possibility to exploit weaknesses in the OS. To that end, security features which power down the device without warning become an effective way to thwart an adversary. This auto-power-off should happen after too many failed attempts to unlock it and there also needs be a "dead man's switch" that shuts the device down should the unit not be "unlocked" after a configurable period of time.
mckinleytabor said:
I completely agree. While I am not a developer, this is the sort of project I would be more than willing to put several hundred dollars into to spur development. I think it is vital that there be an effective whole-device-encryption scheme for the Android Kernel which is based on 256 AES (or better) and utilizes a user provided key at boot time which is completely sperate from the "unlocking" functions during normal use.
While not strictly part of any WhisperYAFFS project, I would also like to see of hardening security features in the OS as well. A system with true whole-device-encryption is of course at it's most secure state when powered off. While on, even locked, there is always the possibility to exploit weaknesses in the OS. To that end, security features which power down the device without warning become an effective way to thwart an adversary. This auto-power-off should happen after too many failed attempts to unlock it and there also needs be a "dead man's switch" that shuts the device down should the unit not be "unlocked" after a configurable period of time.
Click to expand...
Click to collapse
This is exactly what I want. I want 'x' number of wrong password to wipe/poweroff the device and a duress password. I have been working on a geofencing solution so if the phone leaves a set area it auto-powers down.
x942 said:
This is exactly what I want. I want 'x' number of wrong password to wipe/poweroff the device and a duress password. I have been working on a geofencing solution so if the phone leaves a set area it auto-powers down.
Click to expand...
Click to collapse
This would be a great feature i admit
THIS. IS. NEXUS.
Just Checking in...
I thought I would post another reply just to float this post back up to the top.
Does anyone have any new leads on promising projects that will implement a robust full-device-encrypt system on phones and tablets running JellyBean? (not the poorly implemented device encryption that started in ICS)
I was dead serious in my post about putting up a bounty for this. Is there a good clearing house for us un-programers to pony up collective cash to get something like this done?
Thanks.
This should be high priority
I can't believe google hasn't given this any attention and instead gave us a half-butted home directory/data semi-encryption that is vulnerable to being cracked by consumer obtainable fpga tech. When we finally do get someone like moxie working on real solutions, he disappears with a fat salary into corporate america, albeit twitter and they're kind of cool, but then all development stops and only pieces are release to the public.
I'm all for this. Wish I'd done development in this area so I could jump right in. Hope this bumps the thread n someone with experience in this notices.
I know the corporate world is begging for this and wont let us use android for a lot of stuff as a result. So this could gain some real notice for any devs participating.
Hope for WhisperCore
I came across a Tweet from Moxie Marlinspike that seems to indicate that he is restarting work on WhisperCore.
https://twitter.com/moxie/status/301948885398585346
Text: @x942_dev We're getting WhisperCore started again, are you interested in working on that as well?
dicknixondick said:
I can't believe google hasn't given this any attention and instead gave us a half-butted home directory/data semi-encryption that is vulnerable to being cracked by consumer obtainable fpga tech. When we finally do get someone like moxie working on real solutions, he disappears with a fat salary into corporate america, albeit twitter and they're kind of cool, but then all development stops and only pieces are release to the public.
I'm all for this. Wish I'd done development in this area so I could jump right in. Hope this bumps the thread n someone with experience in this notices.
I know the corporate world is begging for this and wont let us use android for a lot of stuff as a result. So this could gain some real notice for any devs participating.
Click to expand...
Click to collapse
The encryption is actually fine by all means. The only issue really is that it doesn't encrypt the whole phone or use 256bit (not huge as 128 bit is technically enough but why settle for less?).
mckinleytabor said:
I came across a Tweet from Moxie Marlinspike that seems to indicate that he is restarting work on WhisperCore.
https://twitter.com/moxie/status/301948885398585346
Text: @x942_dev We're getting WhisperCore started again, are you interested in working on that as well?
Click to expand...
Click to collapse
Yes he did tweet but I have yet to hear any more from him... My project is going to be out soon. It's hasn't fixed encryption yet but it does address the issue of exploits by hardening the kernel with GRSecurity and adding in some other stuff.
Hi Folks:
I'm afraid I rooted a couple of my devices via Kingo a couple weeks ago and only now am I learning of the various confirmed/potential consequences. Based on feedback from a couple programmers and developers, coupled with what I've seen in some of the forums, this application employs its exploit as a guise not only to obtain personal information on the device, but also the PC. Furthermore, from what I understand, it installs very questionable, unnecessary material on one's PC that enables KINGO to track a user indefinitely.
In any case, I want to ensure that I can verify the material that was installed on my PC/phone and to greatest extent possible, remove all traces off my PC. That's my first objective. Second, I'd like to address my device in much the same capacity. Unfortunately, I'm quite lay when it comes to technical matters of this nature and thus I reach out to the community for guidance.
Thanks!
rhetorician said:
Hi Folks:
I'm afraid I rooted a couple of my devices via Kingo a couple weeks ago and only now am I learning of the various confirmed/potential consequences. Based on feedback from a couple programmers and developers, coupled with what I've seen in some of the forums, this application employs its exploit as a guise not only to obtain personal information on the device, but also the PC. Furthermore, from what I understand, it installs very questionable, unnecessary material on one's PC that enables KINGO to track a user indefinitely.
In any case, I want to ensure that I can verify the material that was installed on my PC/phone and to greatest extent possible, remove all traces off my PC. That's my first objective. Second, I'd like to address my device in much the same capacity. Unfortunately, I'm quite lay when it comes to technical matters of this nature and thus I reach out to the community for guidance.
Thanks!
Click to expand...
Click to collapse
Your PC will have to be cleaned very well.
Your phone will wipe it go back to stock and root away
TWEAKED 2.0
BACARDILIMON said:
Your PC will have to be cleaned very well.
Your phone will wipe it go back to stock and root away
TWEAKED 2.0
Click to expand...
Click to collapse
Roger that. I feel pretty comfortable rescuing my devices. It's the PC I'm worried about. What, exactly, does "very well" entail? Do you recommend a particular program? So far, Microsoft, McAfee, and Iobit all fail to identify potential vulnerabilities.
rhetorician said:
Roger that. I feel pretty comfortable rescuing my devices. It's the PC I'm worried about. What, exactly, does "very well" entail? Do you recommend a particular program? So far, Microsoft, McAfee, and Iobit all fail to identify potential vulnerabilities.
Click to expand...
Click to collapse
I am a security freak so you can't go by me. My step would be a full wipe on PC. But that is so extreme. I think is u use good virus protection and a reg checker/ cleaner you should be good. But I am not a pro. You might need to check in PC forums
TWEAKED 2.0
I had my PC checked by many friends who are in the security business and they found nothing after using it. Since I have wiped and installed Linux but they found nothing on my system after using it
Temasek CM11 & Yank Powered SM-N900T
I don't know if I'd go so far as to install Linux (unless, of course, that works for you and your needs...then I would recommend the idea highly)...but to guarantee any level of success I would absolutely insist on a complete repartition and reformat of your hard drive (and an ODIN flash of the complete factory restore image....bootloader, recovery and all)
If there is any residual risk of compromise I would expect virus scanners to pick it up (but not McAfee or Norton...they are the most popular therefore the most targeted for compromise)....AVG, Kaspersky, Avira....Just like Opera is the most secure browser or OSX and Linux are the most secure OSs. It's not that it's necessarily the most inherently secure options but they are also representative of the smallest fractions of the market therefore they are less attractive. The effort required to compromise them would be better spent on a more popular attack surface.
If your personal information and device performance means a goddamned thing to you WIPE EVERYTHING AS THOROUGHLY AS POSSIBLE. I am not kidding, I am not overstating the situation in the slightest. Do as I say.
To do anything less is to consider your personal information (top priority) and device performance (secondary priority) less than important.
Seriously now, does anybody have shred of evidence Kingo is a virus, besides hears says? Don't anti virus companies have a place to submit suspicious programs for evaluation? Did anybody with proper tools run trace to see what exactly Kingo is doing? There are tools to see registry entries made by Kingo and what they mean, there are ways to trace program etc I really would like to see some hard evidence or at least link to it.
daneurysm said:
I don't know if I'd go so far as to install Linux (unless, of course, that works for you and your needs...then I would recommend the idea highly)...but to guarantee any level of success I would absolutely insist on a complete repartition and reformat of your hard drive (and an ODIN flash of the complete factory restore image....bootloader, recovery and all)
If there is any residual risk of compromise I would expect virus scanners to pick it up (but not McAfee or Norton...they are the most popular therefore the most targeted for compromise)....AVG, Kaspersky, Avira....Just like Opera is the most secure browser or OSX and Linux are the most secure OSs. It's not that it's necessarily the most inherently secure options but they are also representative of the smallest fractions of the market therefore they are less attractive. The effort required to compromise them would be better spent on a more popular attack surface.
If your personal information and device performance means a goddamned thing to you WIPE EVERYTHING AS THOROUGHLY AS POSSIBLE. I am not kidding, I am not overstating the situation in the slightest. Do as I say.
To do anything less is to consider your personal information (top priority) and device performance (secondary priority) less than important.
Click to expand...
Click to collapse
LOL wasn't recommending Linux but yes I only installed win 8 to use kingo then back to Linux which is all I have used for years
Tweaked & Lean SM-N900T
The only security concern was their collection of your IMEI number. However, they removed this shortly after being contacted about it. As it currently stands, there are no known risks of using this program.
That and using some public chinese website to store all the software fixes for all different devices, at least as far as I know. This is not some kind of program that appeared from nowhere last night, this was published by Kingoapp technology, or something like that and the program works as advertised. They don't want to publish source code and I don't blame them, maybe they don't want other people to copy their work, maybe they don't want Samsung to patch security holes they found, or maybe they use other developers work, I don't care. I think I read somewhere that none of the 27 or so respectable antivirus programs flag Kingo as harmful and by now somebody should have found something if there was anything to find, especially that there was so much suspicion and controversy. There is always a risk when you download software from the web (whole websites could be fake and look official), but I have not seen one single proof Kingo was harmful in any way from anybody yet and I'm sure many people used it already.
This is all a red herring. The IMEI collection was the really only issue and they stopped that fairly quickly.
krelvinaz said:
This is all a red herring. The IMEI collection was the really only issue and they stopped that fairly quickly.
Click to expand...
Click to collapse
So it's safe to use?
I was planing to root my note 3 and kingo seems good was just worried.
xile6 said:
So it's safe to use?
I was planing to root my note 3 and kingo seems good was just worried.
Click to expand...
Click to collapse
I have encountered 0 problems using it. Used on my note and both of my note 3's. No problems PC or device wise. And there is no proof of KingoApp doing anything malicious, just hearsay.
Qualcomm QSEE and Radio/Modem vulnerability. Totally broken. How do we "fix" it?
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? ( And disable the Radio/Modem in kernel , and cut the traces on the logic board, and wrap the device in tin foil, and leave it in a led box, buried under 4 feet of concrete. )
http://arstechnica.com/security/201...nes-and-networks-at-risk-of-complete-takeover
Next, QSEE, https://bits-please.blogspot.no/2016/05/qsee-privilege-escalation-vulnerability.html?m=1
A chip update might be needed as the author suggested, if a magic kernel update can't mitigate this, I'd do the required changes in the my backports hobby projects of course, but did not touch this part last time as I've not enabled encryption myself, I do a lot of kernel sorcery on the device and gazillions of reboots, It's just not practical. I'll "officially" "forum launch" the backports kernel in the coming days as I have a few goodies lined up. https://github.com/threader/kernel-copyleft-14.6.A.1.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 .
But as this stands, the device isn't safe to use on the cell networks, as far as i know, the entire Qcom based and thereby the Z series is affected, along with every other Qcom device, past and current ... One can't risk getting owned without any knowledge and no working counter measures like this these days. But given the extent of this fault/vulnerability, it might be time to ditch the cellphone part of the cellphone all together, there simply is no such thing as security and privacy in this system, this is just one of several very serious faults and shortcomings of the worlds cellphone network system. Add this to the list after the for instance the SS7 system design malfunction which allows re-direction of calls without the knowledge of the subscriber, just like having a second sim card, and I can't really understand why any security concious person with a need for security would even considers walking around with these mobile tracking and information leaking devices... The computer in your pocket is the way in to all your personal information, you carry it around, connect to your local home network, your work network, your friends network, whatever, you risk infecting all these positions with malicious sorcery... Not good.
http://www.theregister.co.uk/2016/04/18/ss7_60_minutes_iphone/
http://www.cbsnews.com/news/60-minutes-hacking-your-phone/
https://www.youtube.com/results?search_query=Karsten Nohl caos
This is a real shame, really, I like Qcom and their SoCks. . . ... It's where my main familiarity lies with ARM and SoC's.. 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
threader said:
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? ( And disable the Radio/Modem in kernel , and cut the traces on the logic board, and wrap the device in tin foil, and leave it in a led box, buried under 4 feet of concrete. )
http://arstechnica.com/security/201...nes-and-networks-at-risk-of-complete-takeover
Next, QSEE, https://bits-please.blogspot.no/2016/05/qsee-privilege-escalation-vulnerability.html?m=1
A chip update might be needed as the author suggested, if a magic kernel update can't mitigate this, I'd do the required changes in the my backports hobby projects of course, but did not touch this part last time as I've not enabled encryption myself, I do a lot of kernel sorcery on the device and gazillions of reboots, It's just not practical. I'll "officially" "forum launch" the backports kernel in the coming days as I have a few goodies lined up. https://github.com/threader/kernel-copyleft-14.6.A.1.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 .
But as this stands, the device isn't safe to use on the cell networks, as far as i know, the entire Qcom based and there by the Z series is affected, along with every other Qcom device, past and current ... One can't 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 with ARM and SoC's.. 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
Click to expand...
Click to collapse
With all due respect, but neither the arstechnica nor many others know what they are talking about, not to mention that the cell tower vulnerability has already been fixed and most likely the software has already been remotely updated. With regard to Qualcomm, you cite a 2015 vulnerability which also has been fixed. Qualcomm is better than other chip makers. They regularly post security advisories and fixes. Take a look here: https://www.codeaurora.org/projects/security-advisories
Regarding android code, if the rom is built with 4.9 or higher tool chain and developer enabled stack_protection-strong flag, most buffer overflows are prevented...
Regarding basebands: nobody knows what's going on there, because they are all closed source. So, to take advantage of potential vulnerabilities, one must be a state actor...
Heya Opti.
https://github.com/programa-stic/security-advisories/tree/master/ObjSys/CVE-2016-5080 , if you research the issue, the fault lies in a widely used library used by a myriad of manufactures regarding the cell system vulnerability, if you keep reading, the fault is of a nature and in equipment which might be in remote locations and not easily updated, and in the case of the use in cell phones, it will require a modem f/w update, which is as you say, closed source and not something we can patch. Hence why i am asking if radio updates from Z2 or others can be applied to our Z1.
Currently the assumption is that it requires a state actor, but in reality this will, if you research it, it requires access to the signalling system, with enough resources, say a multi billion million dollar one, a chain can be created where this actor can access systems where this fault can be exploited. And what's to say there isn't a mass exploitation of the flaw from even state actors. The flaws is assumed to now be complicated and resource demanding to exploit, thats not to say that down the line, or for all we know, some wise smart soul out there hasn't made the attack trivial even long before the flaw was disclosed. Point is , it exists, it's as bad as it gets, and we might as well be using windows 95 with no firewall directly connected to the world wide interweb.
Cheers
optimumpro said:
With all due respect, but neither the arstechnica nor many others know what they are talking about, not to mention that the cell tower vulnerability has already been fixed and most likely the software has already been remotely updated. With regard to Qualcomm, you cite a 2015 vulnerability which also has been fixed. Qualcomm is better than other chip makers. They regularly post security advisories and fixes. Take a look here: https://www.codeaurora.org/projects/security-advisories
Regarding android code, if the rom is built with 4.9 or higher tool chain and developer enabled stack_protection-strong flag, most buffer overflows are prevented...
Regarding basebands: nobody knows what's going on there, because they are all closed source. So, to take advantage of potential vulnerabilities, one must be a state actor...
Click to expand...
Click to collapse
Woosh, good thing I enabled all crypto option in my Kernel....
The only thing we can do now on baseband is to edit it with NV tools. But not much.....
Testing Z2/Z3 modem/baseband fw sounds good, make sure to use both baseband img and fw files in system/etc/firmware....
Goodness, its worth a shot if nothing else, or this becomes a dev phone with no function but night time radio and certain apps . Might as well drop Android all together and use it as a micro laptop with a proper linux on if this stands. And that's a shame cause i really like it, and i can run apps as root on it, so i know if im being messed with. At least the phone should boot with the wrong radio firmware. Certainly someone has more experience with the z2 etc fw then me. I managed to update the bootlaoder when i stuck to 4.4 to boot the 3.10 kernel and such and risked bricking my phone like that, but it worked, just a matter of reading and really understanding what you're doing before prepping and flashing the device. Question is if it pukes due to being for a different device? Maybe if its similar enough we could binary patch our radio fw with the update for z2? Have these received the Radio fix for this serious fault at all yet anyway?
BlackSoulxxx said:
Woosh, good thing I enabled all crypto option in my Kernel....
The only thing we can do now on baseband is to edit it with NV tools. But not much.....
Testing Z2/Z3 modem/baseband fw sounds good, make sure to use both baseband img and fw files in system/etc/firmware....
Click to expand...
Click to collapse
You're welcome to try this, https://github.com/threader/kernel-copyleft-14.6.A.1.xxx-backports , got too late , so i need to test it tomorrow.
https://github.com/threader/kernel-copyleft-14.6.A.1.xxx-backports - not sure i did selinux correctly as Sony touched it. Gonna try implementing the new rnd device and some other network improvements ( buffer fixups ) which was submitted as a patch to the kernel recently. I'll bet my left toe nail there are problems compiling though, i nearly fell asleep preparing the commit from a WIP i had laying around.
Edit: Bah, i broke something, i got past this before i started putting the changes into the stable published backports, mainly the neon optimized aes/sha in arch/arm/crypto/ - damned thing compiled with in my experimental kernel...
optimumpro said:
With all due respect, but neither the arstechnica nor many others know what they are talking about, not to mention that the cell tower vulnerability has already been fixed and most likely the software has already been remotely updated. With regard to Qualcomm, you cite a 2015 vulnerability which also has been fixed. Qualcomm is better than other chip makers. They regularly post security advisories and fixes. Take a look here: https://www.codeaurora.org/projects/security-advisories
Regarding android code, if the rom is built with 4.9 or higher tool chain and developer enabled stack_protection-strong flag, most buffer overflows are prevented...
Regarding basebands: nobody knows what's going on there, because they are all closed source. So, to take advantage of potential vulnerabilities, one must be a state actor...
Click to expand...
Click to collapse
threader said:
You're welcome to try this, https://github.com/threader/kernel-copyleft-14.6.A.1.xxx-backports , got too late , so i need to test it tomorrow.
https://github.com/threader/kernel-copyleft-14.6.A.1.xxx-backports - not sure i did selinux correctly as Sony touched it. Gonna try implementing the new rnd device and some other network improvements ( buffer fixups ) which was submitted as a patch to the kernel recently. I'll bet my left toe nail there are problems compiling though, i nearly fell asleep preparing the commit from a WIP i had laying around.
Edit: Bah, i broke something, i got past this before i started putting the changes into the stable published backports, mainly the neon optimized aes/sha in arch/arm/crypto/ - damned thing compiled with in my experimental kernel...
Click to expand...
Click to collapse
You don't need Sony and you don't need CM to keep on top of security updates (they are actually quite behind on this). All you need is Google gerrit, Google Security Bulletin and Code Aurora Security Advisories. These 3 sources have it all. Both Sony and CM take most everything from these 3 sources. In addition, about 80% of commits from 3.10 kernel are portable to 3.4 without problems.
Sony blobs: with regard to rhine devices, there is virtually no development. If you look at blobs that they occasionally update, the rhine files they include in their "updates", especially for LP, are just copies from prior releases, as can be seen by time stamps.
Baseband: I am pretty sure that no baseband from Z2 or Z3 would ever fit Z1... We are just out of luck here, but targeting baseband costs thousands if not millions of $. So, if you are concerned about these, throw your phone away and run for a country that has no extradition treaty with your country..
Removed person (nickname) nickname, if the person wishes to identify, person can do this if person so wishes. I can say the person was involved in the Xperia project early, open source team if memory serves, but its not up to me to decide weather or not he wishes to be mentioned here by identifier.
IRC Log snippet:
---
<nickname> thredur: for the first issue, just enable airplane mode, for the second disable qsee in the kernel and enjoy life without drm and whatnot
<thredur> nickname, ok, thats no problem, true, airplane mode is one solution , so there is no patch for the radio for any devices?
<thredur> yet
<nickname> thredur: no idea what the status is on upgrades for that stuff
<nickname> thredur: but i can only presume that there's plenty devices out there that will never get any patches for these issues
<thredur> that's my assumption as well. but the radio part is very/rather similar between certain revisions i would think? except of course if not a new standard is implemented or big bad bus changes have happened
<thredur> i'm really very blank on the radio modem part
<thredur> but hey, people have been binary patching bits of the Amiga 68k's for years, and bios stuff in peecees' it should/would probably not be unimpossible to figure out the effected part and between two updates on the same device and patch the change into a similar but not officially supported device
<thredur> oh well, the z1 is a good development device anyway.
<nickname> that's totally doable, if you find a way around the firmware signature checker
<thredur> hum, yeh, i think open devices, or unlocked like our near and dear z1 would just flash that?
<nickname> flash, no problem...but it won't boot the modem
<thredur> i dont think i'd risk bricking the device if i flash the wrong radio image , no ?
<thredur> exactly
<nickname> the z3 modem will run just fine on z1, but it's not certain that you have any modem functionlity left and i would suggest you have a good backup of everything...
<thredur> ah, of course, i use the z1 as a second device
<thredur> but thanks, thats certainly supported , the z1
<thredur> err z3
<nickname> but who knows what issues you have in that modem
---
I implemented some ASM AES/SHA neon optimized code I found over at Codeaurora, only change really I made is for it to compile with Linaro; ( KBUILD_AFLAGS :=$(KBUILD_AFLAGS:-msoft-float=-Wa,-mfpu=neon-vfpv4 -marm -mfloat-abi=soft) added to arch/arm/crypto/Makefile ).
Getting close to a release now! Cheers fellow tinkerers, coders and hobby coders!
I messed up some selinux stuff just now earlier, so reverting that to the original kernel-copyleft-14.6.A.1.xxx compile and ought work, it's too late for me to test today, but it's ready to be butchered but others
From config to give you an idea.
Code:
+CONFIG_KERNEL_MODE_NEON=y
+CONFIG_CRYPTO_AES_ARM=y
+CONFIG_CRYPTO_ALGAPI=y
+CONFIG_CRYPTO_AES=y
+CONFIG_CRYPTO_ALGAPI2=y
+CONFIG_CRYPTO_SHA1_ARM_NEON=y
+CONFIG_CRYPTO_SHA512_ARM_NEON=y
+CONFIG_CRYPTO_AES_ARM_BS=y
+CONFIG_CRYPTO_SHA1_ARM=y
Now I just need a patch for Drumpf and Pillary, replacing it with Birdie Sanders which is clearly better for system stability.
optimumpro said:
You don't need Sony and you don't need CM to keep on top of security updates (they are actually quite behind on this). All you need is Google gerrit, Google Security Bulletin and Code Aurora Security Advisories. These 3 sources have it all. Both Sony and CM take most everything from these 3 sources. In addition, about 80% of commits from 3.10 kernel are portable to 3.4 without problems.
Sony blobs: with regard to rhine devices, there is virtually no development. If you look at blobs that they occasionally update, the rhine files they include in their "updates", especially for LP, are just copies from prior releases, as can be seen by time stamps.
Baseband: I am pretty sure that no baseband from Z2 or Z3 would ever fit Z1... We are just out of luck here, but targeting baseband costs thousands if not millions of $. So, if you are concerned about these, throw your phone away and run for a country that has no extradition treaty with your country..
Click to expand...
Click to collapse
I'm not entirely sure which forum would be most appropriate to post this under, but this seems like a decent candidate, so I'm starting here. If this would fit better somewhere else, please feel to redirect me, and/or even move the thread if appropriate. I think I've read all the appropriate sticky threads et cetera, but if I do make / am making a faux pas, please let me know.
As you're probably aware (https://www.xda-developers.com/t-mobile-att-require-volte-phone-calls-shut-down-3g/), T-Mobile is expected to shut down its non-VoLTE voice service in January of 2021. As a result, it's imperative for anyone who gets phone service through them to have a phone with working VoLTE support before that point. As that includes me, I've been looking into that.
I currently have a Samsung Galaxy S5, purchased through T-Mobile back in 2015 (if I'm not mistaken, it's a SM-G900T). There seem to be fairly solid statements that this model does support VoLTE under the stock ROM, and indeed T-Mobile support seems to think that it should be working.
I run LineageOS - specifically klte, which matches that model. I'm currently on the August 30th, 2020 "nightly" build of version 16.0 (which was the latest available for that model as of earlier today), on top of TWRP 3.3.1 (ditto). I only recently upgraded from TWRP 2.8.7 and (IIRC) LineageOS 14.1, which I'd been running since sometime in 2017 for reasons that are out of scope but I can describe briefly if desired. The upgrade was specifically in hopes that newer LineageOS would have VoLTE support options which the earlier version did not, but that seems to have been a futile hope.
After some fairly extensive digging (mostly online, but with some poking around on my own device and in my own backups et cetera), I've concluded that while it is theoretically possible to have VoLTE support on this device under LineageOS, it's likely to be effectively impossible in practice. Threads such as https://forum.xda-developers.com/galaxy-s5/devs-only/port-ims-manager-to-klte-t3551084 (not the only place I've looked, but probably the last before giving up) seem to indicate that the only way to get it to work - short of reverse engineering enough of the underlying system to be able to reimplement Samsung's closed IMS implementation for that model - would be to find a Galaxy S5 with the stock ROM and working VoLTE, and copy the appropriate files out of that and into the correct places on the LineageOS-based version of the system.
I thought I'd kept a backup of the stock ROM which my S5 came with, but I haven't managed to find any sign of it in my archives. I don't think I have any other way to get at the correct files, never mind figure out where they need to go and get them there; I certainly couldn't justify buying another S5 just to be able to extract the stock ROM.
As linked from the thread referenced above, there do appear to be, or have been, other custom ROMs for the Galaxy S5 which include - or included - VoLTE support. However, I'm otherwise quite happy with LineageOS, and don't want to switch to another custom ROM line - especially since I want to avoid the data loss that would come with wiping my phone to install another ROM, unless there's absolutely no way to avoid it.
Are there any prospects for my being able to get VoLTE working on this phone under LineageOS? If so, what would I need to do to manage that, within the January deadline?
If not, or if what prospects there are don't pan out, I'm going to need to acquire a new smartphone which will be able to have VoLTE under LineageOS, and preferably one which will at least approximate meeting the other criteria which led me to select the Galaxy S5 in the first place and stick with it all this time. In particular, A: I all but insist on a conveniently user-swappable battery (I carry at least one fully-charged spare in my back pocket at all times), not so much for field battery life extension as to be able to replace the battery rather than the phone when the battery inevitably bloats and dies (I'm on something like my seventh battery for this S5), B: I really like having separate dedicated "home", "back", and (for lack of a better term) "active applications list" buttons, and the only model I know for sure has them is the S5 itself, and C: I very much want to have a traditional headphone jack. Expandable storage, in the form of a suitable SD-card slot, would also be nice but is not strictly required.
What models can I expect to be able to get VoLTE working on under LineageOS, with good support in other regards, within that January deadline? The model-support information I've been able to find in searching thus far does not seem to provide any clear indication on this point.
I don't expect recommendations on what smartphone models will be able to also meet my other criteria, although of course it would be nice; that would probably fit better under the "what phone should I buy next?" thread over in General Q&A.
No chance for adding volte. It's utopic to believe you could eben keep you phone setup.
You don't share your reason for using lineageOS. If it's about avoiding preinstalled apps, you can instead debloat stock rom.
kurtn said:
No chance for adding volte. It's utopic to believe you could eben keep you phone setup.
Click to expand...
Click to collapse
I was afraid of that, but I did still have some hope.
Is that klte/S5-specific, or is it a more general statement about LineageOS at large, which holds true regardless of phone model?
If the latter, then LineageOS is soon to become unusable for anyone with T-Mobile service, which seems like a major problem that people would already be working actively to try to correct. (I also think I heard that other providers may make a similar change, which would make the problem more widespread; I specifically half-remember articles about AT&T in that regard. No concrete backup for that at the moment, though.)
If the former, then what phone models are there for which VoLTE does or can readily be made to work under LineageOS?
kurtn said:
You don't share your reason for using lineageOS. If it's about avoiding preinstalled apps, you can instead debloat stock rom.
Click to expand...
Click to collapse
I'm a little surprised that the reasons would even be asked about, given that this is a LineageOS-specific forum; I wouldn't expect the people here to be up for directing people away from LineageOS to other ROMs.
My original impetus for using LineageOS (at the time, CyanogenMod) was simply one of principle about avoiding proprietary software and vendor lock-in/lockdown/et cetera. I also like the ability to control updates on my own, both in terms of being able to determine when I update to a new version and of being able to continue to get updates independent of whether the manufacturer/carrier/etc. continues to release them.
Avoiding preinstalled apps is certainly one aspect of it, but it's by no means the only one.
I also doubt that I could simply debloat the stock ROM, for the simple reason that I don't think I *have* the stock ROM - or if I do, it's years out of date (as I said, 2015). I left a search running overnight, and on that basis have managed to find the backup copy of the stock image that was on the phone when I received it, but unless trying to extract the necessary stack components for VoLTE support from it might be viable after all I don't know how useful that will turn out to be.
(I'm probably going to invest some time into looking into that today, anyway, but I don't really expect to get any results out of it.)
Alias Bongo said:
I was afraid of that, but I did still have some hope.
Is that klte/S5-specific, or is it a more general statement about LineageOS at large, which holds true regardless of phone model?
If the latter, then LineageOS is soon to become unusable for anyone with T-Mobile service, which seems like a major problem that people would already be working actively to try to correct. (I also think I heard that other providers may make a similar change, which would make the problem more widespread; I specifically half-remember articles about AT&T in that regard. No concrete backup for that at the moment, though.)
If the former, then what phone models are there for which VoLTE does or can readily be made to work under LineageOS?
I'm a little surprised that the reasons would even be asked about, given that this is a LineageOS-specific forum; I wouldn't expect the people here to be up for directing people away from LineageOS to other ROMs.
My original impetus for using LineageOS (at the time, CyanogenMod) was simply one of principle about avoiding proprietary software and vendor lock-in/lockdown/et cetera. I also like the ability to control updates on my own, both in terms of being able to determine when I update to a new version and of being able to continue to get updates independent of whether the manufacturer/carrier/etc. continues to release them.
Avoiding preinstalled apps is certainly one aspect of it, but it's by no means the only one.
I also doubt that I could simply debloat the stock ROM, for the simple reason that I don't think I *have* the stock ROM - or if I do, it's years out of date (as I said, 2015). I left a search running overnight, and on that basis have managed to find the backup copy of the stock image that was on the phone when I received it, but unless trying to extract the necessary stack components for VoLTE support from it might be viable after all I don't know how useful that will turn out to be.
(I'm probably going to invest some time into looking into that today, anyway, but I don't really expect to get any results out of it.)
Click to expand...
Click to collapse
I think your chances for volte are better if you change from samsung to motorola.
kurtn said:
I think your chances for volte are better if you change from samsung to motorola.
Click to expand...
Click to collapse
That's unfortunately fairly vague, as a basis for going out and buying a smartphone.
What I'm looking for in terms of "VoLTE does or can readily be made to work under LineageOS" is something for which a statement like one of the following can be made:
"Yes, VoLTE works on this model under LineageOS out of the box; you don't need to do anything special to get it working, just flash LineageOS and go."
"Yes, it's possible to get VoLTE working on this model under LineageOS; here's what you need to do to get it working, beyond just flashing LineageOS."
Do you know of any specific smartphone models for which you can make one of those statements?
While I'm not against investigating and experimenting and trying things out to get things to work, and in fact sometimes that can even be fun, I do not want to do that in a production environment - and I'm under deadline (albeit with a few months to go), with limited resources for experimenting (in the form of money to buy smartphones which might work), before this becomes a critical production environment.
(Also, I've found what look like IMS-related files in the backup copy of the stock ROM, which don't seem to exist in the LineageOS that's currently running on my phone. Depending on what they look like on further examination, I may try pulling them in and seeing if anything changes; worst-case scenario, I should just have to boot to recovery and restore a backup.)
Alias Bongo said:
That's unfortunately fairly vague, as a basis for going out and buying a smartphone.
What I'm looking for in terms of "VoLTE does or can readily be made to work under LineageOS" is something for which a statement like one of the following can be made:
"Yes, VoLTE works on this model under LineageOS out of the box; you don't need to do anything special to get it working, just flash LineageOS and go."
"Yes, it's possible to get VoLTE working on this model under LineageOS; here's what you need to do to get it working, beyond just flashing LineageOS."
Do you know of any specific smartphone models for which you can make one of those statements?
While I'm not against investigating and experimenting and trying things out to get things to work, and in fact sometimes that can even be fun, I do not want to do that in a production environment - and I'm under deadline (albeit with a few months to go), with limited resources for experimenting (in the form of money to buy smartphones which might work), before this becomes a critical production environment.
(Also, I've found what look like IMS-related files in the backup copy of the stock ROM, which don't seem to exist in the LineageOS that's currently running on my phone. Depending on what they look like on further examination, I may try pulling them in and seeing if anything changes; worst-case scenario, I should just have to boot to recovery and restore a backup.)
Click to expand...
Click to collapse
Yes. Moto e2 lte surnia has volte in LineageOS out of the box.
kurtn said:
Yes. Moto e2 lte surnia has volte in LineageOS out of the box.
Click to expand...
Click to collapse
Thanks! I'll investigate that option, then, in addition to any others that present themselves.
Alias Bongo said:
(Also, I've found what look like IMS-related files in the backup copy of the stock ROM, which don't seem to exist in the LineageOS that's currently running on my phone. Depending on what they look like on further examination, I may try pulling them in and seeing if anything changes; worst-case scenario, I should just have to boot to recovery and restore a backup.)
Click to expand...
Click to collapse
Unsurprisingly, it doesn't seem to be that simple. The files involved in this are themselves few enough, and most although not all of them don't seem to exist in the currently-running image, so they can be copied in without further ado - but there are enough references to them in other files, which either *do* exist (and so would need to be edited, in a way that leaves things compatible with both systems) or seem likely to themselves (need to) be referenced elsewhere, that the whole thing turns into a mess of cascading complexity.
Short of input from someone with expertise on IMS/VoLTE implementation from some other model, I suspect this won't turn out to be a viable avenue to pursue, at least not unless and until I have my hands on a Galaxy S5 which isn't my production phone and as such can be used for experimentation. Even then, I'll probably need to basically build my own custom ROM (or custom local build of LineageOS, at least) rather than just inserting files into a system built from an existing one.
I've looked briefly into the Moto E2, and while it does look like the newest/final models of it would support VoLTE in a way that LineageOS would plausibly be able to handle, it's also at least nearly as old as the S5 and is less capable and desirable in other ways. It'd be better than nothing, but not something I would prefer as my first choice.
I'm hoping that other people chime in with more models to suggest. As this is going to become increasingly important as more carriers shut down their 3G/2G networks, and VoLTE becomes the only way to do voice calling, I'd ideally like to see a page - possibly this thread, possibly another one, possibly a Wiki page - with as comprehensive a listing of phone models which *are* known to have working VoLTE support under LineageOS (and/or possibly other non-stock ROMs) as possible, including links to any necessary how-to directions per model and notes on any special criteria (e.g., carrier-specific support or support differences between regions or the like). I hoped something like that would already exist, given the apparent upcoming VoLTEpocalypse - but as it doesn't seem to (or at least I haven't managed to find one thus far), it wouldn't hurt to start trying to create one.
My understanding is that Verizon is apparently going to make the "VoLTE mandatory" transition in January, much the same as T-Mobile, and AT&T is planning to do it sometime in 2022. With Sprint out of the picture after the T-Mobile merger, that's basically all of the major US wireless carriers that I'm aware of, so this will be universal (at least in the USA) before too very long. Some amount of preparation to make sure the custom-ROM field will remain viable past that point would seem appropriate; I'm surprised by how little activity in that area I've been able to find thus far.
Alias Bongo said:
Unsurprisingly, it doesn't seem to be that simple. The files involved in this are themselves few enough, and most although not all of them don't seem to exist in the currently-running image, so they can be copied in without further ado - but there are enough references to them in other files, which either *do* exist (and so would need to be edited, in a way that leaves things compatible with both systems) or seem likely to themselves (need to) be referenced elsewhere, that the whole thing turns into a mess of cascading complexity.
Short of input from someone with expertise on IMS/VoLTE implementation from some other model, I suspect this won't turn out to be a viable avenue to pursue, at least not unless and until I have my hands on a Galaxy S5 which isn't my production phone and as such can be used for experimentation. Even then, I'll probably need to basically build my own custom ROM (or custom local build of LineageOS, at least) rather than just inserting files into a system built from an existing one.
I've looked briefly into the Moto E2, and while it does look like the newest/final models of it would support VoLTE in a way that LineageOS would plausibly be able to handle, it's also at least nearly as old as the S5 and is less capable and desirable in other ways. It'd be better than nothing, but not something I would prefer as my first choice.
I'm hoping that other people chime in with more models to suggest. As this is going to become increasingly important as more carriers shut down their 3G/2G networks, and VoLTE becomes the only way to do voice calling, I'd ideally like to see a page - possibly this thread, possibly another one, possibly a Wiki page - with as comprehensive a listing of phone models which *are* known to have working VoLTE support under LineageOS (and/or possibly other non-stock ROMs) as possible, including links to any necessary how-to directions per model and notes on any special criteria (e.g., carrier-specific support or support differences between regions or the like). I hoped something like that would already exist, given the apparent upcoming VoLTEpocalypse - but as it doesn't seem to (or at least I haven't managed to find one thus far), it wouldn't hurt to start trying to create one.
My understanding is that Verizon is apparently going to make the "VoLTE mandatory" transition in January, much the same as T-Mobile, and AT&T is planning to do it sometime in 2022. With Sprint out of the picture after the T-Mobile merger, that's basically all of the major US wireless carriers that I'm aware of, so this will be universal (at least in the USA) before too very long. Some amount of preparation to make sure the custom-ROM field will remain viable past that point would seem appropriate; I'm surprised by how little activity in that area I've been able to find thus far.
Click to expand...
Click to collapse
Totally agree, I'm surprised this news hasn't gotten more attention in the community. First came to mind, "ah crap, no more custom roms." (perse).
I started a thread on this on the LG v50 forums to raise awareness, hopefully there can be workarounds:
https://forum.xda-developers.com/v50-thinq/help/att-t-mobile-to-off-3g-networks-disable-t4163491
--
By forcing VOLTE, this can potentially lock out some unlocked phones and also exclude custom roms, forcing users to buy carrier branded phones. In addition, shutting down 3G and forcing 4G VOLTE will ensure that lots of customers upgrade/buy new phones when their current phone may be perfectly fine otherwise(unnecessary costs and more perfectly working phones in the land fill in vain).
IIRC, you could use a stock from on your S5 and just remove the bad parts. It's no substitute for AOSP but you got to do what you got to do. Plus it's free. The stock files should be available and you can use recovery to image your phone so you don't lose your data. That is the route I would go and can't really do on my S3.
Other phone selections are looking GRIM in terms of removable batteries, reasonable size, etc. You can look to the V20 or G5 from LG but you will have to do the above process and that is almost where I'm at. Poked and prodded rom isn't the end, I did it for years on my gS2 when AOSP couldn't get HW fully functional.
Motorola has models that do work but they are mostly sealed units and everything is really hard to find as its plastered all over XDA in posts from years ago. Do all rom links even work?
While we were sleeping people got taken over by the machine and the devs didn't know what was coming or couldn't figure out the proprietary implementations.
The question with Tmo is also, is band 12 mandatory or will other phones work on 2 and 4 and volte over that. Nobody has even asked the question. I'm going to try to be safe.
DUP deleted
So odd that such a fatal issue seems to be imminently coming without some progress being made to avert it because unneeded and dangerous 5g is crowding out 2g & 3g. The s5 and note 4 are THE gold standard of excellent screen and hardware and thus the only real choices of replaceable battery phones - the REAL reason that phone mfg force millions of phones to be tossed in the landfills - shame on them! Custom Roms provide extremely important current security updates and allow apks that are updated and no longer work on slightly older android 6 versions (chase, Starbucks, united, etc). Pretty bad to discover after factory resetting a phone that play store won't let you download current or working version.
Perhaps we can crowd fund developers to attack this looming disaster soon?
uds0 said:
So odd that such a fatal issue seems to be imminently coming without some progress being made to avert it because unneeded and dangerous 5g is crowding out 2g & 3g. The s5 and note 4 are THE gold standard of excellent screen and hardware and thus the only real choices of replaceable battery phones - the REAL reason that phone mfg force millions of phones to be tossed in the landfills - shame on them! Custom Roms provide extremely important current security updates and allow apks that are updated and no longer work on slightly older android 6 versions (chase, Starbucks, united, etc). Pretty bad to discover after factory resetting a phone that play store won't let you download current or working version.
Perhaps we can crowd fund developers to attack this looming disaster soon?
Click to expand...
Click to collapse
Attack
ＧΛËＬＤＵＶΛＬ (@[email protected])
We're in the process to backport VoLTE support to /e/OS on Samsung Galaxy S9 (Exynos). We're looking for strong expertise here. If you know some true experts in the VoLTE support field, please get in touch! (mailto: [email protected]) #VoLTE #engineering...
mastodon.social