Passing OEM_HOOK_RAW requests about android-imsi-catcher-detector HOT 37 OPEN

I am not a developer equipped with gsm and telecommunications details but I know these guys gathering low level gsm info extending android standard sdk http://www.ascom.com/nt/en/index-nt/tems-products-3/tems-pocket-5.htm#overview. How they can do ? Tems pocket may be an inspiring product for this project.

from android-imsi-catcher-detector.

@kamilcakir, I could be wrong, but it seems that they use an external radio scanner.

feature-specific-datasheet.pdf
Scanning: LTE scanning with DRT4311B Scanner

The authors of the AIMSICD may also include support for external modems and scanners (USB or Bluetooth, 3g or 4g).

from android-imsi-catcher-detector.

Test report

ipctool and ipcdump do not exist on this device. The com.android.samsungtest package is not installed too:

# ipctool
sh: ipctool: not found
# am start -D com.android.samsungtest.RilDFTCommand --es COMMAND "at@help"
Error: Activity not started, unable to resolve Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x10000000 pkg=com.android.samsungtest.RilDFTCommand }

The service mode package on this device is com.sec.android.app.servicemodeapp, APK: /system/app/serviceModeApp_U1_EUR_OPEN.apk

Some useful secret codes:

*#1234# = Firmware Version.
*#0011# - Service mode
*#0228# - Battery Status
*#9090# - Diag Config
*#9900# - Sys dump

Sys dump allows to make a dump of logcat, modem log, ram, kernel logs, and even run tcpdump on the device. Also it allows to turn on SecLog (that are very detailed trace files in unknown binary format - err/CP_AENEAS_TRACE_*.bin, err/CP_MA_TRACE_*.bin).

The other interesting internal service is SecTelephonyProvider.apk.
Unfortunately, all the interesting services are closed for non-system applications, and I do not find a way to execute OEM_HOOK_RAW request.

Radio logs and traces are usually large and may contain private data. That is why I do not want to post them.

from android-imsi-catcher-detector.

@illarionov, thanks for posting this information. Here is the Info of my HTC ONE:

ipctool and ipcdump do also not exist on this device.

I recommend to use the Secret Codes-App to crawl your phone. Note: His App is fully Open Source and and on GitHub. Maybe developer @SimonMarquis can be of help for finding how to issue and read OEM_HOOK_RAW requests? @illarionov, do these CSC codes also exist for HTC? Do we need those?

Secret codes on my HTC ONE:

*#*#225#*#*  - Kalendar
*#*#2657#*#* - ROM Control
*#*#4636#*#* - Service Menu (Phone Information, Battery, Usage Stats, WIFI-Info)
*#*#8350#*#* - Speech Dialing
*#*#8351#*#* - Speech Dialing

from android-imsi-catcher-detector.

@SecUpwN @illarionov Did you completely stop looking at the XDA thread!? I uploaded those tools, but they "probably" don't work as expected on the HTC, (There are 2 versions in that package.)

EDIT: oops, wrong guy!

from android-imsi-catcher-detector.

@SecUpwN, CSC is not required. I post it to easily identify the firmware.

@E3V3A, I have downloaded tools that you uploaded to the device (I9100G).
The ipctool/ipcdump from tools_android_binaries does not work:

root@GT-I9100G:/sdcard/tools_android_binaries # ipctool -d 07 00 02 ff 0a 02 02
PDA to modem.
Can't connect to port 7203 (111)

root@GT-I9100G:/sdcard/tools_android_binaries# ./ipcdump -x -v                
Hexadecimal mode
Verbose mode
Can't connect to port 7203 (111)
Connection failed.(111)
Done.

Looks like those tools looking for the debug service on port 7203.

To my amazement, the ipcdump/ipcdump from sgs_note3 are works properly:

root@GT-I9100G:/sdcard/sgs_note3/ipc # ./ipctool  -d 07 00 02 ff 0a 02 02      
PDA to modem.
Connected.
[IPC message][7]
07 00 02 FF 0A 02 02 
-----------------------
7 bytes sent!.

root@GT-I9100G:/sdcard/sgs_note3/ipc # ./ipcdump -v
...
> [RSP] Miscellaneous Control : IMSI                        [1397337619.424953]
    msg_seq 0xFF ack_seq 0xCA len 23
    IMSI: 25002xxxxxxxxxx

logcat -b radio:

E/use-Rlog/RLOG-RIL(  145): ipc_debug_accept_sk:
E/use-Rlog/RLOG-RIL(  145): ipc_debug_read_ipc:
E/use-Rlog/RLOG-RIL(  145): DebugPort: Requested mode 3
E/use-Rlog/RLOG-RIL(  145): ipc_debug_read_ipc:
E/use-Rlog/RLOG-RIL(  145): IPC packet from debug port: mode 3 main 0x0A sub 0x02 len 7 dir 0
E/use-Rlog/RLOG-RIL(  145): get_msg_sequence()
E/use-Rlog/RLOG-RIL(  145):  __IPC_send_singleIPC ipc hdr len =7
E/use-Rlog/RLOG-RIL(  145): TX: Time: 1473248212 / 6761135
E/use-Rlog/RLOG-RIL(  145): TX: M:IPC_MISC_CMD S:IPC_MISC_ME_IMSI T:IPC_CMD_GET l:7 m:ca a:ff
E/use-Rlog/RLOG-RIL(  145): ipc_debug_read_ipc:
E/use-Rlog/RLOG-RIL(  145): IPC debug port disconnected.
E/use-Rlog/RLOG-RIL(  145): set_wakelock: secril_fmt-interface 1
E/use-Rlog/RLOG-RIL(  145): ReaderLoop IOCTL_MODEM_STATUS = 4
E/use-Rlog/RLOG-RIL(  145): processIPC: Single IPC plen 23, pkt 23
E/use-Rlog/RLOG-RIL(  145): [EVT]:Req(0), RX(1)
E/use-Rlog/RLOG-RIL(  145): RX: Time: 1473248225 / 6761148
E/use-Rlog/RLOG-RIL(  145): RX: M:IPC_MISC_CMD S:IPC_MISC_ME_IMSI T:IPC_CMD_RESP l:17 m:ff a:ca
E/use-Rlog/RLOG-RIL(  145): RX: -S-
E/use-Rlog/RLOG-RIL(  145): RX: 0F xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 
E/use-Rlog/RLOG-RIL(  145): RX: -E-
E/use-Rlog/RLOG-RIL(  145): [UNSOL] < 
E/use-Rlog/RLOG-RIL(  145): set_wakelock: secril_fmt-interface 0

E/use-Rlog/RLOG-RIL(  145): ipc_debug_accept_sk:
E/use-Rlog/RLOG-RIL(  145): ipc_debug_read_ipc:
E/use-Rlog/RLOG-RIL(  145): DebugPort: Requested mode 1
E/use-Rlog/RLOG-RIL(  145): ipc_debug_dump_history: log_head 516 log_tail 0 num 516
E/use-Rlog/RLOG-RIL(  145): ipc_debug_read_ipc:
E/use-Rlog/RLOG-RIL(  145): IPC debug port disconnected.

The strace shown that ipctool communicates with the RIL over the unix socket @"IPCDEBUG_UNIX_SOCKET". On the other side this socket is opened by the process /system/bin/rild.
I will try to do the same from java code.

from android-imsi-catcher-detector.

@SecUpwN @illarionov AND everyone else.
Please post you findings and discussions in the XDA thread for others to see and help.
These github threads are really for direct issues and their immediate solutions.

Also it's getting annoying to have to navigate between all these "issues" threads.

Thanks for understanding.

from android-imsi-catcher-detector.

@E3V3A, I do not like long threads in Github issues too and would have answer on the XDA, but "New members (those with fewer than 10 posts) are not permitted to post to development-related forums" :(

(It is the last my finding there) BTW, I have succesfully send IMSI request from the java code. The format of the IPC message can be found in the Replicant external_libsamsung-ipc:

# ipctool -d 07 00 02 ff 0a 02 02 

format:
  length: 07 00
  mseq: 02
  aseq: ff 
  group: 0a  (IPC_GROUP_MISC)
  index: 02  (IPC_MISC_ME_IMSI)
  type: 02  (IPC_TYPE_GET)

But before the IPC message it is necessary to send two additional requests which format I do not understand:

os.write(new byte[] {0, 3, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}); ("DebugPort: Requested mode 3")
os.write(new byte[] {0, 0, 7, 0, 0, 0, 0, 0, 0, 0, 0, 0});

UP: To my fault, this socket is opened only on CM-11 night build. On official stock firmware it is not available and ipctool does not work. :(

PDA to modem.
Can't connect to port 7203 (111)

from android-imsi-catcher-detector.

@illarionov Thanks.

1. Which ipctool are you using? (For qc or xmm?)
2. I'm on GB stock and the xmm version works.
3. What do you mean "is necessary"? When using Java API or from command line?
4. Yes, I have those lines too. I think those 2 numbers (3,7) are the DebugPort_mode and "length". (Those are probably not hex digits.) Also the port is: 127.0.0.1:7203
5. Please install socat , and don't forget to thank sordna who compiled this for me. Then run this:

for x in `seq 1 1023`; do filan -i$x | sed -r "s/^  FD.+//g"; done;

Paste output to convenient place.
6. Similarly run:

busybox ps -aef |sort -k 4
service list |sort -f -k 2

from android-imsi-catcher-detector.

1 Have tried both. On CM11-nightly works only sgs_note3 version. On official stock firmware (DBT-I9100GXXLSR) they both do not work. My comment 1 is about CM11-nightly.

2 I have strace'd traffic sent by ipctool(sgs_note3) and implement sending the same data from the JAVA code (not using ipctool).
ipctool -d 07 00 02 ff 0a 02 02 runs 3 writes to the socket:

write({0, 3, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0})
write({0, 0, 7, 0, 0, 0, 0, 0, 0, 0, 0, 0})
write({07 00 02 ff 0a 02 02})

The first write (according to radio log dump) is set DebugPort_mode to 3.
The second one is unknown. 7 is looks like length, yes.
The third one is the IPC message (IPC_TYPE_GET - IPC_GROUP_MISC - IPC_MISC_ME_IMSI).

5,6 Here is the output on the official firmware: filan, ps, service list, unix sockets, and getprop.

from android-imsi-catcher-detector.

@xLaMbChOpSx , @SecUpwN , @illarionov :
Yes, we need to know the proper format for the OEM_HOOK_RAW IPS'c, so far I have no clue good enough to pursue.

1. The easiest way would be for xLaMbChOpSx to strace the application requests that was successfully made with the previous (AOSP) versions of AIMSICD. I know the OEM_HOOK_RAW should probably be in UTF-16 format, but I have no idea how to push this from command line to this tool. (Which is why we should write our own.)
2. Can you guys confirm that it is possible to use normal binary programs from within an App on your devices? (Given that they're rooted of course.) I.e. making a shell call with something like:

"sh -c ipctool -r <blablah>"

If that is possible, I hope it could be a way to circumvent the signing issues, for ServiceMode app...

PS. You wanna use the latest strace with:

strace -a 100 -s 128 -v -y -C -f -p <program_pid>

from android-imsi-catcher-detector.

@E3V3A, I can confirm that I can use normal binary programs from within an App on my HTC One. But I guess you already know that unfortunately none of my phones has ipctool and the other trivial binaries. Building our own built-in binaries will be inevitable to lead AIMSICD to success.

from android-imsi-catcher-detector.

@SecUpwN : If you're willing to risk messing with your phone, you can try the other binary (in my toolkit), but then you need to backup and replace the other ril.so libraries, if present as such in the ROM you're using. And if that doesn't work, I think the reason is that your're using a ROM and not the official HTC libraries. I need to know how AOSP ROMs selects these libraries for each phone/model they support. Can you find that out?

from android-imsi-catcher-detector.

I think I have found a way to execute invokeOemRilRequestRaw on Samsung phones. This method does not requires any privileges and works at least on all my I9100G firmwares.
Samsung has its own undocumented(?) API for accessing RIL from multiple applications.
This API is implemented in the open source library libsecril-client-sap.

I have prepared a test application here. It executes service mode functions and displays the results. Would be great if someone runs it on the Samsung phone and report if it works. The APK should be installed as a normal application.

from android-imsi-catcher-detector.

@illarionov So it's not dependent on CM?

@xLaMbChOpSx @SecUpwN Did you see this!? If we can get away with just installing a library, then that would be uhhmm, Awesome!? I will test on my oldie tomorrow, but doubt it will work on it. I'm in the process of re-flashing a few different phones (not mine) to update API. Thanks Illy!

from android-imsi-catcher-detector.

@illarionov Couldn't resist trying. On old school junk device GB 2.3.4 I get:
"Multiclient socket is not available"... Any special requirements, APIs etc?

from android-imsi-catcher-detector.

Thanks for testing, @E3V3A! There are no special requirements, it should work right after installing.
"Multiclient socket is not available" means that on this device, this method is likely does not work :(
In any case, to figure out I need additional information on this device.

1. What is model of this device?
2. Is something appears in logcat -b radio when you execute ipctool -r on this device? ipctool uses multiclient socket too when -ris specified.
3. Output of cat /proc/net/unix
4. Exact version of the firmware (to google and download it).

from android-imsi-catcher-detector.

Whoa, awesome discovery, @illarionov! @E3V3A, as already mentioned on XDA, I have no access to my E-Mails at this very moment. This really sucks. Remember: Never change your passwords when enjoying a glas of whine. 😿 @illarionov, when running your linked Samsung RIL Multiclient test on my HTC ONE (AOKP), the output when clicking "Load" is: gsm.version.ril-impl = Qualcomm RIL 1.0

Is this the successful output we wanted to generate? If so, how can I further contribute?

from android-imsi-catcher-detector.

@illarionov This might sound weird but your test app code is absolutely beautiful I love it and to think all the trouble we have been through with platform key signing and system app installation and here you are doing it all in a standard user app! Awesome work!!

I can confirm the test app works correctly on my i9100 providing output and the ciphering indicator details.

Would you have any issues with me integrating this into AIMSICD if the others are happy for this to occur?

from android-imsi-catcher-detector.

@illarionov, you've just been awarded the gold medal by @xLaMbChOpSx! :)
I'm fire and flame to see this capability integrated as soon as possible. Go for it!

from android-imsi-catcher-detector.

@illarionov This time I'm not going to mess you guys up with my old junk. What I mean is that we should primarily aim to support for API 16 and above. My oldie SGS2 GT-I9100 with stock GB 2.3.4. is not staying like that for long. But it is still interesting to know why it doesn't work on my device, but on yours. So I decided to try cryptobin.org just for heck of it. Here's the output you requested after doing "ipctool -r" and "cat proc/net/unix":

https://cryptobin.org/n431c5b7
https://cryptobin.org/87e2l488
P: AIMSICD

(All FD devices/sockets are shown in second paste.)
Main problems are what I usually get:

E/RIL     ( 2580): requestOEMHookRaw
E/RIL     ( 2580): requestOEMHookRaw : check validity failure
E/RIL     ( 2580): RIL_onRequestComplete: tok(0x20548)

getprop
[rild.libargs]: [-d /dev/ttyS0]
[rild.libpath]: [/system/lib/libsec-ril.so]

netstatat
unix  2      [ ACC ]     STREAM     LISTENING       1311 2580/rild           /dev/socket/rild-debug
unix  2      [ ACC ]     STREAM     LISTENING       1313 2580/rild           /dev/socket/rild
unix  3      [ ]         STREAM     CONNECTED       2276 2580/rild           /dev/socket/rild

@xLaMbChOpSx I'm very happy with this, if @illarionov agree and if it works across more devices.

from android-imsi-catcher-detector.

@SecUpwN, This method will only work on Samsung devices. gsm.version.ril-impl = Qualcomm RIL 1.0 means that the device has a Qualcomm RIL implementation that is not supported.
@xLaMbChOpSx, feel free to integrate, I don't mind. Unfortunately, it seems that it only works on a small number of device models, and only on the new firmwares.

from android-imsi-catcher-detector.

@illarionov Yes, that's what I thought, and that's why I am surprised it works on @xLaMbChOpSx device, which he said was a GT-I9100T which should also be a XMM6260 (AFAIK) modem, a non-QC device. It would be helpful if he could dump some of his getprop's also.

Can you both find out what modem you have?
Either by looking HW/SW versions in service mode or by listing some more getprops.

In addition if it is a library from Replicant guys, I thought they only supported XMM modems. But perhaps since all QC leaks they've done some more progress?

EDIT
I just realized what you said and that I have miss-understood! 8 )
(And that is GOOD!)

from android-imsi-catcher-detector.

@illarionov @xLaMbChOpSx I can confirm it also doesn't work on MSM8930AB based Samsung Galaxy S4 mini (GT-I9195) running JB 4.2.2. Giving same error:
gsm.version.ril-impl = Qualcomm RIL 1.0. So for GT-I9100 should be ok.

EDIT! (Removed text)
Miss read above.

from android-imsi-catcher-detector.

This is what I have on the GT-I9100 GB234... So it should work. Perhaps a socket change/problem?

CP SW VERSION:  I9100XXKI1  
HW VERSION: MP 1.300    
FTA SW VERSION:I9100.013    
FTA HW VERSION:REV1.5       
CL NUMBER:  1058311 
IFX SW VER: SP6260_U1_01_1135
HW GPIO VER:    14

@illarionov Do you think it would work using: _/dev/socket/rild-debug_ or _/dev/socket/rild_ ?

from android-imsi-catcher-detector.

I know I have been pretty slack with the stuff from here, I have posted the output of most items that have been requested so if it helps at all it is available here:
https://cryptobin.org/i7b060j8
P:AIMSICD

Some relevant info from getprops:

[ro.telephony.ril_class]: [SamsungExynos4RIL]
[ril.sw_ver]: [I9100XXLS8] - My modem version
[rild.libargs]: [-d /dev/ttyS0]
[rild.libpath]: [/system/lib/libsec-ril.so]
[ril.hw_ver]: [MP 1.400]
[gsm.version.ril-impl]: [Samsung RIL(IPC) v2.0]

from android-imsi-catcher-detector.

Yes, I see you (obviously) have the @Multiclient socket, which I do not. I wonder when this was introduced? And also how to use it and understand it. Does it mean that it's a special socket that can handle multiple connections/ports or what?

PS. I don't like cryptobin because you cannot resize the text-box window...

from android-imsi-catcher-detector.

@xLaMbChOpSx :

1. Did you install that modem version manually? I got the latest stable SlimKat and I got a XXKI1...
2. What is the current status/plan of this? (I need to do some testing, please see addition in #23.)

from android-imsi-catcher-detector.

@E3V3A Yes I installed the modem as that gives me the best signal and data connection with my provider. I will hopefully have the new method integrated into AIMSICD in a day or two just been really busy but tonight I have been able to address some of the items you provided in other issues and will also try and get this done as well.

from android-imsi-catcher-detector.

I just read and uploaded the awesome Analysis on Mobile Phone Security, written by @MatejKovacic. In his cover-up he is mentioning that Sylvain Munaut (@smunaut), a member of the Osmocom-BB project, is developing an open source GSM baseband implementation. Furthermore, this guy has also shown how to transform an old mobile phone with Calypso chipset into a base station. I'm sure he'd be a cool addition to our project and maybe he can give some useful hints on our current challenge here?

from android-imsi-catcher-detector.

Hi,

I just read and uploaded the awesome Analysis on Mobile Phone Security
This is just a draft version, which I sent for a revision to one mailing list.
I will publish the final - and updated version - today or tommorow. Will pass the URL.

Regards,

Matej

from android-imsi-catcher-detector.

Hey @MatejKovacic, thanks for clarifying. Just paste the URL here and I'll update my upload. 👍

from android-imsi-catcher-detector.

Hi,

Hey @MatejKovacic thanks for clarifying. Just paste the URL here and I'll update my upload. 👍

Now it is published:
https://pravokator.si/index.php/2014/06/02/on-mobile-phone-security/

If you want a PDF version, I can create it (or you can copy it to LibreOffice and save as PDF).

Regards,

M.

from android-imsi-catcher-detector.

@MatejKovacic, would be great if you create a good-looking PDF and paste the link here.

from android-imsi-catcher-detector.

Hi,

@MatejKovacic https://github.com/MatejKovacic, would be great if you
create a new PDF for me and paste the link here.

It is here:

http://matthai.owca.info/On_Mobile_Phone_Security.pdf

Regards,

M.

from android-imsi-catcher-detector.

ipctool and ipcdump no found

logcat -b radio -v raw

and

. ./system/bin/am start -D com.android.samsungtest.RilDFTCommand --es COMMAND "at@help":

[ https://defuse.ca/b/ChLX8wSSi9Iw79JhqNNi1X ]
[ https://defuse.ca/b/sQcsbjTJQ6kMDV4UEXmdOs ]
[ https://defuse.ca/b/ZU4GqZnk5EpsaZuouCQ50g ]

from android-imsi-catcher-detector.

From THIS page we have one explanation for the SIM related OEM_HOOK_RAW like requests.

Let's start with the adaptions for iccOpenChannel: The main difference of the S3 is that the Samsung RILD implementation does not use specific RIL_REQUEST_SIM_* commands for the secure element access. Instead, you have to use the RIL_REQUEST_OEM_HOOK_RAW request to encapsulate the commands. From what we found, the format of these vendor-specific commands looks like this:

[command class (1 byte)] || [command (1 byte)] || [command length (2 bytes)] || [data (N bytes)]

• command class always has the value 21
• command is a 1-byte integer identifying the type of request:

        9 for open channel
        10 for close channel
        11 for sending an APDU
        12 for sending a Case-1 APDU command (no data and no expected response)

• command length is a 2-byte integer (MSB first) that contains the length of the whole command including the data field: 4 + N

This means for the iccOpenChannel command we will create a byte array with the values:

[21] [9] [4 + AID.length] [AID]

from android-imsi-catcher-detector.