Re: [A51] Reporting in.. (what's there, what's missing and some ideas?)
On 24/07/10 19.30, Harald Welte wrote: > Please focus your scarce resources where it is really needed... > Harald, i think that you are absolutely right however let me say that doing r&d in telephony it's really a pain and it's a kind of knowledge not very widespread into the hacking community. Usually that's more considered like a techie stuff for TLC experts, radio frequency, difficult protocol to deal with, closed hardware, legal issues and so the environment it's still not knowledgeable enough. Few hackers i know, know what TCH or GPRS Reliability class mean. The entrance barrier (due to telco technology lobbying) to play with those stuff was very high and you and all you guys have the very great and fantastic merit to have opened this environment by providing the building-blocks of software and hardware interaction to play with it. I would like to try to summarize what i understood of the situation and status of the projects and propose some ideas. If i got the point, now we are in a stage where the various technologies require final improvement (from networking side) and different pieces of various projects could be reused for such improvements, particularly for airprobe. >From outside, trying to deal with the various projects, the feeling is that is still a quite disperse set of projects. At 1st attempt it's still quite difficult to understand which are the pieces of the puzzle and how to make what you want to do. That's not easy like playing with the WiFi hacking stuff . People will get crazy when GSM hacking will become something similar to WiFi hacking, in practical term, and more people involved and more people acquiring knowledge on that stuff but at higher level. :-) But security people that want to play with a51 stuff just for security (not being tlc protocol experts) before investing money to buy the hardware typically want to be sure to be able to use it. Still some not major but very important works (compared to previous activity) need to be done to reach that stage (i mean respect to people using it only for security playground without having to know the wide GSM protocol stacks in details). >From what i understood of the various pieces (pls correct me if i am wrong): @ OpenBTS is a BTS software hooked directly (no BSC support )with Asterisk for telephony service, that works with USRP1 @ Airprobe is GSM network sniffer whose oline documentation refer to USRP1 @ OsmocomBB provide: - Baseband processor firmware including all gsm layers protocol stack implementation (cool!) - Radio driver that's compatible with certain Motorola, Sony Ericsson and and OpenMoko @ OpenBSC is a Base Station Controller (BSC) to be used with BTS Siemens BS11 microBTS and ip.access nanoBTS and require an E1 telephony card for interconnection @ A5/1 Security project make the software for cracking by generating and using rainbow tables (recently improved by Frank Stevenson). It has been reported that it worked (with airprobe?) with two USRP2 units (but no public technical setup instruction). @ A5/1 Rainbow tables in size of 2TB are ready and already available to several people in the community Do i got the point or i am missing / misunderstood something? So to summarize, from what i understood, to make the gsm cracking working in real-world environment we still miss: @ Improvement of Airprobe monitoring software (proper demodoulation) to stay up with recording long call and properly following channels (Part of it getting improved by Sascha, part by Piotr?) @ A first full howto on detailed setup hw/sw instruction for a working setup to let ppl start with higher level hacking (should come from Karsten at BH next week?) @ A community / system for Rainbowtable distribution that can scale-up to hundreds of users Do i understood properly or there's something else? Below some ideas about that. @ About missing code of airprobe / other tools? Regarding what's still missing, would it reasonable also to provide something bounties like "Google summer of code" for specific features / module? I mean, it's true that voluntary based development it's the best things but providing some economic incentive for opensource development always help, also getting smart young ppl on-board (you do something fun and challenging and earn some money for holidays). We can arrange some fund raising to support also a bounty based development program on the projects. In past i organized oss development funding with osxcrypt.org project and in 2 days collected 1500USD among the security community. Probably we can get much more. Does this could be an approach that help? @ About documentation I am available to come for a weekend with the proper hardware (within Europe), together with who have the deep project knowledge prepare a setup from scratch, by writing in the meantime the documentation for the hw/sw setup for who don't know anything about the internals/details of the projects but want to start playing with it. It's summer an
Re: [A51] Reporting in.. (what's there, what's missing and some ideas?)
Hi Fabio, On Sun, Jul 25, 2010 at 12:48:16PM +0200, Fabio Pietrosanti (naif) wrote: > On 24/07/10 19.30, Harald Welte wrote: > > Please focus your scarce resources where it is really needed... > > > > Harald, i think that you are absolutely right however let me say that > doing r&d in telephony it's really a pain and it's a kind of knowledge > not very widespread into the hacking community. yes. But like everything else in computer sciece, it's something that everyone with a basic background in CS or EE can learn with reasomable effort. > If i got the point, now we are in a stage where the various technologies > require final improvement (from networking side) and different pieces of > various projects could be reused for such improvements, particularly for > airprobe. > > From outside, trying to deal with the various projects, the feeling is > that is still a quite disperse set of projects. > At 1st attempt it's still quite difficult to understand which are the > pieces of the puzzle and how to make what you want to do. > That's not easy like playing with the WiFi hacking stuff . Sure. But this hasn't really changed much in a number of years for now. The various projects that form airprobe are around for 2-3 years (at least), and none of the people who have managed to reproduce the setup have decided to write documentation or improve the projects much. > People will get crazy when GSM hacking will become something similar to > WiFi hacking, in practical term, and more people involved and more > people acquiring knowledge on that stuff but at higher level. :-) > But security people that want to play with a51 stuff just for security > (not being tlc protocol experts) before investing money to buy the > hardware typically want to be sure to be able to use it. sure, but you can just work with existing capture/sample files of GSM and work on them. Of course you shouldn't do this on real-world data from real-world operators - but there are more than 70 people who have bought an inexpensive Siemens BS-11 BTS plus more people with ip.access nanoBTS who can run OpenBSC (which has encryption + authentication support) and establish encrypted calls on suhc a cell. Samples from that traffic can legally be distributed without any legal issues. And everyoen can test, play with and improve the software tools before he decides on buying any hardware. > From what i understood of the various pieces (pls correct me if i am wrong): > @ OpenBTS is a BTS software hooked directly (no BSC support )with > Asterisk for telephony service, that works with USRP1 ACK. It can be used with other USRP frontends or even other SDR with relatively few code changes. Some of thoes changes have been posted as patches to the list. > @ Airprobe is GSM network sniffer whose oline documentation refer to USRP1 ACK. You can use any frontend, and you can also use it with USRP2. In fact, you can use it with any > @ OsmocomBB provide: > - Baseband processor firmware including all gsm layers protocol stack > implementation (cool!) > - Radio driver that's compatible with certain Motorola, Sony Ericsson > and and OpenMoko ACK. you can use this to "run a phone" with control over all layers of the protocol stack. > @ OpenBSC is a Base Station Controller (BSC) to be used with BTS Siemens > BS11 microBTS and ip.access nanoBTS and require an E1 telephony card for > interconnection E1 only in case of the BS11 > Do i got the point or i am missing / misunderstood something? seems fine to me. > So to summarize, from what i understood, to make the gsm cracking > working in real-world environment we still miss: > > @ Improvement of Airprobe monitoring software (proper demodoulation) to > stay up with recording long call and properly following channels (Part > of it getting improved by Sascha, part by Piotr?) ACK. > @ A first full howto on detailed setup hw/sw instruction for a working > setup to let ppl start with higher level hacking (should come from > Karsten at BH next week?) ACK > @ A community / system for Rainbowtable distribution that can scale-up > to hundreds of users ACK. > Do i understood properly or there's something else? It might be worth publishing a summary paper that covers all the available tools, just like your outline above. > @ About missing code of airprobe / other tools? > Regarding what's still missing, would it reasonable also to provide > something bounties like "Google summer of code" for specific features / > module? I don't think bounties will help. There should be plenty of people with motivation, but apparently not enough people with the combination of available time, skill set and "self-esteem" (i.e. they can do it even if there is no 1:1 detailed instructions they can follow) > @ About documentation > I am available to come for a weekend with the proper hardware (within > Europe), together with who have the deep project knowledge prepare a > setup from scratch, by writing in the mean
Re: [A51] Reporting in.. (what's there, what's missing and some ideas?)
On 25/07/10 19.40, Harald Welte wrote: > Sure. But this hasn't really changed much in a number of years for now. > The various projects that form airprobe are around for 2-3 years (at least), > and none of the people who have managed to reproduce the setup have > decided to write documentation or improve the projects much. > Ok, i just ordered USRP1 + DBRX + Antenna with express shipping and i'm seeing to retrieve a copy of the 2TB rainbow tables. So i should be equiped to be able to run with both OpenBTS and Airprobe. When hardware will arrive i will start playing with it to get enough basic knowledge of the software setup and see which are the difficulties i will encounter, documenting the setup process, what would require better explanation and basic tool usage in a "howto" approach. I hope that most of the information would be provided also by Karsten in the BH talk, in order to make even easier that job of writing down an howto for non-gsm-protocol-stack-coder and non-hardcore-cryptoanalyst . :-) > sure, but you can just work with existing capture/sample files of GSM and > work on them. Of course you shouldn't do this on real-world data from > real-world operators - but there are more than 70 people who have bought > an inexpensive Siemens BS-11 BTS plus more people with ip.access nanoBTS > who can run OpenBSC (which has encryption + authentication support) and > establish encrypted calls on suhc a cell. Samples from that traffic > can legally be distributed without any legal issues. And everyoen can > test, play with and improve the software tools before he decides on buying > any hardware. > Let's discuss about the legal framework more in details. I think that basically it's just illegal to receive and transmit on exclusively licensed frequencies such as 900mhz and 1800mhz, independently from the fact that you are listening and cracking your own SIM card connected to your the mobile operator. So in theory also making TX/TR with Siemens BS-11 BTS plus or ip.access nanoBTS would just be illegal. I am going to write to the mailing list Italian Lawyer Association for IT Laws (www.csig.it) to check and get a picture about it regarding italian laws (or whether there's some european wide regulation). I know for sure that there are 2 different authorization, one for being ham radio (TX/RX on certain freq.) and one for being a radio listener (that i don't know if there are freq. limits). I am going to write to the mailing list Italian Lawyer Association for IT Laws (www.csig.it) to check and get a picture about it. Are there in germany specific rules related to: - Acquiring permission for research - Acquiring permission for limited radio emission - Acquiring permission for radio listening ? If there's a legal framework that allow to transmit and receive on those frequencies, which kind of laws interpretation affect the differences between listening your own BTS respect to listening the mobile operator BTS by cracking SIM card of your subscription? You are on the same frequency in both case. I think that regarding the privacy and monitoring laws if i am aware of the tapping or i am authorized by the owner of the subscription, the subject's privacy would not be broken. So, give the permission to make radio listening on certain frequencies, there would be different accusation related to listening mobile operator specific channels (given that you are listening only yourself). Additionally, does the airprobe allow to filter precisely which on-air data to dump (a specific IMSI) or does it read and work on other radio streams that does not strictly relate to the specific IMSI connection? For example with WiFi hacking and cracking you are listening on 2.4ghz frequency spectrum where a lot of AP exist, but you record and crack only the data related to the AP or user you want to hack (and for which may be authorized). >> @ Airprobe is GSM network sniffer whose oline documentation refer to USRP1 >> > ACK. You can use any frontend, and you can also use it with USRP2. In fact, > you can use it with any > Ok, i got the point. But just now the code that can be downloaded from the SVN already works with USRP1 and with USRP2 or it require code hacking to basically work with one of them? And both USRP1 and USRP2 will be usable with the upcoming airprobe improvements or there is some code logic that's specific to USRP1 or USRP2? If both are compatible, which are the practical advantages/disadvantages of using USRP1 respect to using USRP2 for playing with airprobe? >> @ OpenBSC is a Base Station Controller (BSC) to be used with BTS Siemens >> BS11 microBTS and ip.access nanoBTS and require an E1 telephony card for >> interconnection >> > E1 only in case of the BS11 > On the BTS procurement, which are the most accessible sources (shops, distributors, etc) to acquire it in Europe (or even in South America, USA and Asia? That way we can provide hints on how to get the hardware for BTS. >> @ A
Re: [A51] Reporting in.. (what's there, what's missing and some ideas?)
Im in the same waiting list. I ordered a USRP2 + a couple of receivers for other research also so Im killing 2 birds with 1 stone in my case. Ive started to read everything out there on the subject and its very enlightening. Regarding legalities, please keep us informed, although each country varies. On Sun, Jul 25, 2010 at 11:47 PM, Fabio Pietrosanti (naif) wrote: > On 25/07/10 19.40, Harald Welte wrote: >> Sure. But this hasn't really changed much in a number of years for now. >> The various projects that form airprobe are around for 2-3 years (at least), >> and none of the people who have managed to reproduce the setup have >> decided to write documentation or improve the projects much. >> > Ok, i just ordered USRP1 + DBRX + Antenna with express shipping and i'm > seeing to retrieve a copy of the 2TB rainbow tables. > So i should be equiped to be able to run with both OpenBTS and Airprobe. > > When hardware will arrive i will start playing with it to get enough > basic knowledge of the software setup and see which are the difficulties > i will encounter, documenting the setup process, what would require > better explanation and basic tool usage in a "howto" approach. > > I hope that most of the information would be provided also by Karsten in > the BH talk, in order to make even easier that job of writing down an > howto for non-gsm-protocol-stack-coder and non-hardcore-cryptoanalyst . :-) >> sure, but you can just work with existing capture/sample files of GSM and >> work on them. Of course you shouldn't do this on real-world data from >> real-world operators - but there are more than 70 people who have bought >> an inexpensive Siemens BS-11 BTS plus more people with ip.access nanoBTS >> who can run OpenBSC (which has encryption + authentication support) and >> establish encrypted calls on suhc a cell. Samples from that traffic >> can legally be distributed without any legal issues. And everyoen can >> test, play with and improve the software tools before he decides on buying >> any hardware. >> > Let's discuss about the legal framework more in details. > > I think that basically it's just illegal to receive and transmit on > exclusively licensed frequencies such as 900mhz and 1800mhz, > independently from the fact that you are listening and cracking your own > SIM card connected to your the mobile operator. > So in theory also making TX/TR with Siemens BS-11 BTS plus or ip.access > nanoBTS would just be illegal. > > I am going to write to the mailing list Italian Lawyer Association for > IT Laws (www.csig.it) to check and get a picture about it regarding > italian laws (or whether there's some european wide regulation). > > I know for sure that there are 2 different authorization, one for being > ham radio (TX/RX on certain freq.) and one for being a radio listener > (that i don't know if there are freq. limits). > I am going to write to the mailing list Italian Lawyer Association for > IT Laws (www.csig.it) to check and get a picture about it. > > Are there in germany specific rules related to: > - Acquiring permission for research > - Acquiring permission for limited radio emission > - Acquiring permission for radio listening > ? > > If there's a legal framework that allow to transmit and receive on those > frequencies, which kind of laws interpretation affect the differences > between listening your own BTS respect to listening the mobile operator > BTS by cracking SIM card of your subscription? You are on the same > frequency in both case. > I think that regarding the privacy and monitoring laws if i am aware of > the tapping or i am authorized by the owner of the subscription, the > subject's privacy would not be broken. > So, give the permission to make radio listening on certain frequencies, > there would be different accusation related to listening mobile operator > specific channels (given that you are listening only yourself). > > Additionally, does the airprobe allow to filter precisely which on-air > data to dump (a specific IMSI) or does it read and work on other radio > streams that does not strictly relate to the specific IMSI connection? > > For example with WiFi hacking and cracking you are listening on 2.4ghz > frequency spectrum where a lot of AP exist, but you record and crack > only the data related to the AP or user you want to hack (and for which > may be authorized). > >>> @ Airprobe is GSM network sniffer whose oline documentation refer to USRP1 >>> >> ACK. You can use any frontend, and you can also use it with USRP2. In fact, >> you can use it with any >> > Ok, i got the point. > But just now the code that can be downloaded from the SVN already works > with USRP1 and with USRP2 or it require code hacking to basically work > with one of them? > And both USRP1 and USRP2 will be usable with the upcoming airprobe > improvements or there is some code logic that's specific to USRP1 or USRP2? > If both are compatible, which are the practical advantages/disadvantages > of u
Re: [A51] Reporting in.. (what's there, what's missing and some ideas?)
Hi, > Ok, i just ordered USRP1 + DBRX + Antenna with express shipping and i'm > seeing to retrieve a copy of the 2TB rainbow tables. > So i should be equiped to be able to run with both OpenBTS and Airprobe. OpenBTS won't work without a RX/TX setup obviously ... (You can extract the RX code and try to run it separatly but that's not out of the box stuff) > I think that basically it's just illegal to receive and transmit on > exclusively licensed frequencies such as 900mhz and 1800mhz, > independently from the fact that you are listening and cracking your own > SIM card connected to your the mobile operator. Transmitting without authorization in licensed bands, I'm sure it's illegal in nearly all countries. For reception only tough I think it depends on where you are. In belgium, in all the legislation I read, it's not illegal to receive only. (Of course, targeting other people conversation and/or deciphering other things than your own is illegal, but that's covered by 'privacy/wiretapping' laws rather than purely radiotelecom ones) > So in theory also making TX/TR with Siemens BS-11 BTS plus or ip.access > nanoBTS would just be illegal. You can get experimental low power licences relatively cheaply in some countries. (Here in belgium you'll have to go through a company that must have some telecom related business but that's not hard to do) Also you can skip the 'air' step with a big attenuator in the middle works just great. i.e. Connect the BTS output directly to the USRP via an attenuator. (DO NOT forget the attenuator or your usrp will be short lived !) > But just now the code that can be downloaded from the SVN already works > with USRP1 and with USRP2 or it require code hacking to basically work > with one of them? I think airprobe just require code hacking anyway :) > And both USRP1 and USRP2 will be usable with the upcoming airprobe > improvements or there is some code logic that's specific to USRP1 or USRP2? > If both are compatible, which are the practical advantages/disadvantages > of using USRP1 respect to using USRP2 for playing with airprobe? airprobe currently uses a 'standard' gnuradio graph. The only USRP1 specific block is the signal source, just remove it and instanciate a USRP2 rx block in the python code and it shoudl work fine, pretty easy to do. Cheers, Sylvain ___ A51 mailing list A51@lists.reflextor.com http://lists.lists.reflextor.com/cgi-bin/mailman/listinfo/a51
Re: [A51] Reporting in.. (what's there, what's missing and some ideas?)
On 25/07/10 19.40, Harald Welte wrote: > seems fine to me. > USRP1 hardware are coming. The 2TB tables are coming (will share it online over a 50Mbps connection for 2-3 months). Next week i should be able to start practical hands-on hacking on the gsm security stuff. By looking at the documentation and at the tools currently available it seems to me that's still something else missing. Let me over-summarize the flow for a typical use: 0) USRP1 + DBRX + 900mhz antenna listen to airtraffic 1) Airprobe dump the phone call traffic - We know that it require important improvement for demodulation of real signals - We have to see which is the best pratical approach to do it, to detect the call, to follow it and which procedure must be implemented 2) Kraken crack the call a5/1 Kc key (that's the most important piece) 3) Some piece of sw decrypt the a5/1 encrypted dump generated by Airprobe with the Kc cracked by Kraken. 4) Some piece of sw must have the capability to extract from the decrypted dump the audio flow in GSM or AMR audio format 5) Mplayer replay the intercepted, recorded, decrypted phone call I understand that there are those limits of airprobe that require strong improvement in progress. But point "3" and "4" (like post-processing) are already implemented or on-the-way somehow in some of the sub projects ? Fabio ___ A51 mailing list A51@lists.reflextor.com http://lists.lists.reflextor.com/cgi-bin/mailman/listinfo/a51
Re: [A51] Reporting in.. (what's there, what's missing and some ideas?)
On Wed, 2010-07-28 at 19:20 +0200, Fabio Pietrosanti (naif) wrote: > 1) Airprobe dump the phone call traffic > - We know that it require important improvement for demodulation of > real signals > - We have to see which is the best pratical approach to do it, to > detect the call, to follow it and which procedure must be implemented > > 2) Kraken crack the call a5/1 Kc key (that's the most important piece) > > 3) Some piece of sw decrypt the a5/1 encrypted dump generated by > Airprobe with the Kc cracked by Kraken. > There is a intermediate step here which one shouldn't forget. One needs to find and identify known plaintext, which can be different from network to network. So for initial decryption one will gave to find a way to get Kc from ones SIM card, and use that to decrypt and analyze call setup (on own conversations). This item is probably already made, but should be on the list. An alternative may be to use a straight dump from a Nokia phone. Frank ___ A51 mailing list A51@lists.reflextor.com http://lists.lists.reflextor.com/cgi-bin/mailman/listinfo/a51
Re: [A51] Reporting in.. (what's there, what's missing and some ideas?)
So the known plain text is a fixed length string, or can it differ dramatically. If it is somewhat fixed we can ask the members to contribute their known plain text into a database in order for others to use. On Wed, Jul 28, 2010 at 10:34 PM, Frank A. Stevenson wrote: > On Wed, 2010-07-28 at 19:20 +0200, Fabio Pietrosanti (naif) wrote: > >> 1) Airprobe dump the phone call traffic >> - We know that it require important improvement for demodulation of >> real signals >> - We have to see which is the best pratical approach to do it, to >> detect the call, to follow it and which procedure must be implemented >> >> 2) Kraken crack the call a5/1 Kc key (that's the most important piece) >> >> 3) Some piece of sw decrypt the a5/1 encrypted dump generated by >> Airprobe with the Kc cracked by Kraken. >> > > There is a intermediate step here which one shouldn't forget. One needs > to find and identify known plaintext, which can be different from > network to network. So for initial decryption one will gave to find a > way to get Kc from ones SIM card, and use that to decrypt and analyze > call setup (on own conversations). This item is probably already made, > but should be on the list. An alternative may be to use a straight dump > from a Nokia phone. > > Frank > > > ___ > A51 mailing list > A51@lists.reflextor.com > http://lists.lists.reflextor.com/cgi-bin/mailman/listinfo/a51 > ___ A51 mailing list A51@lists.reflextor.com http://lists.lists.reflextor.com/cgi-bin/mailman/listinfo/a51
Re: [A51] Reporting in.. (what's there, what's missing and some ideas?)
> So the known plain text is a fixed length string, or can it differ > dramatically. > If it is somewhat fixed we can ask the members to contribute their > known plain text into a database in order for others to use. Not read far enough into GSM 04.08 I see :) That plain text will depend on the cell you're on. But by establishing a channel yourself you can gather most of it. Trust me, I know for a fact that using SI5/SI6 (and SI5bis SI5ter if applicable) provide plenty of easily generated plain text. Playing with the CIPHER MODE RESPONSE or the LAPDm ACKs isn't even needed ... Sylvain ___ A51 mailing list A51@lists.reflextor.com http://lists.lists.reflextor.com/cgi-bin/mailman/listinfo/a51
