This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/baseband-devel@lists.osmocom.org/.
Sylvain Munaut 246tnt at gmail.com> - what could happen if i will clone one SIM (Ki, IMSI) and use it to
> register on the same network, but on different BTS/LAC, two phones? Which
> will be rejected as first? Or both?
If you do that, it will send a LOC.UPD.REQ in another LAC ... which is
exactly the same as if you moved your phone to that LAC ... it's a
perfectly valid situation and it's fully specified. Only the latest
registration is valid.
> - if i will send an IMSI detach with one of them... also the other (that is
> phisically in another BTS/LAC) will be disconnected?
As mentionned above : Only one can be active at a time. (the latest
location update), so ... not applicable.
> - what could happen if i will connect a C123 with ./mobile to the network
> using another SIM and then trying to forge IMSI_DET_IND with victim's
> IMSI/TMSI and send to the network where the victim is connected (that could
> mean the same network, but different BTS/LAC), this DoS will still be
> accomplished?
Only the behavior if the message is sent in the same LAC is specified.
What happens in other situation is implementation dependent. Some
network will detach, others won't ... no way to tell and neither
behavior is "wrong" per-spec.
Most will simply ignore the message. Some will accept it ...
Note that the network can also be configured not to use the detact
procedure at all and then ignores all detach messages.
What happens when a detach is sent _while_ a call is active on the
target is also dependent. Some network (including my home network)
instantly disconnect the active call. Some other networks don't ...
> What exactly i would like to know is, if someone already made some
> experiments on it (obviously on private networks, with a legal experimental
> license.) and eventually if there are any interesting results.
It's been tested on commercial networks (with consenting targets
obviously) and it works exactly as expected. And since we're only
sending perfectly formed/valid messages to the network, there
shouldn't be a problem. The issue here is not a bug, it's a specified
behavior / messages that can be exploited.
Cheers,
Sylvain