Greetings,
I have been working with Layer23 stack of OsmocomBB since a couple of months. I decided to try MNCC socket interface without LCR (I'm aware there is an implementation embedded in LCR gsm-ms). I reverse engineered and wrote a simple C application taking mncc.h.
Problem: I'm unable to make a call on live network, although it does channel allocation, ciphering etc. Flow: 1. Create MNCC struct and write on to the osmocomBB socket 2. OsmocomBB parses it well and request for channel, ciphering mode, init MM, sending SETUP etc works great. 3. However, in response to step.2 after sending SETUP it returns with (ms 1) Received 'RELEASE_COMPL' in CC state INITIATED. Why does it release CC? 4. I further debugged, the reason for release is in fn. gsm48_cc_rx_release_compl in (gsm8_cc.c) it says mncc-cause = *GSM48_IE_CAUSE*. with no description.
I really don't know whats causing this issue. Any help would be much appreciated. Or It would be very kind if someone could guide me.
My mncc socket create code: struct gsm_mncc *mncc; int i = 0; int call_ref = new_callref++; mncc = create_mncc(MNCC_SETUP_REQ, call_ref);
if (!strncasecmp(number, "emerg", 5)) { printf("Make emergency call\n"); mncc->emergency = 1; } else { printf("make call to %s\n", number); mncc->fields |= MNCC_F_CALLED;
if(number[0] == '+') { number++; mncc->called.type = 1; /*international*/ } else { mncc->called.type = 0; /*auto-unknown -prefix must be used*/ } mncc->called.plan = 1; strncpy(mncc->called.number, number, sizeof(mncc->called.number) - 1); printf("Calling number %s\n", mncc->called.number);
/* bearer capability (mandatory) */ mncc->fields |= MNCC_F_BEARER_CAP; mncc->bearer_cap.coding = 0; mncc->bearer_cap.speech_ctm = 0;
mncc->bearer_cap.radio = 3; /** Support TCH/H also*/ /** Supported rates **/ mncc->bearer_cap.speech_ver[i++] = 2; /* support full rate v2 */ mncc->bearer_cap.speech_ver[i++] = 0; /* support full rate v1 */ mncc->bearer_cap.speech_ver[i++] = 1; /* support half rate v2 */ mncc->bearer_cap.speech_ver[i] = -1; /* end of list */ /** END **/ mncc->bearer_cap.transfer = 0; mncc->bearer_cap.mode = 0;
/* CC capabilities (optional) DTMF */ mncc->fields |= MNCC_F_CCCAP; mncc->cccap.dtmf = 1;
mncc->fields |= MNCC_F_CCCAP; mncc->clir.inv = 1; mncc->clir.sup = 1; }
return send_and_free_mncc(mncc->msg_type, mncc);
Looking forward to the reply, Thanks, Gerard
-- View this message in context: http://baseband-devel.722152.n3.nabble.com/OsmocomBB-MNCC-socket-implementat... Sent from the baseband-devel mailing list archive at Nabble.com.
hi Gerard,
On Fri, Mar 17, 2017 at 02:47:18AM -0700, Gerard Pinto wrote:
I have been working with Layer23 stack of OsmocomBB since a couple of months. I decided to try MNCC socket interface without LCR (I'm aware there is an implementation embedded in LCR gsm-ms).
Just a quick note: There's mncc-python at http://git.osmocom.org/mncc-python/ which you can use to interface from external programs/scripts, if you'd like.
Problem: I'm unable to make a call on live network, although it does channel allocation, ciphering etc. Flow:
- Create MNCC struct and write on to the osmocomBB socket
- OsmocomBB parses it well and request for channel, ciphering mode, init
MM, sending SETUP etc works great. 3. However, in response to step.2 after sending SETUP it returns with (ms 1) Received 'RELEASE_COMPL' in CC state INITIATED. Why does it release CC?
It would be best if yo could include GSMTAP protocol traces of such situations, so one can analyze what happens.
Also, you can compare the traces of working (no mncc?) and non-working (mncc) cases.
Regards, Harald
Hi Herald,
Thanks for the quick response! My apologize for the delay - I was close to get it working so wanted to put a mail after. GSM_TAP was the key - Thank you for this help. External CC works well now.
There was no way I could figure it out, if I hadn't enabled GSM_TAP. It said "Invalid mandatory information" Just compared mncc with internal and external CC - Debugged a little further and realized 1 of the fields of bearer_cap was missing!
mncc-python is good - I read your blog. Made some changes (socket path). Although it does fail with "Invalid mandatory information" - bearer cap missing. I will have to look again at the code.
*Just an off topic Question*. Osmo-sim-auth and pysim both same projects right? Reason I asked since, I wrote all SIM API's in osmo-sim-auth and was planning to push upstream and then realized there is a project pysim which has all of that ?
Thanks, Gerard
On Fri, Mar 17, 2017 at 8:49 AM, Harald Welte laforge@gnumonks.org wrote:
hi Gerard,
On Fri, Mar 17, 2017 at 02:47:18AM -0700, Gerard Pinto wrote:
I have been working with Layer23 stack of OsmocomBB since a couple of months. I decided to try MNCC socket interface without LCR (I'm aware there is an implementation embedded in LCR gsm-ms).
Just a quick note: There's mncc-python at http://git.osmocom.org/mncc-python/ which you can use to interface from external programs/scripts, if you'd like.
Problem: I'm unable to make a call on live network, although it does
channel
allocation, ciphering etc. Flow:
- Create MNCC struct and write on to the osmocomBB socket
- OsmocomBB parses it well and request for channel, ciphering mode, init
MM, sending SETUP etc works great. 3. However, in response to step.2 after sending SETUP it returns with
(ms 1)
Received 'RELEASE_COMPL' in CC state INITIATED. Why does it release CC?
It would be best if yo could include GSMTAP protocol traces of such situations, so one can analyze what happens.
Also, you can compare the traces of working (no mncc?) and non-working (mncc) cases.
Regards, Harald --
- Harald Welte laforge@gnumonks.org
http://laforge.gnumonks.org/
================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Hi Gerard,
On Mon, Mar 27, 2017 at 02:11:29AM -0700, Gerard Pinto wrote:
GSM_TAP was the key - Thank you for this help. External CC works well now.
great.
Just compared mncc with internal and external CC - Debugged a little further and realized 1 of the fields of bearer_cap was missing!
mncc-python is good - I read your blog. Made some changes (socket path). Although it does fail with "Invalid mandatory information" - bearer cap missing. I will have to look again at the code.
Patches are always welcome. I guess mncc-python is so far only used with OsmoNITB, and not with the MS-side MNCC on OsmocomBB. But it would be great to have this working, too.
Osmo-sim-auth and pysim both same projects right?
no. osmo-sim-auth just performs a (GSM or UMTS) authentication against a SIM card.
pySim is for programming certain cards where that is possible (like MagicSIM, sysmoSIM, sysmoUSIM, etc.)
I think there are two distinct purposes and it makes sense to have two different tools. But yes, it probably could make sense to merge the code in one repository and simply have multiple executables for that.
Would you be interested in merging the two, i.e. provide an incremental patchset against pysim that adds the osmo-sim-auth binary?
Reason I asked since, I wrote all SIM API's in osmo-sim-auth and was planning to push upstream and then realized there is a project pysim which has all of that ?
Sorry to hear that. pySim-prog actually existed for much longer time, it is what we always used to program SIM Cards ever since 2009.
Hi Herald,
Thank you for your responses. I appreciate you taking out time from your schedule. Just a couple of things I would like to share since my interest grew in telecom.
1) Have you or your team tried to reverse engineer/hacking Over the Air OTA spec - firmware upgrade (understanding this type of communication) using OpenNITB and latest phones where bootloaders are locked?
- I was planning to try this! But now I will take up merging osmo-sim-auth and py-sim. (I'm not a great dev but I'm passionate about osmocom and willing to contribute my time to learning/contributing the same).
2) I have been trying something different with OsmocomBB, osmo-sim-auth and Tor lately - I would like to hear your views on the same. Attack Model: Geo-Location Anonymous calling in GSM.
Description: 1. The attacker uses OsmocomBB phone to make a call using a sim card service. (No sim card present in the phone). 2. For this, I have taken the SIM card outside OsmocomBB and re-written all SIM API's in osmo-sim-auth (which is the sim card service). 3. This sim card service is deployed over Tor network, so no one can actually know the location of the SIM card service. 4, The osmocombb connects to the network and uses this sim card service for authentication etc. 5. The whole setup of calling etc is initiated by the sim card service, which is itself behind Tor.
6. Now, This SIM card service can be used my multiple phones, so now you are not exactly going to track the phone since if I use the SIM card service to another phone (cell area) the DB entry in VLR has changed which says the location has changed. 7. My experiments worked well on a LIVE network, understanding the delay in Tor the network, still, the BTS was accepting RES response challenge from the SIM card service behind Tor - I still have to calculate the exact max acceptable delay in sending RES back to BTS to confirm this!
Look forward to hearing from you!
Thanks, Gerard
On Mon, Mar 27, 2017 at 2:29 AM, Harald Welte laforge@gnumonks.org wrote:
Hi Gerard,
On Mon, Mar 27, 2017 at 02:11:29AM -0700, Gerard Pinto wrote:
GSM_TAP was the key - Thank you for this help. External CC works well
now.
great.
Just compared mncc with internal and external CC - Debugged a little further and realized 1 of the fields of bearer_cap was missing!
mncc-python is good - I read your blog. Made some changes (socket path). Although it does fail with "Invalid mandatory information" - bearer cap missing. I will have to look again at the code.
Patches are always welcome. I guess mncc-python is so far only used with OsmoNITB, and not with the MS-side MNCC on OsmocomBB. But it would be great to have this working, too.
Osmo-sim-auth and pysim both same projects right?
no. osmo-sim-auth just performs a (GSM or UMTS) authentication against a SIM card.
pySim is for programming certain cards where that is possible (like MagicSIM, sysmoSIM, sysmoUSIM, etc.)
I think there are two distinct purposes and it makes sense to have two different tools. But yes, it probably could make sense to merge the code in one repository and simply have multiple executables for that.
Would you be interested in merging the two, i.e. provide an incremental patchset against pysim that adds the osmo-sim-auth binary?
Reason I asked since, I wrote all SIM API's in osmo-sim-auth and was planning to push upstream and then realized there is a project pysim
which
has all of that ?
Sorry to hear that. pySim-prog actually existed for much longer time, it is what we always used to program SIM Cards ever since 2009.
--
- Harald Welte laforge@gnumonks.org
http://laforge.gnumonks.org/
================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Hi Gerard
2017. márc. 28. dátummal, 9:10 időpontban Gerard Pinto gerardfly9@gmail.com írta:
- I have been trying something different with OsmocomBB, osmo-sim-auth and Tor lately - I would like to hear your views on the same.
Attack Model: Geo-Location Anonymous calling in GSM.
Description:
- The attacker uses OsmocomBB phone to make a call using a sim card service. (No sim card present in the phone).
- For this, I have taken the SIM card outside OsmocomBB and re-written all SIM API's in osmo-sim-auth (which is the sim card service).
- This sim card service is deployed over Tor network, so no one can actually know the location of the SIM card service.
4, The osmocombb connects to the network and uses this sim card service for authentication etc. 5. The whole setup of calling etc is initiated by the sim card service, which is itself behind Tor.
- Now, This SIM card service can be used my multiple phones, so now you are not exactly going to track the phone since if I use the SIM card service to another phone (cell area) the DB entry in VLR has changed which says the location has changed.
- My experiments worked well on a LIVE network, understanding the delay in Tor the network, still, the BTS was accepting RES response challenge from the SIM card service behind Tor - I still have to calculate the exact max acceptable delay in sending RES back to BTS to confirm this!
This is a very interesting idea, I like it! I wanted to mention the SAP protocol that is available in OsmocomBB's mobile app via a Unix domain socket since some time now. It might be even easier to use it for your idea. I used it via an external card reader and softSIM to provide a SIM card for OsmocomBB.
Cheers,
Domi
Hi Domi,
Thanks! While I building the same, I was wondering 'may be SAP protocol' was built for it. But thanks again for confirming it! And Yes, I used an external card reader too. I did not check all osmocom projects, just checked out softSIM it does mention SAP. Sounds great! Thanks for the feedback again.
Thanks, Gerard
On Tue, Mar 28, 2017 at 12:27 AM, Tomcsányi, Domonkos domi@tomcsanyi.net wrote:
Hi Gerard
- márc. 28. dátummal, 9:10 időpontban Gerard Pinto <
gerardfly9@gmail.com> írta:
- I have been trying something different with OsmocomBB, osmo-sim-auth
and Tor lately - I would like to hear your views on the same.
Attack Model: Geo-Location Anonymous calling in GSM.
Description:
- The attacker uses OsmocomBB phone to make a call using a sim card
service. (No sim card present in the phone).
- For this, I have taken the SIM card outside OsmocomBB and re-written
all SIM API's in osmo-sim-auth (which is the sim card service).
- This sim card service is deployed over Tor network, so no one can
actually know the location of the SIM card service.
4, The osmocombb connects to the network and uses this sim card service
for authentication etc.
- The whole setup of calling etc is initiated by the sim card service,
which is itself behind Tor.
- Now, This SIM card service can be used my multiple phones, so now you
are not exactly going to track the phone since if I use the SIM card service to another phone (cell area) the DB entry in VLR has changed which says the location has changed.
- My experiments worked well on a LIVE network, understanding the delay
in Tor the network, still, the BTS was accepting RES response challenge from the SIM card service behind Tor - I still have to calculate the exact max acceptable delay in sending RES back to BTS to confirm this!
This is a very interesting idea, I like it! I wanted to mention the SAP protocol that is available in OsmocomBB's mobile app via a Unix domain socket since some time now. It might be even easier to use it for your idea. I used it via an external card reader and softSIM to provide a SIM card for OsmocomBB.
Cheers,
Domi
Hi Gerard,
On Tue, Mar 28, 2017 at 12:08:49AM -0700, Gerard Pinto wrote:
- Have you or your team tried to reverse engineer/hacking Over the Air OTA
spec - firmware upgrade (understanding this type of communication) using OpenNITB and latest phones where bootloaders are locked?
I haven't looked at this personally, but several people have looked at security of several different OTA updates for about a decade by now. The main issue is that there is no standard protocol or system, and everyone cooks up their own.
- I was planning to try this! But now I will take up merging osmo-sim-auth
and py-sim. (I'm not a great dev but I'm passionate about osmocom and willing to contribute my time to learning/contributing the same).
thanks!
- I have been trying something different with OsmocomBB, osmo-sim-auth and
Tor lately - I would like to hear your views on the same. Attack Model: Geo-Location Anonymous calling in GSM.
Description:
- The attacker uses OsmocomBB phone to make a call using a sim card
service. (No sim card present in the phone). 2. For this, I have taken the SIM card outside OsmocomBB and re-written all SIM API's in osmo-sim-auth (which is the sim card service). 3. This sim card service is deployed over Tor network, so no one can actually know the location of the SIM card service. 4, The osmocombb connects to the network and uses this sim card service for authentication etc. 5. The whole setup of calling etc is initiated by the sim card service, which is itself behind Tor.
This is basically the sim card forwarding / remote SIM, which people have been experimenting on SIMtrace for quite some time. In this case you can use any regular phone or modem, and don't need osmocombb. There is a complete 'remote sim / card emulation' proof of concept in the simtrace2.git repository, but this requires a prototype of the simtrace 2.x hardware (with SAM3) and not the old/current simtrace 1.x hardware (with SAM7).
Also, there are plenty of commercial suppliers of systems like you have described.
a) in the area of automatic roaming testing (between operators) b) in the area of automatic service quality testing (between operators) c) in the grey area of so-called SIM-boxes, where you have hundreds to thousands of SIM cards in one data center, which you can remotely provision to any number of "GSM VoIP gateways" spread in different countries. This is typically used for interconnection fraud by shady operators.
None of the above use Tor (as they have different use cases), but the option 'c' at least also uses IMEI randomization to avoid tracking the subscriber via his IMEI, which presumably you would want to do in your OsmocomBB based system, t..
- Now, This SIM card service can be used my multiple phones, so now you
are not exactly going to track the phone since if I use the SIM card service to another phone (cell area) the DB entry in VLR has changed which says the location has changed.
Yes, but you have to be very quick. Of course from the time of the LU throughout the call, your position is known to the observer. Not because of your IMSI or IMEI (which you both keep changing) but because of the phone numbers you call.
It depends on what you want to defend against. Basically you can do this already if you carry around a huge bag of sim cards which you always only use for a single call, *and* you have a phone that can change the IMEI every time you change the SIM. This is apparently what e.g. human rights activists in hostile countries are doing.
However, the biggest problem in such situations is not your own identity, but the identities you contact. So if you keep calling the same destination number, all of the above is useless as the key to find you is by the destination number. So at the same time, you require a potentially large number of phone numbers that are not in some way associated to another (and at best in different countries), which then provide call redirect to your real destination.
- My experiments worked well on a LIVE network, understanding the delay in
Tor the network, still, the BTS was accepting RES response challenge from the SIM card service behind Tor - I still have to calculate the exact max acceptable delay in sending RES back to BTS to confirm this!
I think I remember that at least 2 if not 4 seconds of delay are acceptable for the complete authentication handshake. People are even doing this over satellite back-haul.
Hi Herald,
Thanks for the in-depth view. Something that I missed out and you mentioned - IMEI randomization (I haven't done this) And also for introducing me to SIMtrace. As soon as I am done with this one, I will look into pysim and SIMtrace.
Herald, I wish you good luck for OsmoCon2017 good success. I wish to attend it someday, I look forward to hear about the session on 2.5G services and Fundamental GSM radio frequency planning.
Thanks for the help so far! Gerard.
On Tue, Mar 28, 2017 at 2:45 AM, Harald Welte laforge@gnumonks.org wrote:
Hi Gerard,
On Tue, Mar 28, 2017 at 12:08:49AM -0700, Gerard Pinto wrote:
- Have you or your team tried to reverse engineer/hacking Over the Air
OTA
spec - firmware upgrade (understanding this type of communication) using OpenNITB and latest phones where bootloaders are locked?
I haven't looked at this personally, but several people have looked at security of several different OTA updates for about a decade by now. The main issue is that there is no standard protocol or system, and everyone cooks up their own.
- I was planning to try this! But now I will take up merging
osmo-sim-auth
and py-sim. (I'm not a great dev but I'm passionate about osmocom and willing to contribute my time to learning/contributing the same).
thanks!
- I have been trying something different with OsmocomBB, osmo-sim-auth
and
Tor lately - I would like to hear your views on the same. Attack Model: Geo-Location Anonymous calling in GSM.
Description:
- The attacker uses OsmocomBB phone to make a call using a sim card
service. (No sim card present in the phone). 2. For this, I have taken the SIM card outside OsmocomBB and re-written
all
SIM API's in osmo-sim-auth (which is the sim card service). 3. This sim card service is deployed over Tor network, so no one can actually know the location of the SIM card service. 4, The osmocombb connects to the network and uses this sim card service
for
authentication etc. 5. The whole setup of calling etc is initiated by the sim card service, which is itself behind Tor.
This is basically the sim card forwarding / remote SIM, which people have been experimenting on SIMtrace for quite some time. In this case you can use any regular phone or modem, and don't need osmocombb. There is a complete 'remote sim / card emulation' proof of concept in the simtrace2.git repository, but this requires a prototype of the simtrace 2.x hardware (with SAM3) and not the old/current simtrace 1.x hardware (with SAM7).
Also, there are plenty of commercial suppliers of systems like you have described.
a) in the area of automatic roaming testing (between operators) b) in the area of automatic service quality testing (between operators) c) in the grey area of so-called SIM-boxes, where you have hundreds to thousands of SIM cards in one data center, which you can remotely provision to any number of "GSM VoIP gateways" spread in different countries. This is typically used for interconnection fraud by shady operators.
None of the above use Tor (as they have different use cases), but the option 'c' at least also uses IMEI randomization to avoid tracking the subscriber via his IMEI, which presumably you would want to do in your OsmocomBB based system, t..
- Now, This SIM card service can be used my multiple phones, so now you
are not exactly going to track the phone since if I use the SIM card service to another phone (cell area) the DB entry in VLR has changed
which
says the location has changed.
Yes, but you have to be very quick. Of course from the time of the LU throughout the call, your position is known to the observer. Not because of your IMSI or IMEI (which you both keep changing) but because of the phone numbers you call.
It depends on what you want to defend against. Basically you can do this already if you carry around a huge bag of sim cards which you always only use for a single call, *and* you have a phone that can change the IMEI every time you change the SIM. This is apparently what e.g. human rights activists in hostile countries are doing.
However, the biggest problem in such situations is not your own identity, but the identities you contact. So if you keep calling the same destination number, all of the above is useless as the key to find you is by the destination number. So at the same time, you require a potentially large number of phone numbers that are not in some way associated to another (and at best in different countries), which then provide call redirect to your real destination.
- My experiments worked well on a LIVE network, understanding the delay
in
Tor the network, still, the BTS was accepting RES response challenge from the SIM card service behind Tor - I still have to calculate the exact max acceptable delay in sending RES back to BTS to confirm this!
I think I remember that at least 2 if not 4 seconds of delay are acceptable for the complete authentication handshake. People are even doing this over satellite back-haul.
--
- Harald Welte laforge@gnumonks.org
http://laforge.gnumonks.org/
================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
baseband-devel@lists.osmocom.org
-
Gerard Pinto -
Harald Welte -
Tomcsányi, Domonkos