Hi *,
I'm very new to forum and hardware hacking. I'm also new to android dev (I have done some WP7 development).
I want to write application about radio conditions (RSCP, EcNo) and also wanna to decode ASN.1 messages to get some 3GPP layer 3 messages (RRC). To do that, I suppose that low level access is required.
So, is there any tutorials, guides etc. on how to do that for android devices (I know about android telephony class) or WP7/WP8 devices.
I also know that that is not possible on every device due manufacture restrictions.
I'm interested in Galaxy S(2/3), Nokia Lumia, Nexus, etc (device doesn't need to have qualcom chipset, all i wanna to do that).
I also know that some of companies like ASCOM are working together with chip suppliers for that kind of applications.
So, is it possible to do on market smartphones...
Thanks in advance for answers
Cheers!
TK
It's troublesome thing.
Every modern mobile solution does split into AP (Application Processor) and BP/CP/Modem (Baseband/Call Processor), sometimes these are integrated into one SoC (QC chips) or are splitted into 2 SoCs (like Exynos AP+QC/Infineon CP), on AP there's working ARMLinux with Android platform.
Platform does communicate with RIL HAL (proprietary lib), RIL does communicate with modem through some dedicated HW interface using kernel driver, nowaday its common shared-memory topology with abit of control through UART/GPIOs before RAM-share is set up (modem bootup, assuming AP does startup first, which is case in 2xSoC topology, on QC SoCs modem does startup first and does perform bootup of AP submodules).
The problem is - BP OS is closed source. In best case (rather unlikely) low-level transmission params might being received by RIL from AP but not being passed to platform, then you probably would need to patch RIL binary to expose these values to platform. If these transmission params aren't being transmitted from CP to AP, the easiest (and the ugliest) way to do is trying to find network structures inside of modem OS and pooling them from AP (assuming you've got direct access to all of CP memory). More advanced way would be integrating additional data into BP-RIL interface (modifying both RIL and modem binaries), what then narrows down to "best case".
If you aren't familiar with ARM assembly - analysing modem binary is pretty big task, prepare for at least few weeks of intense reversing.
This is a very interesting question!
So far, AFAIK, no one here at XDA (or elsewhere) have been able to successfully extract L1 radio parameters from the modem, using any form of API or other. So anyone who would successfully be able to do this, would be an instant XDA hero! (As for L3, I don't know.)
But then again, I don't think anyone have tried hard enough either. I have tried to a limited extent in my research of the Intel XMM6260 and trying to use some of the Android internal telephony API. Others have managed by hacking the AT command line interpreter, directly in the modem image of some limited versions of the 2xSoC's (like those of Intel/Infineon) used for jailbreaking <4S iPhones. These modem images are "only" 10 MB, whereas the Qualcomm modems "images" consists of 50-60 files and have a size up to 60 MB!! Although we should be able to find the AT command Processor (ATcP) in those...
As I see it today, we only have these options how to get these parameters in the Android eco-system.
1) We believe that the modem AT command interpreter/processor have the capability to provide radio parameters to the outside world. But this direct access often seem to be crippled:
a) by denying local or external terminal (UART) serial-access.
b) by being filtered by the RIL daemons and accompanying RIL libraries
c) by being complicated due to using modified IPC (shared memory) communication, rather than regular serial devices. However, by putting the device into "download/debug" mode, sometimes these devices re-appear!
(This is what ODIN, QPST and other programs does, see (4).)
2) We know that the Android internal phone API can use the following calls to get particular modem "stuff" (including sending AT commands): RIL_OEM_HOOK_RAW and RIL_OEM_HOOK_STR
The problem is that no one seem to know how to use it, nor how it depends on the hardware...
3) We know that the Service Mode's (settings/menu) are displaying many of these parameters, so that the phone OS certainly can get have access to these. So another option is to hack and understand how this is done by the service mode menu and the underlying modem software. This is where reverse engineering would come to its right!
4) We also know that many of the OEM phone debug/repair software, like QPST and QDART (Qualcomm) and "CDMA work-shop" etc. have full access to these variables as well...
Actually, if you're on a Qualcomm based device and can put it into QXDM mode, you can have all radio data to be output to the QXDM (3.12.754) software and possibly interface API. Thus... if we can understand the handshake and protocol they use we should eventually be able to make an app that can fetch this data as well...
Thx for your answers!
It looks like I need many hours to investigate and learn! Sound like fun, hope it will be...
I hope that soon I'll post something new on this thread about question.
Thx and hear ya!
Little update: Regarding radio conditions, here is telephony API http://developer.android.com/reference/android/telephony/package-summary.html and here is Signal strength class http://developer.android.com/reference/android/telephony/SignalStrength.html!
So I have these information (at least I hope so, because I don't have device for testing and I don't have dev environment set yet).
Also, regarding WP7 Samsung devices: there is samsung app called Diagnosis, where you can access root/debug screen in Test Mode... I was looking little into that app (I have unlocked Samsung Omnia W device), and there are very interesting informations, like list of neighbour cells with CellID and signal strength and many others (Handover test, antenna/ADC, RRC state, Tx Channel, Tx Power, EcIo, RSCP, L1 (looking now it's PCH_Sleep value ??), etc)
I need that kind of information + need to find way for decode L3 messages like RRC and RLC. From L3 you can find many other information (RAB establishment, IRAT handover, all 3GPP information element for GSM/WCDMA/LTE and so on!)...
hi *,
What about Gobi platform and GOBI dev?
BR
TheKrigla said:
hi *,
What about Gobi platform and GOBI dev?
BR
Click to expand...
Click to collapse
Hi, i was just looking for GOBI, too.
But they only show 4 Devices, with the Gobi-Modem inside:
qualcomm.com/gobi/products/finder?type=Smartphones
But there are buid in a few UMTS/USB-Sticks, Mobile Hotspots, a Router and some Notebooks (SubNotebooks),
Not bad, if you can use it as an external device, like the mobile router.
So it looks like a very special solution.
Did somebody check the HTC, Motorola or Samsung SDK ?
I am also trying to get low network info, and it looks like AT commands that exist (at least on my Samsung S3) do not provide this information. So I think emulating what QXDM does is the secret sauce... but that's hard
You can probably find what you need in the "QMI" related documents from THIS post... Let us know how it goes!
E:V:A said:
You can probably find what you need in the "QMI" related documents from THIS post... Let us know how it goes!
Click to expand...
Click to collapse
I quite don't fully understand how QMI works. The SDK appears (C++) to run on Windows. Is it possible run QMI directly on android? Also one post said that really low level information like Signaling can only be through the diag port. Perhaps there is a way to emulate QXDM on the android and connect to it to grab this info
Chipset access
I am wondering how tools like qualpoc from SwissQual work. They seem to have access to every damn thing happening in the android phone. Do they have any special API access from Qualcomm ?
enigma99a said:
I quite don't fully understand how QMI works. The SDK appears (C++) to run on Windows. Is it possible run QMI directly on android? Also one post said that really low level information like Signaling can only be through the diag port. Perhaps there is a way to emulate QXDM on the android and connect to it to grab this info
Click to expand...
Click to collapse
mknair said:
I am wondering how tools like qualpoc from SwissQual work. They seem to have access to every damn thing happening in the android phone. Do they have any special API access from Qualcomm ?
Click to expand...
Click to collapse
Thanks.
http://www.swissqual.com/
Probably nothing special. What is special, is that they have full access to all their documentation. If you can download their white papers and the Android app, I'll tell you how they do it!
Is it possible to connect something like a 4G dongle to the usb port to create a roaming RF scanner and get the RSCP ECIO details from that? It's a bit mental but it doesn't look like we will be able to get this detail from the phone without paying the tens of thousands for the documentation anytime soon...
I tried to connect a Sierra Wireless device which can provide this info but I cannot seem to compile the module against the kernel.
I got QMI talking just fine on android 100%. But I need layer 1 info etc as well (DIAG)... Qualcomm docs look easy enough for the packet structure but now i just need access... And I'm totally stuck. USB is one way, but isn't there to get access locally? Like through UART or some other means? I believe all communication goes to the /dev/diag device but so far I have not been able to get access
E:V:A said:
So far, AFAIK, no one here at XDA (or elsewhere) have been able to successfully extract L1 radio parameters from the modem, using any form of API or other. So anyone who would successfully be able to do this, would be an instant XDA hero! (As for L3, I don't know.)
Click to expand...
Click to collapse
Well, I guess I am a XDA hero then I have successfully extracted L1 radio info, etc on Android itself. DIAG is pretty powerful and not very well documented so I had to figure everything out myself, but when it works you can get just about anything possible.
enigma99a said:
Well, I guess I am a XDA hero then I have successfully extracted L1 radio info, etc on Android itself. DIAG is pretty powerful and not very well documented so I had to figure everything out myself, but when it works you can get just about anything possible.
Click to expand...
Click to collapse
Any thought about sharing solution?? Not cool man...
enigma99a said:
Well, I guess I am a XDA hero then I have successfully extracted L1 radio info, etc on Android itself. DIAG is pretty powerful and not very well documented so I had to figure everything out myself, but when it works you can get just about anything possible.
Click to expand...
Click to collapse
Is that right? There were never any heroes who didn't prove their worth. So why don't you share it with us? (Or if you don't want to share, at least tell us why not?)
E:V:A said:
Is that right? There were never any heroes who didn't prove their worth. So why don't you share it with us? (Or if you don't want to share, at least tell us why not?)
Click to expand...
Click to collapse
Yeah, sorry guys for the late reply. Basically I had to rewrite the diag driver to get diag info. And this project is for profit, so I can't put myself at a competitive disadvantage after spending many weeks on it But if anyone has questions, I would be happy to answer
Hi at all!! My hero, enigma99 please tell me (or who knows)!!
I'm developing a app with SDK that use the java methods of classes like SignalStrenght and Telephony. But those methods dont work very well. (they are slow, and in much smartphone dont return the Ec/Io)
Do you think if in 3g tecnhology (UMTS, HSPA) the modem part always returns all measure (RSCP and Ec/Io)??
What's the way to follow for return this values? recompiling kernel? programming with NDK?
enigma99a said:
Yeah, sorry guys for the late reply. Basically I had to rewrite the diag driver to get diag info. And this project is for profit, so I can't put myself at a competitive disadvantage after spending many weeks on it But if anyone has questions, I would be happy to answer
Click to expand...
Click to collapse
Is this for sale yet? Curious minds would like to know.
Related
I saw this product mentioned on infosync, and it got me thinking that with your growing knowledge of the Phone Edition's inner workings that something like this might be possible on the XDA:
PsiLOC+ miniGPS
(in case you don't want to visit the page)... Basically they are using information about which cell towers are in range to trigger events. They give some nice examples, like having an alarm go off when you get close to your train stop (that way even if the train's delayed and you're asleep you still get the "wake-up call" when you're near your destination.) Or how about having the phone turn the volume down (and switch to vibrate) automatically whenever you're in church or your favorite movie theater.
You could do the XDA a great service just making details of how to get at the relevant information (area ID and cell ID) public, if they aren't already...
CellID and other network info
At the lowest layer, there seem to be no AT commands to get network-related information. And at the TAPI layer (the only one an application can easily get to), this information is, as far as we know, unavailable.
We're working on understanding the modem better, and one of the aims of this endavour is precisely this: getting the CellID for location-based stuff.
Stay tuned (but don't hold your breath)
Surely not?
Surely the only communication with the radio stack isn't via AT commands. Is there no low level api, IO ports, DMA, interrupts etc? How, for example, is the voice stream delivered to the radio stack?
Would it be possible to write a kernel mode driver for these services?
I won't teach you to suck eggs, but maybe a few ideas.
Well... As we see it now all communication with the modem may well be multiplexed in one serial 115.200 bps serial stream. We're working on it...
On my Nokia 6210 I've installed Network-monitor. It shows easily this kind of information.
see this:
http://www.logomanager.co.uk/help/Tools/NetMonMenus.html
localization??? it's already there!
look:
http://www1.o2.ie/products_services/location_services
Re: localization??? it's already there!
kimmie said:
http://www1.o2.ie/products_services/location_services
Click to expand...
Click to collapse
These services are network based: i.e. the network knowing where the phone is. This is different than the phone autonomously figuring out where it is, without help from the network.
Depending on the provider, maps with cellIDs may be available.
serial stream.
XDA Developer, I'd like to be involved in the investigation of the modem. This interests me a great deal.
Not hot on hardware, but I can do some dissassembly and stuff like that.
[email protected]
Disassembly would be a lot easier if you set yourself up with a dev system for ATI Nucleus (which I'm told is the embedded OS for the radio stack).
I have a Nucleus setup here but it's geared toward PowerPC as the target. Anybody know what kind of processor is in the radio module? Is the DSP ("TI HERCROM") what's running Nucleus? According to ATI's site all of the dev tools for that port are maintained by TI. The chip has a JTAG interface, so that would make emulation a possibility, and might help. TI's tools for these things are historically free (they want you to buy chips, after all) but I haven't dug any deeper than this right now.
A 4 meg code space is quite a lot to have to wade through, and it's looks like they're using most of it.
Anyone who upgraded their T-Mobile device using the latest update has easy access to the radio stack ROM image, since it lives in the Windows directory after the CE OS upgrade and never gets deleted. There's a file called rsupgrade.cp64 (3.83 MB) which contains the code being squirted into the radio module's ROM by rsupgrade.exe after the first soft-reset.
Hi guys, I've been an avid reader of the xda forum, and it's great, so far it has been an awesome source of knowledge, however up until now I had found everything I needed...
Long story short, I want to be able to use the sensors in my smartphone (Rooted Moto G XT1032, 16 GB) in the open source software Processing. Could somebody please point me in the right direction?
Basically I want to:
Connect my phone to my PC via BT or WiFi
Read the value of the sensors within my phone and transmit them to my PC
Somehow read those values in Processing and create nice graphs and stuff
I know how to program Processing, I've looked into the Amarino Project, but it does require the Arduino Part, and I know how to interface Arduino and Processing (I've done some PID control and other stuff with those), but I want to skip the whole Arduino part (at least for now).
Could somebody please point me in the right direction?
Thanks in advance, cheers!
Update 17/09/2014: Currently looking into the SensoDuino project, which apparently will solve my problems in the Android Front.
I tested it following the video in the main page of the project in the part Pairing and Establishing a Serial Connection between Windows 7 and SensoDuino (sorry I still can't post links), I have been able to read the data using Tera Term
Just mind the COM ports, and that you are actually transmitting over bluetooth, you can check this in the services tab of the properties of the paired device within Windows (If anybody wonders why not Linux, which I use the most, in which I do my main work and in which this would be pretty much a native feature, I intend to use this with a Windows Only Software)
Special thanks to TheBeano!
P.S. Depending on what the rules of this forum regarding solved threads are, I'll either update or publish whatever the outcome of this project is, cheers!
Hectormd said:
Hi guys, I've been an avid reader of the xda forum, and it's great, so far it has been an awesome source of knowledge, however up until now I had found everything I needed...
Long story short, I want to be able to use the sensors in my smartphone (Rooted Moto G XT1032, 16 GB) in the open source software Processing. Could somebody please point me in the right direction?
Click to expand...
Click to collapse
Look at SensoDuino, they have a demo of connecting to Windows 7 via Bluetooth serial. Once you have a Bluetooth serial connection you can use Processing's serial comms to read the phone sensors. You could do the same sort of thing with Amarino, that is just read from the serial port, but it might be more work to decode the binary protocol that it uses from Processing. Sensoduino sends ASCII I think.
TheBeano said:
Look at SensoDuino, they have a demo of connecting to Windows 7 via Bluetooth serial. Once you have a Bluetooth serial connection you can use Processing's serial comms to read the phone sensors. You could do the same sort of thing with Amarino, that is just read from the serial port, but it might be more work to decode the binary protocol that it uses from Processing. Sensoduino sends ASCII I think.
Click to expand...
Click to collapse
Thanks a lot, it looks exactly like the thing that could fulfil my needs.
I'll update this post or publish whatever I come up with cheers, and thanks again!
Has anyone had any luck find the source code for the MTCB MCU? I'd like to mod the shutdown timer such that it leaves the device fully operational for the timer duration. Or if anyone has info on the instruction set used, I could perhaps made the mod using assembly or bitbanging.
This may help. It uses an 8051 instruction set
KLD2-v277 "source"
I have been studying and commenting the MCU code for a few months now -- specifically the KLD2-2.77 version. I used darksimpson's mcu decryption tool on the mcu.img file to get the 8051 binary file, then used the D52 disassembler to create "source" code from that.
Studying this code is an ongoing, very slow process but still I have made significant progress.
A few observations (any of which may contain errors!):
1) The original source appears to be written in a higher level language, probably C (not sure which compiler).
2) It appears to communicate with the Android CPU using Serial Port 2 and also an SPI port. There are two I2C buses that the MCU uses to control the various peripheral chips such as the radio, sound processor, and video matrix.
3) Serial data is in the form of packets consisting of a 3 byte preamble followed by one or more bytes of data and ending with a checksum. The specific form of the packet and checksum can vary and is determined by the preamble.
4) Serial packets mostly go from MCU to Android. The MCU can receive packets too, but that capability doesn't seem to be used much, if at all.
5) The primary method of control from Android to MCU seems to be through the SPI port. This consists of 16 bit command words that are handled by a very large CASE statement. Each command word can be followed by additional data (depends on the command) and may also cause the MCU to send data back, either through SPI or more commonly by serial port packets.
6) It appears to me that the designers have nearly maxed out the code space. In other words there is very little room left for additional code, and also evidence that they did things to try to squeeze more code into the available space.
7) Finally -- and not to bash the Chinese designers in any way (tremendous effort contained in this code) -- there are some obvious bugs and also significant room for improvement.
If anyone wants more specific details on what I've learned please PM me. If anyone wants to dive in and study as well, please share what you learn!
One thing that would help me tremendously would be more information on the actual hardware environment. My HU is an 8133 with 480x800 display (specifically a Pumpkin C0235) but it is already installed in my car and I really like it there instead of on a workbench. . So if anyone is in a position to provide hardware details (such as clear photos and schematic diagrams -- either partial or complete, handmade is ok!), sharing them here will help a lot! The code does a lot with MCU I/O pins and without knowing what is connected to those pins it is difficult to really understand their true purpose.
Zipped text file is attached
dhmsjs said:
I have been studying and commenting the MCU code for a few months now -- specifically the KLD2-2.77 version. I used darksimpson's mcu decryption tool on the mcu.img file to get the 8051 binary file, then used the D52 disassembler to create "source" code from that.
Studying this code is an ongoing, very slow process but still I have made significant progress.
A few observations (any of which may contain errors!):
1) The original source appears to be written in a higher level language, probably C (not sure which compiler).
2) It appears to communicate with the Android CPU using Serial Port 2 and also an SPI port. There are two I2C buses that the MCU uses to control the various peripheral chips such as the radio, sound processor, and video matrix.
3) Serial data is in the form of packets consisting of a 3 byte preamble followed by one or more bytes of data and ending with a checksum. The specific form of the packet and checksum can vary and is determined by the preamble.
4) Serial packets mostly go from MCU to Android. The MCU can receive packets too, but that capability doesn't seem to be used much, if at all.
5) The primary method of control from Android to MCU seems to be through the SPI port. This consists of 16 bit command words that are handled by a very large CASE statement. Each command word can be followed by additional data (depends on the command) and may also cause the MCU to send data back, either through SPI or more commonly by serial port packets.
6) It appears to me that the designers have nearly maxed out the code space. In other words there is very little room left for additional code, and also evidence that they did things to try to squeeze more code into the available space.
7) Finally -- and not to bash the Chinese designers in any way (tremendous effort contained in this code) -- there are some obvious bugs and also significant room for improvement.
If anyone wants more specific details on what I've learned please PM me. If anyone wants to dive in and study as well, please share what you learn!
One thing that would help me tremendously would be more information on the actual hardware environment. My HU is an 8133 with 480x800 display (specifically a Pumpkin C0235) but it is already installed in my car and I really like it there instead of on a workbench. . So if anyone is in a position to provide hardware details (such as clear photos and schematic diagrams -- either partial or complete, handmade is ok!), sharing them here will help a lot! The code does a lot with MCU I/O pins and without knowing what is connected to those pins it is difficult to really understand their true purpose.
Zipped text file is attached
Click to expand...
Click to collapse
Great work! Thank you! I'm not profound in this MCU programming but I really believe that it is of great importance to hack that code and mod it in order to squeeze more from these units. A applause you and hope other will join your effort.
Open source implementation could be interesting down the road
Wonder if we could steal any of the tricks from old days of DSS cards and double up code by using lookup tables for some references to make more room for improvement code.
webdude12 said:
Wonder if we could steal any of the tricks from old days of DSS cards and double up code by using lookup tables for some references to make more room for improvement code.
Click to expand...
Click to collapse
There is a lot of "wasted" space (duplicate initialization data for instance) so there's plenty of room available if the software is written efficiently. However modifying what is there, other than small tweeks, is probably not likely to succeed. It looks to me like there is a lot of "band aid" fixes in there and (in my experience anyway) modifying that kind of code often ends up creating more subtle, unforeseen problems than it fixes.
Yes an open-source rewrite will be the best long term solution but that will require a thorough understanding of both the MCU and the Android side of the interface. On the other hand we have potentially a large group of international talent to apply to the task, and no hard deadlines either. It is certainly possible to do.
The MCU processor itself is well known. The peripheral devices are well known (or knowable). So reimplementing those interfaces can be largely independent of the Android-MCU interface. But knowing what the Android CPU expects, and accommodating that for all variants is currently the big unknown for me.
dhmsjs said:
There is a lot of "wasted" space (duplicate initialization data for instance) so there's plenty of room available if the software is written efficiently. However modifying what is there, other than small tweeks, is probably not likely to succeed. It looks to me like there is a lot of "band aid" fixes in there and (in my experience anyway) modifying that kind of code often ends up creating more subtle, unforeseen problems than it fixes.
Yes an open-source rewrite will be the best long term solution but that will require a thorough understanding of both the MCU and the Android side of the interface. On the other hand we have potentially a large group of international talent to apply to the task, and no hard deadlines either. It is certainly possible to do.
The MCU processor itself is well known. The peripheral devices are well known (or knowable). So reimplementing those interfaces can be largely independent of the Android-MCU interface. But knowing what the Android CPU expects, and accommodating that for all variants is currently the big unknown for me.
Click to expand...
Click to collapse
Well that is great to hear. So what I would think that needs to be done first is a complete comment dis-assembly. This has been completely useful in other "hacking" attempts as it allows you to fully understand step by step what the original coders were doing. It also allows for debuggers / emulators to written.
From there it can be determined if it makes sense to re-write sections, re-route code, or completely re-write from scratch providing the same functions.
webdude12 said:
Well that is great to hear. So what I would think that needs to be done first is a complete comment dis-assembly. This has been completely useful in other "hacking" attempts as it allows you to fully understand step by step what the original coders were doing. It also allows for debuggers / emulators to written.
From there it can be determined if it makes sense to re-write sections, re-route code, or completely re-write from scratch providing the same functions.
Click to expand...
Click to collapse
While it is by no means complete, I've worked through enough of this MCU code that I think I have a pretty good high-level understanding of how and what the MCU does. As I said above, what I'm missing now is much of the hardware context (for example which MCU pins connect to what, some of the peripheral chip #s, etc), and also the Android software context -- specifically the code that sends commands through SPI to the MCU. I have looked briefly at some of the Android code (for example MTCManager.apk) but didn't find anything useful there. It seems like the SPI interface is lower level -- perhaps as in a device driver??
This is just a dumb question because you guys would be so far away from modifying mcu code, yet I'm going to ask it.
Could some of the hardware hacks (Using different sound processor for radio, mic mods) be accomplished through software, if you got a good handle on things?
DRidilla said:
This is just a dumb question because you guys would be so far away from modifying mcu code, yet I'm going to ask it.
Could some of the hardware hacks (Using different sound processor for radio, mic mods) be accomplished through software, if you got a good handle on things?
Click to expand...
Click to collapse
Sound processor yes since that is just sending different commands to the sound processor. Mic mod no since that is a hardware mod only (as far as I can see it anyway).
Isn't the problem with the mic though that even when you use an external mic, the internal does not shut off? Could you send a message stating that an external mic exists, close off internal? Hypothetically of course.
Would be amazing if down the road those sort of mods could be done on the software side.
Also add "Control radio before android boots" to my dream list.
DRidilla said:
Isn't the problem with the mic though that even when you use an external mic, the internal does not shut off? Could you send a message stating that an external mic exists, close off internal? Hypothetically of course.
Would be amazing if down the road those sort of mods could be done on the software side.
Also add "Control radio before android boots" to my dream list.
Click to expand...
Click to collapse
My understanding of the mic hardware interconnection is not good enough to say one way or the other. Probably varies from model to model as well (I don't seem to have a big problem with my external mic).
Control radio before Android boots might be tough since most all of the radio user interface comes through Android anyway. Might be possible to restore previous radio config before Android is up, but that might also not be such a great thing for many users. Not sure I'd want my radio to come up blasting away if I don't also have a way to silence it.
Then again with an open source solution, all you would really need is the will to make it so. I guess we all have our own dream lists, no?
DRidilla said:
Isn't the problem with the mic though that even when you use an external mic, the internal does not shut off? Could you send a message stating that an external mic exists, close off internal?
Click to expand...
Click to collapse
Both microphones are hardwired together. It is not possible to "shut off" one with software. There's also a modification to improve the radio's frequency response by replacing some capacitors. Again, not possible with software.
dhmsjs said:
...
Click to expand...
Click to collapse
Wow, nice work!! I typically have a few KGL units on the bench. Attached are a few images to get you started. These are of the 1024x600px resolution units.
Next time I'm at the office, I'll check out which I/O expansion chip(s) are being used and see if I can identify some of the lines.
Aaaron16 said:
Wow, nice work!! I typically have a few KGL units on the bench. Attached are a few images to get you started. These are of the 1024x600px resolution units.
Next time I'm at the office, I'll check out which I/O expansion chip(s) are being used and see if I can identify some of the lines.
Click to expand...
Click to collapse
Thanks! Really appreciate the photos. Difficult to read the chip #s though.
I know the radio device is similar to a TEF6624 - maybe a TEF6686?
Pretty sure the sound processor is a BD37531 or BD37534.
Not sure what the video matrix switch is -- FMS6502 maybe?
These all connect to the MCU via I2C. Interested in identifying the other devices that connect via I2C too. I can see the I2C addresses they use to communicate with the chips, but I can't generally look up a chip # by its I2C address. The goal is to find the data sheets for each device so that I can understand exactly what the I2C comm is doing. I have data sheets for the devices listed above.
Also as an update: I stated above that the MCU is controlled by Android through an SPI channel. I've been studying this more closely and it is clear that it is not actually SPI. Looks more like a custom 3 wire interface. Uses pins 1, 2 and 3 of the MCU (the IAP15F2K61S2 device).
Pin 1 (P0.5) is data (or ACK) to Android from MCU, driven by MCU
Pin 2 (P0.6) is the clock, which can be driven by either side (open collector with pullup?)
Pin 3 (P0.7) is data (or ACK) to MCU from Android, driven by the Android CPU
It would be helpful to know which pins these connect to on the Android CPU.
Each bit sent must be acknowledged by the receiver before the next bit is clocked out. There is debouncing and timeouts applied to the signals and the transfer is aborted if either fails. Maximum bit rate is around 1MHz I think, and probably slower in actual use. If anyone recognizes this as a particular comm standard, let me know! Otherwise it must be custom for these HUs.
Component Listing (KGL Mainboard)
I noticed the KGL devices use different radio modules even across the same model. I have some units with TEF6624 modules and others with TDA7786 modules. The following are the IC part numbers for the newer 1024x600px KGL main board (date code 2014-07-20):
1. AU6258J61-JES-GR (USB 2.0 Controller)
2. 15L2K61S2 (MCU)
3. FMS6502MTC (Video Sw Matrix)
4. BD37033FV (Sound Processor)
5. GM8283C (? - 10+ traces going to 50-something pin IDC display connector)
6. T132BT (TFT Video Controller)
7. WM8751L (Stereo DAC) - markings rubbed off. See attached photo.
I couldn't find an I/O expander chip on the main board, so I'm guessing the MCU drives most of the I/O lines directly (aside from those handled by their respective audio/video controllers).
Possibly related, I found this document which seems to include many of the same components:
http://p.globalsources.com/IMAGES/PDT/SPEC/216/K1127159216.pdf
MCU Memory Map/Resource Use
So attached below is a document containing a partial memory map, resources used, and I/O pin assignments as I currently understand it from studying the MCU code. The document changes every day as I learn more.
Again this is a KLD2 unit and the V2.77 version of MCU code I'm studying. For Aaaron16 or anyone else who has the ability to explore the hardware of a KLD2 head unit, what will help me a lot in this effort is understanding what the I/O pins connect to. They are listed at the top of the document.
If you explore your hardware, post what you find in this thread and I'll add it to the doc. TIA!
Could Malaysk make modified MCU with redisigned sound processor and sleep mod fo MTCB-MD-V2.67:angel:. I cant post download link
drive.google.com/file/d/0B9-2UI8L0wScel92bUFlaExkWnc/view?usp=sharing
dhmsjs said:
So attached below is a document containing a partial memory map, resources used, and I/O pin assignments as I currently understand it from studying the MCU code. The document changes every day as I learn more.
Again this is a KLD2 unit and the V2.77 version of MCU code I'm studying. For Aaaron16 or anyone else who has the ability to explore the hardware of a KLD2 head unit, what will help me a lot in this effort is understanding what the I/O pins connect to. They are listed at the top of the document.
If you explore your hardware, post what you find in this thread and I'll add it to the doc. TIA!
Click to expand...
Click to collapse
How is this progressing @dhmsjs ?
There are various websites around the web, claiming to provide the Qualcomm Product Support Tool but AFAICT, none of them are official. That is, I have concerns that they might have malicious code in them.
AFAICT the official source, which is the Qualcomm's website, requires registration using the email of a company that is already registered with Qualcomm, but this is not possible for me.
So, which resource is the most trustworthy one for obtaining the QPST and why?
Editorial: Looking at Qualcomm software makes me wonder how they are still in business...
QPST and their detour through "serial ports" makes me want to make a sound like Lurch.
What do you want to do? Grab the boot image?
If you need an EDL client application, here's an open source one in Python: https://github.com/bkerler/edl
OTOH, if you do Windows, you can always use mine: http://www.temblast.com/edl.htm
Renate said:
Editorial: Looking at Qualcomm software makes me wonder how they are still in business...
QPST and their detour through "serial ports" makes me want to make a sound like Lurch.
What do you want to do? Grab the boot image?
If you need an EDL client application, here's an open source one in Python: https://github.com/bkerler/edl
OTOH, if you do Windows, you can always use mine: http://www.temblast.com/edl.htm
Click to expand...
Click to collapse
I need to "repair" the IMEI that is sent to the network operator. I believe this needs to be done directly on the chipset. That is, solutions like Magisk + LSPosed + XPrivacyLua wouldn't work, since I believe it would only work for IMEI that is sent to the apps. (Not even mentioning the fact that the non-premium version of XPrivacyLua does not allow you to "repair" an IMEI, only block the access to it.) Hence, AFAIU, the only way is to flash the chipset with the necessary changes.
Yeah, well if you're doing things with the BP probably QPST is what you want.
I don't know, I don't deal with that.
Renate said:
Yeah, well if you're doing things with the BP probably QPST is what you want.
I don't know, I don't deal with that.
Click to expand...
Click to collapse
BP stands for "Baseband Processor" right?
Yeah. I have a cell phone that I mostly leave alone (with a BP). I have devices (like eReaders) that I hack within an inch of their lives.
Picked up a Moto G8 Power off Ebay and I havent touched an Android since I flashed a HTC Desire with Cyanogen Mod years ago.
Product/Variant: sofair XT2041-3 64GB PVT
?BootLoader? BL:MBM-3.0-sofiar-reteu-0f8934adaf8-210928
BaseBand: M6125_43.45.03.48R Sofia_rowdsds_cust
Recovery mode shows: RPES31.Q4U-47-35-9/54bc43
oem_locked
Spent all of today going around in circles.
Google Locked = it wants a pin to verify. Ebay ad stated it was google locked house clearance and not stolen. Nothing shows up in CheckAmend.com
On an offline PC
Android Studio installed - strangely ADB nowhere to be found.
ADB installed separately.
Got Magisk apk
Got from lolinet mirrors
XT2041-3_SOFIAR_RETEU_11_RPES31.Q4U-47-35-9_subsidy-DEFAULT_regulatory-DEFAULT_CFC.xml
blankflash_sofiar_RPE31.Q4U-47-35
From Motorola
Motorola_Mobile_Drivers_64bit
Rescue_and_Smart_Assistant_v6.3.2.12_setup - This will not install and I find this error in the Windows eventlog
MDM Declared Configuration: Function (checkNewInstanceData) operation (Read isNewInstanceData) failed with (The parameter is incorrect.)
Motorola support cant help until monday, but it might be a ASLR or some other MS security thing.
TWRP is missing the Motorola G8 on their website, G7 and G9 and others exist, so this is not an option.
Followed some of those youtube videos showing how to bypass the FRP, which appear to use a variety of tricks to either disable the Google Play Service or use an app to launch another app, a bit like getting the 2nd dial tone by calling a business freephone number, and hacking their phone system to get an onward outbound dial tone in the 80's.. Showing my age!
Before I put the device online using wifi and no sim for mobile data, I could get access to the Androids settings, where I could list apps, set permissions and other things so I'd tried to disable the play store, but these tricks wouldnt work. Put it online and it appears Android has been updated so those previous tricks for getting all the apps listed and makiing changes to their permission etc is no longer there. One of them was using the emergency phone, getting to the contact detail and then choosing a pic to gain access to other apps and that also stopped working and has disappeared which is why I say I think its been updated in all but version number!
I can access a fat32 sd card in recovery mode, but the apk files I put on it dont show, just the folders Android created on blank Fat32 partitions.
USB and ADB dont detect this device so I cant use the Wireshark USB to watch what is going over the USB connection.
AFAIK Android DeveloperMode/Debugging Mode is disabled.
I havent touched an android since the HTC Desires appeared and then I ported it Cyanogen Mod, but I subsequently learnt the UK Police had access to my phone even back then!
Not taking it apart to get access to the JTAG (just yet), I bought a few broke Pixel4A to see what I could learn about them when they arrive as well.
I see in fastboot, the mention of a "console [NULL]:null" is this the fastboot.exe alongside adb.exe in android tools, or something else?
So is there any other way or suggestion to get root for this device?
I fancied looking at LineageOS, or maybe some other OS like an unofficial port of GrapheneOS. I've found the device tree info put up by someone on here which would suggest its possible to port from Android 10Q to an Android11 distro/os, but my first hurdle is my stumbling block, I cant get the USB to work and have not found any other way to get beyond this stage to poke around with the OS and phone.
So any pointers, suggestions, advice, will be much appreciated!
TIA
Edit. It looks like Android/Google/Motorola have done a good job at locking down this OS and phone.
Edit2
Saw this thread here about making sure the Motorola drivers are installed properly.
[HELP] I seem to have bricked my Moto G Power and not it's stuck on bootloader.
This is what it looks like, and if I try to boot into recovery or system it just says "no operating OS found." Windows won't recognize it when trying to connect via USB. Any way to fix this? Help would be greatly appreciated.
forum.xda-developers.com
On Win10x64 I've been into c:\windows\system32\DriverStore\FileRepository, sorted the subfolders by todays date/time and can see a number of subfolders like
motoandroid.inf_amd64_dd80f24dcfb3dc931
motoandroid2.inf_...
motodrv.inf_....
motousbnet.inf....
and when inspecting one of the .inf files in notepad I can see there appears to be a service linked to the driver, but when I check the services, there isnt any services installed.
So I'm starting to think maybe Motorola's installation software doesnt work on windows with the default windows security settings, like exploit protection running.
More investigations...
Edit4
In the Control Panel (yes its still there in Win10), Device Manager, Other Devices are a couple of entries which the latest attempt to install the Motorola USB x64 msi installer created.
These are:
Mot Composite ADB Interface
Motorola ADB Interface
In c:\Windows\system32\drivers are a couple of 0KB wdf files (Windows Driver Foundation) files:
Msft_Kernel_WinUSB_01009.Wdf
MSft_Kernel_motoandroid_01009.wdf
Msft_User_WpdFs_01_11_00.wdf
So when looking at the c:\windows\system32\DriverStore\FileRepository I think the driver that needs to be installed can be found in the subfolder:
motoandroid.inf_amd64_dd80f24dcfb3dc931
However opening the motoandroid.inf file inside I can see lines like
DriverVer=03/25/2013, 1.3.0.0
As this folder was created about 30mins+ earlier, am I correct to believe the actual motorola driver was created back in 25th March 2013 and is version 1.3?
I know its possible to edit inf files to make drivers W2k and XP drivers work on later versions of windows, but the motorola website has the version number 6.4 but is this 6.4 the version number of the installation program?
Anyway scrolling further down the motoandroid.inf I can see towards the bottom instructions to install a service
"Mot ADB Interface Installation Driver" and it needs to find the actual driver in %root%\System32\Drivers\motoandroid.sys
Various paramaters, like a transfer size 4096bytes, a debug level of 2 and plenty of guids which will be found in the registry.
Anyway uninstalling the software as now removed these subfolders from the DriverStore\FileRepository, so a reboot and another attempt to see where its failing.
I just hope it doesnt need an internet connection, as this offline pc is a dev machine.
Onwards and upwards....
Edit 5
So the Windows 10 setting which prevents the Lenevo Rescue and Smart assist from installing is the Windows App and Browser Control > Exploit Protection > Force randomisation for images (Mandatory ASLR) when its on.
You can have every other windows setting on, like ransomware protection, normal ASLR, DEP etc etc and LMSA installs fine, right now its downloading an image to flash from FastBoot, but its not got the Developer mode/USB debug enable in android to make this possible.
Now lets see if I can get the Motorola USB drivers to work with ADB...
Got to say these forums are excellent cheap intelligence gathering tools for manufacturers and software companies to harden their products.
So tried lots and lots of these types of YouTube videos which are exploiting an SE Linux "vulnerabilities/design flaw" by getting access to enough of the system in order to disable/force stop certain apps in order to get past FRP block.
Some of these are less than a month old with less than 100 views, but I also suspect some of them of doing a bit of camera editing. I guess its a way of bunking up the number of views for a youtube account, before it gets rebranded, if thats even possible!?!
Now I managed to get the Lenovo Rescue and Smart Assist program to work, once I realised it will not install when Windows Exploit protection/Mandatory ASLR is enabled (which is a give away as to what the installer is doing on my system as well), and the give away information which suggests it might be worth downloading wireshark and installing the USB "packet" sniffer is the fact that when LMSA is running and you plug your usb cable into the Motorola phone, the phone displays the battery power as a xx% inside a swirling circle of sorts.
So there is some sort of USB communication taking place?
The other thing that gives it away is when you type in your IMEI number into the LMSA Rescue section, its detecting the version of firmware and wants to download the latest version.
LMSA did this to me last night as it downloaded
SOFIAR_RETEU_RPES31.Q4U_47_35_12_subsidy_DEFAULT__regulatory_DEFAULT_CFC.XML.zip
which I guess I can search for on this computer, or at least search for files on my windows hard drive created within a certain date/time frame, as the filename might be scrambled/obfuscated in some temp folder.
So is it just Firmware level communication, or is there some sort of Android communication taking place as well?
If its just firmware, then what could be elucidated/deduced from attacking the firmware? Perhaps its time to get the Wireshark USB sniffer out after all.
As I can also put an SD card into the phone (the start of a potential side channel attack) and the phone will load the SD card, I could explore different routes like some "malware" embedded using a picture to attach to the Emergency Contact details, maybe some PHP embedded in the pictures EXIF data or something that could trigger some other secondary app/process in Android into action.
It might pay for me to lookup the Google Android source if its open source, and look at the Android project source which is open source for any vulnerabilities. Anything mentioned in Github could give away clues
Configure on-device developer options | Android Studio | Android Developers
Learn how to configure system behaviors that help you profile and debug your app performance.
developer.android.com
So are there any issues listed here which doesn't just affect Android 13, but maybe earlier versions as well?
Google Issue Tracker
issuetracker.google.com
So lots of less obvious or not publicly mentioned intelligent sources of potential attack vectors in plain sight.
Seeing if I can alter the cpu clock speed and quantum could also help to introduce some instability, Linux has a wider range of cpu schedulers than windows, but this route tends to hang systems and I have to get enough access to this phone in order to change the route.
The recovery msg logs seen when selecting different bootloader options give away info, I think this is DMesg output of sorts. I'm not a linux programmer, just a boring old windows programmer.
I could explore what else could be loaded from the SD card, using the Bootloader menu options. I was surprised the APK packages dont appear in SD card in the "Recovery Mode > Apply updates from SD card" option. Maybe its not expecting a APK file extension? Mybe its expecting a different file of sorts like a .bin file or .img file. Is this where BlankFlash comes into play?
I have to admit, buying a second hand phone like this with FRB enabled off Ebay from a guy purporting to be in Salisbury home of Noivchok, is also a great way of spreading the latest and greatest malware to unsuspecting hackers and also to phish those who could potentially get around the FRB restriction with the minimum of effort. The UK civil service have their own internal postal system so has something been posted internally down the M5 motorway from Cheltenham, for some intelligence gathering or a cheap way of outsourcing some device cracking?
Oh well the silence is deafening.
So Motorola Support Centre have been in touch and stated:
I am really sorry to say that the kill switch feature, which is known as "Google Lock" is not bypassable by anyone other than the repair center.
So they are stating the Android Factory Reset Protection (FRP) can be bypassed which is another way of saying it can be undone, so the next challenge is finding out where on the device this flag or flags resides.
Is it something like the RaspberryPi One Time Programmable (OTP) switch's that may not be One Time Programmable but like the dip switches seen on the motherboards of early 8086/286/386/etc personal computers, or something else like a file on the main storage device with the rest of android.
I think the first thing to do is get Wireshark and the USB sniffer to see what information is being sent over the USB cable.
And as its possible to get the device online via wifi, it's probably a good idea to see what information is being sent over wifi, so using wireshark on a raspberrypi masquerading as an access point might be useful as well.
So the first thing to do is have a look at the Android documents
Android
Android has 74 repositories available. Follow their code on GitHub.
github.com
https://developer.android.com/reference/android/app/admin/FactoryResetProtectionPolicy
The factory reset protection policy determines which accounts can unlock a device that has gone through untrusted factory reset.
So it looks like Android are also stating the Factory Reset Protection can be undone. It seems a that a single user setup and a corporate setup exist, where a corporate account could be used to remotely wipe a device and then reenable the device, I guess if the user hands it back to the company.
https://developer.android.com/about/versions/marshmallow/android-6.0-changes API 23
EXTRA_PROVISIONING_RESET_PROTECTION_PARAMETERS is removed so NFC bump provisioning cannot programmatically unlock a factory reset protected device.
You can now use the EXTRA_PROVISIONING_ADMIN_EXTRAS_BUNDLE extra to pass data to the device owner app during NFC provisioning of the managed device.
Interestingly, NFC can be used to unlock FRP in earlier versions of Android. and its possible to use NFC to potentially configure and more other devices using NFC. As NFC is just a low power and thus low range frequency in the RFID range of frequencies alot of other things could be possible. NFC to me is just like any other form of communication method, beit a usb cable, telephone wire, wifi, ultrasonic sounds, or Infrared.
Radio-frequency identification - Wikipedia
en.wikipedia.org
NFCIP-1 and NFCIP-2
Near-field communication - Wikipedia
en.wikipedia.org
As NFC can communicate a request and response, and Android is using NFC to configure devices, using NFC may be a novel attack vector for peoples android devices, without them knowing about it unless they capture on a personal webcam everyone and every NFC device they come in to close contact with. Maybe using payment terminals could become a new attack vector at your favorite local retail outlet?
Well if Covid doesnt make people socially distanced, then maybe an NFC attack vector might if it works beyond the claimed 4cm operating range! Unfortunately this phone does not come with NFC, but others do.
I've got to find the source code....
Android (operating system) - Wikipedia
en.wikipedia.org
Most versions of Android are proprietary. The core components are taken from the Android Open Source Project (AOSP), which is free and open-source software (FOSS) primarily licensed under the Apache License.
Search results for "factory reset protection" | Android Open Source Project
source.android.com
The default implementation of Test Harness Mode uses the same storage mechanism as Factory Reset Protection to store the ADB keys temporarily in a persistent partition.
So it looks like I need to gain access to this "persistent partition" and try to find this ADB for starters.
Seems a bit sneeky of Google and Android here. https://source.android.com/docs/security/bulletin/2016-02-01
At the bottom of the Android webpage is a link to Factory Images of the Google Nexus and Pixel phones which jumps you to Google web page. No indication what so ever I'm leaving Android and going to Google!
Flashing devices | Android Open Source Project
source.android.com
To enable OEM unlocking on the device:
In Settings, tap About phone, then tap Build number seven times.
When you see the message You are now a developer!, tap the back button.
In Settings, tap System, then tap Developer options and enable OEM unlocking and USB debugging. (If OEM unlocking is disabled, connect to the internet so the device can check in at least once. If it remains disabled, your device might be SIM locked by your carrier and the bootloader can't be unlocked.)
Reboot into the bootloader and use fastboot to unlock it.
For newer devices (2015 and higher):
fastboot flashing unlock
For older devices (2014 and lower):
fastboot oem unlock
Tip: if you're seeing `adb devices` output before reboot but fastboot or the flash script are misbehaving, it might be issues with your USB cable. Try a different port and/or switching connectors. If you are using a USB C port on your computer try a USB A port instead.
Confirm the unlock onscreen.
Well the instructions I've seen only talk about the gaining access to settings and the doing 7 taps on the Build Number. Lets see if the rest of the instructions work.
Onwards and upwards....
Well sent the phone back the Ebay seller claiming to be a house clearance business wouldnt provide any paperwork to back up his claims of how he came to be in possession of the phone. So as I planned to do some computer forensics on it, like retrieve the files wiped by a Factory Reset, and the perverse interpretation of the law in this UK, I wasnt prepared to go any further with the phone. So its been sent back. The banks have already shown how untouchable they are, other big businesses are also in the same position and finding illegal stuff on a phone is not a risk I'm not prepared to take without paperwork.