- baseband-devel - lists.osmocom.org

Re: How much protection does an add-on GSM modem give me vs. built into phone ?
by Peter Zotov 04 Oct '12

04 Oct '12

Denis 'GNUtoo' Carikli писал 04.10.2012 15:07: > On Thu, 04 Oct 2012 14:53:08 +0400 > Peter Zotov <whitequark(a)whitequark.org> wrote: > >> Denis 'GNUtoo' Carikli писал 04.10.2012 14:26: >> > On Thu, 4 Oct 2012 00:32:48 +0200 >> > Peter Stuge <peter(a)stuge.se> wrote: >> > >> >> John Case wrote: >> >> > the real trick I am interested is isolating (or at least >> >> > controlling) the interaction between the baseband processor and >> >> the >> >> > application processor. Using a computer with a USB dongle >> gives >> >> me >> >> > that control ... would I have that same level of control if we >> >> > had free software running on the baseband processor, or is >> there >> >> > still additional bleeding possible simpy by virtue of being >> >> > built into the computer ? >> >> >> >> In a smartphone it's almost not possible to distinguish the >> >> "computer" from the "GSM modem" anymore, because of how the >> >> hardware is constructed, so yes. >> > In some yes, in some no... it depend on how the smartphone was >> > designed: >> > >> > On one end some smartphones (openmoko GTA02,golden delicious >> > GTA04), the >> > baseband is isolated(tough on GTA04 it has access to a GPS with no >> > antenna(so it can't work)) . And on the other end there are >> > smartphones >> > with qualcomm System on a chip...where the modem and the CPU are >> in >> > a single chip: >> > The modem part has the audio DSP connected to it, the GPS. >> > And the baseband uses shared RAM memory and shared NAND(if I >> > remember well)... >> > And I'm not sure but maybe the baseband is even needed for booting >> > the >> > main CPU... >> > >> > There are also systems in between like the galaxy S/Neuxs S that >> > uses shared memory but do not have other problems... >> >> In addition to the above, there are some phones where baseband is >> completely >> submissive to the AP, namely Galaxy SII. Basically it's exactly the >> same >> as the USB dongle situation, but the dongle is integrated on the >> phone's >> PCB. > Did you check what the modem transport was(shared memory, high speed > serial etc...)? > > Denis. HSIC. It's basically USB but with a slightly altered physical layer to acommodate the unusual topology. http://www.synopsys.com/dw/dwtb/hsic_usb2_device/hsic_usb2_device.html There is no shared memory or, in fact, any other connections between BP and interfaces of the phone. Audio is transferred via the same USB, for example. GPS technically has some relation with the BP, I'm not absolutely sure which precisely, but you can a) upload reference SiRF firmware to the GPS, thus rendering any changes Samsung put to the latter void and b) AP controls !RESET pins of both GPS and BP. It's trivial to not allow both to run simultaneously. -- WBR, Peter Zotov.

1 0

Re: How much protection does an add-on GSM modem give me vs. built into phone ?
by Peter Zotov 04 Oct '12

04 Oct '12

Denis 'GNUtoo' Carikli писал 04.10.2012 14:26: > On Thu, 4 Oct 2012 00:32:48 +0200 > Peter Stuge <peter(a)stuge.se> wrote: > >> John Case wrote: >> > the real trick I am interested is isolating (or at least >> > controlling) the interaction between the baseband processor and >> the >> > application processor. Using a computer with a USB dongle gives >> me >> > that control ... would I have that same level of control if we had >> > free software running on the baseband processor, or is there still >> > additional bleeding possible simpy by virtue of being built into >> > the computer ? >> >> In a smartphone it's almost not possible to distinguish the >> "computer" from the "GSM modem" anymore, because of how the >> hardware is constructed, so yes. > In some yes, in some no... it depend on how the smartphone was > designed: > > On one end some smartphones (openmoko GTA02,golden delicious GTA04), > the > baseband is isolated(tough on GTA04 it has access to a GPS with no > antenna(so it can't work)) . And on the other end there are > smartphones > with qualcomm System on a chip...where the modem and the CPU are in a > single chip: > The modem part has the audio DSP connected to it, the GPS. > And the baseband uses shared RAM memory and shared NAND(if I remember > well)... > And I'm not sure but maybe the baseband is even needed for booting > the > main CPU... > > There are also systems in between like the galaxy S/Neuxs S that uses > shared memory but do not have other problems... In addition to the above, there are some phones where baseband is completely submissive to the AP, namely Galaxy SII. Basically it's exactly the same as the USB dongle situation, but the dongle is integrated on the phone's PCB. > > Denis. -- WBR, Peter Zotov.

1 0

Re: How much protection does an add-on GSM modem give me vs. built into phone ?
by John Case 04 Oct '12

04 Oct '12

> First, stay away from Qualcomm-based phones. In them the baseband controls > all physical memory, as documented in the Replicant project, and thus has > control over the application processor (the "unix computer"). Ok. So what I am shooting for is a firewall between the baseband processor and the application processor, and I was indeed correct that in a "real" mobile phone there is a lot of bleeding between the two. > Second, even Infineon-based phones are not completely safe, however you can > use Replicant on the Nexus S, and thus there is no proprietary binaries (on > the Unix side) and less risk of meddling from a third party. However, this > won't prevent a baseband exploit from doing evil stuff. In addition there > are Android vulnerabilities constantly appearing, last one as you may have > heard concerned the SGS3's NFC stack. Well, that is why I said "unix computer" and not specifically android - if I am running a computer (like a samsung galaxy player) then I could do something besides android, and perhaps gain quite a bit of control. > Finally, the scenario you suggest (connecting a 3G USB modem) to a computer > seems very impractical although it adds a layer of safety since the > microphone will be fully under the control of the system you trust. However > battery life will probably be very, very short as compared to your current > 2G phone. Yes, ok. Battery life is bad, as well as the physical logistics of connecting a full sized USB dongle to a micro-USB port, etc. > By the way, as documented in presentations at CCC, Blackhat, etc. GSM > networks are not safe, there are multiple vulnerabilities ranging from > offline decryption of comms to active mitm attacks. 3G networks use > stronger, mutual authentication and do not suffer from this. In several > phones, such as the Nexus S, you can force the network mode to 3G only and > therefore have a better level of security. Yes, but the real trick I am interested is isolating (or at least controlling) the interaction between the baseband processor and the application processor. Using a computer with a USB dongle gives me that control ... would I have that same level of control if we had free software running on the baseband processor, or is there still additional bleeding possible simpy by virtue of being built into the computer ? Also, just for my own notes, what is the industry term for "making changes to application processor side of customers handset?" I have heard of some regular examples of how carriers update things and enforce changes to phones in this way (or relock them ?) but what is the term for that behavior ? Thanks.

3 2

How much protection does an add-on GSM modem give me vs. built into phone ?
by John Case 03 Oct '12

03 Oct '12

I use an old 2G dumbphone. I would like to switch and begin carrying a unix computer with me, but two things bother me: 1. When cellular device is added to computer, and integrated in a deep way (as it is in an android phone) there seem to me a lot of instances where the computer is subservient to the cellular partsof the phone. I am thinking about things like carrier published updates to applications and carrier updates to SIM data, etc. - I want to participate on the mobile phone network, but I do not want the carrier to have any access to my unix computer. It seems to me that they have a lot of access, though, when I use something like an android phone. 2. Exploits ... baseband exploits, mobie network exploits, forced dialing, speaker/mic toggling, root exploits like I saw described from rogue cellsites at defcon 2 years ago ... I want nothing to do with this. So my current thought is to not buy a phone at all, but instead buy a unix computer - perhaps the samsung galaxy player ? It is a near-clone of Samsung i9000, but without any phone hrdware (but it does have speaker and mic, so you could use it as a very nice SIP device). And my idea is that when I do not have WIFI access, I could connect a USB GSM modem to this unix computer and use the GSM modem ONLY for data, and connect SIP calls that way. My questions: 1. Am I correct that embedding the mobile components into the computer (like in a mobile phone) give my carrier many more vectors for accessing the computer side of things, and ive "mallory" many more vectors for attack ? I spoke very generally above about those methods - what are the actual names for these behaviors ? 2. Am I correct that if I connect a external GSM modem to my unix computer, I am nullifying most of these, and I am not giving my carrier any abiity to update/examine/alter/access my unix computer .... and am also avoiding things like secretly enabling the microphone, baseband exploits, etc. ? Any additional thoughts on using a computer instead of a phone, and then adding a GSM modem when that is the only way to get SIP connectivity ? Thanks.

1 0

Re: Why not a nexus chipset ?
by Peter Zotov 02 Oct '12

02 Oct '12

Maciej Grela писал 02.10.2012 02:00: >> My colleague/friend Sergey Gridassov[1] has been developing a >> replacement >> RIL[2] >> for SGS2 and found everything of the above. He probably won't be >> posting to >> this list because he's not a native English speaker, but if there is >> enough >> interest (and it seems that there is), I could prepare and post the >> relevant >> instructions. It's pretty trivial actually. >> > > Please do publish them. This is pretty cool. > > Regards, > Maciej Grela Assuming you know C, consider this code: https://github.com/grindars/android_hardware_samsung_freeril/blob/jellybean… The boot process is IROM->PSI->EBL->SecureImage. Authenticity of PSI is not checked. He has verified this by changing the magic constant 0xDEADDEAD and booting PSI. Speaking about 0xDEADDEAD, it's a command ID which makes the PSI make a complete RAM dump. So, then he has sent the modified command and successfully obtained a dump. The rest should be obvious from the source. -- WBR, Peter Zotov.

1 0

cppcheck/pyflakes results for osmocom-bb
by Paul Wise 30 Sep '12

30 Sep '12

Hi all, I noticed that cppcheck and pyflakes are detecting some possible issues in the osmocom-bb codebase on the master branch: ./src/target_dsp/calypso/dump2coff.py:3: 'namedtuple' imported but unused ./src/host/fb_tools/bdf_to_c.py:30: 'string' imported but unused [src/host/layer23/src/common/main.c:146]: (error) Possible null pointer dereference: app_opp [src/host/gsmmap/gsmmap.c:379] -> [src/host/gsmmap/gsmmap.c:384]: (error) Possible null pointer dereference: meas - otherwise it is redundant to check it against null. [src/shared/libosmocore/src/gb/gprs_bssgp.c:1076] -> [src/shared/libosmocore/src/gb/gprs_bssgp.c:1041]: (error) Possible null pointer dereference: dup - otherwise it is redundant to check it against null. [src/shared/libosmocore/src/gb/gprs_bssgp.c:1087] -> [src/shared/libosmocore/src/gb/gprs_bssgp.c:1041]: (error) Possible null pointer dereference: dup - otherwise it is redundant to check it against null. [src/shared/libosmocore/src/gb/gprs_bssgp.c:1088] -> [src/shared/libosmocore/src/gb/gprs_bssgp.c:1041]: (error) Possible null pointer dereference: dup - otherwise it is redundant to check it against null. [src/shared/libosmocore/src/gsm/lapd_core.c:1936] -> [src/shared/libosmocore/src/gsm/lapd_core.c:1948]: (error) Possible null pointer dereference: msg - otherwise it is redundant to check it against null. [src/target/firmware/apps/chainload/main.c:39]: (error) Possible null pointer dereference: entry [src/target/firmware/apps/loader/main.c:92]: (error) Possible null pointer dereference: entry [src/target/firmware/apps/loader_mtk/main.c:87]: (error) Possible null pointer dereference: entry [src/target/ui-experiment/png2tiny.c:20]: (error) printf format string has 1 parameters but only 0 are given. [src/target/firmware/rf/mt6139.c:138]: (error) Uninitialized variable: pga_gain -- bye, pabs http://bonedaddy.net/pabs3/

3 3

[PATCH] gsm_utils.c: cleanup + do not use dynamic memory when decoding 7bit messages
by Nico Golde 21 Sep '12

21 Sep '12

Hi, attached is a patch that cleans up gsm_7bit_decode_hdr() a little and removes the need for calloc/free. This way, this function can be used on systems that do not have the required allocation routines (e.g. a layer1 firmware). This is a bit selfish, as I personally need it :) Cheers Nico

4 7

[PATCH] gsm_utils.c: in 7bit decoding, first check if the last character was an extension character before doing anything else
by Nico Golde 20 Sep '12

20 Sep '12

--- src/gsm/gsm_utils.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/src/gsm/gsm_utils.c b/src/gsm/gsm_utils.c index 6af0a5f..8b1fae0 100644 --- a/src/gsm/gsm_utils.c +++ b/src/gsm/gsm_utils.c @@ -146,15 +146,15 @@ int gsm_7bit_decode_hdr(char *text, const uint8_t *user_data, uint8_t septet_l, (user_data[((i + shift) * 7) >> 3] >> (((i + shift) * 7) & 7))) & 0x7f; - if (c == 0x1b && i + 1 < septet_l) { - next_is_ext = 1; - continue; - } - /* this is an extension character */ if (next_is_ext) { next_is_ext = 0; *(text++) = gsm_7bit_alphabet[0x7f + c]; + continue; + } + + if (c == 0x1b && i + 1 < septet_l) { + next_is_ext = 1; } else { *(text++) = gsm_septet_lookup(c); } -- 1.7.10.4 --4Ckj6UjgE2iN1+kY--

1 0

[PATCH] Decoding UCS2 USSD
by Pavel Baturko 20 Sep '12

20 Sep '12

Hi, I create patch with added decoding of UCS2 USSD messages. Text in UCS2 is printed on 'mobile' console and status is sent to vty since there is no support of wide characters in vty. Added constants to decode GSM 7bit text when DCS is specified as 0x00, 0x01. I tested it with Russian language with several providers and all works ok. Thanks, Pavel

4 9

Sept 19, 8pm / Osmocom Berlin User Group meeting
by Harald Welte 19 Sep '12

19 Sep '12

Hi all! This is the announcement for the next Osmocom Berlin meeting. Sept 19, 8pm @ CCC Berlin, Marienstr. 11, 10113 Berlin There is no formal presentation scheduled for this meeting. If you are interested to show up, feel free to do so. There is no registration required. The meeting is free as in "free beer", despite no actual free beer being around. Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

2 1