Finding the Serial Device on HTC One

[SecUpwN]

Good evening, everyone! Since it seems that the HTC One M7 lacks /dev/radio/ (at least on my personal device), we need to find the correct Serial Device to enable scraping important values used for IMSI-Catcher and Silent SMS detection on our HTC One devices. This Issue shall be for discussing possible solutions to this - and especially for hunting down the correct Serial Device. For a great graphical explanation on how the whole Serial Device thingy works, see this post on XDA.

Since the HTC One has a Qualcomm based modem, we must have a Serial Device. Hunt it down!

---

Important Note: Finding the Serial Device is device specific. While our project really wants to support as many devices as possible, it depends on you finding the serial device (unless someone contributes a pull request with some sort of "Serial Device Crawler" which finds all Serial Devices automatically). This Issue is meant for finding the Serial Device on the HTC One device series, please let us know if the place of your Serial Device is the same when you are on another phone. This helps us improving our ATCoP.

---

Questions I'd like to see answered (@teknogeek, you are invited to respond here):

1. Is it only the HTC One M7 that has no /dev/radio/ or rather all or specific HTC One devices?
2. Can you see the file radiooptions under /system/bin/ while on Stock?
3. Can you see the file radiooptions under /system/bin/ while on Custom ROM?
4. What happens if you execute radiooptions 13 AT on root shell?
5. Can you execute AT Commands when replacing your radiooptions with this (backup first)?

Here is what I got for my own device running AOKP, which is a Custom ROM:

 root@m7:/ #radiooptions
 Usage: radiooptions [option] [extra_socket_args]
            0 - RADIO_RESET,
            1 - RADIO_OFF,
            2 - UNSOL_NETWORK_STATE_CHANGE,
            3 - QXDM_ENABLE,
            4 - QXDM_DISABLE,
            5 - RADIO_ON,
            6 apn- SETUP_PDP apn,
            7 - DEACTIVE_PDP,
            8 number - DIAL_CALL number,
            9 - ANSWER_CALL,
            10 - END_CALL

To find the correct ATCoP enabled shell serial device, please follow this post and post your findings here!

[teknogeek]

So here's the current answer that I have to your questions:

1. I have no idea about other HTC devices, but my HTC One M7 has the /dev/radio/ folder, but there is nothing in it.
2. The 4.4.2 stock ROM I am on does not have radiooptions in /system/bin/.
3. I have not looked in a custom ROM for /system/bin/radiooptions because I haven't switched ROM's in quite some time. I would think ARHD might be a good place to start.
4. Since I had no /system/bin/radiooptions to begin with, I am answering after using the replacement radiooptions from the XDA post. Upon executing radiooptions 13 AT I lose service and it acts as if the SIM card was reinserted. I plan to watch logcat -b radio later today while I execute radiooptions 13 AT.
5. TBD based on watching logcat

NOTE: I was not able to do any of this sucessfully until I acquired S-OFF today.

@SecUpwN I will keep you updated as I test more.

[E3V3A]

I don't think the radiooptions code is not going to get you anything, unless you know how to talk OEM_HOOK_RAW and IPC messages with /dev/socket/rild-debug. You can look at the debugCallback() in ril.cpp. (Note: This is not the same file as rild.c.) Now, I don't know how to use this, but the "old" special version of radiooptions is adding something there, so you need to look at the source code for that...

[SecUpwN]

First of all, thank you for your enthusiasm to contribute, @teknogeek! @E3V3A, also thanks to you for chiming in even after I cross-posted in a different Issue. Here is my idea, tell me if it is possible:

1. AIMSICD should have some sort of "automated crawling" for the correct Serial Device
2. After having found a possible one, it shall try to execute some commands to verify the findings
3. If the test commands executed successfully, AIMSICD should continue normal operation
4. If the test commands failed to execute on the "found" serial device, the following prompt should be displayed to the user: WARNING: Serial Device not found - IMSI-Catcher detection is limited! Please specify the correct Serial Device below and submit your error log to GitHub.

[teknogeek]

I'm about to head home but I've been scraping through the android source code for the location of the serial device or a hint towards how to find it. Gonna leave these here to know where to find again ;)

http://tjworld.net/wiki/Android/HTC/Vision/RadioAnalysis#TalkingtotheRadio
http://tjworld.net/wiki/Android/HTC/Vision/RadioATCommands

[E3V3A]

@teknogeek Unfortunately those pages are very outdated, both regarding the AOS and the baseband processor (BP) that device used.

@SecUpwN Sure you can, but who want to spend the time to write and debug that? I briefly tried that and found that if you try to connect to certain serial driven devices and it's not strictly using a serial protocol, have other weird settings or used by other important processes, you will lock-up the scanner process or messing up the system, while you're at it. So such a scanner would have to be more intelligent and using knowledge of the specific hardware.

Finally, if we get QMI/IPC or RIL access or ServiceMode scraping, we don't need it.

[SecUpwN]

Thanks for clarifying that an automated crawler would not be a solution to this Issue. So are you saying that we should focus on #145 to enable protection measures for HTC One devices? I am just very concerned if we will ever get there for Custom ROMs like my beloved AOKP. If searching for QMI/IPC or RIL access or ServiceMode, which of these would every ROM have? I am just trying to evaluate what makes most sense putting time and effort into, I want Custom ROMs to be able to use our App as best as possible - just like all the stock ROMs out there. So please tell me the truth on this question here.

[E3V3A]

@SecUpwN An automated device enumerator would be great, but is not worth the effort IMO. There are too many unknown variables to test for, while risking locking up your device at every step, requiring a reboot. (Things like, baudrate, echo, "tty properties" etc etc.)

Learning to use /dev/sockets/rild + rild-debug and understanding IPC's is a much more productive and general way to accomplish what we need. (QMI is using IPC.) Once we use lower level interfaces like QMI, we become HW and ROM dependent again.

[SecUpwN]

Learning to use /dev/sockets/rild + rild-debug and understanding IPC's is a much more productive and general way to accomplish what we need.

In which open Issue are we investigating this, @E3V3A? Is there anything @teknogeek and I can investigate on our phones to drive towards success? Feel free to link to specific instructions and tell us where to post our findings here on GitHub. I will close this Issue right after you've done so. Thank you!

[teknogeek]

@SecUpwN I am already looking into how to communicate with rild and rild-debug :D

[SecUpwN]

@SecUpwN I am already looking into how to communicate with rild and rild-debug :D

Great! But do we have an open Issue for this here on GitHub for everyone to follow and contribute to, @E3V3A? If not, shall I open one and link it to this Issue so that anyone reading this can jump over? I will close this Issue after E:V:A replied. Thanks for your post containing a smiley, doesn't happen every day.

[E3V3A]

All the info about how to use RIL related devices are scattered all over the place (and internet), so there is no particular issue here. The closest is the "OEM_HOOK_RAW" titled issue, but that thread is already getting very long and not very on topic. So I suggest we open a small issue here, and direct everyone to do the discussions/testings in the XDA thread, instead. Then lock the GH issue. Once we've reached enlightenment, we can post the conclusion here and close the issue. I'll open one now.

[SecUpwN]

I'll open one now.

Is it # 199 which you mean, @E3V3A? I just want this to be clear before closing this Issue.

[E3V3A]

No #200.