Some thoughts about efuses.... - Motorola Droid and Milestone General

Hi fellas,
i must admit that i'm really impressed by the energy that has been put into the BOINC project, to hunt for the Motorola private certs to crack the RSA key inside OMAP3430.
From the M-shield white paper:
Code:
...
For example, secure on-chip keys (E-Fuse) are OEM-specific, one-time-programmable
keys accessible only from inside the secure environment for authentication and encryption.
...
More specific information here:
https://www.droid-developers.org/wiki/EFuse
What would happen, if we slip into the role of the OEM's?
To be more precisely what happens, if...
a) we disable VFUSE power domain (VPP rated @ 2.4V/50mA, connected to APE_VPP and DBB_VPP)?
b) we use eFuse programming algorithm in mbmloader to blow additional eFuse and enter engineering mode?
(what is the hash for engineering mode?)
c) we use read routines within mbmloader to read eFuse values?
d) we blow all remaining efuse for the 160-bit hash in the user programmable area (factory default on milestone = 1d3fb662 794d8c70 fb57b4cb 492e27f6 6f152e4f)?
(result would be a OEM value of 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF)
Perhaps we'll never know...
Here's what i think:
a) Barely no effect, apart from preventing mbmloader to blow another e-fuse.
b) Maybe the whole mbmloader code could only be accessed from within security domain, not sure if a debugger would work here.
c) Same as above. There had to be a proof of concept that mbmloader routines could be executed.
d) See b) and c). We need the correct offset, of course.
Any comments welcome.
IMHO there might be a better chance to crack the security on Milestone, if the interest would be focussed on mbmloader disassembly and further investigation on JTAG access for debugging the platform more intensely.
If you're a technical geek, you might have a look over here:
http://forum.xda-developers.com/showthread.php?t=849632
Experts are very welcome!!!!
P.S.: If nothing will ever work out, there's something slightly off-topic we might think about ...
Someone should contact Mototola to follow a new marketing strategy... called: ICS (Individual Customer Support).
Customers could upload their custom kernels to Motorola and get them signed by beautiful private key!
We could also push our kernel source to Motorola and as a side effect they would fix bugs and finish firmware updates much earlier .
TBC...
EDIT: Corrected some parts...
Cheers,
scholbert

Always nice to read your posts But there is one error I think:
scholbert said:
...to crack the 128-bit RSA key inside OMAP3430...
Click to expand...
Click to collapse
I think it is a 1024Bit key or am I wrong?

TheSSJ said:
Always nice to read your posts
Click to expand...
Click to collapse
Thanks for your reply!
TheSSJ said:
But there is one error I think:
I think it is a 1024Bit key or am I wrong?
Click to expand...
Click to collapse
Not 100% sure about all this.
In fact i must admit that i'm not a cryptographic expert, but after reading all these hardware manuals and references, this is what i understand:
The hash key stored in the eFuse farm seems to be 160 Bit SHA-1 and uses 1024Bit certification.
Seems that this basically is used to verify mbmloader security.
Maybe this is bull****, so who ever got some more details please join discussion!
I really like to know at which offset the key is stored
Regards,
scholbert

So if I get this right, you want to disassemble a Milestone and mess with the circuit?

djefkbefke said:
So if I get this right, you want to disassemble a Milestone and mess with the circuit?
Click to expand...
Click to collapse
Yeah correct, first this would be hardware stuff to get JTAG to work.
It's not strictly me reaching this, in fact this addresses to a community!
See my JTAG post, there's anything you need to trace the signals
So if you got a broken device go for it!
Afterwards some cracks might use a JTAG debugger (e.g. OpenOCD) to fiddle with the bootcode: Set breakpoints, trace conditional branches, even tweak some lines of code.
The hope is that something will open another door to get access to certain memory areas, especially eFuse location would be interesting
Regards,
scholbert

There was someone on here a month or so ago that had a device without a working radio. There are probably others like him. If we manged to get someone willing to donate their non-working device, would you be willing to try your jtag on it. I don't have a jtag at this time, and although i wouldn't mind getting 'hold of one, it probably wont happen for a while.

http://forum.xda-developers.com/showthread.php?t=849632

Hey,
just stumbled over these lines in one of the Ti documents:
...
The device type is readable from an eFuse by the CONTROL.CONTROL_STATUS[10:8] DEVICETYPE
field. During booting, the ROM code checks the DEVICETYPE field to determine in which mode to
operate.
· The HS device is a production device with all security features enabled. The ROM code requires the
authentication of the Initial SW before execution. A failed authentication causes a watch-dog reset.
Authentication of code in external flash memory or code that is downloaded is handled by routines in
the secure ROM (a part of the ROM code).
· The GP device is a production device in which security is disabled. Authentication is not performed
before initial SW execution.
...
Click to expand...
Click to collapse
Just wanted to add it here for completeness
There's also some progress to understand the bootloader implementations of security functions, pushed by xvilka!
For the geeks, see here:
https://www.droid-developers.org/wiki/Security
Regards,
scholbert

additional info....
Hi,
i gathered some more information about how things work out:
- SHA1 sum of the first (root) key in the CertPK is stored in eFuse array inside SoC, accessible through PKEY 0..4 registers
- the value for the SHA1 sum has a length of 160 bits
- theoretically eFuse bits that are now zero could be blown by using Secure Service, to modify hash value
- Milestone: 1d3fb662 794d8c70 fb57b4cb 492e27f6 6f152e4f
Droid: 75ed7020 641333dd 7bc3aecb 9857683c 2422efe1
- BootRom loads root key in SecureRAM and uses Secure Service, from secure part of BootROM to verify integrity/signature
This secure part of BootRom is not accessible from non secure world.
- All main keys are stored in CertPK/SecureRAM
- In theory we could break the chain of trust with:
a) find rsa keypair where the public key's sha1sum matches the existing SHA1 sum in PKEY 0..4 registers (hash_collision)
b) modify the efuse setup with Secure Service function and alter PKEY 0..4 registers to match a given key pair (this might be a very complicated issue)
Please correct me if i'm wrong
PS: Just realized that this is my 666th post, so this is dedicated to the devil
Regards,
scholbert

The devil thanks you.

Related

[DEVS ONLY] Crack/bypass/trick Boot.img Signature

Ok, so lets get cracking on this bootloader.
boot.img and recovery.img certs (thanks to ntwrkwizard):
http://ponack.net/designgears/atrix/mmcblk0p10 - cert extract.zip
http://ponack.net/designgears/atrix/mmcblk0p11 - cert extract.zip
Flaw in the X.509 certs:
http://www.darkreading.com/security/vulnerabilities/218900008/index.html
Boot.img & Recovery.img
http://www.ponack.net/designgears/dump.7z
DG, afaik, that exploit deals with the md2 hash algorithm. it is a good possible starting point. has the signing cert been found/recovered/viewed yet?
if moto signed it with an md5 hash cert, then that may not be possible.
Well if you guys need any processing power to help crack anything let me know. I am willing to donate my system. Current specs:
i7-970 six core 4.8ghz overclocked
4 gtx580 gpus
24gb ddr3 2000
HSDL 240gb ssd
Like I said, if you guys need any processing power let me know.
Sent from my "5 inch Galaxy Tab"
Atrix here on the 22nd
dtmcnamara said:
Well if you guys need any processing power to help crack anything let me know. I am willing to donate my system. Current specs:
i7-970 six core 4.8ghz overclocked
4 gtx580 gpus
24gb ddr3 2000
HSDL 240gb ssd
Like I said, if you guys need any processing power let me know.
Sent from my "5 inch Galaxy Tab"
Atrix here on the 22nd
Click to expand...
Click to collapse
Please don't post here. This is a dev only thread. Post your offer in General.
Thanks!
These downloads look like just CA certs. Could someone extract the x.509 cert embedded in the beginning of the boot.img and post it to this thread? I'm out and about this weekend and don't have a box with a hex editor handy.
perdurabo2 said:
These downloads look like just CA certs. Could someone extract the x.509 cert embedded in the beginning of the boot.img and post it to this thread? I'm out and about this weekend and don't have a box with a hex editor handy.
Click to expand...
Click to collapse
If you could tell me how to do that I will be more than happy to get those for you. I'm the go to guy, remember?
Here is the extracted cert from within mmcblk0p10.img. This hex dump is extracted from 7FF7FC through 7FFDF9.
Also is the extracted cert from within mmcblk0p11.img. This hex dump is extracted from 7FF7FC through 7FFE79.
Not sure the value of an extracted public side of the x.509 is post signature but I'm sure someone will define that.
Good luck..
NW
back on topic please.
Mr. Clown said:
back on topic please.
Click to expand...
Click to collapse
Who are you talking to? The cert conversation is applicable.
Hi friend,
is the bootloader encrypten the same as defy or milestone?
Or a new one?
Maybe we could get all a free bootloader if this would work?
Or other technical?
Thanks
perdurabo2 said:
Who are you talking to? The cert conversation is applicable.
Click to expand...
Click to collapse
He deleted some unnecessary posts which were getting off topic. That's all.
The structure of an X.509 v3 digital certificate is as follows:
Certificate
Version
Serial Number
Algorithm ID
Issuer
Validity
Not Before
Not After
Subject
Subject Public Key Info
Public Key Algorithm
Subject Public Key
Issuer Unique Identifier (optional)
Subject Unique Identifier (optional)
Extensions (optional)
...
Certificate Signature Algorithm
Certificate Signature
Click to expand...
Click to collapse
The extensions they come in are:
pem - (Privacy Enhanced Mail) Base64 encoded DER certificate, enclosed between "-----BEGIN CERTIFICATE-----" and "-----END CERTIFICATE-----"
.cer, .crt, .der - usually in binary DER form, but Base64-encoded certificates are common too (see .pem above)
.p7b, .p7c - PKCS#7 SignedData structure without data, just certificate(s) or CRL(s)
.p12 - PKCS#12, may contain certificate(s) (public) and private keys (password protected)
.pfx - PFX, predecessor of PKCS#12 (usually contains data in PKCS#12 format, e.g., with PFX files generated in IIS)
PKCS#7 is a standard for signing or encrypting (officially called "enveloping") data. Since the certificate is needed to verify signed data, it is possible to include them in the SignedData structure. A .P7C file is a degenerated SignedData structure, without any data to sign.
PKCS#12 evolved from the personal information exchange (PFX) standard and is used to exchange public and private objects in a single file.
Click to expand...
Click to collapse
Flaws in the X509 Certificate:
Specification: Complexity and lack of quality
The X.509 standard was primarily designed to support the X.500 structure, but todays use cases center around the web. Many features are of little or no relevance today. The X.509 specification suffers from being over-functional and underspecified and the normative information is spread across many documents from different standardization bodies. Several profiles were developed to solve this, but these introduce interoperability issues and did not fix the problem.
Architectural flaws
Use of blacklisting invalid certificates (using CRLs and OCSP) instead of whitelisting
CRLs are particularly poor because of size and distribution patterns
Ambiguous OCSP semantics and lack of historical revocation status
Revocation of root certificates not addressed
Aggregation problem: Identity claim (authenticate with an identifier), attribute claim (submit a bag of vetted attributes) and policy claim are combined in a single container. This raises privacy, policy mapping and maintenance issues.
Delegation problem: CAs cannot technically restrict subCAs to issue only certificates within a limited namespaces and attribute set – this feature of X.509 in not in use. Therefore a large number of CAs exists in the Internet, and classifying them and their policies is an insurmountable task. Delegation of authority within an organization cannot be handled at all, like it is common business practice.
Federation problem: Certificate chains that are the result of sub-CAs, bridge- and cross-signing make validation complex and expensive in terms of processing time. Path validation semantics may be ambiguous. Hierarchy with 3rd-party trusted party is the only model. This is inconvenient when a bilateral trust relationship is already in place.
Problems of Commercial Certificate Authorities
Flawed business model: The subject, not the relying party, purchases certificates. The RA will usually go for the cheapest offer; quality is not being paid for in the competing market.
CAs deny almost all warranties to the user.
Expiration date: Should be used to limit the time the key strength is deemed sufficient. Abused by CAs to charge the client an extension fee. Places unnecessary burden on user with key roll-over.
Client certificates have zero protection value against dedicated attackers.
In browsers, the security is that of the weakest CA. There are very weak CAs.
“Users use an undefined certification request protocol to obtain a certificate which is published in an unclear location in a nonexistent directory with no real means to revoke it.“
Implementation issues
Implementation suffer from design flaws, bugs, different interpretations of standards and lack of interoperability of different standards. Some problems are:
Many implementations turn off revocation check:
Seen as obstacle, policies are not enforced
Would it be turned on in all browsers by default, including code signing, it would probably crash the infrastructure.
DNs are complex and little understood (lack of cononicalization, i18n problems, ..)
rfc822Name has 2 notations
Name and policy constraints hardly supported
Key usage ignored, first certificate in a list being used
Enforcement of custom OIDs is difficult
Attributes should not be made critical because it makes clients crash.
Unspecified length of attributes lead to product-specific limits
Exploits
In 2005, Arjen Lenstra and Benne de Weger demonstrated "how to use hash collisions to construct two X.509 certificates that contain identical signatures and that differ only in the public keys", achieved using a collision attack on the MD5 hash function.
In 2008, Alexander Sotirov and Marc Stevens presented at the Chaos Communication Congress a practical attack that allowed them to create a rogue Certificate Authority, accepted by all common browsers, by exploiting the fact that RapidSSL was still issuing X.509 certificates based on MD5.
X.509 certificates based on SHA-1 had been deemed to be secure up until very recent times. In April 2009 at the Eurocrypt Conference , Australian Researchers of Macquarie University presented "Automatic Differential Path Searching for SHA-1" . The researchers were able to deduce a method which increases the likelihood of a collision by several orders of magnitude.
Domain-validated certificates („Junk certificates“) are still trusted by web browsers, and can be obtained with little effort from commercial CAs.
EV-certificates are of very limited help, because Browsers do not have policies that disallow DV-certificates,
There are implementation errors with X.509 that allow e.g. falsified subject names using null-terminated strings or code injections attacks in certificates.
Click to expand...
Click to collapse
From the sound of it, the X.509 cerificate the Atrix uses will be in .p12 format, although I could be wrong.
Example of a Decoded X509 cert: http://pastie.org/1590676
Great post, this is def a way to go and explore , i have been messsing with NVIDIAFlash all day so far.. i think if i can get a bootstrap or something on here so that i can mount and add some files to system folder with phone off i may be on to something ..
t0dbld said:
Great post, this is def a way to go and explore , i have been messsing with NVIDIAFlash all day so far.. i think if i can get a bootstrap or something on here so that i can mount and add some files to system folder with phone off i may be on to something ..
Click to expand...
Click to collapse
Adding things to the system folder means nothing, the system partition is only check when a new system is flashed via (sbf_flash, rsdlite, or flashing a CG via an update.zip) otherwise you can add/remove items from the /system partition with no worries of the signatures.
I've got a question. Since we are dealing with a closed system. Can we not validate -enddate of the signed boot image. Make note of the exact date and time. Then change the system clock to less than 24 hrs. after this date. This will allow the entire system to think that the bootloader and cert have done their job and simply needs updated. Now we simply need to insert new boot.img that has a valid -startdate within that 24 hr period. The system should simply stop using the expired image and boot the "updated image". Once this generic image is booted, it can simply be swapped out with any further custom roms that we feel the need to use. Once all is done, the system clock will need to be restored to appropriate time. If I knew how to code, I would simply try this myself. But I don't, so I hope this might at least provide some insight to the possibility. I would love to work with developers on finding a solution to this problem, so feel free to ask questions.
jimmydafish said:
Adding things to the system folder means nothing, the system partition is only check when a new system is flashed via (sbf_flash, rsdlite, or flashing a CG via an update.zip) otherwise you can add/remove items from the /system partition with no worries of the signatures.
Click to expand...
Click to collapse
I 100% agree i didnt say that was the end all.... the reason for doing this is so that the computer recoginizes the device in NVIDIAFlash mode and i than can hopefully overwrite the bootloader with the dev version of bootloader.bin
t0dbld said:
I 100% agree i didnt say that was the end all.... the reason for doing this is so that the computer recoginizes the device in NVIDIAFlash mode and i than can hopefully overwrite the bootloader with the dev version of bootloader.bin
Click to expand...
Click to collapse
That will not work, the bootloader is just one piece of a longer chain..changing that out "will" just have the phone reboot and use the backup bootloader. The problem to cracking it lies in all parts. Especially the NvRam where it begins and the MBR.
jimmydafish said:
That will not work, the bootloader is just one piece of a longer chain..changing that out "will" just have the phone reboot and use the backup bootloader. The problem to cracking it lies in all parts. Especially the NvRam where it begins and the MBR.
Click to expand...
Click to collapse
I very much respect all of the work you and your team has put into this situation with other devices, and i very much appreciate the help given by you guys to this forum, and no one including myself wants to waste time, so that being said i have not seen any ideas contributed ... only negative posts on what isnt going to work, i agree that you guys know more than me on this situation perhaps if you could share some of your ideas or the approach or direction you are going i and others could be of some help. We our fresh and not quite so beat up , its like when debuging a program thats driving you nuts and you cant figure out whats going wrong , sometimes a break, sleep, etc is in order so that when you come back your whole train of thought has been altered and you see something differently because you were not looking there before.
I follow instructions well, so lead... i am willing to donate my time my resources, and more than likely my device (at least for the next 29 days )
t0dbld said:
I very much respect all of the work you and your team has put into this situation with other devices, and i very much appreciate the help given by you guys to this forum, and no one including myself wants to waste time, so that being said i have not seen any ideas contributed ... only negative posts on what isnt going to work, i agree that you guys know more than me on this situation perhaps if you could share some of your ideas or the approach or direction you are going i and others could be of some help. We our fresh and not quite so beat up , its like when debuging a program thats driving you nuts and you cant figure out whats going wrong , sometimes a break, sleep, etc is in order so that when you come back your whole train of thought has been altered and you see something differently because you were not looking there before.
I follow instructions well, so lead... i am willing to donate my time my resources, and more than likely my device (at least for the next 29 days )
Click to expand...
Click to collapse
I am not being negative just helping you all steer clear of dead ends. We are looking over some files now and may have some useful tidbits soon. I think we can tell the boot chain from start to finish.
Great!! thanks for the update... on a side note esp in loom of this whole ps3 thing i hope motorola uses the same signing keys for all devices, so that if our day ever comes its x-mas for all

Native Debian on i9000?

Hello and good day, dear XDA Developers forum members!
I have been struggling with this problem for some time and have tried to resolve it myself, but have failed miserably. Anyway, I have installed Linux Deploy from Play Store, an excellent application which automates installation of many Linux distributions on your phone made by a guy called meefik. Everything worked fine. Of course, Linux image file size was automatically calculated by the application so it took quite a lot of free space on my internal SD card. It later proved to be actually reasonable as the desktop environment and everything I installed quite filled those two gigs Linux Deploy allocated. Not quite important for this issue, but... whatever. The real problem I have encountered is the problem of digitizer input. Controlling my phone using x2x through SSH is good enough to eventually resolve some smaller problems or play Dink Smallwood (or freedink, to be exact) just for fun, but it's not quite doable and useful outdoors with no desktop or laptop nearby, so I would like to make Debian somehow recognize digitizer input. Framebuffer output without Android (it is killed by ctl.stop, I guess) and VNC assistance works pretty fine (no HW acceleration, of course, but good enough), just if there is a way to make Debian capture digitizer input, at least in a touchpad-esque way, as I still haven't bought any Bluetooth gear. I tried setting evdev as the driver to recognize digitizer input and /dev/input/event0 as the input device's path in xorg.conf, but no luck. Chroot has access to main Android file system. When cat'ing /dev/input/event0 in terminal it gives output when I tap or swipe on the digitizer, so the actual problem lies in the fact that Linux actually doesn't know to interpret informations that digitizer is sending.
Any ideas? Suggestions? If anything else, do not hesitate to let me know if I made a mistake of some kind (grammar or terminology for example) in my post.
Hooray! Digitizer input finally recognized in Debian! After chatting with pabs* on irc.debian.org I found out that evdev requires ABS_X and ABS_Y coordinates in order to move the cursor successfully around the screen, but as i9000 has a multi-touch digitizer, it sends only ABS_MT_POSITION_X and ABS_MT_POSITION_Y positions** for each finger (as well as an ID for each of them and some other relevant details). Means that evdev isn't quite useful for this purpose. We have a multi-touch digitizer and thus we need a multi-touch driver that will properly interpret our digitizer's input. After browsing through packages in synaptic, I found two seemingly appropriate multi-touch drivers, mtrack and multitouch. As mtrack is a fork of multitouch that (supposedly) brings some improvements when compared to the forkee*** I've chosen to install and set it as the input driver in xorg.conf instead of multitouch. I didn't regret, everything works perfectly! Of course, it still isn't as finger-friendly as Maemo or Android are because it works in touchpad mode, but it's quite a good beginning!
Here's the xorg.conf file (XDA didn't allow me to upload a .conf file as it's an, erm, invalid file) if anyone wants to try this on his i9000!
Code:
Section "ServerLayout"
Identifier "Layout0"
Screen "Screen0"
InputDevice "touchscreen" "CorePointer"
EndSection
Section "InputDevice"
Identifier "touchscreen"
Option "Device" "/dev/input/event0"
Driver "mtrack"
EndSection
Section "Device"
Identifier "Card0"
Driver "fbdev"
Option "fbdev" "/dev/graphics/fb0"
#Option "Rotate" "CW"
EndSection
Section "Screen"
Identifier "Screen0"
Device "Card0"
DefaultDepth 24
SubSection "Display"
Depth 24
EndSubSection
EndSection
* Who is also the author of this post, quite useful (post, not poster :laugh.
** In order to be properly recognized as a multi-touch input device by Android. ABS_X and ABS_Y are provided only if a single-touch digitizer is installed, see here
*** The one being forked, in this case multitouch. According to Google, it's a valid word, well, kind of.
P.S. I've attached a screenshot of current setup if anyone's wondering how it looks.
P.P.S. Cursor moves awkwardly when Xorg is in landscape mode (as if X and Y axes were swapped) so I commented out the Option "Rotate" "CW" line.
Progress: one step forward, two steps back
Help needed! As I might have mentioned in previous posts, cursor moves weirdly (moving finger to the left moves cursor up, moving to the right moves down, etc.) in landscape mode (i.e. with Option "Rotate" "CW" line under "Device" section uncommented), so I would like to know if there is there any way to swap X and Y axes? There have been some efforts to make X and Y finger coordinates swapped in this thread, but, unfortunately, with no actual result, because mtrack ignores the Rotate and SwapAxes options as if they were not valid for mtrack or just not implemented yet. Of course, I would prefer to have the option of absolute mouse movement (in the manner of what tslib provides) instead of having digitizer input recognized in a touchpad way, but it seems that there is something that should be modified in tslib's source code in order to make it work.
Also, I've tried to install Hildon by wget'ing Squeeze armel .deb packages and installing them through dpkg until all the dependencies were satisfied, but it still seems like there is some more missing packages that ought to be installed... so if you guys have tried installing Hildon on your Android device (not necessarily i9000) please reply here. All suggestions are welcome.
P.S. Feel free to let me know if this thread might be more appropriate in some other (sub)forum.
moorkai said:
P.S. Feel free to let me know if this thread might be more appropriate in some other (sub)forum.
Click to expand...
Click to collapse
yup, it would get better attention here and here
Check this out!You , YES! you are an " Android ". Not your phone but U.
You Must watch this documentary concerning your privacy Terms & Conditions we had agreed to, by using a PC or Smartphone
How to say Thank you? If you find any post helpful on XDA, please click on the Thanks button
If you are using XDA App or Tapatalk, long press on the post and select :good: Thanks Its easier to give "Feedback" in this manner than make an additional post.​
Yeah, it could, but over here (at least I believe) I'm dealing with issues that occur only on i9000 and similar boards. After all, Android Software and Hacking General forum seems like it's more appropriate for finalized works done by people who absolutely (or at least mostly) know what they're doing, not that thingy I'm messing with, and on the other hand, Android General is flooded by various posts mostly related to flashing problems and doubts, interesting offers and similar stuff, so my thread doesn't actually fit in neither of these forums. That thing I'm messing with is an odd duck. I'm trying to address issues that are tightly related with i9000 as well as problems more related to Android-Debian communication through chroot (it's not my primary problem at the moment, but I should look into it someday too), and reincarnating Maemo through chrooted Debian through Hildon Desktop too, but I don't consider myself experienced enough to post in any of the above mentioned categories.
So, to summarize, I don't know. Feel free to convince me if you think I'm wrong.
P.S. It's my 60th post, hooray!

[Q] Altering Shutdown Message

Good Evening Guys,
A few quick questions for you this Wednesday evening; looking to make some customizations to my Windows Phone. I would like to alter the word "Goodbye" when the phone turns off to display alternative text.
Question 1: Is anyone familiar where these settings are stored in the root offhand?
Question 2: Can anyone confirm if this is simply text or a prerendered image?
Questin 2: Has anyone ever tried anything like this before?
Best Regards!
Device Type
Almost forgot:
Nokia 1020
OS:8.0.10521.155
Um... we can't even made the smallest of changes to the Lumia file system (outside of the user documents/media folders and the app folders) or registry. Trying to change system stuff like this is pretty out of the question.
Since you ask, though: to the best of my knowledge, nobody has found that even on the Samsung Ativ phones, for which we have most of a working "jailbreak".
The string that is displayed is probably pulled from a .MUI file.
Thanks for the feedback guys. If I make any headway, I will post back. Would love to have the device power down with "Will I dream?" from 2010 The Year We Made Contact.
That would indeed be cool. You've got an uphill battle, though. If it is, in fact, a .MUI file then it's probably signed (MUIs are technically DLLs, and although they are usually just loaded as resource files they can contain executable code so I expect Microsoft signs and enforces signature checks on them). Thus even if you get filesystem write access, it may not work.
A true custom ROM, where you could remove the signature check requirements, would probably work. That's no simple thing to ask for, though!
Shut Down Message
GoodDayToDie said:
That would indeed be cool. You've got an uphill battle, though. If it is, in fact, a .MUI file then it's probably signed (MUIs are technically DLLs, and although they are usually just loaded as resource files they can contain executable code so I expect Microsoft signs and enforces signature checks on them). Thus even if you get filesystem write access, it may not work.
A true custom ROM, where you could remove the signature check requirements, would probably work. That's no simple thing to ask for, though!
Click to expand...
Click to collapse
What is free time for if not to obsess over little niggly things? Thanks for the feedback

WP8 MDM: how to hack?

After enrolling my Lumia 920 to the corporate Exchange email, new MDM (mobile device management) policies are applied to my phone. It's OK but company administrator(s) set the unlock password (pin) expiration time too short. Every damn month I should choose and remember a new pin... And I can not use the old pins (or I don't know what is the time for "clearing" my old passwords).
Do you know/could you suggest any tricks/hacks to get around this situation? I want to reuse my old pins.
Hey Dude,
I don't think that you can do anything. And this is not the correct thread for such questions.
In the MS World the recommended value for reusing old passwords is 24 so after 2 years
(if 4 weeks was choosen) you can use the first one again.
Why do you think it's an incorrect forum? This forum is about "hacking", and I need a hack. It's definitely not a "Q&A" or "General" forums question...
Hmmm this WOULD fall under the Q&A because it is technically asking a how-to although it involves hacking. Typically the threads under the Development and Hacking are threads that start projects with the hopes of hacking instead of asking how to. With that said, I'll move that over there for now and if there is some development that comes out of this, it can be renamed and moved back to Development and Hacking.
If you have a registry editor, it's pretty easy to tweak those settings. Unfortunately, you're on a Lumia so right now that's not possible (we're working on it!)
The only other option I can think of right now is to try intercepting the communication between the phone and the corporate server. Exchange ActiveSync uses HTTPS, so any standard HTTPS proxy (like Fiddler or Burp Suite) should work. You may need to set the proxy to use a client certificate (if one was provided for your phone), and you definitely need to install the proxy's certificate on the phone (so the phone trusts it to spoof the corporate server). Anyhow, once you have interception set up, it should be pretty easy to modify the policy rules that get pushed down.
In either case, though, the changes will only last until the next time the phone checks its policy rules. I don't know how often that happens - it *might* even be only at initial enrollment, in which case if you un-enroll and then re-enroll you should be fine - but it could be a problem.
GoodDayToDie, thanks for reply. Could you remind me: is it possible to just read values from registry on the Lumia handsets? At least I want to know value of the DevicePasswordHistory settings (according to this article).
[UPDATE] I installed Fiddler's root certificate on the phone, and able to catch & decode https traffic; however there is nothing about provisioning xml in the content, account synchronization produces 3 https requests, first response is a short binary data, second contains an email body (or header) etc. , no xml at all. Looks like MDM policies are applied only on service discovery (I should google for that). Will try to remove this Exchange account and add it again. By the way, I'm not very familiar with the Fiddler: can I change https XML response on the fly?

[Q&A] [WP8.1] Hypothesis about a possible interop unlock with Messaging+ app

Q&A for [WP8.1] Hypothesis about a possible interop unlock with Messaging+ app
Some developers prefer that questions remain separate from their main development thread to help keep things organized. Placing your question within this thread will increase its chances of being answered by a member of the community or by the developer.
Before posting, please use the forum search and read through the discussion thread for [WP8.1] Hypothesis about a possible interop unlock with Messaging+ app. If you can't find an answer, post it here, being sure to give as much information as possible (firmware version, steps to reproduce, logcat if available) so that you can get help.
Thanks for understanding and for helping to keep XDA neat and tidy!
CAPs required for editing registry
snickler said:
You won't achieve any sort of interop-unlock with such an app. The Messaging+ app uses capabilities specific to chat that are restricted. Just because an app uses the interopservices capability, does not mean that it has rights to write to the specific portion of the registry needed to provide interop-unlock. There are a few threads out there that discuss this already
Click to expand...
Click to collapse
I am curious what CAP is required for editing the registry?
gingerjoke said:
I am curious what CAP is required for editing the registry?
Click to expand...
Click to collapse
You at least need ID_CAP_INTEROPSERVICES or ID_CAP_OEM_DEPLOYMENT at the minimum. There are many threads that detail that interop unlock canNOT be achieved unless we have an RPC Service that runs under the SYSTEM account. The MaxUnsignedApp reg value is locked down so that it can only be edited in the way that I just spoke of.
No app on the marketplace, no modifying a store app will achieve this. We were just VERY lucky with Samsung in the beginning.. That's all.
More generally true: there are lots of CAPs (such as OEM_DEPLOYMENT) that permit editing specific parts of the registry. There is *NO* capability that allows you to edit all of it (in theory ID_CAP_BUILTIN_TCB should, through minor additional work, but in practice that cap doesn't seem to do anything for an app).
ID_CAP_INTEROPSERVICES does not give registry access, or at least not any meaningful amount. All that it gives is the ability to call into RPC servers and drivers. *IF* one of those services exposes an externally-callable API for editing the registry - as one of Samsung's (FCROUTER?) does, or at least did - then you can use that to edit the registry. So in that specific case, INTEROPSERVICES indirectly makes it possible to edit the registry, but it doesn't inherently do anything of the sort.
GoodDayToDie said:
More generally true: there are lots of CAPs (such as OEM_DEPLOYMENT) that permit editing specific parts of the registry. There is *NO* capability that allows you to edit all of it (in theory ID_CAP_BUILTIN_TCB should, through minor additional work, but in practice that cap doesn't seem to do anything for an app).
ID_CAP_INTEROPSERVICES does not give registry access, or at least not any meaningful amount. All that it gives is the ability to call into RPC servers and drivers. *IF* one of those services exposes an externally-callable API for editing the registry - as one of Samsung's (FCROUTER?) does, or at least did - then you can use that to edit the registry. So in that specific case, INTEROPSERVICES indirectly makes it possible to edit the registry, but it doesn't inherently do anything of the sort.
Click to expand...
Click to collapse
Finally found RPC service in NdtkSvc.dll
But requires InteropServices Capability
Here is list of functions works as "SYSTEM".
CopyFileEx()
NdrServerCall2()
CreateThreadpoolWait()
SetThreadpoolWait()
CloseThreadpoolWait()
SetEvent()
SetServiceStatus()
CreateEventW()
RegisterServiceCtrlHandlerW()
CloseHandle()
OpenProcessToken()
FindFirstFileW()
CopyFileExW()
GetCurrentProcess()
CreateDirectoryW()
RegCreateKeyExW()
RegQueryValueExW()
IsCharAlphaNumericW()
LookupPrivilegeValueW()
FindClose()
RemoveDirectoryW()
RegOpenKeyExW()
FindNextFileW()
AdjustTokenPrivileges()
InitiateSystemShutdownExW()
DeleteFileW()
RegCloseKey()
RegSetValueExW()
RpcServerUnregisterIfEx()
RpcServerInqBindings()
RpcEpRegisterW()
RpcServerUseProtseqW()
RpcBindingVectorFree()
RpcServerRegisterIf3()
RpcEpUnregister()
ResetPhoneEx()
EncodePointer()
DecodePointer()
QueryPerformanceCounter()
GetCurrentThreadId()
GetSystemTimeAsFileTime()
GetTickCount64()
But I'm confused about how to write a code for as RPC Client or using any DllImport functionality. ?
Can someone provide me at least demo/example code of RPC client ?
... Whoa, that is a seriously valuable list of APIs. Those are callable as SYSTEM, without any restrictions except the caller needing ID_CAP_INTEROPSERVICES? Either I've been out of the loop longer than I thought or this should have been discovered long ago (is it new to some not-yet-widely-available version?) You cannot *trivially* get root this way - it doesn't, for example, include the APIs you would need to inject arbitrary code into a SYSTEM process or similar - but you can certainly do things like write an arbitrarily powerful file-and-registry browser. With that, you can do a hell of a lot of other stuff, stuff that even Samsung's RPCComponent didn't permit.
MS RPC is documented on MSDN here: https://msdn.microsoft.com/en-us/library/windows/desktop/aa378651(v=vs.85).aspx
It includes a full API reference, lots of guidance on development, and a tutorial. The tutorial looks pretty well-written, and is probably a better place to start than the API reference unless you know more about RPC at the moment than I do.
However, this documentation is aimed at "normal" implementations, where the client has, if not the server's source code, at least the interface definition. You have to know the UUID (probably easily findable though I'm not sure where) and the function interfaces (in a reasonable level of detail). Black-boxing that is going to be one of the harder tricks, I think, though somebody may have written one or more tools to make it easier.
EDIT: I can't find NdtkSvc, or its binary, on my phone. It's either OEM-specific or (more likely) requires a particular OS update/upgrade. What version did you find it in?
EDIT2: How'd you get the list of APIs it serves? Do you have the IDL file for the RPC server? That would help a ton; if you have that, we're good to go.
EDIT3: Don't forget you can PM people if you don't want to put this stuff out in public.
@GoodDayToDie
Hi, Sorry for the late reply.
It is only specific for Lumia.
NdtkSvc.dll known as "Nokia Device Toolkit Service".
"C:\Windows\System32\NdtkSvc.dll"
Yes, ID_CAP_INTEROPSERVICES cap is everything here too on Lumia.
Here is a one of the example which same "Nokia.SilentInstaller.Runtime" does that on RPC Access,
Code:
static bool NRSCopyFile(String sourcePath, String destPath);
works without any "RESTRICTIONS", with any "PARTITION".
Even possibilities to "REPLACE" the hidden/non-accessible Registry "HIVE" Files.
Such as,
"C:\Windows\System32\Config\ProvisonStore"
But unfortunately they are all in simply zip file having a signed.
We can't modify and place back them such HIVE/POLICY files, sad
So what i did it so far,
-Modified "DeviceReg.exe" with hex-editor and replaced to "C:\PROGRAMS\DEVICEREG\DeviceReg.exe". (signature getting a braked)
-Replaced "PolicyFiles". (signature getting a braked)
It's frustrating to me, It's shame for me that i cant do anything having a full FS Access, lol.
Such files and System binaries are fully signed with the new 8.1 "Policy Engine".
but i think .dll files doesn't required to be signed to run in System chamber.
Well, Time to write a some RPC library
Thanks.
Edit: I don't know about which update is required, I think it is from WP8.0 GDR1. At least WP8.1 GDR1 or above.
but the "NdtkClient.dll" is available since WP8.0 GDR1 in "Extras+Info" App.

Categories

Resources