baseband-devel

baseband-devel@lists.osmocom.org

2022 discussions

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 04 Oct '12

04 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 03 Oct '12

03 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 01 Oct '12

01 Oct '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 21 Sep '12

21 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 20 Sep '12

20 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

[PATCH] build: fix directory creation for core headers, introduced by d471a219
by Nico Golde 19 Sep '12

19 Sep '12

Attached is a patch for libosmocore that fixes the error mentioned in CABvrX2XCNRP+qhdW+b8eiWzCDJGVeC5vEaHfO3tOTsjaUg96Lw(a)mail.gmail.com. I guess this should be fixed in libosmocore and not osmocom-bb and the included shared library should be updated. Cheers Nico

1 0

[PATCH] build: fix directory creation for core headers, introduced by d471a219.
by Nico Golde 19 Sep '12

19 Sep '12

--- include/Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/Makefile.am b/include/Makefile.am index 61ab67d..60b9ea9 100644 --- a/include/Makefile.am +++ b/include/Makefile.am @@ -100,5 +100,5 @@ endif noinst_HEADERS = osmocom/core/timer_compat.h osmocom/core/crc%gen.h: osmocom/core/crcXXgen.h.tpl - $(AM_V_GEN)$(MKDIR_P) $(notdir $@) + $(AM_V_GEN)$(MKDIR_P) $(dir $@) $(AM_V_GEN)sed -e's/XX/$*/g' $< > $@ -- 1.7.10.4 --jRHKVT23PllUwdXP--

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel