Hello all
I've been reading this forum for some months now and i like the windows'es and informations i've found here on my Hermes device
But now i have some questions on using the often integrated tool field test.
I've found out that with the IMSI-catcher (german wikipedia as one of the sources), that are more and more often used semi-legal by the police(here in europe there are a lot of 'GA-90' devices sold to the police and other institutions), it is possible to listen to phone calls(man in the middle attack), by just 'emulating' the strongest phone-cell in the area, to which the device connects instead of connecting to the provider's cell.
I also read that it would be possible to find out if there was an imsi-catcher device active in the area near you or not. The only thing needed is a special monitor software (field test?) that observes the MNC(Mobile Network Codes) behavior(appearently you need 2 handy's from the same provider with the monitoring software running).
But they didn't explain exactly on which behavior you should pay attention.
Since I could use 2 windows mobile devices to test this out, I am searching for more detailled information on this subject, and the first place that came in my mind was xda-developers
I allready did search this forum for the subject imsi catcher, and the only thing I've found is this.
google result
so one person who tries to change hies imei number, and another one who doesn't seem to know exactly what an imsi catcher can do.
Is here anyone who knows more?
I know that where I live, there are pple who make abuse with IMSI-catchers(catching calls without the permission from a judge or similar, or even one time someone listening to his girlfriends phone calls to see if she's cheating(and she did and that was the reason he left her))And yes this one was a young policeman who told that to his friends and even was proud of it.
I also dislike the fact that the handy, instead of the encrypted one with the provider's cell, has an non encrypted connection to the imsi catcher(if not there would be no possibility for a listening man in the middle attack).
I also read about the cellphones from http://www.cryptophone.de/
Appearently they do allways have encrypted conversations even through an Imsi-catcher. But if that would be true, the other side will need the same handy to decrypt it again. Because it has to encrypt, the allready encrypted data traffic with the provider's cell, if not it can't allow any protection against IMSI -Catcher devices. I also ask myself if, depending on where u want to use it, the 2nd encryption could produce a to huge phone traffic that could result p.ex. in a robot voice...
Anyone who could light me up?
Or is there any software able of reencrypting the encrypted transfer on windows mobile devices?technically it should be possible(2nd phone dialer installed so you choose the normal one for normal calls and 2nd one for calls with pple who also have this software installed on their phones)perhaps not with an 256 bit encryption but perhaps with a 128 or 64 bit encryption...
BTW, if there would be anyone able to programm such a hot piece of software for windows mobile devices I wouldn't have any problem to donate him with paypal, and i suppose other pple would do the sameAnd no I don't wanna replace that by Voip or skype via HTC...
Thanks in advance
Patrick
So no one who knows more about this?
I would be very happy if i could at least test if they're really used that often as they say they are(where i live).
And since i could try it in different major 'cities' over here, i suppose catching a imsi catcher soon or later
I'm quite curios if all the pple, telling that there is a lot of abuse with these machines, are right, or if that's all nonsens...
It would be nice if a warning icon could be integrated into Windows Mobile or the dialer to indicate that a call is not being encrypted. Read the Wikipedia entry for IMSI-catcher for more info. I'm guessing CDMA is largely unaffected since the hole seems to rely on the UMTS spec's backward-compatibility with GSM.
I'd also like to note that Skype is the way to go for true endpoint to endpoint call encryption. You know, if you're a gangster or something and need to brush off the popos. It would be interesting to investigate whether the WM6 integrated VOIP stack requires authentication/encryption.
I'm new to WM programming and I'm trying to access a bunch of information like signal strength on CE devices. I've found some of the information I need through the TAPI and RIL APIs, but I haven't managed to find either the SID or APN (e.g. wap.cingular).
I thought both of those would be pretty easy to get, but I haven't had any luck finding them.
In case anyone is interested in the answer to my question - it looks like I had a couple of misunderstandings.
First - I was having trouble finding the SID because I now understand that SID is not used on GSM devices. GSM devices have a Mobile Country Code (MCC) and Mobile Network Code (MNC). Both of these are available via the RIL_GetCurrentOperator() call.
Second - maybe APN is specific to GPRS? It's available via the RIL_GetGPRSContextList() function.
Does the magic by default or any other android builds support having two numbers on the same sim card?
And if so has anyone tried how you can call/text from a specific number?
Thanks in advance ppl
My friend this is a general question.. So it should be placed on the General threads... bla bla bla bla...
Now back to the answer.. I think that the question you are making is related to Twin SIM cards. This can have two numbers on the same SIM. If android will run use this cards without prob.. why not? Never tested, but If old phones can do it why not Android?
Not an expert on this but isn't all handling of this happening outside the phone and at the mobile provider ?
ronni.rasmussen said:
Not an expert on this but isn't all handling of this happening outside the phone and at the mobile provider ?
Click to expand...
Click to collapse
Yes, is out of phone question in my opinion too.. But, we can take this question if this phone is capable of reading Twin SIM cards.
Doesn't the phone OS allow the user to choose between numbers?
I posted this under the android subforum cause my question is if the OS supports it and not the hardware.
If the sim has 2 numbers you must be able to choose for example from which one to send an SMS from, or from which one to make an outgoing call.
This is something that android will have to handle.
Am I saying something incorrect here? :/
I managed to find the proper name for this twin sim thingie.
It's called ALS "Alternate Line Service" and is NOT supported by any Android device so far.
I'll try posting on the android google group for some more info.
http://android.modaco.com/content/htc-hero-hero-modaco-com/291775/line-2/
Hello.
I'm just studying about feasbility of Virtual SIM.
I know that every SIM has one Ki and IMSI information and there are many dual SIM holders that provides STK functions.
If I want to make a dual SIM like SIM-Max or 10-in-1 SIM, what sould I do?
Here is my idea.
Is there anyone who can tell me the idea below is correct?
1. Contacting a SIM card manufacturer like Gemplus(Gemalto).
1.1 Buying an SDK
1.2 Buying some Java Based SIM Cards.
1.3 Programming for SIM card, which is compatible with GSM11.11, GSM11.14
2. Getting two IMSI and two Ki from two existing SIM(which has COMP128 v1) for test.
2.1 Copy the information I have got to the programmed SIM.
2.2 Toggling with STK menu.
3. Contracting with two operators.
3.1 Buying a serial of information from the operators, for example AT&T(US) and Orange(UK), where the information is IMSI and Ki.
3.2 Putting the information to the programmed SIM card.
4. implementaion of OTA function.
4.1 Ki and IMSI downloaing STK applet.
If this is possible, I think I can make dynamic virtual SIM for roaming users, where user can download an IMSI and Ki information.
Please reply to this about the feasibility.
Thank you in advance.
Hi all,
My question is one that has been asked a few times around here, but never answered in a very satisfying way:
Is NFC card emulation possible for app development?
I've done days of research on this, and I have yet to encounter any decent summary thread explaining clearly the current state of affairs on this particular subject. Therefore, I'm starting this thread to gather all the information I've been able to find into one place and hopefully get some help filling in the gaps in my understanding of the subject.
What I think I know:
- NFC Card emulation can be done one of two ways:
1) In hardware, using the secure element.
This way seems like the hard way.
h t t p://nelenkov.blogspot.com/2012/08/android-secure-element-execution.html <-- This article talks about the process of accessing the secure element in great detail for ICS on the Galaxy Nexus.
The secure element can emulate Mifare Classic cards, JavaCard formatted cards, EMV credit cards, and ISO 14333A/B formatted cards in general. Google Wallet is the premiere example of an app that utilizes this emulation method. Access to the secure element is difficult, but possible.
2) In software, using a virtual smartcard independent of the secure element
This is not a method built into standard Android ROMs, but has been supported in Cyanogenmod since version 9.1. Again, h t t p://nelenkov.blogspot.com/2012/10/emulating-pki-smart-card-with-cm91.html <-- this blog explains in detail. This method is only capable of emulating EMV cards. NFCProxy and SimplyTapp are the premiere examples of apps that utilize software card emulation
What I've had trouble finding is API documentation and practical examples of any kind. Several people have claimed, as in threads like this: http://forum.xda-developers.com/showthread.php?t=1706057&page=7 , that they have emulated MIFARE cards on their phone, but details are scarce.
What I'd like to know:
- Are there any APIs available for writing to the secure element, official or otherwise.
- Is there any way to perform raw reads and writes to/from the NFC module, (to replicate raw card information, for instance)
- What protocols are actually supported, both in secure element and software? For instance, what is the state of FeliCa emulation?
If anyone out there knows the answers to these questions, or can provide any further insight, please share it below.
Thanks!
Hi,
Timuu-kun said:
Is NFC card emulation possible for app development?
Click to expand...
Click to collapse
Yes, but with many limitations.
Timuu-kun said:
The secure element can emulate Mifare Classic cards, JavaCard formatted cards, EMV credit cards, and ISO 14333A/B formatted cards in general.
Click to expand...
Click to collapse
There are different types of secure elements. E.g. a phone may have an embedded secure element (a chip soldered into the phone), an NFC UICC (a SIM card that acts as a secure element) and a removable secure element in another form factor (e.g. MicroSD card). More than one of these secure elements may coexist in one device.
Some secure elements (e.g. NXP's SmartMX) can emulate MIFARE Classic. In general secure elements use standard smartcard communication protocols. Thus, they can be accessed using APDUs (as defined in ISO/IEC 7816-4).
Most (or all?) secure elements are based on JavaCard technology. Note that this is not a format, but a specification of the execution environment for applications. I.e. JavaCard defines a Java-based API and a Java virtual machine that runs Java applications (called applets) in JavaCard byte code.
Thus any application that runs on a secure element is a JavaCard application. For instance if a bank implements an EMV compliant credit card to be used on a secure element, this credit card applet would be a JavaCard application. Similarly, whenever you want the secure element to process APDU commands, you would create just another JavaCard application to handle your APDU commands.
Typically in Japan you may also find secure elements that emulate FeliCa (though I have not seen any of them yet).
Regarding ISO/IEC 14443: This is the contactless communication protocol used by smartcards/by the secure element (except for FeliCa which uses a different communication protocol). The different layers of ISO/IEC 14443 define modulation, coding, anti-collision (i.e. enumeration of cards if multiple cards are visible to a reader), selection, framing and a transport protocol. For layers below the transport protocol, ISO/IEC 14443 is split into two different protocols: Type A and Type B. Not all smartcards/NFC tags support all protocol layers.
For instance MIFARE Ultralight uses a proprietary protocol on top of the framing protocol of ISO/IEC 14443-3 Type A. MIFARE Classic also uses a proprietary protocol on top of ISO/IEC 14443-3 Type A (though it uses a slightly different framing).
A smartcard that uses ISO/IEC 7816-4 APDUs over the contactless interface (i.e. a typical secure element), exchanges these APDUs on top of the transport protocol defined in ISO/IEC 14443-4. This transport protocol is the same for ISO/IEC14443 Type A and Type B. Thus, secure elements can use either ISO/IEC14443 Type A or Type B. A secure element that emulates MIFARE Classic will use Type A, as MIFARE Classic is (partly) based on that protocol.
Timuu-kun said:
[Software card emulation] is only capable of emulating EMV cards.
Click to expand...
Click to collapse
Software card emulation (or host card emulation) using NXP's NFC controller PN544 (or its successor PN547) can only "cards" using the transport protocol of ISO/IEC 14443-4 (e.g. no FeliCa, no ISO/IEC 15693). (Either as a Tpye A or as a Type B "card".) Thus, no proprietary protocols below that transport protocol can be emulated (e.g. no MIFARE Classic, no MIFARE Ultralight). Also the UID (unique identifier) used during the anti-collision phase will be a new random value for every activation through a contactless reader.
So you could emulate an EMV payment card (but you are not limited to EMV).
Unfortunately, the only manufacturer of NFC controller chipsets that was willing to provide me datasheets & user manuals of their NFC controllers was NXP (and even they release them only under a strict NDA). Broadcom and others were not willing to share such information with academic institutions. Thus, I have no information on the software card emulation capabilities of other NFC controllers.
Timuu-kun said:
Are there any APIs available for writing [better: access] to the secure element, official or otherwise.
Click to expand...
Click to collapse
For Android:
Embedded secure element on Android devices:
com.android.nfc_extras
This API is available at least on Google's Nexus devices and Samsung Galaxy S3.
Nikolay explains how to use that API: http://nelenkov.blogspot.nl/2012/08/accessing-embedded-secure-element-in.html. You can also browse the source code in AOSP: https://android.googlesource.com/platform/frameworks/base/+/master/nfc-extras/
UICC based secure elements and virtually any other type of secure element including embedded secure elements:
SEEK-for-Android (based on simalliance's standardized Open Mobile API)
This API is available at least in Samsung Galaxy S3, Samsung Galaxy S2 NFC, Sony Xperia S, though all three devices implement only access to the UICC through this API.
You can find details on this API here: http://code.google.com/p/seek-for-android/
Software card emulation:
Doug Yeager's extensions to the Android NFC API
These API extensions are available on CyanogenMod since 9.1 and will soon be integrated into our SuperSmile ROM. The current implementation will only work with NXP's NFC controller chipset.
Timuu-kun said:
Is there any way to perform raw reads and writes to/from the NFC module, (to replicate raw card information, for instance)
Click to expand...
Click to collapse
I'm not quite sure what you are trying to achive here.
Timuu-kun said:
What protocols are actually supported, both in secure element and software? For instance, what is the state of FeliCa emulation?
Click to expand...
Click to collapse
See above.
Hope that sheds some light on the card emulation topic.
Best regards,
Michael
kennymccormic said:
I'm not quite sure what you are trying to achive here.
Click to expand...
Click to collapse
Hello!
As far as I can understand most of the people just want to do one simple thing:
Clone any type of nfc id card and use phone instead of it. They don't want to bother with standards, interfaces, etc.
Put card on the phone, "read" it. And later "play" it. If this is not possible there is no reason to discuss it further.
HCE tools
Hi guys, just want to do an update here. ST is releasing javacard tools for cloud based SE to be used starting out on CM, but hopefully soon in AOSP....we'll see.
We are releasing a few SDK's. there is no charge to use the SDK's or make your own cards at this time. just looking for experts on the board to use it and try out some of there own applications.
basically, the idea is simple. develop your own JavaCard / Global Platform application, or just recompile your original one from a hardware based SE using eclipse tools. then upload your applet to the cloud after you are done testing.
Then using OAuth consumer, you can consumer the applet from your CM application or any other payment type application for that matter. THe cloud SE gives you backend access to an HSM, but this is abstracted through GP/JavaCard.
To present to an NFC terminal, CM or other HCE based devices are required to pass the card APDU's through the phone to the handset.
we will continue to develop and support and update these tools going forward. at this point they are pretty sparse, but smart folks could get a jump on it without too much effort.
again, this is just away to extend the SE environment to those who can't afford to buy it from a telco. so we hope that people find lots of good ways to use the SE, cause it is available now to just about anyone who wants to learn and use it.
thx guys, there are tons of smart people who follow this forum. i'm amazed at how folks figure this sh** out on next to 0 docs...
oh yeah, see the developer section on simplytapp website, the wiki is starting and you can start playing with tools there. we need bug feedback too to build out help docs. we will try to fix bugs as quick as possible.
-doug
SE dev kit for HCE applications
ST is releasing a free development kit to build your own SE applications and host them off of the mobile device.
these apps can emulate existing cards like V/MC/AMEX/DIS cards or your own cards if you have a closed loop system.
please see simplytapp.com to get the stuff you need. release is end of october 25, 2013.
-doug
[email protected] said:
ST is releasing a free development kit to build your own SE applications and host them off of the mobile device.
these apps can emulate existing cards like V/MC/AMEX/DIS cards or your own cards if you have a closed loop system.
please see simplytapp.com to get the stuff you need. release is end of october 25, 2013.
-doug
Click to expand...
Click to collapse
Will this work on CM Androids, or is there any chance that Google will open up API?
Is there any chance to working NFC HCE on Nexus 4 (Android 4.4) outsite the US?
Vojtas.m said:
Is there any chance to working NFC HCE on Nexus 4 (Android 4.4) outsite the US?
Click to expand...
Click to collapse
The HCE API is not restricted to any region, so you can already use it outside the US.
I know, but Google Wallet is and I can't find any other application which can work with it.
I've seen some post here @xda that some users even with old SGS2 (nfc edition) use it to open doors and pay for transport. And claim is was android 2.3.x.
And now we are waiting for HCE, probably backported to 4.1-4.3. I don't undertand at all...
Any update to this with the latest release of KitKat and Lollipop with their HCE libraries? Interested in Mifare Ultralight emulating via HCE. The raw data is readable.
cryzies said:
Any update to this with the latest release of KitKat and Lollipop with their HCE libraries? Interested in Mifare Ultralight emulating via HCE. The raw data is readable.
Click to expand...
Click to collapse
The Android HCE API permits emulation of ISO/IEC 7816-4 application structures only (i.e. applications that use APDUs over ISO/IEC 14443-4 and that are explicitly selected using a SELECT (by AID/DF name) APDU). So you cannot emulate MIFARE Ultralight (or any other tag type that does not speak APDUs).