Users Beware!
Following this reported hack of Android OS, it is now even more important check the MD5 Checksum provided with each developer's ROM against a value your system indicates for your download. This is the only way currently available to make sure you have downloaded ONLY what the developer intended for you to download. And without a little rootkit hiding somewhere within the ROM.
If MD5 Checksums are beyond you at the moment, then Google, read and learn.
You have your whole life on your phone do you really want to share it with persons unknown?
So, I've been following this thread recently and I need to ask a very basic question about some bootloader basics.
Someone referenced a post that explained the difference between locked and encrypted bootloaders but I cannot seem to find it.
From what I understand, in the simplest of terms, locked is good news and encrypted is bad news. In other words, a locked bootloader will enable us to eventually install custom ROMs from a different kernel not currently supported by the latest OTA update. Whereas with an encrypted bootloader, it is pretty much impossible to install ROMs from a different kernel and are limited to installing from the same kernel.
I'm not sure if some (if any) of the above is right.
So, I go back to check on that thread today and I notice the OP has been updated to say that the bootloader is signed is the same as either locked or encrypted? Or is it a completely different term?
I really home it's the same as a locked bootloader, but I have no idea.
If anyone has a good link describing this, or feels like explaining it themselves, it would be appreciated.
Thanks!
First of all, thanks for asking this question in General, instead of the Development section.
Encrypted means that the data payload is encrypted and cannot be decrypted without a valid private key. These days private keys are virtually impossible to decrypt in any reasonable amount of time, even with thousands of machines helping out. So there are generally two other attack vectors for this scenario:
1) someone leaks the private key, or
2) There is a weakness or flaw in the encryption algorithm that allows us to bypass the need for the private key.
Signed produces a digital signature that is computed from the contents of the payload. If one modifies the payload, the generated digital signature would no longer match and verification would fail. It's very similar to when you see md5/sha checksums for a file download.
This is a very layman's explanation of what's going on and subject to pedantic corrections . For further discussion, check out the following links:
http://en.wikipedia.org/wiki/Public-key_cryptography (Especially the section: http://en.wikipedia.org/wiki/Public-key_cryptography#Description)
http://en.wikipedia.org/wiki/Digital_signature
Hope that helps
perdurabo2 said:
First of all, thanks for asking this question in General, instead of the Development section.
Encrypted means that the data payload is encrypted and cannot be decrypted without a valid private key. These days private keys are virtually impossible to decrypt in any reasonable amount of time, even with thousands of machines helping out. So there are generally two other attack vectors for this scenario:
1) someone leaks the private key, or
2) There is a weakness or flaw in the encryption algorithm that allows us to bypass the need for the private key.
Signed produces a digital signature that is computed from the contents of the payload. If one modifies the payload, the generated digital signature would no longer match and verification would fail. It's very similar to when you see md5/sha checksums for a file download.
This is a very layman's explanation of what's going on and subject to pedantic corrections . For further discussion, check out the following links:
http://en.wikipedia.org/wiki/Public-key_cryptography (Especially the section: http://en.wikipedia.org/wiki/Public-key_cryptography#Description)
http://en.wikipedia.org/wiki/Digital_signature
Hope that helps
Click to expand...
Click to collapse
Thanks for the reply!
So, is signed better news than encrypted? Sorry for my confusion but I'm not the best with understanding this kind of stuff.
But in the mean time, I'll be checking those wikipedia articles.
qcom100 said:
Thanks for the reply!
So, is signed better news than encrypted? Sorry for my confusion but I'm not the best with understanding this kind of stuff.
But in the mean time, I'll be checking those wikipedia articles.
Click to expand...
Click to collapse
For the most part, it's better news because the payload can be examined for exploits.
PKI (public/private key crypto) is a good thing to have an understanding of because it's use is so widespread in the computing world.
perdurabo2 said:
First of all, thanks for asking this question in General, instead of the Development section.
Encrypted means that the data payload is encrypted and cannot be decrypted without a valid private key. These days private keys are virtually impossible to decrypt in any reasonable amount of time, even with thousands of machines helping out. So there are generally two other attack vectors for this scenario:
1) someone leaks the private key, or
2) There is a weakness or flaw in the encryption algorithm that allows us to bypass the need for the private key.
Signed produces a digital signature that is computed from the contents of the payload. If one modifies the payload, the generated digital signature would no longer match and verification would fail. It's very similar to when you see md5/sha checksums for a file download.
This is a very layman's explanation of what's going on and subject to pedantic corrections . For further discussion, check out the following links:
http://en.wikipedia.org/wiki/Public-key_cryptography (Especially the section: http://en.wikipedia.org/wiki/Public-key_cryptography#Description)
http://en.wikipedia.org/wiki/Digital_signature
Hope that helps
Click to expand...
Click to collapse
OK, thanks!
Finally went and made the beginnings of a general flashing guide that should eventually cover the basics of everything streak related.
forum.xda-developers.com/wiki/index.php?title=Dell_Streak/Flashing_Guide
For the time being I ask that noone directly adds to the list and instead gives me the details to add myself. As it's a wiki I cannot force anyone to do this but i WILL edit it to match the phrasing or possibly remove it if it's redundant.
It is intentionally not excessively verbose/detailed as too much additional detail is only needed if you're completely new to flashing/messing with software.
It doesnt handhold your way though flashing stuff, if you dont know how to use the command line you should NOT be flashing roms as when you brick you only have your self to blame for not having the needed prereq ability pc wise.
It also only covers windows as I only work/dev on windows, if anyone on *nix/osx wants to give me the OS specific details i'll go ahead and add it
It's also missing most of the details on how to use QDL tool as i've never used it or needed it. I need someone to add/help me add the details in the same guide style without handholding users though using it
It's also very generic as installing most roms dont have specific requirements to them (excluding setting up SD's install.txt which is it's own thing)
it does NOT and will not cover using automated tools such as Gingerbreak or mutlirecovery flasher as automated tools ultimately mean that you do not wish to read the instructions on how to do it properly. (on the streak at least) (no offense to respective makers)
edit: it should also NEVER contain links to the forum and especially "read this post to do xxx" stuff, it should be more or less self contained except with regards to downloading files, which should either be direct links (preferably not on a filesharing site like multishare/etc) or links to another section of the wiki containing links
I know there's a couple users about with compiled guides but I cant recall who/which offhand as I dont need them myself. I'd like your input whoever you are
Great job!
Sent from my Inspire 4g using XDA Premium App
I have added some comments on the talk/discussion page on the wiki. If there is any specific topic you need help on in the wiki let me know.
TheManii said:
Finally went and made the beginnings of a general flashing guide that should eventually cover the basics of everything streak related.
forum.xda-developers.com/wiki/index.php?title=Dell_Streak/Flashing_Guide
For the time being I ask that noone directly adds to the list and instead gives me the details to add myself. As it's a wiki I cannot force anyone to do this but i WILL edit it to match the phrasing or possibly remove it if it's redundant.
It is intentionally not excessively verbose/detailed as too much additional detail is only needed if you're completely new to flashing/messing with software.
It doesnt handhold your way though flashing stuff, if you dont know how to use the command line you should NOT be flashing roms as when you brick you only have your self to blame for not having the needed prereq ability pc wise.
It also only covers windows as I only work/dev on windows, if anyone on *nix/osx wants to give me the OS specific details i'll go ahead and add it
It's also missing most of the details on how to use QDL tool as i've never used it or needed it. I need someone to add/help me add the details in the same guide style without handholding users though using it
It's also very generic as installing most roms dont have specific requirements to them (excluding setting up SD's install.txt which is it's own thing)
it does NOT and will not cover using automated tools such as Gingerbreak or mutlirecovery flasher as automated tools ultimately mean that you do not wish to read the instructions on how to do it properly. (on the streak at least) (no offense to respective makers)
edit: it should also NEVER contain links to the forum and especially "read this post to do xxx" stuff, it should be more or less self contained except with regards to downloading files, which should either be direct links (preferably not on a filesharing site like multishare/etc) or links to another section of the wiki containing links
I know there's a couple users about with compiled guides but I cant recall who/which offhand as I dont need them myself. I'd like your input whoever you are
Click to expand...
Click to collapse
Thanx!
I had a problem with Zune update of samsung focus i917and tried to restore as suggested. I got a bricked phone. I need to try downloading the following file: i917-Focus-firmware-UCJK2-ATT-USA.exe to try and get the phone to be updated and functioning, but I cannot find the file anywhere. XDA has some links for the file, but they have been hijacked by B...S websites. Does anyone know where to find the file? I have searched, but have gotten a bunch of websites that want you to download a bunch of crappy software, but never provide the actual file.
Bill
Please see my post here. I've just tested both mediafire and digzip (you just need to wait 30).
If you use the MediaFire links, be sure to download BOTH parts of the ROM you want. I had to break them into two pieces due to the limitations of MediaFire. Then Run the First part to extract the ROM files. Also, you may need the Samsung Drivers if you have not installed them previously. It is also included in that link.
So after reading about all the App Store hacks that have developed around Fiddler2, I decided to give it a go myself. After setting up the proxy, I noticed that most SSL-based transactions were failing to connect on my device (Windows Updates, Email, etc).
I exported the SSL cert that fiddler 2 installed on my development PC, emailed it to myself, and installed it on my Windows Phone device. LO and Behold, Most of my SSL issues went away! (App store still woudn't auth). More Interestingly, Windows Updates started checking for updates successfully. These transactions are done with SOAP calls.
The basic process is as follows:
1. Phone initiates a connection to the windows update server
2. a series of cab files are downloaded containing certificate and base URL info of the update server
3. the phone connects to the update server with a list of all updates it has installed as well as a unique device identifier.
4. the server responds with a list of updates that it wants the phone to evaluate.
5. If the phone decides it needs the update, it sends a request to the server for instructions to deter
6. the server responds with a specially crafted packet that contains a link to where the microsoft cab can be downloaded from as well as a checksum of the cab file and evaluation instructions to determine if the update is needed. (checking registry keys, etc the SOAP commands contain things like RegRead32)
7. the phone then downloads and installs the update, if needed.
Fiddling around with fiddler, I was able to remove the "filter" GUID from the phones request to the server. As a result, it evaluated and installed any update it could get its hands on. The Hardware Test app still shows that my last update was 5/1/2013, but the number of updated packages included in that update jumped from 83 to 200!
I have some more experiments I would like to try (such as trying to blindly write a reg key instead of just reading it...anyone know of a good one?). I am also wondering if I can somehow package a Microsoft cab file, and tell the update mechanism to download and install it. Depending on how it evaluates the cabs, I might be able to get away with signing the cab with the private key from the Fiddler certificate I installed.
Just thought I'd pass along
Very, very nice finds! I had noticed the cert pinning used on the store and on dev-unlocking, but apparently had failed to look into the update process.
Give me a little while and I'll find you the reg key used for dev-unlock. I can't guarantee you that I'll be able to give you the exact value you need - they seem to have changed the format since WP7, and I'll be working blind from templates and policy files here - but it's worth a shot. Mind you, I wouldn't be surprised if the whole process is read-only, or if the responses from Microsoft are signed (although you could try re-signing them, I guess). For what it's worth, creating an entire update from scratch (or even editing one) is unlikely to work; Windows has required a Microsoft signature (not just any trusted signature) on update files for many years now. It's certainly possible that they messed that up, though.
I also kind of want to see if some of the recent ZIP signature validation bypass exploits from Android (where you could create a ZIP file containing multiple files that have the same name, and the original would be used for the signature but the *last* copy of each file would be the one actually unpacked) might be made to work as well. I've got some ideas about that... not sure if it would work for the update format, though.
Please keep researching this!
Not that i seriously looked into that, but you may probably consider these entries as interesting
Code:
[HKEY_LOCAL_MACHINE\Software\Microsoft\DeviceReg\Install]
"MaxUnsignedApp"=DWORD:A
[HKEY_LOCAL_MACHINE\Software\Microsoft\PackageManager]
"EnableAppLicenseCheck"=dword:00000000
[HKEY_LOCAL_MACHINE\Software\Microsoft\PackageManager]
"EnableAppSignatureCheck"=dword:00000000
[HKEY_LOCAL_MACHINE\Software\Microsoft\PackageManager]
"EnableAppProvisioning"=dword:00000000
[HKEY_LOCAL_MACHINE\Software\Microsoft\.NETCompactFramework\Managed Debugger]
"Enabled"=dword:0
"AttachEnabled"=dword:1
[HKEY_LOCAL_MACHINE\Software\Microsoft\Silverlight\Debugger]
"WaitForAttach"=dword:1
Some of those might get obsolete already, though.
Though, the most interesting thing one can do with registry is enabling KD.
For what it's worth, creating an entire update from scratch (or even editing one) is unlikely to work; Windows has required a Microsoft signature (not just any trusted signature) on update files for many years now.
Click to expand...
Click to collapse
Yeah
I've never really looked at the fact: which certificate is used by actual cabs? look at *.cat file
GoodDayToDie said:
Very, very nice finds! I had noticed the cert pinning used on the store and on dev-unlocking, but apparently had failed to look into the update process.
Give me a little while and I'll find you the reg key used for dev-unlock. I can't guarantee you that I'll be able to give you the exact value you need - they seem to have changed the format since WP7, and I'll be working blind from templates and policy files here - but it's worth a shot. Mind you, I wouldn't be surprised if the whole process is read-only, or if the responses from Microsoft are signed (although you could try re-signing them, I guess). For what it's worth, creating an entire update from scratch (or even editing one) is unlikely to work; Windows has required a Microsoft signature (not just any trusted signature) on update files for many years now. It's certainly possible that they messed that up, though.
I also kind of want to see if some of the recent ZIP signature validation bypass exploits from Android (where you could create a ZIP file containing multiple files that have the same name, and the original would be used for the signature but the *last* copy of each file would be the one actually unpacked) might be made to work as well. I've got some ideas about that... not sure if it would work for the update format, though.
Please keep researching this!
Click to expand...
Click to collapse
Will do! Here is where it gets interesting...The attached screenshots are of a SOAP request from my phone to the update server (I disabled filtering, so the GUID isn't present) and then it's response for "missing" updates to evaluate.
the section labeled "xml" contains the instructions on how to evaluate if the update is needed.
here is a cleaned up, friendly dump of what is in the "XML" section it needs to parse to determine if an update is applicable:
Code:
<UpdateIdentity UpdateID="f092f820-8161-410b-ab11-c7a6d36b7837" RevisionNumber="101" />
<Properties UpdateType="Software" />
<Relationships>
<Prerequisites>
<UpdateIdentity UpdateID="eb644fbf-5e6e-4719-b97c-485ffb9e867f" />
<AtLeastOne>
<UpdateIdentity UpdateID="450b8808-d056-4c18-a383-2db11e463eb0" />
</AtLeastOne>
</Prerequisites>
</Relationships>
<ApplicabilityRules>
<IsInstalled>
<CspQuery LocUri="./DevDetail/SwV" Comparison="GreaterThanOrEqualTo" Value="9.0.0.0" xmlns="http://schemas.microsoft.com/msus/2002/12/MobileApplicabilityRules" />
</IsInstalled>
<IsSuperseded />
<IsInstallable>
<And xmlns="http://schemas.microsoft.com/msus/2002/12/LogicalApplicabilityRules">
<CspQuery LocUri="./DevDetail/SwV" Comparison="LessThan" Value="9.0.0.0" xmlns="http://schemas.microsoft.com/msus/2002/12/MobileApplicabilityRules" />
<b.RegSz Key="HKEY_LOCAL_MACHINE" Subkey="Software\Microsoft\Windows\CurrentVersion\DeviceUpdate\Agent\Protocol" Value="TestTarget" Comparison="EqualTo" Data="72c5dc6d-00a9-412f-9d13-f4f483f2ed7f" xmlns="http://schemas.microsoft.com/msus/2002/12/BaseApplicabilityRules" />
</And>
</IsInstallable>
</ApplicabilityRules>
an interesting URL with info from someone else that was looking into this for Win7...
http://withinwindows.com/2011/03/06/notes-on-windows-phone-7-update-process-thus-far/
I wonder if we can figure out what "updates" are actually required if we can trick the server into giving us more OOB updates/othercarrier updates/updates we aren't "supposed" to have..
Found some info on the "Evaluate" action:
Action: The action that clients in the specified target group will perform on this revision: Install, Uninstall, PreDeploymentCheck (which means that clients will not offer the update, just report back on the status), Block (which means that the update will not be deployed, and is used to override another deployment), Evaluate (which means that clients will not offer the update and will not report back on the status), or Bundle (which means that clients will not offer the update for install; it is only deployed because it is bundled by some other explicitly deployed update).
Click to expand...
Click to collapse
source:
http://msdn.microsoft.com/en-us/library/cc251980.aspx
I was also messing with fiddler and I noticed my phone access two different places when a phone update is selected. One of the pages is: http://ds.download.windowsupdate.com/wp8/MicrosoftUpdate/Redir/duredir.cab . In that cab is this file wuredir.xml and consists of:
<?xml version="1.0"?>
<WuRedir xmlns="http://schemas.microsoft.com/msus/2002/12/wuredir" redirectorId="1002">
<Protocol
elementVersion="1"
clientServerUrl="https://fe1.update.microsoft.com/v6/"
reportingServerUrl="http://statsfe1.update.microsoft.com/" />
</WuRedir>
the second page accessed is: http://fe1.update.microsoft.com/WP8/MicrosoftUpdate/Selfupdate/5_UssDetection.dll
I hexed the .dll after download and found some download links to some cert files, which are:
Microsoft Windows Phone Production PCA 2012.crt
http://www.microsoft.com/pkiops/certs/Microsoft Windows Phone Production PCA 2012.crt
MicRooCerAut_2010-06-23.crt
http://www.microsoft.com/pki/certs/MicRooCerAut_2010-06-23.crt
MicTimStaPCA_2010-07-01.crt
http://www.microsoft.com/pki/certs/MicTimStaPCA_2010-07-01.crt
can any of this info help us?
If either that DLL or any of those certificates are not signed (highly unlikely, but worth checking), or if the DLL doesn't enforce the signature check (extremely unlikely), or if any of the certs include the private key or use a weak hash algorithm or a short key... maybe. I checked the certs, though; they at least are clean. Nothing useful that I saw.
Reverse engineering the DLL may be useful, but it's probably native code and therefore a pain to decompile.
aclegg2011 said:
I was also messing with fiddler and I noticed my phone access two different places when a phone update is selected. One of the pages is: http://ds.download.windowsupdate.com/wp8/MicrosoftUpdate/Redir/duredir.cab . In that cab is this file wuredir.xml and consists of:
<?xml version="1.0"?>
<WuRedir xmlns="http://schemas.microsoft.com/msus/2002/12/wuredir" redirectorId="1002">
<Protocol
elementVersion="1"
clientServerUrl="https://fe1.update.microsoft.com/v6/"
reportingServerUrl="http://statsfe1.update.microsoft.com/" />
</WuRedir>
the second page accessed is: http://fe1.update.microsoft.com/WP8/MicrosoftUpdate/Selfupdate/5_UssDetection.dll
I hexed the .dll after download and found some download links to some cert files, which are:
Microsoft Windows Phone Production PCA 2012.crt
http://www.microsoft.com/pkiops/certs/Microsoft Windows Phone Production PCA 2012.crt
MicRooCerAut_2010-06-23.crt
http://www.microsoft.com/pki/certs/MicRooCerAut_2010-06-23.crt
MicTimStaPCA_2010-07-01.crt
http://www.microsoft.com/pki/certs/MicTimStaPCA_2010-07-01.crt
can any of this info help us?
Click to expand...
Click to collapse
Those are the first steps in the update process. Basically, it gets the certs that it will use for validation and server communication. then the CAB file contains the info on what servers are used for Windows Update communications. It then logs that a request has been made to the tracking server. After that, it gets a list of updates from the v6 address. If there are no updates, Once the update process is complete, it logs the result to the tracking server.
Do you guys think I could use this to fix the problems I seem to have when trying to stream or download music from Xbox Music? I get a lot of errors, or this song can't be played on your device and some times the app crashes. I have had this problem since I switch from my Windows Phone 7 device to my Nokia Lumia 920, and I am on my 4th 920. I think for some reason the Music store is getting botched certificates or something.
Kind of on the same subject. anyways i extracted around 140 Certificated from a HTC 8x Ruu. then installed them to my pc. Which is windows 7. The cool part was i was able to install windows phone sdk 8 and 8.1 with emulators and visual studio 2013. which i though all of these were not possible to run on windows 7. all because of certificates from a rom.