Develop Bugs

[WORK IN PROGRESS] XML Provisioning for all devices...

At the moment I'm working on an app called "WP7 Root Tools". I got the registry editor almost finished, but I am also going to add a File Explorer, Certificate Stores and maybe more. When the registry editor is working I will release the first alplha-version. As the title of the app implies, the tool uses root privileges to perform queries and transactions. I let the tools parasitize other processes to get the code executed in the TCB chamber of the device. I have this working stable now on my Samsung Omnia 7. Unfortunately I have to use a little bit of device-specific API's to do this. And I have to make quite a detour to make it work, which has a negative impact on the performance.
So the ultimate goal is that, in the end, this will work with other, more direct API's, which work on all devices. During my research I found some possiblities that need more investagation. I already decided that I will first concentrate on getting this working with my Samsung device, so that I have at least the tools to do further research. But I thought I'd drop some of my findings here that may lead to better device-support and better performance for future-versions of the tools.
There are many ways that may lead to executing code with elevated or root privileges. But in this post I want to concentrate on XML provisioning. A lot of info can be queried and configured through these API's. I have tried to call the native OS functions for XML provisioning. The function you need to call is: DMProcessConfigXML(). And it is declared in: Cfgmgrapi.h. If you call this function it returns errorcode: 0x4ec (or 0x800704ec), which means "Access disabled by policy". If you use a native COM dll and you forget to add ID_CAP_INTEROPSERVICES to the WMAppManifest.xml, you will get the same errorcode when calling a native function through the COM-interop. So when I get the same errorcode when calling DMProcessConfigXML() this may suggest, that I might be missing a capability in the WMAppManifest.xml.
In another thread on this forum some undocumented capabilities were discussed. One of them was ID_CAP_WAP. Since OMA Client Provisioning is also call WAP-Provisioning, I thought that might be the missing capability. I was not able to add the capability from within Visual Studio, because the capability is missing from the corresponding xsd's so it will give an validation error on building the project. But I could add it manually after the project was build. When I deploy it to the device, using the Application Deployment tool, it would return "Access is denied". I thought it might be an invalid capability, but when I changed the capability to ID_CAP_XXXXXX that would return "Install failed. Fix the capabilities." which is the real error message for an invalid. That implies that ID_CAP_WAP is in fact an existing capability, but I'm just not allowed to use it. When I would be able to use it, I would probably have access to the function DMProcessConfigXML(). That part of the app would be impesonated into higher chambers.
So the big question is what is keeping me from using the ID_CAP_WAP? Why am I not allowed to use it? I tried to attach a debugger to XapDeploy.exe, but it does not throw any exceptions at all. The errorcode is generated in the phone. Getting this fixed will give a big boost to getting closer to root access on all devices. Any help or insight on this will be appreciated.
Heathcliff74

I sent some tweets to da_g, chris, chevron, julien schapman, and a few other devs to let them know this is going on...I'll try tom hounsell too he may know a bit more about this
I'm notifying notebookgrail too because he has been doing some work with dell venue pro devices
Good luck

At a wild guess, it's probably looking for a signature. Using signed code for trusted functions is the kind of thing MS likes to do. :-/
All that said, if you have ProvXML working on Samsung, I would *love* to take a look at it. I'm maintaining a cross-platform Homebrew library. Currently I have at least partial ProvisionXML on HTC and LG, but none on Samsung. I don't have a Samsung device to test with, which is making it hard to try things out...

ID_CAP_WAP isn't a capability you can assign yourself. A higher up has to assign it to you.
<!-- Account loaded from: W:\WINCEROOT\temp\oakcopy28570\Release\x86\XDE\Policy\cb659c75-eac9-4db7-afd8-055632acf233.policy.xml(292,2) -->
<Account Id="S-1-5-112-0-0X71-0X49445F4341505F574150" Description="Autogenerated group for capability ID_CAP_WAP" FriendlyName="ID_CAP_WAProvides access to WAP API" Type="Group">
<!-- MemberOfGroup loaded from: W:\WINCEROOT\temp\oakcopy28570\Release\x86\XDE\Policy\cb659c75-eac9-4db7-afd8-055632acf233.policy.xml(293,2) -->
<MemberOfGroup GroupAccountId="S-1-5-112-0-0X71" />
Click to expand...
Click to collapse
(BasePolicy.xml)

domineus said:
I sent some tweets
Click to expand...
Click to collapse
Thanks.
GoodDayToDie said:
All that said, if you have ProvXML working on Samsung, I would *love* to take a look at it.
Click to expand...
Click to collapse
Well, the whole ProvXml stuff will become irrelevant, when I finish the tools. Because ProvXml is not really user-friendly and my tools will provide that functionality in a user-friendly fashion. So at this moment I want to concentrate on finishing the first alpha-version. Later on, I will probably clean-up the code and release it. But it's quite complex, because I added async multithreading to keep it all smooth.
WithinRafael said:
ID_CAP_WAP isn't a capability you can assign yourself. A higher up has to assign it to you.
Click to expand...
Click to collapse
Thanks for this info. But what I read from this is that you just need to be able to impersonate. Has anyone tried CeImpersonateToken() with this SID?

Abstraction of the ProvXml capabilities is awesome, assuming that we can fully use them and/or extend them if needed. It's useful for a ton of stuff. I've written a small amount of abstraction for registry writes and such, but having the full functionality exposed through a clean API would be fantastic.

[Q] nfc-tools on Android?

Has anyone tried porting anything based on libnfc (libnfc.org), such as nfc-tools (code.google.com/p/nfc-tools), to Android?
I've heard of the odd person or two managing to cross-compile libnfc for Android and get it working with an external reader, but I'm more interested in getting nfcutils and mfoc to run on my Galaxy Nexus...

Hi,
I was looking for the same thing as you.
Indeed some people succeeded to compile libnfc on android (android 2.3 if I remember well) and they have published a little outdated tutorial.
The problem that is their porting use libusb and permits to use an external NFC reader connected via the phone USB link.
I think you are most interested in using the internal one.
On my galaxy SIII, the NFC device seems to use an I2C link (the device is /dev/pn544). So you will need to make a libnfc "driver" for your device wich link to the I2C. I you look into libnfc code, you have some code to mange serial links but it seems a little experimental.
Moreover, there is already a driver and a lib that manage your NFC device, so you'll probably have some conflicts by trying to add libnfc.
The built-in lib is libnfc-nxp wich also includes drivers, hardware abstraction and a upper level libraries (called "FRI") providing services to manage cryptography, NDEF messages and so on. This lib is completely different from the linux libnfc.
So if you want to get lib-utils working, you will probably need to compile them after developing a wrapper between libnfc functions using libnfc-nxp. (or something like this)
In my knowledge, nobody did the job yet.
I found some tries to recode mfoc utility in an android apk but nothing functional yet (and there is often no recent activity of these projects).
Sorry.

I found this:
https://github.com/ehabkost/nfc-tools (last activity two years ago)
It appears the Android API lacks some features to get the mfoc running.
It may be possible to overcome this modifying the libnfc-nxp source in the android repo....... who knows.

Porting [nfc-tools] libnfc to Android 4.4.2
Does anyone have news about this ?
I did some research though but instead of creating a new thread, I ended up here.

if anyone is still interested, I have compiled libnfc and nfc-list from last commit on git and works on my Nexus 5 5.0.1
You can find here github.com/etmatrix/libnfc and github.com/etmatrix/libusb01 for libusb
I attached an usb device SCL3711-NFC&RW and nfc-list show me a Mifare Classic and SRIX4K.
I need to improve external module libusb, libnfc look at /tmp/libusb-0.1.12 for linking.

etmatrix said:
if anyone is still interested, I have compiled libnfc and nfc-list from last commit on git and works on my Nexus 5 5.0.1
You can find here github.com/etmatrix/libnfc and github.com/etmatrix/libusb01 for libusb
I attached an usb device SCL3711-NFC&RW and nfc-list show me a Mifare Classic and SRIX4K.
I need to improve external module libusb, libnfc look at /tmp/libusb-0.1.12 for linking.
Click to expand...
Click to collapse
Hey! I'm just trying to get into this issue, and I would really appreciate if you could help with some piece of advice
I've digged up all google, but all instructables are dated 2010-2012, I am sure that there should be some progress in this area! My goal is to flash libnfc to Android and make it use an internal nfs chip
Can you contact me? It would also be great to have a compiled file to install libnfc to my galaxy s3 and some explanation, because unfortunately I'm just a beginner in this, though a really ambitious
Thank you!

Bump.
Any news on this? I'd really like to be able to read my public transportation pass to see how much I have credit left (It is mifare classic 1k). There is no official app to read it either (nor unofficial for what I know).

You can try the app "västtrafikreader" or vasttrafikreader. You have to google it yourself.
Classik k1 efter carry heavy encryption wich makes is almost impossible to ream them. But in vasttrafikreader they got the keys for the swedish system and the cards can even be manipulated.
Its rather safe to say that you basicly cant carry out the hack w/o the proper keys.

There have been ports of mfoc and similar tools for Android in the past, but only for externally connected NFC-Readers, since the Android APIs don't allow the necessary access to the internally embedded NFC chips. The best app for working with Mifare Classic NFC chips is the "MTC - Mifare Classic Tool", which is available on the Play Store. It's open-source on GitHub and supports reading and writing to the chips if you add the keys to the dictionary file or if the sector you're trying to access uses one of the default keys. This app could totally be expanded with mfoc-like functionality, at least on rooted devices, but for now you have to run mfoc on the PC once to get the keys, add them to the dictionary and afterwards you're able to get full read/write access to all sectors of the specific chip from a supported Android handset (hardware-wise, depends on the NFC chip used).

hello, its been 4 yearsany news on an internally embedded NFC chips mfoc functionality ?

Card Emulation in general

Hi there,
right now I am researching for a possibility to emulate a smartcard with a smartphone. As we all know, the standard os and api won't let us do this. What I want to achieve is create a way to use the smartphone for physical access without the need to change the existing infrastructure. o achieve that, the smart phones gets a localy and time limited informationtoken it should present to the reader. In other words, I actually dont realy need access to the secure element, as any data would be temporary.
Right now I am a bit confused about this. Is there a way to use card emulation, without the need of a secure element? I have searched for different ways to acchieve this, but on many ends, I can't seem to find a definitv answer.
For example I stumbled on OpenNFC. They praise that they can acchieve card emulation. Yet, they don't provide any examples on this and fail to actualy deliver some sort of information on the requirements of this. As I understand it, it seems like this method only works when the smartphone uses Inside Secures Chips MicroRead or SecuRead. Anyone knows more about this?
I'm realy open to ideas on this one, as it seems theres little to no documentation or examples to go on.
I'd realy be happy to read about what you guys found out on this issue as of yet.

I've been looking into it too. This is what I have found:
EddieLeeDefcon20.pdf
nfcproxy
(Google them, I can't post links)
So, yeah, it can be done, but you have to modify android to be able to.

I ended up to OpenNFC too, but no sample code!
I have a good background on Mifare Classic 1K and 4K programming using RFM130 under linux and win.
Sent from my HTC One X using Tapatalk 2

Ok, so after browsing the mailinglist like a maniac I found this answer from one of OpenNFCs developers:
Hello,
The OpenNFC stack porting on Android complies to the Google API, as far as the applications are concerned.
Since these API do not allow an APK to do card emulation, it is not possible to use this mode on the Nexus,
nor on any Android phone, with or without OpenNFC.
However, OpenNFC provides card emulation feature for other porting (Win32, linux), depending on the hardware capabilities.
Kind regards,
Stephane
Click to expand...
Click to collapse
Source is on their mailing list on sourceforge, cant post link....
So seems we can forget this one... Only option would be using the Cyanogenmod patch that is used by NFCProxy.

When this message has been posted? I think things has changed (not sure)
Anyway, I posted a message yesterday to have more informations about their projects on Android

The Message is from March 29th, 2012.
Again as I said, if that has changed, they really have to work on their communication to the outside. There seems to be noone but the devs that can say anything about this. And that means quite a lot.

When there is no API for something, we can use native code and directly communicate to NFC hardware. Agree?
Sent from my HTC One X using Tapatalk 2

Well, the way I understand it is, that we could take a build of android and tinker with it to get it to work. We would have to change the NFC softwarestack and its interaction with the rest of the system in order to make software emulation possible. That is quite some pile of nontrivial work to do if you ask me.

Sorry for doing a new reply instead of editing the old one, but I think this is interesting enoug to not get overread.
I got an answer from the OpenNFC Developerteam regarding my question. Part of my question was also if it was possible to emulate for example a Mifare Tag through their NFC Stack. Here is the answer:
Hello XXXXX,
The Open NFC stack is designed to be largely hardware-independent, with a small adaptation module (NAL) for each hardware chipset. However, currently we only provide the NAL module for the MicroRead / Securead chipsets; therefore out of the box we are only compatible with these chipsets.
It is possible to emulate ISO 14443-4A and -4B cards and Type 4 tags from the Open NFC stack; for emulation of MiFare Tag, you’d indeed need to use a Secure Element.
Best regards,
Sebastien.
Click to expand...
Click to collapse
Hope this clears some questions regarding OpenNFC.

Windows RT 8.1 new APIs preview

Full Article
http://justinangel.net/Win81APIs
Bluetooth 4.0 RfComm and GATT support
Point of sale: Barcode scanners and Magnetic card readers
Smart Cards
Lock screen Image Apps
VPN support for Metro apps
Scanner APIs and apps
Support for any External / USB device
Native PDF rendering in apps
Multiple screens projection support in apps
XAML/WinJS: New resolution scaling support / Super-high resolution tablets
Camera: Low-lag cameras / HDR
New Metro App Types: Appointments, LockScreen, Contacts and GeoLoc
New App Type: GeoFenced activation
New App Type: Lock screen call
New App Type: Appointments Provider
Text-to-speech
Read-write access to Camera roll, Saved pictures and playlists
XAML/WinJS: new SearchBox control
XAML/WinJS: Hubs for SemanticZoom
XAML: DatePicker and TimePicker
XAML: Flyout, MenuFlyout and SettingsMenuFlyout
XAML: AppBar simplification
XAML: DataBinding Improvements
Globalization: Currencies, Numeral systems and Numerical formatters
Other minor but important Win8.1 features

Be aware: these are new WinRT APIs, not Windows RT features. WinRT != Windows RT (I usually abbreviate the latter as "WRT" to avoid confusion and for similarity with things like WP8).
With that said, since WinRT is the only official API for developing WRT apps, and since Win8.0 and WRT_RTM support the same WinRT APIs, it's reasonable to assume that the same APIs are coming to WRT and therefore apps using these API features will be available on WRT devices.
Another interesting point is that WP8 uses WinRT as well (though only a subset of it). Hopefully at least some of these new APIs also become available on WP8.1; the obvious candidates are things like alarms and Bluetooth and such, though it'd be great to get *any* kind of VPN support in there...

"Support for any External / USB device"
Does that sound like unsigned (or testsigned, whatever) kernel mode code to anyone else?
Edit: Should probably read the thread closer, this is WinRT stuff.

It's not kernel mode. More accurate would be the ability to write (sandboxed, low-privilege) user-mode drivers using WinRT. That's still cool - it's the first official driver API of any kind, and from a security standpoint I'm way more comfortable about installing WWinRT apps than actual NT drivers - but it probably won't help with unlocks. It does mean you can talk directly* to USB devices, though, which is cool in many ways.
Given the ability to handle unrecognized devices, I'm guessing that apps will be able to register for specific USB IDs (in the same way that they can register for URI schemes and file extensions now) so that the app will auto-start when you connect a device, or so you can search the store for apps which can handle a specific device. This is big. The lack of third-party NT drivers for obscure hardware on RT has been an impediment (one of many) to progress on the platform. Asking people to write their own drivers is probably not going to fly for really complex hardware unless it's also quite popular, but I can see people doing things like writing an ADB app; there's no reason I know of why that needs to be a kernel driver.
* I'm assuming that the new WinRT APIs basically call into a generic NT driver that does the actual device IO. So, it's not literally directly talking to the device in the sense of sending bits down the USB port from your software, but it's still a lot closer to the metal than we could officially get before.

GoodDayToDie said:
* I'm assuming that the new WinRT APIs basically call into a generic NT driver that does the actual device IO. So, it's not literally directly talking to the device in the sense of sending bits down the USB port from your software, but it's still a lot closer to the metal than we could officially get before.
Click to expand...
Click to collapse
Yes, it is probably just a Metro wrapper around the old well-known WinUSB API: http://msdn.microsoft.com/en-us/library/windows/hardware/ff540174(v=vs.85).aspx
And there is a strange question in the article:
Despite the plethora of new VPN APIs, an open question remains as to whether WinRT Win8.1 apps will work by default on VPNs.
Click to expand...
Click to collapse
VPN works fine on RT. At least I can connect to our company VPN with the built-in client and access all our internal resources, for example Sharepoint from the Internet Explorer.

Confusion of "Windows RT" and "WinRT" again*. VPN works "fine" on Windows RT, or on Windows 8, for desktop apps. However, WinRT apps, on either Win8 or WRT, are known to have problems tunneling through VPNs. These new APIs will hopefully help with that, but the question remains whether WinRT (Metro) apps will work *by default* over a VPN, or not.
* I swear, the entire Microsoft branding department, or at least any of them who can't provide proof they didn't argue against this idiocy, need to be stood up against a wall, slapped in the face, by everybody who ever got those two mixed up, and then fired. Much like Windows Phone... at least the complete retard who came up with "Windows Phone 7 Series devices" got the boot, but the result was merely slightly less awful and it hasn't gotten better since.

Being able to write drivers in WinRT level sounds very interesting indeed. I wonder how much integration into the OS will those drivers have, especially, if they are to remain active even when the parent app is not running.
I just hope they bring the entire IO interface of .NET on WinRT. That way we would be able to write drivers from scratch if we really wanted to...

I just want to access to COM ports. Seriously that was a dumb decision on microsofts behalf to block it. Only security threat it poses Tcp also poses so that can't be the reason.
I guess with raw usb access you can try a custom driver to a usb adaptor.

[Q] Bringing Wii Remotes with Sensor Bar to the FireTV?

So I have spent the last couple of days researching this topic as I am extremely interested in making a Wii Controller with sensor bar work with the FireTV.
Here is what I know.
Amazon FireTV is running on Fire OS Mojito 3.0 which equates to a base Android OS 4.2.2. This does not mean, however, that the bluetooth stack is running on BlueDroid (Broadcom's bluetooth stack driver, which USB BT Joystick Center indicates that it breaks native compatibility with Wii and PS3 controllers, thus the app recommends a physical USB BT CSR device to work.). Supposedly FireTV is still using the BlueZ stack which ought to make things work normally, but Joystick Center does not detect the Wii remote natively still and of the 2 bluetooth dongles I already own they do not appear to be compatible for whatever reason. I have ordered a new one that may work with Joystick Center and I will report back.
There is every indication that Joystick Center should be capable of allowing Wiimotes IR pointers to work, but we need to figure out how to make it work and preferably natively.
http://www.pocketables.com/2012/03/usbbt-joystick-center-now-does-wii-motion-controls.html
I also ran into this interesting video of someone implementing CWiiD directly into the firmware of their device (in the video the guy launches as an app, but trust me it is not a simple app or one that you can find to download).
www.youtube.com/watch?v=xyAowQRkfto
This is the CWiiD project that I believe the folks at Ouya are using to allow Wiimotes to sync with their device and likely other apps in the marketplace both free and commercial (despite whatever gpl license that may be involved).
http://cvpcs.org/projects/android/cwiid4android
If we can start making custom FireTV roms then we need to integrate CWiiD imo, because if we can use 1 or 2 controllers as a replacement for a touch interface it would open up a wealth of cheap gaming via any app in the Google Play marketplace.
What currently works.
Wiimote Controllers v0.65
This does not allow for IR pointers, but it does allow for normal button presses of a remote control.
https://play.google.com/store/apps/details?id=com.ccpcreations.android.WiiUseAndroid&hl=en
A Place to Start
If we want true Wiimote support then I think we need to start focusing our efforts on updating cwiid-android on github. This package is 4 years out of date as gingerbread was the last OS it was compiled for and it had IR support back then. Why no other developer finds this important boggles my mind.
https://github.com/cvpcs/android_external_cwiid
https://github.com/cvpcs/android_packages_apps_CWiiDConfig

Additional Information
So I have ran 'sdptool browse local' in the shell and have confirmed the BlueZ stack. I think this was very wise of Amazon to keep and seems to be some justification certainly for not using a more stock or AOSP like firmware.
Service Name: Generic Access Profile
Service Provider: BlueZ
Service RecHandle: 0x10001
Service Class ID List:
"" (0x1800)
Protocol Descriptor List:
"L2CAP" (0x0100)
PSM: 31
"ATT" (0x0007)
uint16: 0x1
uint16: 0x8
Service Name: Generic Attribute Profile
Service Provider: BlueZ
Service RecHandle: 0x10002
Service Class ID List:
"Generic Attribute" (0x1801)
Protocol Descriptor List:
"L2CAP" (0x0100)
PSM: 31
"ATT" (0x0007)
uint16: 0x10
uint16: 0x13

So I have put my research on hold - I gave this projects days more than I should have. I simply can't figure out how to port something this old and 4 versions behind. I tried recompiling from source on both OSX and Ubuntu, but I couldn't work through all of the compile errors. Not sure why cwiid4android https://github.com/cvpcs/android_external_cwiid has been abandoned for 4 years!