I need to lower the microphone gain.
My audio codec is clipping becouse of incoming PCM samples saturated from
the mic. I don't need AGC becouse it doesn't work well with my app.
I just need to manipulate the mic gain via software.
Is there a way to do it? I'm using waveform audio api ti capture voice.
Actually the gain is too loud !!!
Thanks.
Anyone knows?
OK, I don't have the answer. But since no one is responding I'll try to give a few ideas that might help.
First, I have a hp6315 and an apache. Under settings, they both have a utility to enable/disable AGC. The ipaq's utility is labeled "ipaq audio" if you disable agc, you can then configure the microphone gain. This gain is stored in the registry. I think searching for gain or audio will find it. The apache doesn't have this. searching for audio, gain, wav, volume in the apache registry doesn't find anything that looks like microphone gain. I guess this is a "value added" thing from hp. But you could try searching anyway.
Then there's the mixer API. This is the way that user level apps are meant to control the audio. Works great on the desktop. Use mixerGetNumDevs() to find out how many devices you can control. On the h6315 mixerGetNumDevs returns 0. I haven't tried the apache, but I can remember a few years ago reading that many (most?) devices return 0. Oh well, hopefully you'll have better luck. However, there are two mixers that are implemented on the pocketPC the question is how to access them.
see this link for info on the mixers
http://blogs.msdn.com/medmedia/archive/2007/01/12/what-do-you-mean-by-mixer.aspx
Here's a link that shows the relationship between the mixer api and the other mixers, wavedev2 mixer, and software mixer.
http://msdn2.microsoft.com/en-us/library/ms923709.aspx
You'll notice that the the mixer api interacts with the mixer in the device driver not the software mixer in the WaveAPI.dll. You'll so notice that this section on audio drivers has pages for MDD/PDD drivers and Unified Audio Model (UAM) drivers. Platform Builder for WinCE 5.0 comes with a sample for each of these model drivers. Both models handle WAV_IOControl Messages. There are two types of messages, IOCTL_MIX_MESSAGE for the mixer, and IOCTL_WAV_MESSAGE for the rest of the driver. It looks like these IOCTL_MIX_MESSAGE are the way the mixer API controls the mixer. In the MDD/PPD sample they can be used to set WPDMX_MIC_VOL and WPDMX_LINEIN_VOL. In the UAM driver it's AC97_MIC_VOL and AC97_LINEIN_VOL. Perhaps sending the right IOCTL will solve the problem.
This blog entry
http://blogs.msdn.com/medmedia/archive/2007/01/03/windows-ce-audio-driver-samples.aspx
seems to say that a wavedev2 sample is available now. Also, while the WinCE 5.0 page above only metions two models the corresponding wince 6.0 also talks about wavedev2. I suspect if you got the current version of platform builder for WinCE 6.0 (trial version is free) you would have get the sample code for wavedev2, which is likely to be the best documentation of how this works. Amazingly, the drivers aren't that hard to read.
Both of the functions waveInMessage() and waveInSetProperty() are available to user apps. Hopefully both should be able to change the microphone gain if you can set the parameters properly. While most of these things are about windows CE, I think most (or all) apply to windows mobile 5.
Windows mobile 5, likely uses wavedev2 devices not MDD/PDD or UAM drivers.
Another interesting page about wavedev2 audio is here:
http://blogs.msdn.com/medmedia/archive/2007/01/04/the-wavedev2-gainclass-implementation.aspx
If your able to succeed or even learn more, be sure to post it back here.
I said a lot so I probably got something wrong. Anyone, please feel free to correct anything.
mixerGetNumDevs() returns 0 on my device
I can't find any registry entry which suggests microphone gain manipulation.
Perhaps i just need to send a waveInMessage properly.
I'm getting confused, should i implement a driver for this?
How do i know what kind of driver is running on my device and what messages
does it accept?
Thanks.
i think this may be what you need(?)
use a registry editor, (phm do a good free one)
hkey_local_machine/software/htc/audiogain (and audiogain 0 and 1 and 2)
try playing with the settings in there, soft reset to take effect
I don't have that keys on my HTC, should i create it?
Do you mean audiogain0 audiogain1 audiogain2?
Thanks.
see the attached screenshot, if you don't have those settings to adjust, a similar/same question was asked last night in a other thread, with different answers here
http://forum.xda-developers.com/showthread.php?t=306655
Looks like the cab file from the link provided by bbobeckyj just sets those audiogain registry settings. I don't have those settings on my apache. I don't think adding will help, but "you never know".
If you want to use waveInMessage() or waveInSetProperty() search for them at microsoft. You'll find there are a few parameters that you don't know. Read though the sample drivers that you can get with platform builder. See what values they expect, and which one cause them to change the microphone level. Try calling the function with values from the sample driver. While there is no guarantee that they use the same values, it's like that they do. I would start with the wavedev sample.
I don't know why microsoft doesn't seem to allow access to the source without agreeing to download all of platform builder, but it looks like that's the only way to get it. You can download the trial version for free. The source often helps if your trying to fingure out how something really works.
Uhmmm, i havn't found any download link about platform builder for windows CE 6.0. I've only found the 5.0.
Should't the trial be free?
Thanks.
I need to fix audio gain in my Itel Experience Phone (Windows Mobile 6.0 Pro)?
Please help.
I need to mute mic while on a call. Anyone has a idea of how may i do it?
Thanks
moved to the right forum, please post in the correct forums.
Hi kernel hackers,
it is getting very silent recently about possible security hacks on the Milestone platform.
Today i stumbled over some kernel code located in /drivers/misc/sec.
Maybe this had been discussed already.... anyway
There're some interesting functions in the source code and i wonder which application is using this module to enter the secure world of OMAP.
Some of the functions are accessing registers, that are also involved in low level routines of the bootcode (e.g. mbmloader).
Some questions:
Which application in android userspace is using this module?
Could we tweak this module to get access to some of the protected OMAP registers?
Is it a signed module?
Would be nice to use a modified module and activate some of the blocked features (e.g. DAP controller for debugging).
Any comments welcome!!!
Regards,
scholbert
scholbert said:
Hi kernel hackers,
it is getting very silent recently about possible security hacks on the Milestone platform.
Today i stumbled over some kernel code located in /drivers/misc/sec.
Maybe this had been discussed already.... anyway
There're some interesting functions in the source code and i wonder which application is using this module to enter the secure world of OMAP.
Some of the functions are accessing registers, that are also involved in low level routines of the bootcode (e.g. mbmloader).
Some questions:
Which application in android userspace is using this module?
Could we tweak this module to get access to some of the protected OMAP registers?
Is it a signed module?
Would be nice to use a modified module and activate some of the blocked features (e.g. DAP controller for debugging).
Any comments welcome!!!
Regards,
scholbert
Click to expand...
Click to collapse
Well, I'm not a kernel hacker, but I have an educated guess...
I believe that the radio system uses those functions to check whether the kernel is valid or not, so, we have the radio not working with a replacement kernel that is loaded using kexec...
Perhaps, if it is possible to "change" this function using a module, we could get a function always telling the kernel is valid and have kexec working on Milestone. Again, I'm not a kernel hacker, but that is my guess.
Hi, I'm sorry that I wont be much help but these guys might;
https://www.droid-developers.org/
irc://irc.freenode.net/#milestone-modding
Hi,
thanks for your comments so far.
To be more precisely i think this kernel driver is calling the secure monitor in some way. See here:
https://www.droid-developers.org/wiki/Secure_Monitor
There's also a structure defined in that driver. I think i'll have to compare some of the ioctl entries.
https://www.droid-developers.org/wiki/Secure_Services
I'll do some investigation on this issue and search the web for some userland source code using this driver.
Again, if someone knows more about it, your welcome
Cheers,
scholbert
scholbert said:
Hi,
thanks for your comments so far.
To be more precisely i think this kernel driver is calling the secure monitor in some way. See here:
https://www.droid-developers.org/wiki/Secure_Monitor
There's also a structure defined in that driver. I think i'll have to compare some of the ioctl entries.
https://www.droid-developers.org/wiki/Secure_Services
I'll do some investigation on this issue and search the web for some userland source code using this driver.
Again, if someone knows more about it, your welcome
Cheers,
scholbert
Click to expand...
Click to collapse
you don't have to search for the source, it's on SourceForge:
http://sourceforge.net/projects/milestone.motorola/files/
SophT said:
you don't have to search for the source, it's on SourceForge:
http://sourceforge.net/projects/milestone.motorola/files/
Click to expand...
Click to collapse
Yeah sure, i knew this
Anyway, thanks for the hyperlink!
In the meantime i grepped all binaries from the latest distribution.
I found out, that two applications are using /dev/sec.
1. dbvc_atvc_property_set
2. tcmd
If someone knows which package of source code they belong to... would save some time searching.
EDIT:
O.K. Google did it for me...
Seems that both binaries are proprietary code. Some early conclusions:
1. dbvc_atvc_property_set
This one is started as a service in init.mapphone_umts.rc and seems to use /dev/sec for granting rights to access OMAP secure world (e.g. read eFuse values for unique device id, IMEI etc.).
This binary contains a certificate which is not Milestone specific (XT720 uses the same).
So right now i don't know, if this certificate is needed to access /dev/sec or the application itself identifies itself as trusted application (signed app).
Would make sense, if the BP uses signed applications to access certain low level functions, e.g. read/write the eFuse bank.
2. tcmd
This one is also started as a service in init.mapphone_umts.rc to access a variety of devices. Seems to be related to data streaming or stuff.
As stated it has an entry for /dev/sec and it got no certifcate.
Would be interesting to get some more info about that.
Further comments....
P.S.: This bloody security stuff is making me sick
Regards,
scholbert
Hi again,
i just compared some of the defines in the kernel driver headers (/drivers/misc/sec/sec_core.h) with the ones xvilka reversed inside mbmloader.
Code:
...
#define API_HAL_KM_SOFTWAREREVISION_READ 33 // 0x21
...
#define API_HAL_NB_MAX_SVC 39 // 0x27
#define API_HAL_MOT_EFUSE (API_HAL_NB_MAX_SVC + 10) // 0x31
#define API_HAL_MOT_EFUSE_READ (API_HAL_NB_MAX_SVC + 15) // 0x36
...
For comparison see the table here:
https://www.droid-developers.org/wiki/Secure_Services
It is obvious that /dev/sec allows to access OMAP secure world and uses the above mentioned API calls to push information to userspace apps.
The question would be, if ioctl must be certified through the API using some key ...
O.K. i see this is deep down code creeping, but maybe someone understands what i try to work out
See ya,
scholbert
scholbert said:
O.K. i see this is deep down code creeping, but maybe someone understands what i try to work out
Click to expand...
Click to collapse
I think I know what you are trying to work out, but I can't think of any way to help
You're pretty much comparing the results of your findings with that of the mbmloader dump right?
I would like so much to fully understand what you are doing, but I can understand just a little..
btw I hope that you'll be glad to know that you have all my psychological support!
mystichobo said:
I think I know what you are trying to work out, but I can't think of any way to help
You're pretty much comparing the results of your findings with that of the mbmloader dump right?
Click to expand...
Click to collapse
Yeah, kind of... we know for sure there's an API to access security functions on OMAP. I just digged out some parallels in kernel code and mbmloader.
If we could make use of security functions from within kernel space (by using a tweaked module) this would be a nice playground.
Perhaps, there's any bug or backdoor we could shamelessly exploit to:
a. boot custom kernel with second boot
b. tweak the security system and enable some hidden functions inside OMAP
puffo81 said:
I would like so much to fully understand what you are doing, but I can understand just a little..
btw I hope that you'll be glad to know that you have all my psychological support!
Click to expand...
Click to collapse
Thanks a lot for pointing out
Best regards,
scholbert
scholbert said:
Yeah, kind of... we know for sure there's an API to access security functions on OMAP. I just digged out some parallels in kernel code and mbmloader.
If we could make use of security functions from within kernel space (by using a tweaked module) this would be a nice playground.
Perhaps, there's any bug or backdoor we could shamelessly exploit to:
a. boot custom kernel with second boot
b. tweak the security system and enable some hidden functions inside OMAP
Click to expand...
Click to collapse
That's what I thought
Surprised noone has looked into it earlier really
Anyway good luck with it, adding my moral support too.
Cheers,
hobo
mystichobo said:
Surprised noone has looked into it earlier really
Anyway good luck with it, adding my moral support too.
Click to expand...
Click to collapse
I got into contact with xvilka.
Obviously there'd been some investigations concerning this issue.
To be honest, i don't know if it's worth to digg a little deeper or if it will ever led to something useful in the end. Could be fun though
Perhaps it would be nice idea to tweak the driver and put some debug message in the code.
Another interesting thing to do would be a logging function.
This way it would be possible to get some insights of the API to secure monitor.
Anyway, i think it's never useless to discuss about some hacking here. At least were at xda-developers
If you like to tweak some kernel code, join in!!!
Have fun!
scholbert
Hi,
I already read about the option to remap some keys by editing the keyboard layout file. Is it also possible to switch between keyboard layouts as you type (using a hotkey) - e.g. I need to be able to quickly change between Cyrilic and Latin keyboards.
Thanks.
I think you're talking about hardware keyboard.... But keyboard apps like swiftkey allow for 3 allow for 3 languages simultaneously.
Sent from my ICS Splashed MT4GS using xda premium
Oops haha double post
Hi indeed, I was talking about the hardware keyboard, if it is not possible to use both cyrillic & latin keys and quickly switch between them, this would decrease the benefit of the keyboard for me and I might decide to go with a non qwerty phone in the end.
Thanks for you insight though.
nickexel said:
Hi indeed, I was talking about the hardware keyboard, if it is not possible to use both cyrillic & latin keys and quickly switch between them, this would decrease the benefit of the keyboard for me and I might decide to go with a non qwerty phone in the end.
Thanks for you insight though.
Click to expand...
Click to collapse
In this dev thread: Hardware Key Mapping | Flashable zips & Requests
...user Paitor has come up with and explained how to implement swedish language support for the hardware keyboard.
Given what Paitor has figured out how to do, it is absolutely within our ability to sit down and make exactly what you are asking.
All it takes is someone willing to sit down and invest the time into actually making it happen.
I would volunteer, but I have a lot on my plate already and realistically it's just not feasable for me to do this and keep up with my other projects on this device.
I will however be willing to take a finished keymapping and turn it into a flashable zip file and update the first posting of the key mapping thread with the result.
(and I always credit the author both in the installer package and thread post)
We still have to write in hardware keyboard language support for other languages, and I invite anyone else who wants to use alternative languages to read that thread and see about putting some time into helping us make that available for everyone. What you want to do is not exactly a small project, but pushing what we know to the next level is the reason for XDA's existence.
So, short answer is yes, what you are asking for is completely possible - you can make a key map file that has all of the keys in the languages you would want.
This is XDA, where you can get exactly what you need right down to the last little detail - if you want to put the time into making it happen. We'll be glad to help out where we can along the way.
--------
Edit:
If I were to tackle this project - this would be my approach:
Some apps, like Drocap2 or soundhound, pop up in the list when you have the Genius key remapped to 'search' and long press it. If there is nothing else that utilizes this shortcut function it will default to the only app that does ( in the case of a stock installation or on my ROM, voice search ).
So what I would do is write in each hardware keyboard layout that I wanted, then design an app that utilizes that Genius shortcut function to run - and the sole purpose of the app would be to switch between hardware keyboard layouts.
To me, that seems like the most elegant and refined approach to your problem without making one monstrously cumbersome key-mapping.
You could just press the Genius button to access the app wherever you happened to be, and then have it just show a menu as an overlay to swap between whatever keymappings you wrote in.
--------
My time is being invested in my ROM - then once that's set to my satisfaction, on to kernel work on overclock/undervolt leading into GPU work in conjunction with TV-out, and then on to bluetooth work for controller support on a Sense device.
These are big projects and very time consuming undertakings, so as you can see a project like this keylayout issue is a long time coming before I can get to it - but i'm happy to help where I can for anyone who wants to dive in and do.
Figured i'd throw out what my approach would be to give someone an idea on where to start - and while certainly not the only solution, is something to consider.
I think I have very good news for you!
There's a keyboard called "AnySoftKeyboard" (search for it in the Market and click Dev Website if you want more info) which supports hard kbd mapping (and switching bet layouts by pressing Alt + Space), they have a Russian language pack (Cyrillic & Phonetic), and it is all free.
I have never used it, but remembered coming accross it a while back and decided to check it out for you.
Hope it works
Hey guys, thanks for your replies!
I will definitely check this application - i am not sure it supports all hardware keyboards in general (or just the g1/droid as written in the description), but I will give it a try if I get this phone
And yes, I will gladly help in creating a layout for a Bulgarian keyboard. Unfortunately I cannot create an application for switching between the layouts myself, as I am not a developer.
thanks again.
AnySoft does work
Got my phone and installed AnySoftKeyboard. It does allow for switching bet layouts on the MT4Gs, but does seem a bit quirky so far... (that's with Hebrew & English, you might want to experiment yourself)
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).
Hi all,
Few days ago I'v repaired HTC Desire Z with Russian keyboard and installed CM10.2 onto it. And of course I want to have working Russian keyboard layout.
Unfortunately only official firmware support it, and problem cannot be solved by editing layout tables because for some buttons there is two Cyrillic letters on one button. There is ruKeyboard application to fix it, but it closed source, so it doesn't acceptable for me.
So, I'm going to develop my application for it (open source, of course) and want to ask some questions... I have a lot of development experience (especially low level, e.g. drivers, MCU's firmware and so on), but never programmed for Android (however I know Java to some degree).
Of course, I can patch android kernel/sources to get my task done, but I suppose that it's a bad idea, because I'll need to port changes to new versions and so on. So, I want to process keyboard events from userspace.
My question: Is it possible to hook all hardware keyboard events (i.e. scancodes, not characters) from userspace, remove them from message queue, and produce new events? I know that producing new events is possible, but what about hooking it (like MS Windows event hooks?). Can you give me a hint (maybe link to example or API, suitable for it)?
Thank you in advance.
FossaFX said:
My question: Is it possible to hook all hardware keyboard events (i.e. scancodes, not characters) from userspace, remove them from message queue, and produce new events? I know that producing new events is possible, but what about hooking it (like MS Windows event hooks?). Can you give me a hint (maybe link to example or API, suitable for it)?
Click to expand...
Click to collapse
I am not a programmer, but I would be interested in an app that could substitute key press events (on my Motorola Droid 4).
Have you heard of the Xposed framework? Maybe this would be a possibility to achieve your goal and Xposed might make things much easier for you.
daniel_m said:
I am not a programmer, but I would be interested in an app that could substitute key press events (on my Motorola Droid 4).
Have you heard of the Xposed framework? Maybe this would be a possibility to achieve your goal and Xposed might make things much easier for you.
Click to expand...
Click to collapse
Thank you, I'll read about it (and no, I didn't hear about it, I have never programmed for Android).
daniel_m said:
I am not a programmer, but I would be interested in an app that could substitute key press events (on my Motorola Droid 4).
Have you heard of the Xposed framework? Maybe this would be a possibility to achieve your goal and Xposed might make things much easier for you.
Click to expand...
Click to collapse
http://www.howtogeek.com/195476/7-t...ramework-on-a-rooted-android-phone-or-tablet/ looks like good thing. So I'll investigate sources of Xposed to look how do they did it.
Good luck!
Would be wonderful for yet another useful Xposed module to see the light of day