AT Command Interface

[Kml55]

I am browsing the source code. I do not have a rooted phone but I am wondering the AT Command injection output. Can you provide application screenshots ?

[E3V3A]

This feature doesn't work at the moment. Only if you use an AOSP based ROM and the older alpha-0.1.4.

[Kml55]

When AT Command injection feature works, will it be possible to list some low level gsm values such as bsic,bcch etc..?

[E3V3A]

That depends, but it certainly would make it easier. Because then we know what to talk with and how, and we can use IF to set the appropriate MUXing to dump diagnostics. Goto XDA thread and try some of the stuff I've mentioned there and post the results.

[SecUpwN]

@kamilcakir, we first need to solve Issue #27. You're invited to help us!

[E3V3A]

@xLaMbChOpSx Would you be able to re-introduce the AT command stuff now? I'm thinking as a separate page, that you access by either: (a) menu item or (b) screen side-slide. I need to do some testing on the XMM modem ATs so if the manual AT entry option is still available that would be great. Or is it better if I just download the old version?

[E3V3A]

@xLaMbChOpSx In response to comments in #66.

I understand the MultiRIL is probably Samsung and device specific, but I think it's the only solution we have that have given us partial success. At least that was my impression from the early AT query in the old release, but I don't know, since I was not able to test it at that time. So what I suggest is that you make a "device" check on the AT command "page", and just disable it for non Samsung devices as we did for non-CDMA devices in the FemtoCell detector part. Another thing about that, as far as I have (mis?)understood the RIL_REQUEST_OEM_HOOK_STRINGS is not used when communicating with AT interface, since the internal ATCoP (interpreter) seem to process one character at the time. At least that was my impression from studying the RIL behavior in the old S2's GB 2.3.4.

Surely, we will continue to look for correct AT terminal on our devices, but it is damn hard since no one seem even remotely interested in trying things and doing this.

Another thing I found, is that issuing the following command, gives your IMEI:

u0_a202@MSM8960:home # service call iphonesubinfo 3
Result: Parcel(
  0x00000000: 00000000 0000000f 00340032 00300030 '........2.4.0.0.'
  0x00000010: 00300030 00300030 00300030 00300038 '0.0.0.0.0.0.0.8.'
  0x00000020: 00390037 00000035                   '7.9.5...        ')

I have no idea where (what APP) this comes from, and need to be looked into. However, I have some shell problems on that device, severely restricting editing and control characters, and not being able to investigate deeper at this moment.

[SecUpwN]

Surely, we will continue to look for correct AT terminal on our devices, but it is damn hard since no one seem even remotely interested in trying things and doing this.

That might be correct for the majority of people who are lazy and are just using our App instead of supporting development, @E3V3A. To be honest, I am more than willing to even BRICK MY DEVICE for this project to succeed, but I'm still missing an idiot-proof instruction on how to test and what to report to drive progress forward. Might be, that most people like me are just confused with all the commands to issue. Recalling my conversation with you via PM on XDA, I remember that you suggested writing a script that will automatically do the required tests to collect what we need. I very much support this idea - I'm sure many people would contribute their results and we'd reach our goal much faster. If possible, would you please start up on the code of such a script and upload it to our repository?

[E3V3A]

@xLaMbChOpSx @SecUpwN Since I can't find the last working AT injector version, I'd like to build this by myself, where and how do I activate the AT injector in the current version?

[SecUpwN]

Hey @E3V3A, I'm sorry you're having such trouble finding it (and I know you can't await until the AT Command Injector works again). As far as I know, WIP-Release v0.1.4-alpha was the version before it's functionality got removed. Would you please try that one? Hope it helps you with the testing. Good luck!

[E3V3A]

@SecUpwN That was still a signed version, which doesn't install. So it would be better to try to build this.

[SecUpwN]

@xLaMbChOpSx, would you please chime in and either give @E3V3A instructions on how to build a version with re-enabled AT Command-Injector? Or maybe (and I would much prefer it) could you push a new WIP-Release with fully re-enabled AT Command-Injector and bugfixes (although not very much tested yet)? I'd like @E3V3A to be able to run his much desired tests, maybe he'll find out useful stuff..

[E3V3A]

@xLaMbChOpSx and @SecUpwN and @He3556
I now have local shell access to the AT Command Processor (ATCoP) interface, on the Qualcomm MSM8930AB based S4-mini (GT-I9195). All the details in THIS XDA POST. (Phone is rooted but in Enforcing mode and rild + server is NOT killed!)

[SecUpwN]

AWESOME! Congratulations, @E3V3A! 👑

[xLaMbChOpSx]

@E3V3A Great work on getting the AT access on your device if you like I can now attempt to implement a method that uses your findings into the AT Command Injector fragment, I did a quick check on my device (i9100) and it shows ttyS0 as the ril device but I have not had a chance to test it fully using your instructions yet.

Would you like me to try and get this incorporated tomorrow night for you to test? It will mean invoking that section of the app will require root but it would only be requested IF a user attempted to use the AT Command injector. Let me know and I will get cracking on it straight away.

[E3V3A]

@xLaMbChOpSx That would be just excellent! I just added some afterthoughts and further instructions in a later post. Can you verify, if your device is using a Multiclient RIL? Perhaps you and others can post your devices + services + getproperty'ies in the XDA thread for me to look at, in case you can't get it to work.

Happy Midsummer!

[SecUpwN]

Let me say a HUUGE THANK YOU to @E3V3A for figuring out how to implement AT Command Injection and @xLaMbChOpSx for coding it! I updated the AT Command Injection WIKI. Shall we close this now?

[E3V3A]

Just to be clear. AT does not work for XMM modem based devices, AFAICT. (I would love to hear of a verified success.) Probably only for Qualcomm, unless also other people can start to test and report and respond to my XDA posts. It should work for MTK based ones...

[SecUpwN]

@E3V3A, I would like to add some instructions to the AT Command Injection WIKI:

• What users can do with it
• What we are searching for with it
• Which things they should report

Maybe you can take a minute to update the WIKI entry? I hope people will submit their results.

[E3V3A]

@SecUpwN Wow!! Very nice.

[andr3jx]

Hi, the AT command injection doesn't work at the moment on my MTK device.
The serial devices we need are here:
I have a dual SIM device, so atci1 is for first SIM, and atci2 for second SIM.

root@wiko:/dev/radio # ls
atci1
atci2
ptty2cmd1
ptty2cmd2
ptty2cmd3
ptty2cmd4
ptty2noti
pttycmd1
pttycmd2
pttycmd3
pttycmd4
pttynoti
pttyvt                         
root@wiko:/dev/radio # cat atci1&
[1] 5867                           
root@wiko:/dev/radio # echo -e "AT\r" > atci1
root@wiko:/dev/radio # 
OK

130|root@wiko:/dev/radio # echo -e "AT+cind=?\r" > atci1                       
root@wiko:/dev/radio # 
+CIND:("battchg",(0-5)), ("signal",(0-5)), ("service",(0,1)), ("message",(0,1)),("call",(0,1)), ("roam",(0,1)), ("smsfull",(0,1))

OK

130|root@wiko:/dev/radio # echo -e "AT+cfun=?\r" > atci1                       
root@wiko:/dev/radio # 
+CFUN: (0,1,4),(0,1)

OK

Maybe you can also make it work without root on MTK. Use the same approach like in the engineer menu (.invokeOemRilRequestStrings)..

Maybe out of place here: My device is dual SIM, so it has also two separated radios. If I use the first SIM / radio the app works, but if I use only the second SIM/ radio it crashes immediately on start.

[E3V3A]

@andr3jx : Please also post your findings in the XDA thread, where it can also be found helpful to others. From your log above, it seem that this works, which is very good. The AT interface is very alpha and was only enabled to get more developing input from our users, like you. Thank you.
(Brilliant use of 'bash' for code quoting. Worked surprisingly well!)

I'm sure @xLaMbChOpSx will implement your /dev device in one of next releases. Just to make sure, please also post the output of the ATI and AT+CSQ AT commands. (Remove your IMSI/IMEI if shown). For dual SIM support, you will have to wait, no support planned yet.

EVERYONE:
To make your AT command line testing a little easier, copy and paste this shell function to your command line:

say () {
    echo -e "$1\r" >/dev/smd0
}

[Change the device name "smd0" to what you found working.] Then use with: say ATI, for example.

[andr3jx]

Ok, posted to our XDA thread ;)

[andr3jx]

@xLaMbChOpSx, I tested AIMSICD 0.1.21 and experienced some problems. It is possible to use atci1 but I get often "Command Timeout/ No Response". In logcat I can still see the response. So we need to find a more reliable way to obtain the response. This problem also persists when I do AT Injection using shell, so I think cat is not optimal for obtaining the response. Another bug: AT Injector doesn't save the serial device I selected. Everytime I leave AT Injector and come back, it adds again all serial devices and tries to use /dev/ttyC0

[E3V3A]

@andr3jx :
Yes, the ATCoP is a slow "thing", it's just a matter of time-out and in addition the ATCoP may cancels current requests, if the modem RTOS is too busy, like when receiving new network info or changing connection state. I think this could be debugged with PC-to-phone MTK Catcher, QXDM or Xgoldmon and wireshark. But then we would not know how to fix it anyway. So that is above our current possibilities, until we can get RF debug interface access. The ATCoP response can take up to 20 seconds for some requests. So this is far from an ideal interface to use, but is the only one working for us at this time, apart the Samsung ServiceMenu requests.

To use something else than cat, we had to use a proper device connection, that is non-blocking and would require more programming. Maybe better, but timing issues would remain.

If you suffer time-out issues, please try to close down the use of other RF related applications.
(And let us know if that helps.)

@xLaMbChOpSx : Can you increase the time-out for AT request, maybe to 10 seconds?

[tobykurien]

@E3V3A AT command injector looks the same to me on the latest code - I see the "current serial device", "detected devices", etc. Check that you have given super user permission, perhaps?

[E3V3A]

@tobykurien su has never been a problem (for me). The AT injector worked fine in 0.1.21 and hasn't worked since. It is probably because you guys insists in testing this on custom ROM devices and searching for/using the the wrong modem devices, by making assumptions, that only work on your ROMs. One such faulty assumption, is to think that AT interface can always be obtained from rild.libargs. But this is rarely true, which is why we have to allow manually selecting the device. Going on like this will never solve this problem. I just made b14 and although the interface now shows correctly, we get a new error:

Response:
*** Setting Up... Ignore any errors. ***
*** Setup Complete ***
Found: /dev/radio//dev/radio: No such file or directory

As for solving the previous builds error, (which from the PR's still have not been addressed.) Please do the following:

1. Allow user to select device.
2. When running cat /dev/smd0 &, please fetch the sub-shell PID.
3. Then when writing AT command, please
   • a) use the letter case as as supplied (i.e. remove the toUpper() thing.)
   • b) be ready to wait a while for the response. Some network operations can take up 15-20 seconds.
4. After result or timeout, kill the PID, or that device will be locked-up until next reboot.

[tobykurien]

@E3V3A I understand your frustration at the issues you are having. A couple of points:

• I am not intentionally adding bugs to any part of this app, esp. the AT Command injector. Please have a look at the history of this functionality: https://github.com/SecUpwN/Android-IMSI-Catcher-Detector/commits/master/app/src/main/java/com/SecUpwN/AIMSICD/fragments/AtCommandFragment.java - you will see that I've only made a 1 line change so that it doesn't overlay itself on top of other fragments. I've also included the RootTools source, which is probably newer than the JAR file we had.
• I make no assumptions about the AT interface, I don't even know what rild.libargs is. The response you show above is what I've always seen from this app, even from before I worked on it.
• I will not currently make any changes to AT command injector, because I don't understand it fully on a technical level. It also does not work on any of my devices.
• I am sorry that I don't have a stock device to test with. This is another reason I cannot work on the AT command injector.

My hope is that @xLaMbChOpSx will return and continue work on this. I'm sorry that I cannot help.

[E3V3A]

@tobykurien No of course you're not adding bug intentionally and I certainly didn't mean it to sound like that. Sorry if it did. The changes that broke it, was made long before you came into the picture. We may consider temporarily pulling this code out and make it to a stand-alone app, that can be more easily tested. Once that works, we can put it back in. (Just a suggestion.)

However, since it did work a couple of alpha versions before, it should be easy to fix. But I'm not sure how to best do code diff's on older versions. I think there was a lot of other changes at that time, that would mask the functionality of the ATCoP interface.

[E3V3A]

Ok, I've upgraded my mksh function that should handle the entire AT sequence in one go. This is also the PoC on how it should be implemented in the App. Please note that a root shell has to be available.

Also note that newer SuperSU versions (>1.99) may require you to specify a SELinux context. For me, the u:r:init_shell:s0 seem to work, so the shell should probably be started with something like: su -cn u:r:init_shell:s0 -c "COMMAND".

say() {
    ATDEV="/dev/smd0"
    cat ${ATDEV} & ZATPID=$!; 
    echo "ATCoP interface PID: $ZATPID";
    sleep 2
    echo -e "$1\r" >${ATDEV}
    sleep 10
    eval '[ -d "/proc/$ZATPID" ] && kill -15 $ZATPID'
    unset ATDEV
}

Then edit the ATDEV to what you actually have. (Don't ask me.) The 2 second sleep is critical for working, but the 10 second wait for response may not be enough. For example the AT command AT+COPS? can take up to 30 seconds. So the App need to inform user of this time delay.

How To Use: Edit and copy paste this in a root shell, then use it with (for example): say ati.

@tobykurien Can you have another look at this?

EDIT: 20141201 Fixed code typo

[SecUpwN]

@E3V3A, what was the solution to the missing /dev/radio/ on the HTC One M7/8 devices again? I know you told me before, but would you please refresh my mind? I've been asked by @teknogeek1 on XDA who's got the same Issue like me - we never had any output from the AT Command Processor so far. Where should I continue to do research to finally enable AT Commands for our beloved HTC One?

[andr3jx]

@SecUpwN /dev/radio is only available on (Dual SIM?) MTK devices. The AT command injector just looks for serial devices which are specified. For most phones we don't know the serial device or it can't be accessed easily so you can't expect that it works on many phones. On HTC devices you can try to use radiooptions 13 AT.

[SecUpwN]

Thanks for your response, @andr3jx. Issuing radiooptions 13 AT to the ATCOP does not show any response, neither through using Better Terminal Emulator Pro. Digging further into this, the default radiooptions only seems to go up to option 10 - END_CALL. Do we need to replace radiooptions?

 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

I remember E:V:A having posted a full version of radiooptions on our XDA thread, but essentially I would like our App to work on HTC One devices without having to replace stuff. Can't we add some sort of "search algorithm" to the ATCOP to find the right serial device or use any other working commands?

[E3V3A]

@SecUpwN We've already discussed this in considerable length in the XDA thread. Please look there. This issue is to fix what used to work, so if you didn't have (or found) AT interface before, it will not resolve that problem with this issue in the future. You either have an AT enabled device under /dev or you don't, simple as that. Then it's entirely up to you how to find it, since it is device specific. On Qualcomms we know there is always one, same on most MTKs. On XMM's and yours, no idea.

[andr3jx]

@SecUpwN You used logcat -b radio to monitor for response, right?

[SecUpwN]

@SecUpwN You used logcat -b radio to monitor for response, right?

Yes, I did. But since value 13 does not exist, I am probably on my own here.

We've already discussed this in considerable length in the XDA thread. Please look there.

I know you are annoyed by this, @E3V3A. I'm just trying to support this device class too, especially since I love HTC myself and will never buy anything else. Just two last questions regarding the HTC One:

1. If the HTC One series does not feature AT commands, what is the "replacement" instead? This?
2. What is it that I need so search for on the HTC One series to find or enable detection values?

---

• If both questions above are answered, I will open a fresh Issue for this to digg down deeper there.

Thank you for your patience with my questions. Hope @tobykurien will continue here. Peace out.

[andr3jx]

@SecUpwN Wait - you don't have stock ROM, do you? I can imagine this is only available on stock ROMs. Please compare /system/lib/libril.so and /system/bin/radiooptions with the files on Stock ROM.

[SecUpwN]

@andr3jx, might be. How exactly do you want me to compare this? And what if this is the case?

[andr3jx]

@SecUpwN Copy radiooptions from stock ROM to your phone and see which options it offers. You can also use strings to check if libril.so contains "uniat". You could also try to replace libril.so with the one from stock ROM.

[SecUpwN]

@andr3jx, I already did that a while back when E:V:A posted the ZIP file on our XDA thread. And yes, radiooptions indeed had option 13. I guess that this might mean that AT Commands are supported on HTC One devices with Stock ROM, but what about all the other devices with Custom ROM? Do we need to replace the relevant files? If so, shall I open a fresh Issue especially meant for Custom ROMs?

[andr3jx]

@SecUpwN
We only need to replace files if
a) we want to support custom ROMs
and
b) we don't find an other way (easier) way to do AT injection.
For now we don't need to open an issue for that.

[teknogeek]

Hello, I figured I would step into this conversation since it was I who prompted it through @SecUpwN on XDA.

I am on currently running AT&T Stock 4.4.2 4.18.502.7 Rooted Odexed on my HTC One M7. I don't even have radiooptions as a command in /system/bin at all. Am I missing something here? I also checked the stock rom zip that I flashed from and radiooptions is not in there either.

[teknogeek]

After installing the radiooptions binary from the XDA, I now get this error:

root@m7:/ # radiooptions
/system/bin/radiooptions[1]: syntax error: '(' unexpected

[E3V3A]

This thread is to fix the built-in injector for those who already have the ATCoP interface on their devices.

Please open a new issue for your device specific AT questions/issues, or post in the XDA development thread. Thanks for understanding. I'm locking this issue until further notice.

[SecUpwN]

@E3V3A, I can fully understand why you're so mad about this. From now on, I will make damn sure to not cross-link Issues again. To avoid further spamming, I previously asked about opening a fresh Issue for discussion, but unfortunately we had some heavy miscommunication going on, that is also why more people joined into this side-channel. Please excuse all this, it will NOT happen again! To remedy things like that in the future, I have added a warning to our Problems page. I am very sorry for what happened.

I will now re-open this Issue solely to fix the built-in injector for those who already have the ATCoP interface. Please stay on topic everyone. @teknogeek, please continue discussion in #195. Thank you!

[E3V3A]

Just as a reminder, here is one way to kill shell processes from within Java...

[E3V3A]

Fixed in commit: 8a6fbd9