Database Users

CDMA HERO source is now available

The devices are similar enough, maybe a Desire/Eris dev can take a look to find a root.
developer.htc.com
CDMA Hero users are getting ready to see our world turned upside down. Soo much is getting ready to happen, hope to see you get root soon!

Will the Sprint Hero kernel be the same as the one for our phone?

I can confirm that the CDMA Hero source makes reference to our device specific flag (CONFIG_MACH_DESIREC) in a couple different places (all in arch/arm/mach-msm/). It is worth noting that almost all the same references were found in the original Hero source. The only thing that has been added for our architecture alone was an isCDMA flag in what appears to be USB descriptor.
That said, I don't believe this is exactly our source. Based on hardware release timelines, I would expect to see ours within the next 1-2 months.
EDIT: Following up, I would expect to see our source contain files like: arch/arm/mach-msm/board-desirec-xxxxx.c
As currently these device-specific files (board-heroc-xxxx.c) are explicitly built in the Makefile by the CDMA Hero specific switch (CONFIG_MACH_HEROC).

pinksocker69 said:
I can confirm that the CDMA Hero source makes reference to our device specific flag (CONFIG_MACH_DESIREC) in a couple different places (all in arch/arm/mach-msm/). It is worth noting that almost all the same references were found in the original Hero source. The only thing that has been added for our architecture alone was an isCDMA flag in what appears to be USB descriptor.
That said, I don't believe this is exactly our source. Based on hardware release timelines, I would expect to see ours within the next 1-2 months.
EDIT: Following up, I would expect to see our source contain files like: arch/arm/mach-msm/board-desirec-xxxxx.c
As currently these device-specific files (board-heroc-xxxx.c) are explicitly built in the Makefile by the CDMA Hero specific switch (CONFIG_MACH_HEROC).
Click to expand...
Click to collapse
That may be true, but your biggest obstruction right now is unable to root the phone. It's possible that, although the phone section itself isn't exact, the rest of the kernel may be a match. If so, you may take a look for any vulnerabilities that you can use to root the phone.

tkirton said:
That may be true, but your biggest obstruction right now is unable to root the phone. It's possible that, although the phone section itself isn't exact, the rest of the kernel may be a match. If so, you may take a look for any vulnerabilities that you can use to root the phone.
Click to expand...
Click to collapse
We know that the CDMA Hero is vulnerable to the Bluetooth socket/sendpage local root escalation, which the Eris is not vulnerable to. That alone is enough to make me bench it for now.

how would you go about finding a kernel exploit?

laxattack said:
how would you go about finding a kernel exploit?
Click to expand...
Click to collapse
Tenacity. Deep knowledge of the linux kernel. Tracing through HTC's custom code and hoping to get lucky.
I know I'm probably not up for finding and writing my own exploit. Tracing through the VMSplice exploit was like looking at a book written in Chinese, and I don't consider myself awful at C. The bluetooth socket/sendpage bug was much more readable, but also a once-in-a-blue-moon exploit, I think. If someone else found an exploit, I think I'd be in at least an okay position to try to port and modify it to suit our needs, but that's about it.

me + linux, C, or code in general = :-( so that bubble just popped, lol, but my friend is a wiz at linux so time to send him the cdma hero source just for giggles, hey you never know

True! Just let him know that the major security holes (bluetooth/sendpage and vmsplice in particular; you'll see binaries exploiting these in the Hero forums referred to as asroot and asroot2) have already been patched for our phone. Thanks for bringing another into our fold!

[Q] THEORETICAL Unlocking Question

WARNING
The topics discussed below are THEORETICAL only, and don't imply real world feasibility.
WARNING
That being said, let me test my understanding of how the system works:
The Droid 2 has a 'locked bootloader'. This means that the kernel has an RSA signed hash. THEORETICALLY, one could break the RSA key into its two component primes to determine the private key and enable anyone to sign a kernel correctly, thereby allowing custom kernels on the device.
If this is the case, where does the eFuse technology come into play? Is it merely a means of hard wiring the correct hash into the phone?
Also, assuming the above is correct, where can one find the public key used in the RSA key pair for the Droid 2? Thank you for your time.

I actually thought of this a couple months ago, but never got around to asking, I'd like to know also.

Can anyone confirm at least the first part of my understanding? Is there a common encryption key across all devices of the same make, or does that change within models? For example, If you knew the encryption key for a single Droid 2, does that mean you know the encryption key for every Droid 2?
Again, thanks for your time.

noctolater said:
Can anyone confirm at least the first part of my understanding? Is there a common encryption key across all devices of the same make, or does that change within models? For example, If you knew the encryption key for a single Droid 2, does that mean you know the encryption key for every Droid 2?
Again, thanks for your time.
Click to expand...
Click to collapse
Think about it. If it were really that simple, don't you think the Devs would have unlocked it by now?

DeBaKai said:
Think about it. If it were really that simple, don't you think the Devs would have unlocked it by now?
Click to expand...
Click to collapse
Even using the General Number Field Sieve, which is the best known large integer factorization method currently available, it took a group of researchers 2 years to crack a 768-bit key in 2009 (look up RSA numbers). Every bit you add doubles the difficulty of the problem, meaning a 1024-bit key would be 10^77 times harder to crack. By their estimations, it will be feasible in roughly ten years time.
So no, I don't think the Devs would have unlocked it by now. And this is why this is a THEORETICAL discussion, instead of a practical one. I understand that what I am talking about is probably not possible at this time, I just want to make sure I fully understand how the manufacturers are locking down the phones. Thanks for you time.

I understand what you are saying (and for the record, your reasoning is accurate) but even theoretically it is pretty improbable (almost impossible without aid from Moto).
You could have just as easily done some research to find your answer. Although interesting, this topic is somewhat redundant.

DeBaKai said:
I understand what you are saying (and for the record, your reasoning is accurate) but even theoretically it is pretty improbable (almost impossible without aid from Moto).
You could have just as easily done some research to find your answer. Although interesting, this topic is somewhat redundant.
Click to expand...
Click to collapse
I did do research, about a weeks worth of Google searches, before I posted this. I couldn't really find any concise locations of information, so my knowledge is piecemeal at best. I just want to test my understanding of the concepts, even though it serves no practical purpose.
That being said, if you have any links to concise descriptions, I would be more than happy to see them

Fair enough. Although I think it may take a while before you get your answer.
Unfortunately, my knowledge in this particular subject is limited. I'm not going to be of any real help. Good luck with this, though.

DISCUSSION [hybridROM_MOTOfied] MoTo-nomous v0.1.0 preALPHA, stabile as RC!)

Mods: please, this is a temporary post pending moderator elevated privelege to start forking my build via proper Android Development Section, everything I post is valid and true. No mock ups. Please, do not delete this thread. It is purely education and informational pre-release details to explain down to details most but not all details, as a developer i dont just release security structure or anything deemed sensitive.
A PROJECT UNIQUE AND NEVER BEFORE UNIFIED OR ATTEMPTED SUCCESSFULY. De-Androidinzation and bulding, slipstream and super-enhancing, raising Linux core from the dead to Linux-based and minimally VM until the day comes where I can project it out to substitute it with a replacement, only as good or better performance but not cross-coding as mobility has been so confined to since the start.
Introduction: to a very genetic-autonomous and not even a contender of its class to match it
Hello Fellow co-developers. I am anything but new around here, and I've grown frustrated and impatient trying to revive my XDA credentials I've had auto saved for years and yeasrs. Please, if you find interest in what you see following A PROJECT UNIQUE AND NEVER BEFORE UNIFIED OR ATTEMPTED SUCCESSFULY. this notification, message moderators or seek to at very least a head-start as I cannot even start a thread in the appA PROJECT UNIQUE AND NEVER BEFORE UNIFIED OR ATTEMPTED SUCCESSFULY. ropriate section, due to having to create an account. I've come to a sheer intolerable irritating boredom with Android, and the fact that well, Google and relative developers, and/or mainline toolchain dev's are well, diddling and we see an entire circus from Donut to Lollipop, then when they rollover on 6, and only then...and with nothing that is cheap to meet the proper standard for the hardware it takes to not back-grade your hardware and Android base version 1.6 (DOH'NUT). Yes, such non-sense as SDcard support when the damn things are ready to evolve into the next format. Don't get me, wrong, I'm glad it made the changelog, but still a mock-up and in a developers eyes so much more could have or should be incremented to a more attainable adjustment and even features. But, this post is not about Google, Android, and a lousy slipstreamed Apps2SD knockoff repurposed as adoped storage. I've always tested roms, tweaked, modified and until I found performance, stability, and can go 2 weeks without losing 40 hours of dedication getting it where she needs to be, I started porting per-say, drawing back the resource-loving java base they use in every phone regardless the base, or OS....but I have yet to see anyone shoot for the Linux-Cabal. A tip-the-scale fork of Android where rolling release and as come the updates increment, so shall the independance of too in the Android cocktail for my liking.
Let's just put it out there, I've been stabilizing and unifying a custom build (at this point for Moto ARM), and yes I know waht I am saying but to title it a ROM A PROJECT UNIQUE AND NEVER BEFORE UNIFIED OR ATTEMPTED SUCCESSFULY. would be mislabelling and a blow to what I think the OS deserves. More Linux backbone, compiled and debugged to hell and back step by step. I don't have any plan...YET to play god and cut out any serious concept such as framework, VM, but I have a goal, and a very vast plan drafted for the next quarter. I know any Linux Penguin-Dorks, and developers who know their cards and where I'd bet my bytes in any arena vs most other Os's.
History and Pre-requisuite (in order to enter and initialize a new fork officially, and establish a support system consisting of credible, daily-active and feedback producing beta-testers as well as the system and policies they will adhere to throughout initial first phase. This is not another AOSP or clone of source and hidden bugs you have to come to discover the hard way. I am offering only until another phase anyway, to primarily and MotoG3 ONLY, device dependent. push, shove and patch my tamper-resistant modules will enforce any interopibility. Remeber these are encrypted with MULTI-LAYER mutli-bit and a subset of different combination encryption algorithms and not APK, were weaning that dependence slowly but eventually here. Modules, system core hard up and real time individiual file encryption layering system. Safe from FBI and NSA and Israeli counter-parts. Included but not enforced are optional ability of IPC (Tor-lke) supreme sms, voice chat, and push to talk functionality, and among per file on top entre data drive encrypto....comms will be dual-end encrypted, obviously all of which can be enabled/disabled, configured and tweaked to ones preference.
Until I have proper authority and have enough resonsibility good-boy credits, there will be nothing. And I mean no beta program, no releases, no source code except I will move along to the next accepting Android community, which is my last thought and not at all in my interests. I am a developer 16 years, on a broad number of languages, on many arch's, from pascal, html, basic to visual basic, c, c++ C#, java, to ASM (yes Im old school, an I only dispense above and beyond what I would set as a mile stone.). All my projects in the past, creating the very first OpenGL wrapper, and utilizing a direct-injection loader that was always available in HL.exe. Primarily for Counter-Strike, as Valve global banned any cdkeys and steam accounts associated with at first any Alias nearing the format of my preferred handle. As they rolled out VAC for the first time, I watched every (neraly) system hook based all in one hacks go down as KIA-dead soldiers, while my opengl-wrapper emulated the driver, allowing my to get raw data to maipulate, block, pass-trough to the real-deal OGL.dll. My OpenGL in suspended development and without requirement to play tag with steam and losing 100 purchases of Counter-strike making a VAC-undetected, play for a day or 2 then POOF. Another good key gone up on Joolz, like his sorely lost system hook as it was spitting calls to the Windows API, the HL api, and just many easily noticed flags that his only circumventing was heading on VAC module manipulation, playing with memory in process, unloading and this damn module was live, as in every server change a slipstreamed update could be pushed and suddenly the VAC process, and all the memory offsets surgically and delicately rendered harmless. Too much working hard than the efficient smart ways I came up on. Why try and reinvent the wheel when you know the wheel is superior to date. Kid wasted his entire adolescents, and his family savings trying to serve up something that guarenteed, yes you will be the best hacker online, yes you will be detected by the end of the weekend, and the advantages well, there were none except a trial what hacking a system hook was like. As for my opengl, well at first for Valve, they did their thing wiping out the hundreds of hacks but only 1 or 2 who had stood any sort of equality to the efficacy, stability, virtual impossibilty to detect as I took a native function very seldom known and not documented, and even those who did, none had the brains to probe and go from a function with no instruction or info to the process and how to invoke and follow it through. I didn't reinvent the wheLet's just put it out there, el, but I gave it redbull-wings, titanium belts, nitrogen, and embedded withtin the system from which VAC also called home and well, all its code and dependent libraries, modules and api calls gatehered and had conferences and played golf. VAC could not for years, learn how to attack itself, and this was a fluke at first. Next I started to get out the matches, fire playin time....and i love to push buttons see where or how far i can get.
LONG story short, my very first C++ project, very atypically, was a win32 video card gfx driver, and wrapper and then put Joolz down deep, I was able to hybridize a opengl driver to bear code of no relation at all, not even close whatsoever, and without trying to break and enter a bank and crack a safe while risking setting off an alarm just to steal a 20$ bill. Get what I mean, this was at the age 0f 13. Lost my E-DEV virginity and any dev working in a windows environent, on win 98 knows that for a first project, you don't just self-teach yourself to code then start squatting and pushing out dynamic link libraries like they are ever coded to spec in MS eyes, and its just not a novice coder challenge. The following project, most of your in FTA satellite likely have heard of the latest of a technology innovated on my part and consult with few others on my FTAbins team. Also the author of the handbook aka the bible to the absolute and very well drafted, and at its time prior to increases vastly in bandwidth, it was predecessor and stepping stone for entry to IPTV. Yes Nagra2 was never cracked, it was actually a breach of trade secrets and confidential patented technology on the behalf of a disgruntled and underpaid dev who was a team lead on the the maiden of its release. For the unaware. Nagra2 is the security protecol and encryption system designed to scramble satellite television signals, as far as from my involvement only Dish Network as far as satellite, but also used and more so in europe, australia, uk and asia, on cable boxes (digital) usually those whom took input to your subscription via smart card.
But they double-time develloped and debted themselves over a exploited draft (N2) that really didnt secure a damn thing, only was a deterrant but always 24 hours behind every key roll. NKS is the patented tech, as nagra3 was exponetially much more secure and utilized 5 times the bit depth for each key, and rolled on predefined and update at randomly subscriber only pushed updates. Virtually impossible to crack, but with the aid of more advanced on completely different architechture and embedded firmware nontheless, i wasn't that intelligent i suddenly could learn 5 more instruction sets from x86. But with very little effort, and suceeding with no difficult to overcome blowbacks. Developing not an exploit, but a shadow, if you cant beat em. Join em. and that we did, nothing troubled DN ecm dev's more than trying to circumvent a system that utilized subscriber keys, and encrypted, offshored and live-streamed direct in millseconds behind a authentic event trigger, key roll or key changes and ecm's. ecm's become counter-effective when those you target are identical to your nonIKS subscribers
Thats just some history shared on 2, early on, but also serous and major accomplishments to certify and add credibility to what I claim to do and if doing this at 13 and 15 respectively, both drawing hundreds of thouseands to hundreds of millions from each of 2 entirely different classification corporations. But a thorn in both eyes while dancing circles around them, not even hitting puberty are 2 that only opened channels to knowledge, and expanding my IQ in area's and subjects I would never have thought prior,
I am not ready and urgently tryinHistory and Pre-requisuite g to put something out not prepared to dump unassessed to public, but in context I only initially had prospects of private membership availability and even that I have not authorized either. I am running an XT1540, but kicked alot of Moto framework, slipstreamed Sony framework minus the headache inducing svox, and bits and pieces of certain framework manipulation, but only in areas of absolute necessity.
Minus the not-well supported termux app and api, my build is just as extensive, with a integrated system bin directory containing apt, dpkg, a indirect but priveleged api bridge to all things android and its framework. Wifi-N enabled, 2.4ghz and 5ghz on one that only natively ever offered 2.4 G. Also, some off the books properties, I've been able to extend and further dominate the radio and modem accessibility, more specifically on UMTS/AWS bandf here in Canada on WIND. Now alot is new but I've yet to encounter very many warnings let alone any real conflicts or stability or performance setbacks. CPU is unlocked, can be volted and clocked as well as GPU, and although schedulers are there, much needs my expertise and some fine tuning before I'd even open my mind to considering it in control of fatality-potential software on another persons device.
Now, with apt and a 3 more repos than termux can match. Many would give their left nut just to have even 1/4 of the full capability (and i mean capability of all thats fully stable and operational to perfection as of right now). I had to nearly wrestle my device from a buddy of mines hands, and very promptly vacate his residence as he was dying to just get a particular build of metasploit not freely available to public, and on that part metasploit is integrated discreetly but as building block and one of many that basis the security infrastructure I am still actively forking. Stringray-safe, no prying eyes or cloning cell towers to snoop through anything private.
Currently my personal attention has me fired up towards recompiling Pale Moon custom build, and likely a entirely new browser with FF initial base but this fork of Palemoon is gecko oriented and Android API elevated privelege, it has features that even addons of chrome have yet to scratch. Capable out of the box as a IPC/Tor private browser or entire device firewalled, Tor/IPC and crypto down to the teeth. I have my own fork of recent builds of Adobe flash module, and stagefright is a secured as well. All exploitable lose ends are presently beyond par, as Android hasnt even come to that extent yet.
Anyways, I wrote this just thinking of some of my favourite features. I'll tally a list and re-post this alll in a better edited and spell-checked draft. Yes, i will post screenshots, but ONLY on request. If i have to screenshot otherwise we would all be loading alot of png files needlessly.
Xposed & MOD EDIT: warez reference removed & 3C Pro potential unified hybrid of sorts in consideration too. Pending confirmation. Also, I've been fortunate to be in possession of a Perfect-ADB i nicknamed it as it is a custom build with everything it should have plus some, and finally for right now....TWRP just makes me angry how we have 2 dozen random versions available but each has its own catch, the newer the worse it is it seems. this is unacceptable. too many builds, too many cooks in the kitchen, and off the primary source obviously. like a cocktail of suicide soda. just add 10 flavours, flash it, if it boots slap latest and DISTRIBUTE! unacceptable, this is a development resource credible well established website and name, sigh, but one thing at a time.
i will be remaining on my lonesome adding, pulling and testing my flavours and shiny sparkles with neon colors until the day i can start my devdb. and the day i do that i will immediately open up to members. with consideration of development and vetted testers prior to extensive durability and relibility testing..
Til then, mkocmut1986 @ gmail.com should you require contact.
or PM me. I got my hands full, and im but one dev as you can tell and constantly 100 new innovations to add.

Can you tell this story in short in noob language Not everyone is a developer here.

Sorry @mkocmut That was so long I skipped it... How about a tl;dr version?

@mkocmut: Well I read all the parts, all the history but one question: what was the purpose of writing all this?? BTW, great writing, enjoyed it. And yeah, I would appreciate a few screenshots if you can bother uploading some png files here, thanks.[emoji1] .
Broadcasted from Zeta Reticuli

Says: "LONG story short..."
Goes on to write 11 more paragraphs...
You're a passionate fella, I'll give you that much. Heheh, strangely enough, your post kinda made my day. (-:

A wouldn't mind u posting a link to ur beta port??

mkocmut said:
Introduction: to a very genetic-autonomous and not even a contender of its class to match it
Hello Fellow co-developers. I am anything but new around here, and I've grown frustrated and impatient trying to revive my XDA credentials I've had auto saved for years and yeasrs.
Click to expand...
Click to collapse
Would be interesting if you at least tell us what's your old username.
mkocmut said:
Modules, system core hard up and real time individiual file encryption layering system. Safe from FBI and NSA and Israeli counter-parts.
Click to expand...
Click to collapse
You totally forgot about the KGB...

THREAD CLEANED - Please don't post references to warez/software that violates XDA Rules

Wow! The room is spinning after reading all of that! It's left me with a feeling of huh? But either way I am almost certain that you are very passionate in all the above and I'm cool with that. So preach on brotha!

Good luck man. @mods : if someone quotes the whole OP, burn him!

sounds cool to unlock the cpu + gpu hope all your plans will be made possible

HelpMeruth said:
sounds cool to unlock the cpu + gpu hope all your plans will be made possible
Click to expand...
Click to collapse
How u getting on dev?

Any updates?
Sent from my SM-G900V using XDA Labs

Newyork! said:
Would be interesting if you at least tell us what's your old username.
You totally forgot about the KGB...
Click to expand...
Click to collapse
Late reply, but the KGB has been gone since the last millennium
---------- Post added at 01:02 PM ---------- Previous post was at 12:57 PM ----------
mkocmut said:
Modules, system core hard up and real time individiual file encryption layering system. Safe from FBI and NSA and Israeli counter-parts.
Click to expand...
Click to collapse
Worried about Israeli intelligence? If you're not involved in terrorism, you'll be fine, and if you are, then I'd want the Mossad to have your info.

Sounds more like drunken late night ramble than anything else. Especially since there hasn't been a peep out of him since.
Sent from my MotoG3 using Tapatalk

riggerman0421 said:
Sounds more like drunken late night ramble than anything else. Especially since there hasn't been a peep out of him since.
Sent from my MotoG3 using Tapatalk
Click to expand...
Click to collapse
We can still hope that this will ever be released right?

Sure, why not? Keep the dream alive.
Sent from my MotoG3 using Tapatalk

Hey, Whats up? :laugh:

Google confirms phones are rootable and unlockable bootloader

http://www.phonearena.com/news/The-Pixel-and-Pixel-XL-will-be-rootable-Google-confirms_id86575 for all the naysayers...google did not let us down

I did not doubt it but it is good that it is confirmed

Confused - That doesn't really make sense - While Google can (and thankfully will) make the bootloader unlockable, they don't make it rootable. They have never done that. Root is usually achieved when developers find exploits (that are unpatched by Google), and root using that.
For Google to say that the device will be rootable is like saying "we left some exploits unpatched", or "we will provide you a means of rooting" - I don't think either is true. (yes, I read the exact verbiage on the article - and saw what you are referring to)

The bootloader being unlockable is making it rootable.....that's the "exploit"....
Sent from my XT1096 using Tapatalk

tacosrdelicioso said:
The bootloader being unlockable is making it rootable.....that's the "exploit"....
Sent from my XT1096 using Tapatalk
Click to expand...
Click to collapse
Technically, no.
Regardless, glad Google confirmed that the bootloader will be unlockable (as we were expecting/hoping)

jj14 said:
Technically, no.
Regardless, glad Google confirmed that the bootloader will be unlockable (as we were expecting/hoping)
Click to expand...
Click to collapse
My point is it gets us 95% of the way there
Sent from my XT1096 using Tapatalk

The expliot is modifying the kernel. Google knows this as we do. In order to have a modified kernel you must have a unlocked bootloader. While only time will tell i believe the verizon version will never be rooted because of this new security,cause only unlocking the bootloader will allow it, hence what i believe google was getting at, sometimes people read too deep and miss whats on the surface

I think we are having a war of definitions here, so let me say a few things that I believe will clear things up:
In this context an exploit, by definition, means taking advantage of a feature in a given software or hardware platform. The word has a stigma associated with it that implies that this feature allows an unintentional effect, and that taking advantage of it gains something for the one who exploits it. E.G. a buffered array that doesn't properly safeguard writing past the allocated memory for that array would be an exploitable software feature. The exploit that takes advantage of such a feature is known as a buffer overflow exploit, which would allow an attacker to overwrite code or data at a known location in device memory, potentially allowing for arbitrary code to be executed in the context of whatever software exposes that feature.
So, an unlockable bootloader could be exploited to allow a custom kernel to run, but it would not really fit the context of "an exploit", because the feature is there to be used for that purpose. Nor, really would building a custom kernel be an exploit for the very same reason: the kernel source is provided so that it can be built and modified by anyone.

Fenny said:
I think we are having a war of definitions here, so let me say a few things that I believe will clear things up:
In this context an exploit, by definition, means taking advantage of a feature in a given software or hardware platform. The word has a stigma associated with it that implies that this feature allows an unintentional effect, and that taking advantage of it gains something for the one who exploits it. E.G. a buffered array that doesn't properly safeguard writing past the allocated memory for that array would be an exploitable software feature. The exploit that takes advantage of such a feature is known as a buffer overflow exploit, which would allow an attacker to overwrite code or data at a known location in device memory, potentially allowing for arbitrary code to be executed in the context of whatever software exposes that feature.
So, an unlockable bootloader could be exploited to allow a custom kernel to run, but it would not really fit the context of "an exploit", because the feature is there to be used for that purpose. Nor, really would building a custom kernel be an exploit for the very same reason: the kernel source is provided so that it can be built and modified by anyone.
Click to expand...
Click to collapse
Yeah what he said lol...thanks for the explantion i guess exploit is the wrong word cause it does have a negative implication

yes, even HTC devices that are unlocked and rootable is not SOFF, and you had to pay for it. Does anyone know if there is any such restriction that is "hidden"?
Is it really as "open" as the nexus devices?

Has there been any confirmation on whether or not source will be released...
Sent from my ONEPLUS A3000 using XDA-Developers mobile app

[SnapDragon] New Root/BL Methods?

So what realistically are the time frames on getting a new root and BL unlock for the snapdragon chipsets?
I ask since now the leak that happened means keys and other information are public.

Here's the thing about real security that has been properly implemented: a source leak doesn't compromise the security of the system. Thus, there is no realistic time frame, because there is no guarantee that a source leak will even result in a bootloader unlock method. A source leak will give insight into how the system works, and it might even expose a vulnerability, but even if revealed, it doesn't mean it will translate into a practical bootloader unlock method.
Imagine for example this purely hypothetical speculation: the persistent state of the OEM unlock bit, in the steady partition or wherever it is stored, is not encrypted or protected by a secure hash. While such a hypothetical vulnerability represents an attack vector, it would likely still be problematic to activate, possibly even requiring direct physical access to the device's eMMC IC.

I've seen said leak. If you're hoping for such access, I'd recommend disabling updates for a while. As far as phones are concerned, the leak goes deep. We're talking certs, signing apps, source code, even qualcomm source.
I dont imagine it will be long.

FesterCluck said:
I've seen said leak. If you're hoping for such access, I'd recommend disabling updates for a while. As far as phones are concerned, the leak goes deep. We're talking certs, signing apps, source code, even qualcomm source.
Click to expand...
Click to collapse
There is a lot there for sure. That said, the Snapdragon (cinammon) bootloader trees seem a lot lighter than the Exynos (strawberry) bootloader trees.
On the Exynos side, "SATURN/bootloader/lib/sbl_security/ddi.c implements get_oem_unlock_val() which is called in a variety of places. I'm still trying to understand the relationship between the two instances of the OEM Unlock flag, that is FROM_RPMB vs. FROM_PERSISTENT. In the case of the latter, this seems to simply be stored in the clear as the last byte in the PERSISTENT partition, where 0 means locked, and 1 means unlocked. As such, it can probably be readily written via JTAG or directly to the eMMC in a matter analogous to how the PERSISTENT partition is deleted to clear FRP state in many YouTube videos, though admittedly these both require special tools and invasive physical access.
I assume there exists at least conceptually similar implementation on the Snapdragon side, but so far I have not found it.
@Badger50 if there is a better place for this development-oriented discussion please advise or move the thread as (a) there does not seem to be a lot of development-oriented discussion in this forum and (b) it is likely not very specific to S20 devices--it is likely to apply to many recent Samsung models.

sjevtic said:
@Badger50 if there is a better place for this development-oriented discussion please advise or move the thread as (a) there does not seem to be a lot of development-oriented discussion in this forum and (b) it is likely not very specific to S20 devices--it is likely to apply to many recent Samsung models.
Click to expand...
Click to collapse
I'll move it to the "Guides and News" section since that would be the more appropriate section. Thanks for the shout out.

I'd be happy to donate to make progress. Just bought a new S20 and of course it has v2 BL. So lmk if there is anything needed.