Has anyone been able to extract amss.bin from radio.img? Or the efs filesystem (Not the same as /efs btw.)?
Would anyone be interested in helping me rip apart a radio image?
I've googled around looking for any instances of extracting the radio firmware from radio.img and have come up with nothing.
More information for those who know less about the baseband:
What is it?
AMSS is the name Qualcomm gives the software that runs the phones modem. When the modem software is compiled, it is encrypted and stored in a file called amss.bin. There is a small entry point in amss.bin which decrypts the image into the phones memory during boot and then executes it.
What does it do?
Its job is to find, connect, and decode cell phone signals and convert them to usable data. In most older cell phones the phones operating system was a part of this as well, but with android the modem runs along side android (Question: Is it a separate processor for the baseband? or is it somehow multiplexed with android on the main CPU?)
This software reads settings that were set either by the phone itself (2G/3G or 4G data, PRL on cdma, APN settings, and other radio related things.) or by the carrier/manufacturer (NVRAM) and changes its behavior accordingly.
It then accepts commands and gives responses to another piece of software (In this case android) which does something useful with the phones modem. (Dials a phone number, connects to a data service, etc) and lets the software know when events happen (Text messages, incoming calls, etc)
The modem firmware (amss.bin) is inside radio.img for the nexus s 4g, This much should be blatantly obvious. However, the phones EFS filesystem (FAT12 IIRC) is also located here as well. radio.img may be encrypted or compressed, (Why it takes so long to flash a radio update to the nexus s 4g)
Why?
With access to amss.bin it can be decrypted and disassembled to show the phones true inner workings, and I may be able to develop a solution to the absolutely terrible data speeds for the nexus s 4g (No matter where I go, with 3 different D720's now, I get 56k dialup speeds and once in a great while it will go up to 3g, unless I'm sitting right next to my airave.) or at least have an insight as to why this phones data is so slow.
How do you know all of this?
I originally tried to get android running on a Samsung Eternity, I was able to decode the first part of AMSS.BIN but then realized that writing the radio interface layer for android was going to be a real challenge, not to mention that the phones hardware was barely capable of running 1.5 (And by barely I mean not really capable at all). But I learned an awful lot about the internals of Qualcomm phones along the way, and even wrote a small utility to edit the boot images and EFS filesystem (In this case, EFS also held the OS itself, not just the radio stuff)
Great read. I have no experience in this, nor any worthwhile software experience so I doubt i can help you, but if you think I can just let me know. I havn't experienced any particular issues on my GSM Nexus though. It's not like I get to use data very often anyway considering how little data i have and the state of Vodas current data network.
Question: Is it a separate processor for the baseband? or is it somehow multiplexed with android on the main CPU?
Answer: On phones like the Nexus S where the "Sleep" state (and even "Deep Idle" state) shuts off the CPU entirely, there must be a seperate low-power processor just for decoding and sorting through cell signals. This, in turn, will wake up the main CPU when something happens (call, text message, push notification, etc). That should clear a little up for you.
If I had skills required I would gladly help you, But I don't. It seems like you have done your homework, and done this before, so what exactly do you need help with? Re-writing it?
By the way that was a very interesting read!
Sent from my Nexus S 4G using XDA App
Very good read, and useful info. Have you tried mounting the radio.img in Linux, yet? I don't know exactly how to do it, but you should be able to. I run Linux dual booted with Windows, and have mounted the system.img no problem. I tried with the recovery.img, but no luck. I think you have to mount it as another filesystem.
mabry said:
Very good read, and useful info. Have you tried mounting the radio.img in Linux, yet? I don't know exactly how to do it, but you should be able to. I run Linux dual booted with Windows, and have mounted the system.img no problem. I tried with the recovery.img, but no luck. I think you have to mount it as another filesystem.
Click to expand...
Click to collapse
I doubt that radio.img would mount, Android is based on linux and uses linux filesystems. The radio is different, its more the same class as a bootloader (or rather, somewhere between). It does have a filesystem in that radio.img, but its likely encrypted.
Code:
Mar 15 17:45:28 localhost kernel: EXT3-fs (loop0): error: can't find ext3 filesystem on dev loop0.
Mar 15 17:45:28 localhost kernel: EXT2-fs (loop0): error: can't find an ext2 filesystem on dev loop0.
Mar 15 17:45:28 localhost kernel: EXT4-fs (loop0): VFS: Can't find ext4 filesystem
Mar 15 17:45:28 localhost kernel: SQUASHFS error: Can't find a SQUASHFS superblock on loop0
Mar 15 17:45:28 localhost kernel: FAT-fs (loop0): bogus number of reserved sectors
Mar 15 17:45:28 localhost kernel: FAT-fs (loop0): Can't find a valid FAT filesystem
Mar 15 17:45:28 localhost kernel: FAT-fs (loop0): bogus number of reserved sectors
Mar 15 17:45:28 localhost kernel: FAT-fs (loop0): Can't find a valid FAT filesystem
Mar 15 17:45:28 localhost kernel: ISOFS: Unable to identify CD-ROM format.
Mar 15 17:45:28 localhost kernel: hfs: unable to find HFS+ superblock
Mar 15 17:45:28 localhost kernel: hfs: can't find a HFS filesystem on dev loop0.
Mar 15 17:45:28 localhost kernel: ufs was compiled with read-only support, can't be mounted as read-write
Mar 15 17:45:28 localhost kernel: UDF-fs: warning (device loop0): udf_load_vrs: No VRS found
Mar 15 17:45:28 localhost kernel: UDF-fs: Rescanning with blocksize 2048
Mar 15 17:45:28 localhost kernel: UDF-fs: warning (device loop0): udf_load_vrs: No VRS found
Mar 15 17:45:28 localhost kernel: UDF-fs: warning (device loop0): udf_fill_super: No partition found (1)
NS4G.John said:
If I had skills required I would gladly help you, But I don't. It seems like you have done your homework, and done this before, so what exactly do you need help with? Re-writing it?
By the way that was a very interesting read!
Sent from my Nexus S 4G using XDA App
Click to expand...
Click to collapse
I need help getting amss.bin out of radio.img. I know how to deal with amss.bin once I have it, but I cannot find it in radio.img by signature (And indeed it would be hard to find anyway, due to how many signatures there are, and the length of the file is unknown.)
I mean, to clarify, I know I'm looking right at it, and I know when I'm in the middle of it. but I don't get where it starts and ends. And that is the important part.
A string dump of radio.img makes it appear as though the radio is un-encrypted. I could be wrong.
Stuff that makes me think its unencrypted:
Code:
desktop crespo4g # strings radio.img | grep amss
amss_start = 0x%x, amss_size = 0x%x
Code:
desktop crespo4g # strings radio.img | grep AMSS
0:AMSS
0:AMSS
0:AMSS
0:AMSS
0:AMSS
0:AMSS
AMSS
AMSS
AMSS_BOOT
AMSS_FILL_PAD_1
AMSS_EMPTY_PAD_1
AMSS_ZI_REGION
AMSS_EMPTY_PAD_2
AMSS_AUTOGENERATED_CODE_1
AMSS_AUTOGENERATED_CODE_2
AMSS_MODEM_CODE_1
AMSS_FILL_PAD_2
AMSS_MODEM_DATA_2
AMSS_MODEM_DATA_1
AMSS_APP_RAM
AMSS_FILL_PAD_3
AMSS_INTERNAL_BOOT_RAM_1
AMSS_INTERNAL_BOOT_RAM_2
AMSS_FILL_PAD_4
AMSS_MAIN_APP_2
AMSS_MAIN_APP_3
AMSS_MAIN_APP_4
AMSS_MAIN_APP_4_REDBEND
AMSS_FILL_PAD_5
AMSS_MAIN_APP_DATA_1
AMSS_FILL_PAD_6
AMSS_SHARED_RAM
AMSS_EMPTY_PAD_3
AMSS_UNINIT_RAM
AMSS_EMPTY_PAD_4
Harbb said:
Great read. I have no experience in this, nor any worthwhile software experience so I doubt i can help you, but if you think I can just let me know. I havn't experienced any particular issues on my GSM Nexus though. It's not like I get to use data very often anyway considering how little data i have and the state of Vodas current data network.
Question: Is it a separate processor for the baseband? or is it somehow multiplexed with android on the main CPU?
Answer: On phones like the Nexus S where the "Sleep" state (and even "Deep Idle" state) shuts off the CPU entirely, there must be a seperate low-power processor just for decoding and sorting through cell signals. This, in turn, will wake up the main CPU when something happens (call, text message, push notification, etc). That should clear a little up for you.
Click to expand...
Click to collapse
If you look at things like XEN, it would be entirely possible that the host os (radio, in this case) is trapping and preventing CPU halting. As a matter of fact I believe that the evidence points in the opposite direction due to the fact that "Deep Idle" produces no measurable battery savings. Its entirely possible, and perhaps likely, that the radio acts as a sort of, hypervisor, that controls Android's access to the underlying hardware. I don't know if this type of virtualization is available on ARM though. It really could go either way. And even in a halt state, interrupts are usually still possible, So the radio may be running inside of a timer even.
The crespo/d720/Nexus S 4G/Whatever else you'd like to call it, has severe issues regarding data speeds. Sprint pretends the issue doesn't exist, Samsung pretends the issues doesn't exist, Google is mostly powerless because its a radio issue that Sprint and Samsung are responsible for fixing. Hacking this radio may be the solution, but I've gotta get amss.bin out of radio.img. Until I do, there is nothing I can do either.
Quick update
Pouring over radio.img I came across the following string
Code:
NICTOKL4 - (provider: Open Kernel Labs) built on May 19 2009 00:21:02 using
gcc version 3.4.4.
What does this mean?
It mean's that AMSS Runs on the same CPU as android, and that it runs as a Hypervisor (Microvisor as Open Kernel Labs calls it). It has control over what the android kernel has access to. This is pure speculation, but I would guess this is why Deep Idle doesn't provide any real tangible benefit when it really should.
Thanks for the informative read. D
plaguethenet said:
If you look at things like XEN, it would be entirely possible that the host os (radio, in this case) is trapping and preventing CPU halting. As a matter of fact I believe that the evidence points in the opposite direction due to the fact that "Deep Idle" produces no measurable battery savings. Its entirely possible, and perhaps likely, that the radio acts as a sort of, hypervisor, that controls Android's access to the underlying hardware. I don't know if this type of virtualization is available on ARM though. It really could go either way. And even in a halt state, interrupts are usually still possible, So the radio may be running inside of a timer even.
The crespo/d720/Nexus S 4G/Whatever else you'd like to call it, has severe issues regarding data speeds. Sprint pretends the issue doesn't exist, Samsung pretends the issues doesn't exist, Google is mostly powerless because its a radio issue that Sprint and Samsung are responsible for fixing. Hacking this radio may be the solution, but I've gotta get amss.bin out of radio.img. Until I do, there is nothing I can do either.
Click to expand...
Click to collapse
Unfortunately a lot of your work is out of my league. However, Deep Idle (and the Sleep state, and even the idle state) all have proven benefits in various ways. Deep Idle shuts off the processor for, generally (for music), 19ms out of 20ms if i remember correctly. Idle would clock the processor at zero in much the same way, however i don't understand exactly what benefit (or process) there is to it aside from effectively minimizing power consumption (estimating CPU power consumption relies on the frequency, turning this to 0 in a perfect system would eliminate power use with the processor "on".. in theory). Either way, even Idle has shown power savings - while idle is used there is a far lower power draw. Without it, the results are much more believable and expected for the frequency, showing that it saves power by clocking the cpu to 0.
Further, i havn't tried this myself, but isn't Android perfectly capable to run without a radio at all? Because of this i highly doubt the radio is a hypervisor of any sort aside from anything radio-specific. I'm fairly certain the Radio acts more like a WoL chip, invoking the rest of the system as soon as it is triggered. Some reading material, maybe those two links add some insight too.
There is evidence of my argument here. Maybe you have confused Deep Idle and Sleep, but either way the two have proven benefits.
One thing to note, all of this is done on GSM Nexus S'. It could very well be different for the 4G CDMA radio, and even for the i9020A variant (i have the i9023 and think bedalus has a i9020T - ONLY difference is the screen). I have no experience with either the i9020A or 4G so it's all hearsay if it comes from me.
Harbb said:
Unfortunately a lot of your work is out of my league. However, Deep Idle (and the Sleep state, and even the idle state) all have proven benefits in various ways. Deep Idle shuts off the processor for, generally (for music), 19ms out of 20ms if i remember correctly. Idle would clock the processor at zero in much the same way, however i don't understand exactly what benefit (or process) there is to it aside from effectively minimizing power consumption (estimating CPU power consumption relies on the frequency, turning this to 0 in a perfect system would eliminate power use with the processor "on".. in theory). Either way, even Idle has shown power savings - while idle is used there is a far lower power draw. Without it, the results are much more believable and expected for the frequency, showing that it saves power by clocking the cpu to 0.
Further, i havn't tried this myself, but isn't Android perfectly capable to run without a radio at all? Because of this i highly doubt the radio is a hypervisor of any sort aside from anything radio-specific. I'm fairly certain the Radio acts more like a WoL chip, invoking the rest of the system as soon as it is triggered. Some reading material, maybe those two links add some insight too.
There is evidence of my argument here. Maybe you have confused Deep Idle and Sleep, but either way the two have proven benefits.
One thing to note, all of this is done on GSM Nexus S'. It could very well be different for the 4G CDMA radio, and even for the i9020A variant (i have the i9023 and think bedalus has a i9020T - ONLY difference is the screen). I have no experience with either the i9020A or 4G so it's all hearsay if it comes from me.
Click to expand...
Click to collapse
Quite the opposite, I was saying that because android and the RTOS (Real time os, for the radio) run under a "Microvisor" which is much like XEN, Android can halt the CPU all it wants, but the underlying OS that is virtualizing android wont really allow it. There are others that say the opposite of deep idle. I myself have noticed no benefit from it.
This is the results of a real study about battery life, specifically stating that deep idle does nothing, and indeed, as I noted above, I myself have also noticed no benefit. (But it SHOULD give a MAJOR benefit, which is why its so puzzling)
You can read it here.
I'll go into a bit more detail to clarify:
The phones basic startup process is:
Hardcoded Cryptographically secure bootloader -> NICTOKL4 (OS Hypervisor, or as OKL calls it, Microvisor)
NICTOKL4 Starts up the RTOS, and FASTBOOT
Fastboot then loads either the battery charging screen, Android, or Recovery (Or boots into fastboot mode) depending on the state of the phone.
(I could be wrong about what launches what, and may be missing, but I know that RTOS and Androids boot code are started at the same time by the microvisor)
RTOS Is running at all times after the phone is first powered on after having the battery removed, However it will disconnect from the cell network and sleep if told to, or if it has nothing to talk to. (Airplane mode and "off")
This is very similar to say, Linode. Where BIOS/EFI Loads an OS (The hypervisor Dom-0) and that OS Launches multiple guest OS's (Dom-U)
NICTOKL4 Is the only part of the phone that has true access to the hardware, and marshalls requests (usually blocking requests) to modify other OS Memory space, or access hardware.
The radio itself is actually just another guest OS, running under NICTOKL4. Android is entirely capable of running without a radio, but not on a phone without replacing the radio with android boot code.
Back to Deep Idle and Sleep. Sleep can be done and should provide benefit, because the microvisor can sleep too. Guest Sleeps, Microvisor sees all guests sleeping, so it sleeps too.
However, the radio software absolutely requires realtime communication with the hardware and network, or else synchronization would be lost. So halting the CPU (As deep idle does) cannot be allowed by the radio, and therefore cannot be allowed by the microvisor.
The information about the microvisor is fact by the way, I've found it in the radio.img for both my phone, and the i90xx radios.
I'm not trying to outright reject what you're saying Harbb, I just feel like I'm having trouble translating what I know into words others can understand.
You can learn more about the microvisor and its capabilities here
plaguethenet said:
Quite the opposite, I was saying that because android and the RTOS (Real time os, for the radio) run under a "Microvisor" which is much like XEN, Android can halt the CPU all it wants, but the underlying OS that is virtualizing android wont really allow it. There are others that say the opposite of deep idle. I myself have noticed no benefit from it.
This is the results of a real study about battery life, specifically stating that deep idle does nothing, and indeed, as I noted above, I myself have also noticed no benefit. (But it SHOULD give a MAJOR benefit, which is why its so puzzling)
You can read it here.
Click to expand...
Click to collapse
That battery life Portal post was a preliminary finding, which now is FOR deep idle, not against it. The thread that is linked to in it actually takes you to the same thread that i posted above proving my argument on deep idle. Go through the first 5 or so posts in the thread it links to, you'll find my own findings and bedalus' findings, and now even nathanson666's findings which is basically a deep idle experiment under a 1kHz ampmeter which provides proof to the millisecond level (which is where deep idle works). The larger problem with deep idle is that there is very little besides music that can truly benefit from deep idle, aside from it helping the surrounding OS very slightly while awake with the screen off.
Also, do you mind clarifying the bolded part a bit more?
plaguethenet said:
I'll go into a bit more detail to clarify:
The phones basic startup process is:
Hardcoded Cryptographically secure bootloader -> NICTOKL4 (OS Hypervisor, or as OKL calls it, Microvisor)
NICTOKL4 Starts up the RTOS, and FASTBOOT
Fastboot then loads either the battery charging screen, Android, or Recovery (Or boots into fastboot mode) depending on the state of the phone.
(I could be wrong about what launches what, and may be missing, but I know that RTOS and Androids boot code are started at the same time by the microvisor)
RTOS Is running at all times after the phone is first powered on after having the battery removed, However it will disconnect from the cell network and sleep if told to, or if it has nothing to talk to. (Airplane mode and "off")
This is very similar to say, Linode. Where BIOS/EFI Loads an OS (The hypervisor Dom-0) and that OS Launches multiple guest OS's (Dom-U)
NICTOKL4 Is the only part of the phone that has true access to the hardware, and marshalls requests (usually blocking requests) to modify other OS Memory space, or access hardware.
The radio itself is actually just another guest OS, running under NICTOKL4. Android is entirely capable of running without a radio, but not on a phone without replacing the radio with android boot code.
Back to Deep Idle and Sleep. Sleep can be done and should provide benefit, because the microvisor can sleep too. Guest Sleeps, Microvisor sees all guests sleeping, so it sleeps too.
However, the radio software absolutely requires realtime communication with the hardware and network, or else synchronization would be lost. So halting the CPU (As deep idle does) cannot be allowed by the radio, and therefore cannot be allowed by the microvisor.
The information about the microvisor is fact by the way, I've found it in the radio.img for both my phone, and the i90xx radios.
I'm not trying to outright reject what you're saying Harbb, I just feel like I'm having trouble translating what I know into words others can understand.
You can learn more about the microvisor and its capabilities here
Click to expand...
Click to collapse
I am doing much the same, only friendly discussion here I don't have time at the moment but i'll get to reading some more on this soon.
Anyway. I can guarantee that the main CPU can entirely halt and effectively freeze EVERYTHING in the phone so long as the screen is off and nothing is keeping it awake, and likely the exact same thing happens with Deep Idle but while processing something (this runs on the race-to-idle principle, even if slightly lower clocks may be more efficient here - hurry the hell up so i can shut down the CPU). If such a thing can happen, how can you conclude that the CPU must stay awake? This is why i've narrowed it down to another chip that must be aiding the radio.
I'd write more but i must get going. Keen to see where this takes us.
Harbb said:
That battery life Portal post was a preliminary finding, which now is FOR deep idle, not against it. The thread that is linked to in it actually takes you to the same thread that i posted above proving my argument on deep idle. Go through the first 5 or so posts in the thread it links to, you'll find my own findings and bedalus' findings, and now even nathanson666's findings which is basically a deep idle experiment under a 1kHz ampmeter which provides proof to the millisecond level (which is where deep idle works). The larger problem with deep idle is that there is very little besides music that can truly benefit from deep idle, aside from it helping the surrounding OS very slightly while awake with the screen off.
Also, do you mind clarifying the bolded part a bit more?
Click to expand...
Click to collapse
The radio is a real time operating system. I'd imagine that halting the CPU and bringing it back up is too costly for the radio, and therefore would be prevented by the radio. As far as WoL like functionality, I don't see any chip on the board that could provide that for the radio (or indeed anything for that matter). The only thing that has any radio capability is the main Application Processor, which has to be shared.
Harbb said:
I am doing much the same, only friendly discussion here I don't have time at the moment but i'll get to reading some more on this soon.
Click to expand...
Click to collapse
I get a bit excited and tend to get very technical and often miss things or seem like I'm trying to argue when i'm not. I just wanted to clarify that it wasn't intended as such.
Harbb said:
Anyway. I can guarantee that the main CPU can entirely halt and effectively freeze EVERYTHING in the phone so long as the screen is off and nothing is keeping it awake, and likely the exact same thing happens with Deep Idle but while processing something (this runs on the race-to-idle principle, even if slightly lower clocks may be more efficient here - hurry the hell up so i can shut down the CPU). If such a thing can happen, how can you conclude that the CPU must stay awake? This is why i've narrowed it down to another chip that must be aiding the radio.
I'd write more but i must get going. Keen to see where this takes us.
Click to expand...
Click to collapse
The freezing may only be for android though, You can independenly suspened/halt and resume virtualized applications (Either at their request, or preemptively). So its entirly possible for Deep Idle to behave properly in android, but not have the overall effect that one would think it would have. The processor would have much less to do and as such it likely does have some effect but the allowing an OS to execute such a disruptive instruction defeats the purpose of virtualization, if that makes any sense. Indeed the virtualized machine is halted, and nothing else is executing in the virtualized instance during this time. But the radio and Microvisor are very much alive during this. (You wouldn't be able to get an incoming call if they weren't.)
So in summary my argument is this:
Android cannot completely disable the CPU, this would cause NUMEROUS issues with the underlying radio software. WoL/WoR like functionality would be implemented in the radio software, From a development standpoint the complications FAR outweigh the benefits of such a design, It would not be fiscally responsible to design radio software in this way. If the processor were truly off, the microvisor would be unable to run and it would defeat the purpose of having said microvisor in the first place.
It would appear to android that the CPU Was off, and everything would halt (for android only). This should produce some battery savings (As even when idle an android system as some upkeep to do), but no where near the kind of savings you'd see with a truly halted CPU (that is woken by external interrupts). I will admit I was unaware additional testing was done.
If the system was truly halted for any period of time, When it was woken, the radio would be disconnected and would have to reconnect. You'd lose the ability to get notified of an incoming call or text (and to the cell network, your phone would be offline). You'd know if the cpu was TRULY frozen/halted/suspended.
Now, I'm not saying that the CPU Can't be put into a stopped state, just that android itself cannot make this happen. The microvisor would need permission from the radio, and the microvisor itself, would also need to be set to sleep as well. The radio is unlikely to give permisison, and as long as the microvisor, any of its children, or server processes, require the CPU, it will not actually happen. But the OS that halted itself will enter a fake halted state. (In reality, the hyper/microvisor would replace a HLT with a NOOP and stop executing the child. To the child this seems like being halted, but other things are still at work here.)
Another quick thought on deep idle. Perhaps the radio spends alot of time sleeping. Ideally it would know how often to wake up the delay may be as large as 50ms, which would explain the battery savings.
I don't know how often the phone would be polling the tower so can't comment on how often the radio would be sleeping, however i can say that i've had averages of around 50-60ms of deep idle time and possibly more. This is of course with the radio active.
I did try to erase the radio in fastboot, and BOOM! an error. It won't let me erase it to see how far it would boot. I'd rather not flash a bad file purposely, so i can't give any hard evidence on the radio being a primary boot initiator or kernel of sorts.
The minimum frequency of the CPU is 100mhz to my knowledge. Anything below this will likely get more and more inefficient and potentially useless. This is why on the Tegra 3's we now have a quad core main CPU + a little, much weaker (and much more efficient) core dedicated to low loads and the ability to rapidly switch between any setup you can imagine. Couldn't such interfaces such as WoL/WoR be entirely integrated into the radio chip?
Maybe i'm entirely deluded here, but i've yet to find hard evidence on either side and i'm leaning toward the ability to entirely shut off the CPU so far. Right now though, anything's possible.
Harbb said:
I don't know how often the phone would be polling the tower so can't comment on how often the radio would be sleeping, however i can say that i've had averages of around 50-60ms of deep idle time and possibly more. This is of course with the radio active.
I did try to erase the radio in fastboot, and BOOM! an error. It won't let me erase it to see how far it would boot. I'd rather not flash a bad file purposely, so i can't give any hard evidence on the radio being a primary boot initiator or kernel of sorts.
The minimum frequency of the CPU is 100mhz to my knowledge. Anything below this will likely get more and more inefficient and potentially useless. This is why on the Tegra 3's we now have a quad core main CPU + a little, much weaker (and much more efficient) core dedicated to low loads and the ability to rapidly switch between any setup you can imagine. Couldn't such interfaces such as WoL/WoR be entirely integrated into the radio chip?
Maybe i'm entirely deluded here, but i've yet to find hard evidence on either side and i'm leaning toward the ability to entirely shut off the CPU so far. Right now though, anything's possible.
Click to expand...
Click to collapse
I cant comment on tegra's design, I've never played with anything with a Tegra chipset. What I am speaking of is Qualcomm specific, its not a general truth for all phones. The problem with WoR/WoL in the radio chip, is all the radio chip does is pass demodulated data to the radio software, and modulate data thats going out on a requested frequency. ie, the radio hardware is dumb, and does exactly what its name implies, its a radio. It may be possible for it to say "Hey, I have data" but that would happen so frequently it would be pointless.
Erasing the radio would require JTAG to get the phone booted again, At least, I am 90% sure. The flash software for the radio also verifies the cryptographic signature and CRC's, so you won't be able to flash a "bad" radio at all. Only way to simulate this would be to yank the battery during a radio flash. But I believe there are also systems in place to prevent this from bricking the phone as well. If someone has a phone to sacrifice, this would be an interesting experiment and would yield some clues as to the boot process.
Also, On the tegra's, they may use a dedicated baseband processor instead of virtualizing it on the main CPU like the MSM chipsets do. If you want to point me to some tegra radio flash images I can give you some insight.
plaguethenet said:
I cant comment on tegra's design, I've never played with anything with a Tegra chipset. What I am speaking of is Qualcomm specific, its not a general truth for all phones. The problem with WoR/WoL in the radio chip, is all the radio chip does is pass demodulated data to the radio software, and modulate data thats going out on a requested frequency. ie, the radio hardware is dumb, and does exactly what its name implies, its a radio. It may be possible for it to say "Hey, I have data" but that would happen so frequently it would be pointless.
Erasing the radio would require JTAG to get the phone booted again, At least, I am 90% sure. The flash software for the radio also verifies the cryptographic signature and CRC's, so you won't be able to flash a "bad" radio at all. Only way to simulate this would be to yank the battery during a radio flash. But I believe there are also systems in place to prevent this from bricking the phone as well. If someone has a phone to sacrifice, this would be an interesting experiment and would yield some clues as to the boot process.
Also, On the tegra's, they may use a dedicated baseband processor instead of virtualizing it on the main CPU like the MSM chipsets do. If you want to point me to some tegra radio flash images I can give you some insight.
Click to expand...
Click to collapse
Good thing my phones smarter than me then, but it would've made a damn pretty paperweight
By the way, my suspicions seem to be correct, The Nexus S does have an integrated Baseband Processor, it can be found in step 10 of that page. Courtesy of iFixIt, of course.
After a quick look i couldn't find a radio for the Tegra 3s but i'm sure they'll pop up soon in the HTC One forums soon, even though it may not mean much now.
Harbb said:
Good thing my phones smarter than me then, but it would've made a damn pretty paperweight
By the way, my suspicions seem to be correct, The Nexus S does have an integrated Baseband Processor, it can be found in step 10 of that page. Courtesy of iFixIt, of course.
After a quick look i couldn't find a radio for the Tegra 3s but i'm sure they'll pop up soon in the HTC One forums soon, even though it may not mean much now.
Click to expand...
Click to collapse
Thats not a processor, Its an antenna selector and noise filter. SPI is too slow to handle GSM/UMTS/CDMA traffic.
Its purpose is to select the frequency band, detect if there is a signal, and select an antenna (Low gain, hi gain, etc) and connect the antenna to something else with the correct frequency. Thats all it really does.
You can see for yourself in the functional diagram located in this PDF: http://www.skyworksinc.com/uploads/documents/201206b.pdf
The radio of the Tegra would me most interesting to me, and but certainly not relevant to this project.
EDIT: Apologies, I missed the Infineon chip. I'll have to see if i can find a data sheet for it to see what it can do. I'll get back to you as soon as I know more.
EDIT2:
I found this PCI-Express card that uses the same baseband processor, The PDF has a pinout of the same baseband chip.
http://module.amod.com.tw/files/Product/2012215113150.pdf
It seems to me that this does most of the protocol/baseband processing, and makes me curious as to why they multiplex the application CPU At all in this case? This makes no sense to me. I mean, I know they do, and I know AMSS.BIN is supposed to run the radio, but it seems like it may be more of a driver between RIL and that chip in this case. Question is, why not write the RIL to use the chip directly using GPIO pins on the CPU? Puzzling...
More questions than answers. But in this case, WoL/WoR functionality is possible at least on GSM Models. Although it's more likely a hardware event (Interrupt) that would wake the processor anyway. Perhaps the seperate modem software is to implement extra AT commands for the modem, and hide the interrupts from Android's RIL? I wonder if we can send random AT Commands to that chip... I'll see what I can figure out with my phone.
Good luck mate. Let us know your progress.
Reading this conversation is quite intriguing.
Where can I find more information to feebly attempt to gain knowledge of what I've just read (besides Google )?
I want to create an "un-steal-able" phone.
Of course this is impossible, but I want to make it as difficult as possible for thieves to get away with it, and as easy as possible for me to find it.
Assumptions:
Phone has available call and text messaging service.
Phone has internet capabilities and "permanent" Internet access. (We will consider 2G, 3G, or 4G cellular access with a data plan to be permanent. Depending on an open WiFi network to be available at all times is unreliable).
Phone is on and has some charge in its battery. (If the phone is off, we can't do anything).
Phone has an accurate GPS receiver.
Requirements:
Software that relays GPS coordinates via an Internet connection. As a backup for when there is no cellular data signal, software that relay GPS coordinates via SMS
Software cannot be disabled or removed without authentication.
GPS on phone cannot be turned off without authentication (alternative: remote activation of GPS receiver via Internet or SMS)
Cellular data and/or WiFi cannot be turned off without authentication (alternative: remote activation of cellular data via SMS)
Where GPS signal can be used for macro location (within 10 to 30 meters), there must be some method of micro location (within a few feet).
Phone cannot be powered off via any button press, on-screen menu, or removal of battery
Phone cannot be wiped by on-screen menu or by computer cable connection
Now I have approached this solution from two starting points: the iPhone running iOS, or an Android-based smartphone. Both have different advantages and technical details. Let's look at how we can meet each of these requirements one by one.
iOS solution:
Unfortunately, if your iPhone is not jailbroken, your choices are not so great. But FindMyiPhone does do the basic job of relaying GPS coordinates. For a jailbroken iPhone, iCaughtu seems to be the best of the bunch from the research I have done and gives you a bunch of cool anti-theft features.
and
Using the options under Settings -> General -> Restrictions, you can disallow users from deleting apps AND from turning off location services. Of course, you can accomplish something similar by simple setting a password to access your phone. Unfortunately I haven't yet seen any program that allows you to remotely activate the GPS receiver on an iPhone.
Unfortunately I don't think there is anyway to prevent a thief from disabling your cellular connection other than setting a password on the whole phone. This has its advantages and disadvantages.* Similarly, I don't see any way to remotely activate the Cellular Data on an iPhone via SMS.
This is where things start to get more complex and we need to start thinking of actually modding the phone. So far the best RF tracking solution I have found (in terms of size, cost, and effectiveness) is a cheap chinese-made product that I picked up in Asia and cannot find a link to. This one is very similar http://www.amazon.com/Loc8tor-LTD-Loc8torLite-LOC8TOR-Lite/dp/B0012GMDC4/ but the reviews are meh. It is RF-based but does not really give any directional information. Once you are close to the RF transmitter (using the GPS coordinates), you can use the RF receiver to basically play a little game of hot and cold and walk in different directions all while watching if the signal gets stronger or weaker. I've done two real world field test with the similar device and was able to successfully find a purposely concealed bag in a slum twice.
But how do we get this into the phone? If you disassemble the transmitter, it is a very small circuit board, but most phones these days are already packed to the brim. Additionally, these units need power, so you would need to solder it into the phone's power system.
For the iPhone, concerns about a battery-based shutdown are reduced by its "sealed" battery compartment. Of course, with the right tools, someone can get to the battery. But this is not likely to happen quickly and will likely occur in a specific home or shop, from which we can get coordinate data. We only need to delay the thieves long enough to track them. The bad news is that preventing an iPhone from being shutdown via button press is much more difficult. Even with a lockscreen password, anyone can turn off an iPhone with a long power/sleep button press. I found a mod on Cydia that required a password before any shutdown, but it seemed it was only compatible with iOS 5 and I am running iOS 6.
This is the most challenging problem, as the most common method for any experienced phone thief to avoid detection is simply to power off the phone (or disable internet/3G) and as quickly as possible get to a computer and perform a complete wipe using any number of computer programs. A password on the phone can prevent access to the menu options for resetting factory default, but very little can prevent a thief from physically connecting the phone to a computer and wiping it.
Again I turn to physical modding. Would it be possible to modify the iPhone connector in such a way that the pins for power and charging would still work, but the pins for a data connection would require a specially modified cable to conect to the computer? Once my phone is through its initial setup and/or, most anything I need to do as far as data can be accomplished via WiFi. If needed, I would keep my special data cable at my home only and never take it out. But losing the ability to charge from any iPhone cable would be too debilitating to daily usage.
So I ask the experts: how can I improve on or solve these ideas? Is there software out there that I don't know about, either on the App Store or the Cydia Store? Are there ways to remotely control the iPhone's wireless and GPS functions via text? There should be. Any ideas on incorporating a tiny RF transmitter into the iPhone? Is there any way to prevent an iPhone from being shut down via the sleep button? Is there anyway to sabotage the lightning connector in an intelligent way to prevent a computer-based wipe?
*Advantages and Disadvantage of a phone-wide password. Honestly, I would rather not have a lockscreen password on my phone. I'm not a privacy freak and I don't care if a thief sees my pictures of e-mails or Facebook. If my phone is stolen, I'm hoping it is stolen by an idiot and that they WON'T try to wipe the phone. None of my solutions are foolproof. Everything in here is about delaying the thief long enough to track them. If an idiot steals a phone without a password, he MIGHT just use it as is. But if an idiot steals a phone and can't doing ANYTHING with it, he is going to take it to someone who will be smart enough to wipe it MUCH SOONER. Of course, the disadvantage is a loss of privacy, but iCaughtu has a cool solution for that too.
Android solution:
Android phones are much easier to root, and software solutions exist that will work reasonably well even for nonrooted phones. The best software I have seen is Avast! Anti-theft (part of Mobile Security), AndroidLost, and Cerebrus. All of these can report GPS coordinates, and with Avast! at least, you can also see coordinate history online and actually follow the path of your phone through the minutes, hours, and/or days. AndroidLost can report GPS coordinates online OR via SMS!
,
and
Avast! cannot be removed without a pin code. It can also prevent the user from during off Cellular Data and GPS. AndroidLost can be used to activate WiFi, Cellular Data and/or GPS via internet command OR via SMS. There are a ton of other internet-based and SMS commands in AndroidLost as well. Even without an active lockscreen password, a thief would be powerless to disable communication between the tracking software and you. In this department, Android truly outshines the iOS solution.
Getting an RF tracker into an Android-based phone has the same challenges as an iPhone.
I haven't found ANY glimmer of hope for a mode to disable shutdown via a long-button-press on Android. At least I found one mod for iPhone, even if it was the wrong iOS version. This is a huge gap in the goal of building an "unstealable" phone for both operating systems. As for the battery: Android phones come in many flavors. Many have removable batteries, so if you want to make life more difficult for thieves you'll have to limit yourself to a phone with a "sealed" battery compartment such as the HTC One.
A computer-based wipe via USB cable presents the same challenges as an iPhone EXCEPT that we're dealing with a more standard interface so that MIGHT make modding an easier task. Is there any way to make the microUSB jack more "proprietary" so that any normal USB cable can charge it but only a specially one can transmit data?
There is one other detailed I am interested in, but which is, I believe, currently impossible since it would require modifications to the lowest level of the phone's software, and that would be an auto-on feature. If the phone's battery dies for any reason (or any other shutdown that is not user-initiated), I would love for the phone to automatically power back on whenever it receives a new power source (either being plugged into the wall or getting a fresh battery).
Why am I so interested in doing this? I live in a third-world country and I travel to many other third-world countries. For 3 years, I guess I had good luck, but in the past year I have had three phones and a laptop stolen from me on the street and I have been punched in the face. Several of my friends have also had phones stolen during that time, and one friend was even kidnapped and robbed. Maybe crime is getting worse or maybe it is just coincidence. I have tried to be more careful each time, but one should not live life in fear or blame ones carelessness alone. It is time to fight back. Money, time, memories, self-respect, and peace of mind have been taken away from me and from people I care about. These thieves bear the real responsibility for these crimes. And the police and government here is largely unwilling, incapable, uncaring, and/or corrupt. Maybe I can help others as well.
Thanks for your suggestions and input.
Your thoughts are well expressed.
Hopefully something is coming fast to consumers.:good: