Database Info

Testing software (voice encription) in Europe

My company developed a product that uses GSM/CSD mode to send voice encrypded using 256 bits Rijndael. I don't know if in Europe my product works. I have a XDA working fine here in Brazil. I will apreciate if my software could be tested using the XDA and XDA-II (we don't tested-it with the XDA-II), because we don't have how to test-it in Europe.
My site is http://www.raseac.com.br , and in the site we have a working demo with 128 bits security and one minute of conversation per call. We have also a manual in PDF format (in english).
I will apreciate some help from Europe.
My personal e-mail is MOD EDIT: REMOVED EMAIL
Please erase the [REMOVE] in the e-mail.
Thank You.
Cesar Bremer Pinheiro

cesarbremer said:
My company developed a product that uses GSM/CSD mode to send voice encrypded using 256 bits Rijndael. I don't know if in Europe my product works. I have a XDA working fine here in Brazil. I will apreciate if my software could be tested using the XDA and XDA-II (we don't tested-it with the XDA-II), because we don't have how to test-it in Europe.
My site is http://www.raseac.com.br , and in the site we have a working demo with 128 bits security and one minute of conversation per call. We have also a manual in PDF format (in english).
I will apreciate some help from Europe.
My personal e-mail is MOD EDIT: REMOVED EMAIL
Please erase the [REMOVE] in the e-mail.
Thank You.
Cesar Bremer Pinheiro
Click to expand...
Click to collapse
I think you might consider looking also for European based solution, similar but using specifically MDA / XDA for encrypted comm
http://www.cryptophone.de/html/products_en.html
BTW when you consider introducing fully fledged and operational version for wm2003 ??
regards, monika

Thank you for your interest in our product.
We will test our product with the wm2003 in the next month, but we can't have a date limit to finish the compatibility test yet. There are a lot of hardware available to run our product. I will remember you that we are selling software (not hardware like cryptophone), and to sell our product we need to make compatibility tests in a lot of hardware . Our idea in this case is, if you have a hardware available (like the XDA), you only need to buy a software (and not the hardware that you already have). You investment in this case will be US$149,99 for the 128 bits version (US$ 249,99 for the 256 bits) in order to have a solid voice encryption product. Our product uses a TAPI modem linked with a PocketPc 2002 handheld by cable, bluetooth or a compactflash connection, and uses fixed, cellular and satelite lines. We tested the Raseac Secure Phone it in a lot of hardware (we have our product in our lab running in a XDA). We don't know about the CSD (Circuit Switched Data) quality in GSM networks outside Brazil (we are asking the readers to test-it and send us their comments). The bonus in this case is the use of a solid 128 bits voice encryption software free for one minute of conversation per call, with no limits in the number of calls (our freeware version).
Thank you.
Cesar Bremer Pinheiro

Sorry for the mistake in the price: The correct values are US$149.99 for the 128 bits version and US$249.99 for the 256 bits version.
Thank You.
Cesar.

How do we know if the software is actually carrying out the encryption, and that the voice is actually being encrypted is there something obvious that will let me know this.

The encryption is the easier part to be done in this system, if you see the user's manual, the most part of the system is the user interface and its architecture (our strongest point is our system design).
If you made a system that sends and receives voice without encryption, in our case you have 90% of the work done (error correction, codec optimization, software optimization). Think about reading the voice signal, compressing this signal using a voice codec, building the telephony interface, optimizing the code (our system is full-duplex), working a lot to optimize the code and let it running with quality), and until now i am not talking about encryption.
You can see in the google a lot of stuff about encryption (random number generators, hash functions, encryption functions), the encryption library available is huge.
After that work done to send and receive voice in a 4800 bauds line, you will see that 95% of the job is done. But i will remember that: To this system be a security system, all this design must be done before build the system. It is very dificult to transform a voice transmition system in a good security system(almost impossible) if you don't thing in security before building the system.
Now a little bit about encryption.
Our design is completely different from vast majority of the voice systems designs, we use block mode encryption and CBC mode encryption. The vast majority of the systems designs uses streaming mode. We generate an external random file in order to use the random numbers by the system. You can analyse this random file, it passes in the Diehard test (you can download the Diehard test and submit our generated file).
Each contact used by the system have its own master key, and you can edit this contact master key.
If you change one bit of this contact master key in your handheld, you will not be able to do the voice connection with the other handheld.
After reading our user manual, available in our site, you will see that this system was carefully built having security in mind, because you will see that you will have a 50 pages manual with a lot of information about security, and I invite you to read this manual (again, you will see a lot about our system design in this manual).
The Raseac Secure Phone security system spec will be published in february, and after that we will ask for an independent organization to analize our source code and publish the results (We think that the common user doesn't have the competence to analyse the source code). Our source code will not be available to the public only because commercial reasons, we sell software for commercial hardware available in the market (unlike our competition that sells proprietary hardware and have the copy protection inside their proprietary hardware), we have our system copy protection inside our code and we want to protect our intelectual property.
A little bit more about proprietary hardware systems: If you sell a hardware system and publish only part of the system (you can't garantee that the operational system was not changed in a dangerous way to compromise the security), the source published doesn't garantee the security at all.
Thank you.
Cesar Bremer Pinheiro.
MOD EDIT: REMOVED EMAIL
Please erase the [REMOVE] in the e-mail.

is it available in Asia?

[Q] Need a Location App Help

The target of the software is to gather some network info remotely avoiding any notification to the target mobile user and not installing any software in the target mobile.
Let me explain the idea in detail. First of all, we know that if we press *#06# then we can see the IMEI number of the set. So, there might be some secret way or code so that anybody can get the IMEI number of any mobile set with the help of just target mobile number.
That was just an example. However, there are some system of ping to check the reachability in IP network. In GSM network also there should be some secret code by which ping, trace route targeting a mobile number is possible. By these, the availability of the target can be confirmed. By the trace route result, we can obtain the path Of the pong reply or ping, present cell id. The individual cell ID also carries the name of the area in Unicode which is displayed in many sets optionally. That text may also be obtained from that. Actually, we want to do this by developing and installing an android software. In that car, we need to know the coding, programming language and special DLL or header that has to be called for this purpose.
2. Is there any way to call or search IMEI in any mobile network? Is it possible to find out the mobile number by inquiring with IMEI number from any mobile?
3. There is a way to configure a GSM modem with a cloned SIM may be so that the target mobile's all traffics including voice and SMS, may be data also. By default, all SIM's destination priority setting is 0. In the case, the modem has the higher priority so that at first the traffics reach there, modem software captures and records the traffic and then throws again to the target device. It's clear that here, the modem acts in transparent mode so that the target do not feel anything as well as it does not catch eyes of operators. We want to do this.
As here, I'm throwing the complete requirement along with technical description. Please let me know any further requirement.

Figuring out Samsung Accesory Protocol internals

Hello,
I want to figure out the Samsung Accesory Protocol in order to create a "open source" Gear Manager app replacement. This thread is to ask if anyone has been trying to do the same thing as well as try to gather as much information about this protocol as possible. Generic discussion is also accepted, in case anyone has better ideas.
Right now all I know is that this protocol is based on RFCOMM, albeit it can be transported over TCP too. It has a level 1 "framing" which consists basically on
Code:
packed struct Frame {
uint16_be length_of_data;
char data[length_of_data];
}
packed struct FrameWithCRC {
uint16_be length_of_data;
uint16_be crc_of_length;
char data[length_of_data];
uint16_be crc_of_data;
}
I also know that there are various types of packets. "Hello" packets are exchanged early during the connection and contain the product name, etc. Authentication packets are exchanged right after the initial "hello" and contain some varying hashes (crypto warning!). Then the normal data packets are "multiplexed", as in usbmuxd: they have 'session' IDs which described towards which watch program they are talking with. All Hello and authentication packets are sent without CRC, but normal data packets are. The CRC implementation used is crc16, same poly as in the linux kernel.
I suspect that whatever we uncover about this protocol might be useful to e.g. pair Gear with an iPhone, with a PC, things like that.
Note: most of this comes from viewing Bluetooth logs. However it's clear that reverse engineering will be required for the cryptographic parts. In this case I believe it's legally OK to do so in the EU because it's purely for interoperability reasons. I don't want to create a competitor to the Gear2, I just want to talk to it.
Motivation: I bought a Gear2 in order to replace a LiveView that was dying (buttons wearing out, broken wriststrap clips, etc.) . I used it both for notifications as well as map/navigation.
Since I have a Jolla, no programs are available to pair with most smartwatches, but I've been developing my own so far (MetaWatch, LiveView). Thus I decided on a replacement based purely on hardware characteristics and price. Also Tizen seems more open than Android, thus I figured out it would be easier for me to adapt to the watch.
However it seems that I understimated the complexity of the protocol that connects the Gear with the GearManager. So my options in order to make use of this watch are:
Sell Gear2 back and buy something that's easier to hack (e.g. another LiveView ),
Figure out the SAP protocol and write a replacement Gear Manager app (what this thread is about),
Write replacement Tizen applications that don't use SAP. This involves writing new programs for Calls, Messages, Notifications, Alarms, Camera, watchOn, Pulse monitor, etc. i.e. a _lot_ of work if I want to exploit all features of the watch.
But at least one can reuse the existing Tizen settings app, launcher, drivers, etc. (I started porting Qt to the Gear2 with this idea)
Use a different Linux distro on the Gear 2. Such as Sailfish, Mer, etc. This involves all the work of option 3 + possibly driver work.
As of now I've not decided which option is easier for me so I'll keep trying to push them all.

javispedro said:
Hello,
I want to figure out the Samsung Accesory Protocol in order to create a "open source" Gear Manager app replacement. This thread is to ask if anyone has been trying to do the same thing as well as try to gather as much information about this protocol as possible. Generic discussion is also accepted, in case anyone has better ideas.
Right now all I know is that this protocol is based on RFCOMM, albeit it can be transported over TCP too. It has a level 1 "framing" which consists basically on
Code:
packed struct Frame {
uint16_be length_of_data;
char data[length_of_data];
}
packed struct FrameWithCRC {
uint16_be length_of_data;
uint16_be crc_of_length;
char data[length_of_data];
uint16_be crc_of_data;
}
I also know that there are various types of packets. "Hello" packets are exchanged early during the connection and contain the product name, etc. Authentication packets are exchanged right after the initial "hello" and contain some varying hashes (crypto warning!). Then the normal data packets are "multiplexed", as in usbmuxd: they have 'session' IDs which described towards which watch program they are talking with. All Hello and authentication packets are sent without CRC, but normal data packets are. The CRC implementation used is crc16, same poly as in the linux kernel.
I suspect that whatever we uncover about this protocol might be useful to e.g. pair Gear with an iPhone, with a PC, things like that.
Note: most of this comes from viewing Bluetooth logs. However it's clear that reverse engineering will be required for the cryptographic parts. In this case I believe it's legally OK to do so in the EU because it's purely for interoperability reasons. I don't want to create a competitor to the Gear2, I just want to talk to it.
Motivation: I bought a Gear2 in order to replace a LiveView that was dying (buttons wearing out, broken wriststrap clips, etc.) . I used it both for notifications as well as map/navigation.
Since I have a Jolla, no programs are available to pair with most smartwatches, but I've been developing my own so far (MetaWatch, LiveView). Thus I decided on a replacement based purely on hardware characteristics and price. Also Tizen seems more open than Android, thus I figured out it would be easier for me to adapt to the watch.
However it seems that I understimated the complexity of the protocol that connects the Gear with the GearManager. So my options in order to make use of this watch are:
Sell Gear2 back and buy something that's easier to hack (e.g. another LiveView ),
Figure out the SAP protocol and write a replacement Gear Manager app (what this thread is about),
Write replacement Tizen applications that don't use SAP. This involves writing new programs for Calls, Messages, Notifications, Alarms, Camera, watchOn, Pulse monitor, etc. i.e. a _lot_ of work if I want to exploit all features of the watch.
But at least one can reuse the existing Tizen settings app, launcher, drivers, etc. (I started porting Qt to the Gear2 with this idea)
Use a different Linux distro on the Gear 2. Such as Sailfish, Mer, etc. This involves all the work of option 3 + possibly driver work.
As of now I've not decided which option is easier for me so I'll keep trying to push them all.
Click to expand...
Click to collapse
I think your thread should probably go in the Dev section for Tizen. Have you made any development? If your want it moved, report your own post with the button in top right labeled report. You can then suggest your thread be moved to the new Tizen Development section. Ok, I wish you all the luck, you seem to be very talented programmer/dev. Thanks for your contributions.
Chris

noellenchris said:
I think your thread should probably go in the Dev section for Tizen.
Click to expand...
Click to collapse
Well, some mod already moved this thread from Development, where I originally posted it, into Q&A. This is not exactly "Tizen" development (SAP is used in may Samsung devices seemingly).
noellenchris said:
Have you made any development?
Click to expand...
Click to collapse
Yes, lots of progress. I have been able to write a program that connects to the Gear2 from my PC, succesfully "completes" the setup program and synchronizes the date&time. Things like changing the background color etc. are now trivial. I will soon port it to my Jolla.
I am now looking into how to send notifications to the watch. I've not been able to get Gear Manager to actually send any notifications (to use as "reference"), because goproviders crashes when I try to simulate notifications on my android_x86 VM
If anyone can send me an HCI / Bluetooth packet capture of their Android device while it is sending notifications to the Gear2 I would really appreciate it.
Unfortunately, the main problem here is that Samsung uses some cryptographic authentication as a form of "DRM". I am not exactly sure why.
There was no way for me to discover how the crypto worked so I took the unclean approach and dissasembled their crypto code (libwms.so). That means there's no way I would be able to distribute the code now without risking a lawsuit from Samsung.
Sadly this means that while I can distribute the protocol specifications I obtained, legally distributing "Gear Manager replacements" is probably impossible.

javispedro said:
Well, some mod already moved this thread from Development, where I originally posted it, into Q&A. This is not exactly "Tizen" development (SAP is used in may Samsung devices seemingly).
Click to expand...
Click to collapse
Ya, I was kinda in a Gear 1 mind set, and they have separate threads for Android and Tizen....
Chris

javispedro said:
Unfortunately, the main problem here is that Samsung uses some cryptographic authentication as a form of "DRM". I am not exactly sure why.
There was no way for me to discover how the crypto worked so I took the unclean approach and dissasembled their crypto code (libwms.so). That means there's no way I would be able to distribute the code now without risking a lawsuit from Samsung.
Sadly this means that while I can distribute the protocol specifications I obtained, legally distributing "Gear Manager replacements" is probably impossible.
Click to expand...
Click to collapse
I would gladly write a MIT-licensed C library implementing your protocol specifications. That would be correctly following the chinese-wall approach to reverse-engineering, right?
Anyway, AFAIK, being in Europe decompiling for interoperability purposes is allowed -- I know that wikipedia is not to be taken at face value, but: en.wikipedia.org/wiki/Reverse_engineering#European_Union

Antartica said:
I would gladly write a MIT-licensed C library implementing your protocol specifications. That would be correctly following the chinese-wall approach to reverse-engineering, right?
Anyway, AFAIK, being in Europe decompiling for interoperability purposes is allowed -- I know that wikipedia is not to be taken at face value, but: en.wikipedia.org/wiki/Reverse_engineering#European_Union
Click to expand...
Click to collapse
Well, the problem is not the protocol specifications per se, which I'm actually quite confident I'd be able to redistribute (I'm in EU). The problem is the cryptography part, which is basically ripped off from the Samsung lib "libwsm.so" . Unless we can find out what cryptographic method that lib uses, distributing alternate implementations Is a no-go.

javispedro said:
Well, the problem is not the protocol specifications per se, which I'm actually quite confident I'd be able to redistribute (I'm in EU). The problem is the cryptography part, which is basically ripped off from the Samsung lib "libwsm.so" . Unless we can find out what cryptographic method that lib uses, distributing alternate implementations Is a no-go.
Click to expand...
Click to collapse
If you have the time, I don't mind researching the possible crypto used (although I've only studied DES/3DES, AES and Serpent, hope that whatever scheme used is not very different from them).
Some ideas to start from somewhere:
1. As you have used its functions, it is a block cipher? I will assume that it is.
2. What is the key size and the block size?
3. Are there signs that it is using a stack of ciphers? (that is, applying one cipher, then another to the first result and so on)

Antartica said:
If you have the time, I don't mind researching the possible crypto used (although I've only studied DES/3DES, AES and Serpent, hope that whatever scheme used is not very different from them).
Some ideas to start from somewhere:
1. As you have used its functions, it is a block cipher? I will assume that it is.
2. What is the key size and the block size?
3. Are there signs that it is using a stack of ciphers? (that is, applying one cipher, then another to the first result and so on)
Click to expand...
Click to collapse
Hello, I've not forgotten about this, just somewhat busy and been using the MetaWatch lately
1. Yes it is clearly a block cipher, and the block size Is 16bytes.
2. I don't know about the key size, it is obfuscated.
3. Doesn't seem like a stack of ciphers. It looks like some overcomplicated AES. But to be honest AES is the only encryption I know of
By the way I think I will upload my current test "manager" source code to somewhere after removing the crypto specific files . Since the protocol itself has been obtained cleanly. Note I've used Qt (not the GUI parts) so it's useless for creating a library; the code will probably need to be rewritten to do so, but it may be useful as "protocol specs".

javispedro said:
Hello, I've not forgotten about this, just somewhat busy and been using the MetaWatch lately
Click to expand...
Click to collapse
No problem. Curiously, I've transitioned from the metawatch to the Gear1 fully (null rom, not pairing with bluetooth to the phone but gear used as a standalone device).
[off-topic]I'm not using my metawatch anymore. I was modifying Nils' oswald firmware to make it prettier and to have some features I wanted (calendar, stopwatch), but it was very inaccurate, supposedly because of missing timer interrupts (the existing LCD drawing routines were too slow). I rewrote the graphics subsystem just to stumble into a known mspgcc bug, and trying to use the new redhat's mspgcc resulted in more problems (memory model, interrupt conventions). In the end I couldn't commit enough time to fix that and my metawatch is now in a drawer[/off-topic]
Returning to the topic:
javispedro said:
1. Yes it is clearly a block cipher, and the block size Is 16bytes.
Click to expand...
Click to collapse
Good. We can at least say it isn't DES/3DES nor blowfish (64 bits block size). Regrettably there are a lot of ciphers using 128-bits block size; that I know: AES, Twofish and serpent.
Perusing the wikipedia there are some more of that size in use: Camellia, sometimes RC5 and SEED.
javispedro said:
2. I don't know about the key size, it is obfuscated.
3. Doesn't seem like a stack of ciphers. It looks like some overcomplicated AES. But to be honest AES is the only encryption I know of
Click to expand...
Click to collapse
I understand that to mean that you cannot use that library passing your own key, right?
What a pity! One way to test for these ciphers would have been to just cipher a known string (i.e. all zeroes) with a known key (i.e. also all zeroes) and compare the result with each of the normal ciphers :-/.
javispedro said:
By the way I think I will upload my current test "manager" source code to somewhere after removing the crypto specific files . Since the protocol itself has been obtained cleanly. Note I've used Qt (not the GUI parts) so it's useless for creating a library; the code will probably need to be rewritten to do so, but it may be useful as "protocol specs".
Click to expand...
Click to collapse
Perfect. I don't need anything more .

Ok, so I've uploaded my SAP protocol implementation: https://git.javispedro.com/cgit/sapd.git/ . It's "phone" side only, ie it can be used to initiate a connection to the watch but not to simulate one. In addition, it's missing two important files: wmscrypt.cc and wmspeer.cc which implement the closed crypto required to "pair" the watch. The most important file is sapprotocol.cc which implements the packing/unpacking of the most important packet types. The license of those files is GPLv3 albeit I'm very happy if you use the information contained on them to build your "Gear Manager" program under whichever license you'd prefer.
For anyone who hasn't been following the above discussion: I've figured out a large part (useful for at least establish contact with the watch and syncing time/date) of the SAP protocol used between the Gear watch and the Gear manager program on the phone. This has been done mostly by studying traces and afterwards talking to the watch using my test implementation above to figure out the remaining and some error codes. The debug messages left by the watch's SAP daemon were also immensely helpful. As long as I understand this is perfectly safe to do, publish and use as I'm in the EU and is basically the same method Samba uses.
Unfortunately, the protocol contains some crypto parts required for the initial sync (subsequent connections require authentication). However, the communication itself is not encrypted in any way, which helped a lot with the process. Because it's impossible for me to figure out whatever authentication method is used, I had to disassemble the library implementing this stuff (libwms.so). This is still OK according to EU law, but I'm no longer to release that information to the public. I'm looking for alternatives or ideas on how to handle this fact.
In the meanwhile, let's talk about the protocol. It's basically a reimplementation of the TCP(/IP) ideas on top of a Bluetooth RFCOMM socket. This means that it's connection oriented and that it can multiplex several active connections (called "sessions") over a single RFCOMM link. Either side of the connection can request opening a connection based on the identifier of the listening endpoint (called a "service"). Strings are used to identify services instead of numeric ports as in TCP. For example, "/system/hostmanager" is a service that listens on the watch side. Once you open a session towards this service (i.e. once you connect to it) you can send the time/date sync commands. In addition to be the above the protocol also seems to implement QoS and reliability (automatic retransmission, ordering, etc.). It's not clear to me why they reimplemented all of this since RFCOMM is a STREAM protocol, and thus reliability is already guaranteed!! So I've not focused much on these (seemingly useless) QoS+reliability parts of the protocol.
Let's start with the link level. There are two important RFCOMM services exposed by the watch: {a49eb41e-cb06-495c-9f4f-aa80a90cdf4a} and {a49eb41e-cb06-495c-9f4f-bb80a90cdf00}. I am going to respectively call those two services "data" and "nudge" from now on. These names, as many of the following ones, are mostly made up by me .
The communication starts with Gear manager trying to open a RFCOMM socket towards the "nudge" service in the watch. This causes the watch to immediately reply back by trying to open a connection to the "data" service _on the phone_ side. So obviously this means that your phone needs to expose the "data" RFCOMM service at least. In addition, the watch will try to open a HFP-AG connection (aka it will try to simulate being a headset) to your phone. Most phones have no problem doing this so no work is required. Of course, if your phone is a PC (as in my case ) then you'll need to fake the HFP profile. I give some examples in my code above (see scripts/test-hfp-ag and hfpag.cc).
Once the RFCOMM socket from the watch to the phone "data" service is opened, the watch will immediately send what I call a "peer description" frame. This includes stuff such as the model of the watch as well as some QoS parameters which I still don't understand. The phone is supposed to reply back to this message with a peer description of its own. See sapprotocol.cc for the packet format.
After the description exchange is done, the watch will send a "authentication request" packet. This is a 65 byte bigint plus a 2 byte "challenge". The response from the phone should contain a similar 65 byte bigint, the 2 byte response, and an additional 32 byte bigint. If correct, the watch will reply with some packet I don't care about. Otherwise the connection will be dropped. It obviously looks like some key exchange. But this is the crypto part that's implemented in libwms.so....
After these two exchanges link is now set up. The first connection that needs to be opened is towards a service that is always guaranteed to be present, called "/System/Reserved/ServiceCapabilityDiscovery". It is used by both sides of the connection to know the list of available services present on the other side. Despite this, you cannot query for all services; instead, you must always know the name of the remote service you're looking for. There's some 16-byte checksum there which I don't know how to calculate, but fortunately the watch seems to ignore it!! I suspect that you're expected to actually persist the database of available services in order to shave a roundtrip when connection is being established. But this is not necessary for normal function. This service is implemented in capabilityagent.cc, capabilitypeer.cc . This part was actually one of the most complex ones because of the many concepts. I suggest reading the SDK documentation to understand all the terms ("service", "profile", "role", etc.).
If everything's gone well, now the watch will try to open a connection to a service in your phone called "/system/hostmanager". Once you get to this message things start to get fun, because the protocol used for this service is JSON! It's implementation resides in hostmanageragent.cc, hostmanagerconn.cc . For example, Gear Manager sends the following JSON message once you accept the EULA: {"btMac":"XX:XX:XX:XX:XX:XX", "msgId":"mgr_setupwizard_eula_finished_req", "isOld":1}. At this point, the watch hides the setup screen and goes straight to the menu.
Well, this concludes my high-level overview of the SAP protocol. Hope it is useful for at least someone!
Things to do:
Personally I'm looking for some traces of the notification service. Ie the one that forwards Android notifications towards the watch. For some reason it doesn't work on my phone, so I can't get traces. I suspect it's going to be a simple protocol so a few traces will be OK. It's the only stuff I'm missing in order to be able to actually use the Gear as a proper smartwatch with my Jolla.
We still need to tackle the problem of the cryptographic parts. Several options: either "wrap" the stock libwms.so file, try to RE it the "proper way", .... I'm not sure of the feasibility of any of these.
Many other services.

javispedro said:
After the description exchange is done, the watch will send a "authentication request" packet. This is a 65 byte bigint plus a 2 byte "challenge". The response from the phone should contain a similar 65 byte bigint, the 2 byte response, and an additional 32 byte bigint. If correct, the watch will reply with some packet I don't care about. Otherwise the connection will be dropped. It obviously looks like some key exchange. But this is the crypto part that's implemented in libwms.so....
Click to expand...
Click to collapse
About that 65-byte bigint... that is a 520-bit key. The usual length of ECDSA keys is exactly 520-bits, so we may have something there: it is possible that they are using ECDSA signing (just like in bitcoin, so there are a lot of implementations of that code).

Not forgotten about this!
Just an status update:
I'm still in the process of defining the API of the C library using javispedro's sources as template.
It's tougher than I originally supposed because the C++ code has a lot of forward-declarations of classes, which is very difficult to map into C. To counter that I have to move elements between structures and I'm not so comfortable with the codebase yet.
And then there is still the hard work of translating the Qt signals/slots to plain' old callbacks... and implementing the bluetooth part using bluez API... and... well, I hope that is all.
Anyway, patience .

I've now had access to a Samsung S2 and thus I have been able to obtain more traces. The latest Git now contains code to connect to the notification manager service, thus allowing to send notifications from the phone to the watch.
That was the last missing part to be able to use the Gear 2 as a 'daily' smartwatch with my Jolla, so I've now also ported the code to run under Sailfish. In fact I'm using this setup at the moment. My first comment is "wow the vibrator IS weak".
You can find a log of sapd's (ie my code) startup qDebug() messages; they may be useful (if you can't yet get your code to run)
I suspect that there may still be some important battery issues because the watch keeps printing error messages about SAP services it can't find on the phone (and instead of sleeping, it starts busy polling for them.... :/ ). It does not seem to happen while the watch is out of the charging cradle, so it may not be important, but not sure yet.
As for the encryption, I'm not sure how to proceed. I could describe the code to you, but that would be risky, because I don't understand what it does. Thus the only way (for me) to describe it would be to pass on the mathematical formulas/pseudocode ... Apart from that, we also have the problem of the keys...
Antartica said:
The usual length of ECDSA keys is exactly 520-bits, so we may have something there: it is possible that they are using ECDSA signing
Click to expand...
Click to collapse
They do use ECDH indeed, and they link with OpenSSL and import the ECDH functions. However it's not clear if they use ECDSA; while the crypto algorithm DOES resemble DSA, I cannot fully identify it.

Congratulations for managing to make it work with the Jolla .
I have finally found a suitable "flattened" class hierarchy as to be able to map your code into C; see the attachs. Basically, I have to move the functionality of SAPConnectionRequest, SAPSocket, CapabilityPeer and SAPConnection into SAPPeer, and then it is suitable for my needs.
javispedro said:
As for the encryption, I'm not sure how to proceed. I could describe the code to you, but that would be risky, because I don't understand what it does. Thus the only way (for me) to describe it would be to pass on the mathematical formulas/pseudocode ... Apart from that, we also have the problem of the keys...
They do use ECDH indeed, and they link with OpenSSL and import the ECDH functions. However it's not clear if they use ECDSA; while the crypto algorithm DOES resemble DSA, I cannot fully identify it.
Click to expand...
Click to collapse
If you manage to describe it using mathematical formulas as in
http://en.wikipedia.org/wiki/Ellipt...ture_Algorithm#Signature_generation_algorithm
it would be perfect, but I reckon that to be able write that you need intimate knowledge of the code and don't know if you have time for that :angel:
And identifying the hash function used would be a problem in itself...
One idea: how about a ltrace so we have the calls to the openssl library? That may uncover new hints.
Anyway, I have a lot of work before me until I need that, so don't fret over it.

Hi there! Any chance that the Gear can (really) work with an iPhone?

gidi said:
Hi there! Any chance that the Gear can (really) work with an iPhone?
Click to expand...
Click to collapse
agreed. Needs iPhone support please.

Antartica said:
Congratulations for managing to make it work with the Jolla .
I have finally found a suitable "flattened" class hierarchy as to be able to map your code into C; see the attachs. Basically, I have to move the functionality of SAPConnectionRequest, SAPSocket, CapabilityPeer and SAPConnection into SAPPeer, and then it is suitable for my needs.
Click to expand...
Click to collapse
You may want to look at the official Samsung SDK docs to match their class hierarchy. I tried to match my hierarchy to theirs, but this happened very late in the development process, so there is some weirdness.
Antartica said:
One idea: how about a ltrace so we have the calls to the openssl library? That may uncover new hints.
Click to expand...
Click to collapse
I more or less know what it is doing with OpenSSL, but that's because I looked at the dissassembly. They use OpenSSL for key derivation (ECDH), but the actual cryptographic algorithm is their own. This 'block cipher' is the part they have tried to obfuscate. Not much, but still enough to require more time than what I have available It is basically a set of arithmetical operations with some tables hardcoded in the libwsm.so binary, so no external calls to any library. The hardcoded tables are probably derivated from their private key, which is most definitely not on the binary. In fact I suspect this is basically AES with some changes to make it hard to extract the actual key used, so that's where I've centered my efforts.
Technically it should not even be copyrightable, so maybe I could just redistribute my C reimplementation of the algorithm, but as with any other DRM who knows these days... and that still leaves the problem of the tables/"private key".
Digiguest said:
agreed. Needs iPhone support please.
Click to expand...
Click to collapse
Well you are welcome to implement one such iPhone program yourself. Will be happy to resolve all the protocol questions you have.
(But please stop with the nagging).

Wasn't nagging at all. Just agreeing with him. I am no programmer so I have to rely on others for answers. Sorry if you thought otherwise.
Looking for to see more work on it though. Keep it up.

Hi there! Nice work on getting Gear2 to work with Jolla.
I'd love to get Gear1 to work with WP8.1. Do you have the code for Jolla
on github/bitbucket so I could give it a peek? Thanks in advance.

Duobix said:
Hi there! Nice work on getting Gear2 to work with Jolla.
I'd love to get Gear1 to work with WP8.1. Do you have the code for Jolla
on github/bitbucket so I could give it a peek? Thanks in advance.
Click to expand...
Click to collapse
javispedro had the sources in gitorius, but they are not there anymore (surely related to gitlab buying gitorius).
I attach a tarball with javispedro sources as of 19 October 2014.
Note that it lacks the files implementing the crypto, so just porting it is not enough to be able to communicate to the gear. OTOH, I know that there are some differences in the protocol between the Android Gear1 and the Tizen Gear2 (if the gear1 has been updated to Tizen, it uses the same protocol as gear2). Specifically, to be able to communicate with both watches, the gear manager package has both gear manager 1.7.x and gear manager 2.x. javispedro's code implements the gear 2 protocol.
Personally, I have my port on hold (I have problems with bluetooth in my phone, so there is no point in porting sapd right now as I would not be able to use it).

[GUIDE] Reversing of insertions for ARM-based mobile phones

Author: Apriorit (Research and Reverse Engineering Team)
Permanent link: www(dot)apriorit(dot)com/dev-blog/76-reversing-of-mobile-phones-insertions
Once we faced the need to investigate how Samsung cellular phones work; we required some information from them, which is not documented (and will never be, for sure). So this article is about interesting points our reverser had met while working with Samsung cellular phones firmware.
Reversing of Insertions for ARM-based Mobile Phones
I have managed to research insertions of all Samsung' generations, including CDMA (except for the smartphones only). In every Samsung phone the ARM-compatible processor with a set of ARM7TDMI commands is used. Insertions are built on the basis of three OS: RTCX, RTK, Nucleus, and compiled on different compilers. I have seen insertions compiled on ADS (SDT) and IAR.
On forums people call Samsung's generations in different way: somebody divides them into Gumi/Suvon (2 cities in Korea), others give code names - "Sysol", "Agere", "VLSI", "Conexant" and "Ancient". I have come to a conclusion that it's more correctly to divide them according to the phone processor.
Processor Models
OM6357 (aka Sysol) E100, E700, E720, E800, E820, S50x, X100, X460, X60x
M46 (aka Conexant) A100, A110, A200, A300, A400, M100, T208
SkyWorks (aka Conexant) C100, C108, C110, P510, P518
ONE-C (aka VLSI) R2XX, Nxxx, Txxx(except for T208)
Trident (aka Agere) Dxxx, Qxxx, Sxxx(except for S50x), Vxxx, C200, E105, E310, E400, E600, E710, E810, X105, X400, X42x, X450 etc.
MSMxxxx all CDMA
Hope, I haven't made any mistakes in this list. )
According to the list, insertions within the same generation are very similar and, to be honest, sometimes they are twins at all (with extremely slight changes). For example, in X100 there are obvious traces of E100/E700/X600 - why then there is a code for working with the second display, camera and IRDA, which it didn't have in a whole life?
Naturally, OS is the same for the whole generation:
OM6357 - RTK
M46 - RTCX OSE
SkyWorks - RTCX OSE
ONE-C - RTK
Trident - Nucleus
MSMxxxx - don't know exactly, it might be any OS from Qualcomm. It's just clear that they are collected to ADS/SDT.
If you are going to investigate the low level, then SDK from corresponding OS will be to the point. Another helpful thing is the symbolical information, which can be met in some insertions archives. Sometimes you can come across the insertions with .lst, .sym, .map, .out files, containing the information, extremely useful in researches. In particular, such files occur in almost all C100, S500 insertions. When talking about the other models, the situation is worse and you have to content yourself with symbols signatures, made for insertion of the same generation. For example, for M46 I have managed to find just one insertion with symbols and it was from A110. But signatures made from it perfectly lie down on A200, A300 etc.
Interpretation of the symbolical information
MAP format
.map files contain the information on modules included in the insertion and look like
Code:
Base Size Type RO? Name
0 20 CODE RO AAA_vectors from object file obj/isr.o
20 38e8 CODE RO C$$code from object file../../src/t9latin.o
3908 30 CODE RO C$$code from object file obj/mmi_date.o
3938 5a4 CODE RO C$$code from object file hw_slow.o
3edc 874 CODE RO C$$code from object file rtkgo.o
etc.
where
Base - displacement in an insertion file.
Size - length.
Type - region type.
RO? - region access type.
Name - original file name, part of which was included in the insertion
How all this can be interpreted? For example, this way: starting with displacement 20, there is a block of the code (CODE) 38e8 length - it's an access to Read Only block. The fact that block has CODE attribute is far from being means that the WHOLE area is filled with a code. Actually, it is a code plus data, just as if the block has DATA type it does not mean that it is necessary to make it all by data in IDA.
Without the names/symbols file this information can be used only for determination of insertion code size (i.e. to not get into the graphics). Therefore, we will better examine SYM format.
SYM Format
.sym files are the mines of information. They look like:
Code:
Symbol Table
AAA_vectors$$Base 000000
AAA_vectors$$Limit 000020
VectorMap$$Base 1006a3c
VectorMap$$Limit 1006a60
isr$$Base 12774c
isr$$Limit 127bb0
gl_MaskIT 1000078
Rtk_RegionCount 100564c
rtk_WorthItSched 10056a0
Rtk11_Schedule 11f5c8
etc.
It is a little bit easier here, because the name-address correspondence exists. But as for the addresses, there are some secrets - a set of names exists, containing $ sign and having the special status. Symbols with $$Base at the end indicate the beginning of virtual address space area, $$Limit indicates the end. I.e. here we have the information on segments. It is possible to make a memory map of these segments and see how the parts of binary code are being thrown to different addresses. Building memory map should be started with such symbols:
Code:
Image$$RO$$Base 000000
Image$$RO$$Limit 1afef4
Image$$RW$$Base 1000000
Image$$RW$$Limit 107dad4
Image$$ZI$$Base 1006a60
Image$$ZI$$Limit 107dad4
RO - Read Only, indicates code addresses.
RW - Read/Write i.e. it is RAM.
ZI - Zero Initialized. RAM, which is being stuffed with zero values when mobile phone is turned on.
Thus segments can be easily created on these addresses. Now we look further:
Code:
AAA_vectors$$Base 000000
AAA_vectors$$Limit 000020
C$$code$$Base 000020
C$$code$$Limit 127310
C$$code$$__call_via$$Base 127310
C$$code$$__call_via$$Limit 127320
Example$$Base 127320
Example$$Limit 127324
HAL_boot$$Base 127324
HAL_boot$$Limit 12735c
RtkCode$$Base 12735c
RtkCode$$Limit 127408
SysSupportCode$$Base 127408
SysSupportCode$$Limit 12744c
boot$$Base 12744c
boot$$Limit 127654
clib$$Base 127654
clib$$Limit 12774c
isr$$Base 12774c
isr$$Limit 127bb0
C$$constdata$$Base 127bb0
C$$constdata$$Limit 1afef4
C$$data$$Base 1000000
C$$data$$Limit 1005a38
Stacks$$Base 1005a38
Stacks$$Limit 1006a3c
VectorMap$$Base 1006a3c
VectorMap$$Limit 1006a60
C$$zidata$$Base 1006a60
C$$zidata$$Limit 107dad4
In this interesting way they go one after another. If you wish, it is possible to divide them into segments to corresponding addresses, but this is merely a logic division. Moreover, in .sym file these lines are scattered badly. And more sooner or later a question appears: why the code size is 1afef4, if length of insertion file is 1b6950? Where to put the rest 6a60 byte? We look again on the initial memory map:
Code:
Image$$RW$$Base 1000000
Image$$RW$$Limit 107dad4
Image$$ZI$$Base 1006a60
Image$$ZI$$Limit 107dad4
RAM ends on 107dad4 address, block 1006a60-107dad4 is zero initialized, hence there is a question: what does initialize the 1000000-1006a60 block, which size is exactly 6a60? Absolutely right, those odd bytes. If analyse the OS start code, then in the RAM initialization procedure you will find the same copying.
In the newer insertions there is a chance to come across the next inscriptions:
Code:
Load$$IRAM$$Base 639a74
Image$$IRAM$$Base 2010000
Image$$IRAM$$Length 0015a4
They should be understood this way: data of 15a4 length are being loaded from 639a74 file displacement to the 2010000 address.
We continue the analysis of symbols with the $ sign:
x$litpool$ - Literal Pool, pieces of the data from functions. At the end of many functions indexes, lines, constants are placed, and x$litpool$ specifies the beginning of such constants.
x$litpool_e$ - Literal Pool end.
$T is merely for debugger. Indicates the addresses where the PC register change take place. So, at these addresses transition commands BL/BEQ/B/BX etc. are placed.
$$- addresses where there is a change of ARM/THUMB state.
There are also C$$code symbols, but I haven't found what it is.
Other names without $ sign are the names for constants and functions. They can be freely used.
If the archive with an insertion contains both MAP and SYM, it is an ideal variant - when you set a name taken from SYM it is possible to check up whether it lays in the code area by using data from MAP. If yes, we may freely indicate it as code not being afraid, that code/data will be determined in IDA incorrectly.
LST Format
It's a real paradise for a reverser, in these files lays all at once. They consist of five parts:
Image Symbol Table - symbols... their meaning I have not understood yet
Local Symbols - everything is clear from the name
Global Symbols - .sym file analogue.
Memory Map of the image - memory map! All at once!
Image component sizes - .map file analogue
The information is so detailed, that even the processor mode for each function is specified.
OUT Format
Have met it only in the Nucleus-based insertions. Here can be tlink.out and tsymb.out files:
tsymb.out - ordinary SYM
think.out - MAP file to which almost useless linker information is added.
Now when we are armed with the symbolical information we can load the insertion in IDA.
What to do if there are no symbols at all
"When there is no toothbrush at hand..." Yes, we take IDA, emulating debuggerand brains in the hands. IDA is "must have". The emulating debugger for ARM, called Trace32, can be taken here.
First of all, we load the insertion in IDA to 0 address. I.e. the whole insertion is being loaded to default addresses. Then look what is on 0 address.
Code:
BOOT:00000000 B ResetHandler
BOOT:00000004 B loc_3B4
BOOT:00000008 B loc_410
BOOT:0000000C B loc_42C
BOOT:00000010 B loc_488
etc.
The code in any case begins with 0 address. In all Samsungs and, as I guess, not only in Samsungs an insertion begins with the interruption vectors. These are eight B commands in ARM state, i.e. 8 vectors. 0 address is a vector of null interruption or insertion start/restart. This zero interruption simply starts the mobile phone and thus handler leads to the system loader:
Code:
BOOT:00000048 ResetHandler; CODE XREF: BOOT:loc_0 _ j
BOOT:00000048 MRS R0,CPSR
BOOT:0000004C BIC R0,R0,#0x1F
BOOT:00000050 ORR R0,R0,#0x13
BOOT:00000054 ORR R0,R0,#0xC0
BOOT:00000058 MSR CPSR_cxsf,R0
BOOT:0000005C LDR R3,=(InitialHWConfig+1)
BOOT:00000060 MOV LR,PC
BOOT:00000064 BX R3
If the jump from zero address goes to the non-existent address it means that the rest part of the code is mapped to some other addresses. It's easy to determine to which exactly. For example, we have such beginning:
Code:
BOOT:00000000 B 0x4003CE
And there is no code on the 4003CE address. We look on 3CE displacement and see an ARM-code. It means the rest part of insertion is displaced on 0x400000. So we have to copy piece of insertion with interruption handlers, load them to zero address and then load an insertion from 400000 address. Now our code is in the right place. We go further. It is necessary to find out where are the RAM and area of input/output ports. The ports are usually either in the end (addresses from about e0000000 and higher) or in the beginning of the memory (up to 0x200000), depending on where the insertion is being loaded. There can be several RAM areas. First of all, we see ports initialization:
Code:
BOOT:00000588 MOV R1,#1
BOOT:0000058A LDR R0,=0xE0006000
BOOT:0000058C LSL R1,R1,#0x1B
BOOT:0000058E STR R1,[R0]
BOOT:00000590 STR R1,[R0,#0x10]
BOOT:00000592 STR R1,[R0,#0x20]
BOOT:00000594 LDR R1,=loc_20102
BOOT:00000596 LDR R0,=0xE0003040
BOOT:00000598 STR R1,[R0, #4]
BOOT:0000059A LDR R1,=0x20003
BOOT:0000059C STR R1,[R0, #8]
BOOT:0000059E LDR R0,=0xE0003000
BOOT:000005A0 MOV R1,#0xC
BOOT:000005A2 STR R1,[R0,#0x24]
I.e. since around E0000000 there is an area of input/output ports. Its size doesn't exceed the size of segment and therefore it's possible to create a segment of 0x10000 size. Now we go further. In any insertion there are RAM area which is initialized by zero values and the area which is filled by initial settings which are taken from an insertion. We are looking for copy cycles, so we need the debugger.
Here we see copying:
Code:
BOOT:000000D4 LDR R0,=0x63B018
BOOT:000000D8 LDR R1,=0x1000000
BOOT:000000DC LDR R3,=0x1045B38
BOOT:000000E0 CMP R1,R3
BOOT:000000E4 BEQ loc_F8
BOOT:000000E8
BOOT:000000E8 loc_E8; CODE XREF: BOOT:000000F4 _ j
BOOT:000000E8 CMP R1,R3
BOOT:000000EC LDRCC R2,[R0],#4
BOOT:000000F0 STRCC R2,[R1],#4
BOOT:000000F4 BCC loc_E8
The block is being copied from 63B018 address to 1000000 address of insertion. The length is 45B38.
This is the first RAM area. Now we look for the second one, whose zero initialization should be nearby:
Code:
BOOT:000000F8 LDR R1,=0x11ED9E4
BOOT:000000FC MOV R2,#0
BOOT:00000100 CMP R3,R1
BOOT:00000104
BOOT:00000104 loc_104; BOOT:00000108 _ j
BOOT:00000104
BOOT:00000104 STRCC R2,[R3],#4
BOOT:00000108 BCC loc_100
Indeed, there is a stuffing with zero values in the area from 1045B38 to 11ED9E4, so here we have the second part. If there are any areas, then there will certainly be zero or copy initialization. Other memory pieces can be found only analytically, but we have got the basis already.
The further research depends on the presence of symbols/signatures. If yes, then everything comes to looking for the necessary function in the names list. What to do if not? First of all, it is necessary to determine approximate code bounds and, if possible, to find functions in the code. The most primitive and effective way is to search for a push command with which 60 % of insertion code begins. Insertion code usually consists of Thumb code on 90 %, so we should look for B5 byte (push) and try to define it as the code in IDA. Insertion code usually takes less than 50 % of the whole size, the rest part is for graphics and language resources. Else I can say that very often at the end of the code there are copyrights lines, a kind of "Samsung corp. 199x-200x ARM ADS 1.2".
Some code has been revealed, around 20% were harmed by IDA itself, because it often can't cope with THUMB/ARM transition. And now we have to take anything left lying around loose, i.e. what had been left by programmers. And what they had left? Trace and Assert. And any trace and assert doesn't go without sprintf/printf. We have to find it. It's easy - we should just look for the "%s" line. We need that which obviously contains a pattern of the error message. With xref we find where this line is used and it will be exactly sprintf, followed by Trace or Assert. Now, with basing on the error messages, we can name the functions. I.e. walking with xref to the Trace/Assert function, we can find output of more than half of mistakes. Further functions naming is possible by searching the following words:
Code:
Bad
Fail
Incorrect
Invalid
Error
Memory
File
Null
No
Critical
Abnormal
etc.
This way we will find some more error output functions. Thus we will gradually gain the information, not being based on anything except for the insertion.

CellBroadcast and Emergency Warnings on Android - is it a mess?

Hey,
Germany is implementing EU-Alert (ETSI TS 102 900 [1]) at the moment and referring to the local News, it is a huge mess [2].
But let's start at the beginning.
CellBroadcast is a core component of each mobile network generation (2G,3G,4G,5G,...) and part of the 3GPP spec. CellBroadcast basically allows the network to send a simple SMS to all mobile phones connected to a specific base station. Thes SMS-CB are sent with a Message Identifier (aka Channel, aka Topic) which gives them a special purpose by convention. e.g. ID / Channel 50 is often used for area related information [3], while channel 207 might broadcast local weather information. Since not all Channels are standardized, there is also the option to broadcast an Index that lists all channels with a description. And since users probably don't want any message broadcasted, users have to subscribe to these channels.
Since decades now, CellBroadcast is also used for public Emergency Warnings. This means that, by definition of a country, a specific channel is used to broadcast Emergency Warnings. Long time ago, in many countries it looks like Channel 919 was used for this purpose. For this to work properly, mobile phones were instructed to subscribe to channel 919 by default and also use a special ringtone (even if muted) to alert such a message.
Later - over 12 years ago - additional channels from 4370-4399 were standardized in ETSI TS 123 041 [4] for public warning systems like CMAS, EU-Alert, KPAS. All using the same channels which is beneficial for global roaming.
Android of course supports these public warning systems specified in ETSI TS 123 041 [4] since at least Android 4.2.2 [5]. And nations that use these systems already, like CMAS in the US, report very high and reliable coverage.
However, referring to German news [2] and government, not many phones that are currently on the market will actually support EU-Alert in Germany, despite already supporting EU-Alert in Netherlands or CMAS in the US.
How is this possible when exactly the same SMS-CB is broadcasted, just in a different country?
Golem [2] says that Samsung and Google already confirmed that EU-Alert is currently not supported in Germany, but updates will be rolled out to recent devices.
This strongly suggests to me that OEMs like Samsung and Google actually added country specific filters/configurations for these public warning systems to their phones without deploying a reasonable fallback. Public warning systems based on ETSI TS 123 041 [4] thus may only work in countries that were known to use these systems when the phone was released.
Isn't this an obvious issue?
Google said, starting with Android 11+ it will be possible to update the CellBroadcastReceiver App via Google Play. So devices with Android 11+ will likely receive an update to support EU-Alert in Germany. For Android 10 and older, OEMs will have to supply updates.
What also confuses me is the fact that all Android Phones I own (Nexus 4 with Android 5, Nexus 5X with Android 8, Pixel 3a with Android 12) here in Germany do actually offer the setting for Emergency Warnings and they are already enabled by default. So I assume they would work? Did Google actually deploy a sane default configuration here already?
But if they did - why isn't it working on ALL Android 11+ Phones already? I'm pretty sure my Pixel 3a uses Googles CellBroadcastReceiver App which is provided through the Play Store. So all Android 11+ phones should already use the exact same App?! Or am I wrong here? So what is this update Google actually needs to provide?
And does this also mean that with Android 11+ OEMs are not allowed / cannot implement their own Emergency Warning CellBroadcastReceiver?
This topic is really confusing to me
Shouldn't it be really simple?
All phones, regardless of the OEM, should have a proper SMS-CB Application which allows you to subscribe to custom channels, view the index, and manage your SMS-CB Messages.
Phones should also be aware of special channels to apply special ringtones etc if needed, but they should have a sane fallbacks!
A phone that knows about NL-Alert and CMAS may call messages on Channel 4370 received in the Netherlands "NL-Alert". But when it receives the same message in Germany, it shouldn't just drop it! It should display it as warning and call it whatever it wants. And if it doesn't know about CMAS / EU-Alert, it should just receive it as regular SMS-CB.
Can't be that hard?
Interestingly enough, Samsung phones allow you to subscribe to custom channels. Google phones do not :/
Should there be a better / more enforced standard, so that a country that wants to implement CMAS/EU-Alert in the future doesn't have to rely on OEMs help?
And finally some technical Questions:
I found zero Apps for Android that would allow me to subscribe to custom CellBroadcast Channels on my Google Android phones. Is this even possible?
Also, is it possible to test these CellBroadcasts somehow? Is it possible to write an App that can inject SMS-CB into the system?
Sorry for the long post, but I think this an important Topic.
Let me know what you think
Do you have experience with these Emergency Warnings already?
[1] https://www.etsi.org/deliver/etsi_ts/102900_102999/102900/
[2] https://www.golem.de/news/cell-broadcast-warum-es-am-warntag-ruhig-bleiben-koennte-2206-165822.html
[3] https://source.android.com/devices/architecture/modular-system/cellbroadcast#channel-50
[4] https://www.etsi.org/deliver/etsi_ts/123000_123099/123041/11.04.00_60/ts_123041v110400p.pdf
[5] https://cs.android.com/android/plat...ternal/telephony/gsm/SmsCbConstants.java;l=58

Hey! I was just researching something about this. Thanks for your detailed post.
I am from Chile and, in my case, my operator had subscriptions to two channels: 919 and 920.
In order to see the Cell Broadcast menu in the Messages app, I had to override a CSC setting (I use a Samsung device), particularly "CarrierFeature_Message_DisableMenuCBMessage") because it seems some Chilean operators ordered Samsung to hide it.
Even then, the Google Cell Broadcast app would not let me modify settings other than test alerts.
In my country these emergency alerts are quite unreliable and are often sent by mistake or to the wrong place (i.e. sending a tsunami alert to an area more than 100 km away from the coast).

Shooting Star Max said:
Hey! I was just researching something about this. Thanks for your detailed post.
I am from Chile and, in my case, my operator had subscriptions to two channels: 919 and 920.
In order to see the Cell Broadcast menu in the Messages app, I had to override a CSC setting (I use a Samsung device), particularly "CarrierFeature_Message_DisableMenuCBMessage") because it seems some Chilean operators ordered Samsung to hide it.
Even then, the Google Cell Broadcast app would not let me modify settings other than test alerts.
In my country these emergency alerts are quite unreliable and are often sent by mistake or to the wrong place (i.e. sending a tsunami alert to an area more than 100 km away from the coast).
Click to expand...
Click to collapse
Can you explain how you disabled this CSC setting and on what samsung phone/os?
You can see Googles/Androids latest default configuration for Chile (MCC 730) here:
https://cs.android.com/android/plat...apps/CellBroadcastReceiver/res/values-mcc730/
The config.xml really has some restrictive features enabled :/

Thanks for your reply!
Please note that all the following information assumes you have rooted your device. It's impossible to override this configuration otherwise.
My device is a Galaxy Note20 Ultra (Exynos version, SM‑N985F) running Android 12, One UI 4.1.
As you might know, Samsung devices include several packages named “CSC”, which define settings according to a sales code matching with a region. For example, a device sold in Chile without a carrier uses the sales code CHO, while one sold by operator Movistar uses the sales code CHT.
In the Galaxy Note20 Ultra, the CSC packages are stored in /optics/config/carriers/single (older Samsung devices might use /omc/).
Once you find the sales code matching with your current configuration, you can grab two files: cscfeature.xml and customer_carrier_feature.json. Taking CHO again as an example, the files would be /optics/config/carriers/single/CHO/conf/system/cscfeature.xml and/optics/config/carriers/single/CHO/conf/system/customer_carrier_feature.json.
These files are encoded, but OmcTextDecoder can take care of that.
In the case of CHO, customer_carrier_feature.json has the value "CarrierFeature_Message_DisableMenuCBMessage":"TRUE", which hides the cell broadcast menu in the stock Messages application. Just replace “TRUE” with “FALSE”, save the file and push it to its location. The next time you reboot your system, it will be applied.
Regarding the link you sent, I think we could get around that configuration by decompiling the GoogleCellBroadcastApp.apk through Apktool, modifying the restrictive values, and then pushing the APK to the device, replacing the original version.

Thank you!
Let me know if you managed to patch your original CellBroadcastReceiver.apk!
I actually tried using Runtime Resource Overlays (RROs) which is described on the official docu about CellBroadcast in Android.
You can find the result here: https://github.com/xsrf/android-de-alert
However, I didn't quite get these RROs. It looked like in Oreo you can use RROs to overlay any resource of any app without any permissions or matching signatures, which is quite a surprise to me?!
On my phones with more recent OS, I get signature mismatch errors and also it looks like apps now have to define what resources can be overlayed ...