Related
Hello,
I am new to the forum and also the owner of an HTC Fuze. I have been playing around recently with the GPS on the phone and got me thinking. I live in NY and we have a CORS network of gps base stations that are fed by the use of ntrip.
I was wondering if their was any way to use the gps signal on my phone and the connection to this CORS network to give me sub inch accuracy on my phone...then not sure what I would do with it then. But I do live on a farm and I would like to see some type of precision agricultural use.
I guess I need a way to have the GPS on the phone talk with the GNSS internet radio and then give me spot on guidance and such.
Please let me know your thoughts or if I need to explain better.
Thanks,
Clayton
bump
bump. Any ideas? Anyone
Great idea cwrisrey !
That will save the cost of a geodetic device, which is many times the cost of a Fuze. Further, it will lead the accuracy of the buildin GPS into millimum class.
Not dig into this further, would you go further to tell these:
Is that CORS data encrypted?
Is that accessible through public internet or VPN?
Is there copy right or intellectuall property right issue involved? (I don't think so, but better make it clear first)
Once again, great idea. Please do remember to update this thread once you got any progress. Thanks.
More info
Hello wg5566,
This site would probably answer alot of your questions clearer than I could:
http://www6.nysdot.gov/spiderweb/frmIndex.aspx
* Is that CORS data encrypted?
-I don't believe so, I think that it is just a form of compression, to distribute across the internet.
* Is that accessible through public internet or VPN?
Yes, the NYS CORS anyway. It accessible from the public internet (although they require you to register with them) But I believe there are other free streams. I also believe it was modeled after being able to be sent threw GPRS.
* Is there copy right or intellectuall property right issue involved? (I don't think so, but better make it clear first)
-I believe the ntrip is based on a GNU, I think the source code is available. http://igs.bkg.bund.de/index_ntrip_down.htm
Windows CE version:
http://www.ilmb.gov.bc.ca/crgb/gsr/downloads/installGNSS.CAB
Please, let me know your thoughts...
Thanks,
Clayton
My fast thoughts:
First make sure there is no satisfied freeware currently available for WM.
If so please ask a moderator to move this to the development & hackings section. And Add tyis sentence on the title: Call for developers for revolutionary GPS app!
I'm sure somebody here can develop this. You know the geodetic device was invented many years ago with very weak profiles comparing to current WM devices. The hardware on our phone should be capable to deal with these calculations, and the WM Pro platform should be capable to support such an app. Anyway it should not be a biggy for many masters here. But it is a biggy for gps users with high accuracy demand for any reason.
Edit: Did you try install that wince cab on your phone? I think some of WINCE apps can just run on WM. Please backup your data first.
Edit2: I tried to install it on my device, at first it did not show up in start menu, then I found the cab just put files and shortcut in the folder names in French. But there is no registry involved in the cab. Only three files. And then program UI itself is in English. Just run the executable from the folder will go right out of the box. So please try it. I did not try to connect & loggin yet, due to not registered account.
Edit3: Looks like the cab is only access the data from internet, convert the data format and export the data, but we still need a geodetic/gps software to process/use the data.
Disclaimer: I attatched these three files for the only purppose of exchanging software developement infomation. Anybody if download it please do not use it for any purppose other than this. Thanx.
Some thoughts on the subject
Hi All,
The idea of using NTRIP to make a Windows Mobile GPS device sub-meter accurate crossed my mind. After some research I found this thread.
Unfortunately, I haven't been able to find any software capable of doing this. My idea is that it should be possible to accomplish this goal, using a combination of existing tools (which would be really cool!).
As wg5566 notes, there is a (WM) tool called GNSS Internet Radio, which is capable of downloading NTRIP corrections. It turns out this software works, but does have some flaws. Someone wrote another open source tool which is better (?), but unfortunately it isn't built for Windows Mobile (see: http://lefebure.com/software/).
More searching revealed a (dead?) project on codeplex: SharpGPS. It's an unfinished demo. It does however seem to be designed to do exactly what we're suggesting in this thread.
My idea: Completing the WM version of SharpGPS with parts of GNSS Internet radio / lefebure NTRIP client should result in a tool that's capable of upgrading a WM devices' gps signal to sub-meter accuracy through RTK/DGPS corrections over NTRIP.
Any ideas / suggestions about this?
It's already been done for the commercial market
Land surveyors, construction companies, and farmers use RTK GPS and RTK GNSS correction services on a regular basis. Some are free and some are paid subscription. They can be either NTRIP protocol with casters or individual TCP or UDP connections. Examples of software available are Carlson SurvCE and MicroSurvey. Read Carlson's support site for how they deal with the data flow using such networks on SurvCE (Windows Mobile and CE).
I have worked in land surveying using such equipment, and it generally requires dual frequency receivers, RTK corrections, and high quality antennas to achieve 1-2cm 95% CI horizontal precision. The current GPS chips in cell phones are only single frequency and so the best you could expect under ideal conditions is 2'-3' precision using some form of differential correction like WAAS or beacon or DGPS via NTRIP. Under average conditions, the precision will likely be in the 10-20' range. The dual frequency receivers take care of the large errors caused by radio waves traveling through the ionosphere.
Due to the limitations of batteries, antennas, and space for more chips in cellphones, the future of location accuracy will likely include some combination of GPS/GLONASS and cellular radio signal frequency timing calculations from cell towers. True Position, with its U-TDOA technology, is one example of measuring the time differences of cell phone radio waves using cell towers with known coordinates. Rumors (from surveying journals) have it that there are current patents in place that can allow for sub foot precision using such methods when sufficient cell towers are present for multilateration.
Has anyone found success on this topic? WM or Android...
Would be very interested, since there is a free NTRIP feed available in Switzerland... anyone?
*bump* it up
Been there still trying. Problem is no carrier phase off internal gps.
Grimli said:
Hi All,
The idea of using NTRIP to make a Windows Mobile GPS device sub-meter accurate crossed my mind. After some research I found this thread.
As wg5566 notes, there is a (WM) tool called GNSS Internet Radio, which is capable of downloading NTRIP corrections. It turns out this software works, but does have some flaws. Someone wrote another open source tool which is better (?), but unfortunately it isn't built for Windows Mobile (see: /lefebure.com/software/).
Click to expand...
Click to collapse
Lance lefebure is a really cool guy I'm sure he wouldn't have any problem building a wm version but it is going to takea lot more than that to get rtk to a cell phone.
Very good ,thanks.
Ed hardy bikini said:
Very good ,thanks.
Click to expand...
Click to collapse
If you are confused just ask questions and I will do my best to answer them. I am in the ag industry and deal with RTK networks and different ways of connecting them and tons of different gps units on a daily basis.
Look at this:
http://stakemill.wordpress.com/2010/07/19/ashtech-mobile-mapper-100-supports-esri-arcpad-10-0/
and this:
http://www.ashtech.com/-2359.kjsp?RH=1272644205746&RF=1270806507068
Is that still a phone !?
wg5566 said:
Look at this:
Is that still a phone !?
Click to expand...
Click to collapse
Nope PDA with support for external GPS with a builtin reciever that even sees glonass satellites (russian constelation). That was made specifically to do RTK mapping. It does have a GSM radio for data to connect to the cors.
Phone positioning using CORS
To perform a CORS (Network Reference correction we need a GGA stream from the GPS in your device. This allows us to remove the anomalies and provde the correction stream. As phones use a sirf II chip or similar they do not have input capability to output the NMEA stream to achieve this.
This one works great! it will connect to an Rtk receiver and get the nmea string from it or will use the internal GPS to be able to register on the CORS network. It will then stream the corrections over Bluetooth to a receiver or even a repeater radio. It won't however correct the internal GPS. http://antrip.dyndns.biz/Home/DownloadTrial
I see alot of threads around xda requesting miscellaneous apps or ports. I have written down a lot of my ideas and I'm not quite to the stage where I can make them myself, and I'm sure a few others are in the same boat. I don't see much of a point to keeping them a secret when there are alot of capable developers around here. If there are developers out there with free time that see a cool idea in this thread, try to give a mention to the person if you create the app!
3rd party app toggle
Just an app similar to adb toggle, that quickly toggles on 3rd party app installs. It's not secure to leave it on all the time, and for people with settings locked it can cut the time taken to install a 3rd party app. If you're an overachiever try toggling all app installs, not just 3rd party.
Password Scanner
Basically an app that just scans /data for SQLite entries and lists items associated with password fields. Plaintext is enough to make it useful for a lot of people, with options of a pro-version that cracks encrypted passwords.
Car Remote
This is the most challenging one I've thought of. It's an app that uses the device's radio antennas to unlock cars that have remote control locks. I've looked into it and the encryption looks tough to break, but if you're a genius you can probably figure something out. Here's something to get started: auto.howstuffworks.com/remote-entry.htm
Time Machine
I thought of this while reading en.wikipedia.org/wiki/Year_2038_problem
A mod/app that messes with the clock to cause app compatibility issues, which could enable potential root exploits on devices which don't have current root methods. This one is risky because it is likely it result in bricks (yet another use if you want a device to be bricked in the event of a theft). I'm unsure if something like this would need root access to work.
Share your ideas! My apologies if any of these have been thought of, it wouldn't be the first time I've rethought the wheel.
Wow, some nice ideas there! 3D party app can be a popular one. I also like the car remote app idea, but will it be helpful?
Found this video on a PDA for the car remote, it used infrared though..
Time machine looks interesting but can it be realized !
A port for ADOBE PHOTOSHOP CS6 for Android..!
It will be a big boon for GFX Designers like me..!
Sent from My Premium Calculator HD
Lol btw those days aren't far
nikufellow said:
Lol btw those days aren't far
Click to expand...
Click to collapse
But urs is...
How can a app be a time machine.. xD
Sent from My Premium Calculator HD
If you sir are able to do something about the 2038 problem then you are getting some world recognition for sure .
DD-Ripper said:
A port for ADOBE PHOTOSHOP CS6 for Android..!
It will be a big boon for GFX Designers like me..!
Sent from My Premium Calculator HD
Click to expand...
Click to collapse
oh don't let me get started on the list of ports I want haha. Top 3 would probably be cain & abel, cisco packet tracer, and something like encase.
cs6 is would be nice for sure though, adobe is really slacking with their tablet app. I see something like gimp coming before photoshop due to it's source being more available.
i would really like something like frozen synapse on a phone i think it would work really well.
Make an android rom for the samsung brightside instead of its Brew, and you give 50 thousand people a boner...
its the only smart-ish phone that can be used on verizon without upgrading to the smart phone plan.
if it gets a rom,you have a verizon phone and dont pay the bastards the smart phone fees
I would love a hearing aid app to control the different settings.
Would be amazing!
Car remote app will never work as each car uses some sort of encryption and frequency to unlock the door while the phone antennae can only transmit on 2G/3G/4G frequency bands.
hsalps said:
Car remote app will never work as each car uses some sort of encryption and frequency to unlock the door while the phone antennae can only transmit on 2G/3G/4G frequency bands.
Click to expand...
Click to collapse
and bluetooth, and wifi, and gps. There are a number of antennas in each phone. The one in the video I posted managed it with infrared.
I think car remotes work on the 400-500mhz spectrum so it will take some research to how compatible it could be with most phones, and that's not even exploring dongles.
ickkii said:
and bluetooth, and wifi, and gps. There are a number of antennas in each phone. The one in the video I posted managed it with infrared.
I think car remotes work on the 400-500mhz spectrum so it will take some research to how compatible it could be with most phones, and that's not even exploring dongles.
Click to expand...
Click to collapse
My Nissan Altima Remote operates on 315Mhz whereas
Bluetooth operates on 2400–2480 MHz
GPS operates on 1575.42 & 1227.60 Mhz
Wifi operates on 2.4, 3.6 and 5 GHz
IR operates on 33 to 40 kHz or 50 to 60 kHz
All these antennae are not capable to transmit in any frequency band, they have been hardwired to operate on a particular band to save money and be power efficient.
Create a 'Date' contact ?
G'Day Guys
I have been searching for an app. now for a few years & have not been able to find one that 'fits the bill'
When I get a phone call from a new contact ( so not currently in the contact list )
Create the contact with the name as date eg. DD MM YYYY & mark it as blocked
Anyone know if an app. exists that can do this ?
or
Anyone interested in deving this app. for me ?
BTW - I have 40+ years experience programming in Assembler, C, Basic etc. & I built Palm apps. in C & built a couple of droid apps approx. 5 years ago with Phone Gap. Buy, not wanting to have to setup the environment for a simple droid app. dev.
Proposal---- Build cellphone with off shelf components, or 3d printed components, using an advanced moving point ad hock mesh network to pass encrypted packets, with multiple chain parody across an ever changing free network
in other words free the data..... free the world........
I am a node, I am moving this way, you are here and like data, I like data, here is some for you from here, I can have some from you.... bye bye I am going to talk to this car for a moment, and then this wireless router over here....
Adding more
Another nice idea would be a modular input system, like a accelerometer , etc
Ray Maker of DC Rainmaker on Twitter reports ANT+ is coming to the Samsung Galaxy S4 through an October Firmware update and will be supported on all flagship devices going into the future
dcrainmakerblog
"We will support ANT+ in the Galaxy S4 in a firmware update coming in October" - Samsung (at the ANT+ Symposium)
dcrainmakerblog
"We do plan to support ANT+ on all of our flagship smartphone devices in the future" - Samsung (at the ANT+ Symposium)
Ray now has a blog post about this:
http://www.dcrainmaker.com/2013/10/samsung-mobile-devices.html
Particularly for anyone with sports data tracking devices this is huge news! Not to mention ANT+ is pretty simple to implement now with the new Plugin services they're bundling with the Note 3 right now
ANT also allows you to build really neat wireless topologies as well if your into that stuff, plus it supports full multicast as seen on DC Rainmaker:
http://www.dcrainmaker.com/2013/09/curiositysurvey-different-cycling.html
A little background on ANT and ANT+:
ANT is a mature ultra low power wireless protocol running on the 2.4 GHz band like WiFi and Bluetooth. Bluetooth Smart is a protocol similar to ANT but architected around Bluetooth style bonding/pairing with several connection layers and services.
ANT is a compact and flexible protocol, allowing virtually any type of wireless network topology to be created. ANT transmitters automatically manage coexistence and divide the RF channel they are transmitting on into timeslots, which means any number of receivers can listen to an ANT device, excellent for gyms, training areas, anything which requires a large number of transmitters, as ANT can handle potentially hundreds of devices transmitting to an infinite number of receivers.
ANT+ is a set of interoperability specifications called "Device Profiles" which means devices which use them are able to "talk" to one another. ANT+ has reportedly shipped in over 60+ million devices globally, predominantly in Sports and Fitness (Adidas miCoach, Garmin Watches, Running Sensors, Heart Rate Straps, etc).
Why does this matter?
Right now, it only matters if you're into any type of sports or fitness training, or if you have an idea which requires 600+ transmitters communicating to XXX number of receivers simultaneously. As a nice bonus, any ANT+ device is compatible with any app as long as it's certified.
For developers
The ANT+ API appears to be much simpler to implement than the BLE API. The ANT+ API already handles device discovery and decoding of data events from sensors into the useful data without even reading the Device Profile. You just request access to heart rate, cadence, etc, and then subscribe to the event handlers which pass the data to you decoded. The BLE API still requires a lot of work to do the decoding properly, handling characteristics, etc
ANT+ Plugin API - Supported from Android 2.1+
http://www.thisisant.com/APIassets/.../plugins/antplus/pcc/AntPlusHeartRatePcc.html
BLE - Officially integrated from Android 4.3+
http://developer.android.com/guide/topics/connectivity/bluetooth-le.html
Some Apps which include ANT+:
-Google My Tracks
-Endomondo
-Sportstracklive
-Garmin Fit™
-Run.GPS Trainer UV
-IpBike, IpWatts, IpPeloton, IpSmartHr
-Selfloops
-SportyPal
-MapMyFITNESS/RIDE/RUN/WALK+/HIKE/DOGWALK
Directory of Certified Devices
http://www.thisisant.com/directory
How will it help us exactly?
fuser1337 said:
How will it help us exactly?
Click to expand...
Click to collapse
Right now its used mostly in sports and fitness although some of those device profiles they've implemented are branching into things like remote control like the O-synce bike handle bar remotes. They submitted patches for Apollo but the developer's busy with other features ATM.
sounds like bloat..
dannyella said:
sounds like bloat..
Click to expand...
Click to collapse
It depends on how you use your phone.
For fitness addicts like me, that is good news.
In general, there are different protocols to transfer the data from your heart rate belt. Most devices for home use like spinning use the ANT+ - protocol. Others use the Bluetooth 3.o 0r 4.0 protocol.
BT 4.0 LE (Low Energy = battery saving) is implemented to Android 4.3. I am guessing that it is the same with ANT+.
Benefit for Android-users: You can use your heart rate belt that you use with your home device also with your Android phone
I use ant to build my projects.. lol..
Sent from my GT-I9500 using XDA Premium 4 mobile app
Great news! Any reference?
Sent from my GT-I9505 using xda app-developers app
it's an interesting move for Samsung to make. Considering they and their competitors are bringing out smart watches using bt4 and android 4.3 standardising bt4 api. It was starting to look like ant+ was going to lose the smartphone market. Perhaps they cut a deal with Samsung
Infy_AsiX said:
it's an interesting move for Samsung to make. Considering they and their competitors are bringing out smart watches using bt4 and android 4.3 standardising bt4 api. It was starting to look like ant+ was going to lose the smartphone market. Perhaps they cut a deal with Samsung
Click to expand...
Click to collapse
Honestly, Ill believe Ant+ inclusion when it actually happens. BT4 smart has started to catch on with cycling manufacters, both Topeak (currently) and Wahoo (soon) will be able to use bt4 smart sensors soon. I saw a S4 at Interbike hooked up to a BT smart heartrate monitor and speed/cadence sensor.
This was big news to me, as for a long time without a dongle (super annoying) there was no way to use an Android phone with speed/cadence sensors or heartrate monitors, unless you had a sony.
If Ant+ doesnt pick up soon, its going to be left behind. Android including BT smart in 4.3 is going to change the field for newer phones.
I too would like to see some documentation/references about Ant+ inclusion.
-Bicycle Industry Professional
After flashing the 4.3 leak i noticed some ANT library packages in the 'installed packages' list.
I found the app "ANT+ Demo" from the app store and it is reading my ANT device! It's already working!
It is working with an ANT+ development kit i have here on my desk, haven't tried it with any official devices yet.
I do have ant+ and some ant plugins installed on my note 3. Factory untouched android 4.3
Sent from my C6802 using XDA Premium 4 mobile app
Subscribing
jorgenmk said:
After flashing the 4.3 leak i noticed some ANT library packages in the 'installed packages' list.
I found the app "ANT+ Demo" from the app store and it is reading my ANT device! It's already working!
It is working with an ANT+ development kit i have here on my desk, haven't tried it with any official devices yet.
Click to expand...
Click to collapse
What "4.3 leak" did you flash? Can you tell us the rom? Can we have some links/references? Where do I get the packages so I can bribe some S4 cook to bake it into some rom? (or am I missusing the term?)
I use ANT+ to upload my running activities from my garmin watch to the garmin website. As the watch can only comunicate via ANT+, I either have to have a PC around or, when in holiday or somehting, I have to use a micro usb otg adapter and connect the ANT+ dongle to my samsung s2 using an app called garmin-uploader (along with a coupple of ant+ services found on google play).
There is something that I don't quite understand here.
Does this mean that these devices listed (s4 and s3 I believe) were already shipped with ANT+ capable hardware?
ANT+ was therefore already possible on them by using the ANT+ radio service available on google play without the need of an ANT+ dongle right ?
If not, and the hardware has to be enabled somehow with a propretary driver of Samsung, how about the Samsung S4 Google edition? Those don’t have a Samsung customized ROM but a google vanilla Android right?
Also, DCrainmaker wrote a post about the matter :
http://www.dcrainmaker.com/2013/10/samsung-mobile-devices.html
I see the lack of balls in Samsung to not include the S4 active to get ant+. It's worth pointing out amoled screens are organic and have their life degraded by heat as well as UV light.
there's some photos posted a couple times on xda forums where someone bought a store display s3 or note 2 that had the original screen sticker decals shadow burnt into the screen. In fact it was the rest of the screen that was exposed to the light that had degraded. The sticker decals had shaded the screen and not degraded some parts leaving their shape visible on a white screen.
I suppose it doesn't matter for indoor sports at least...
here's a couple of examples a quick Google search pulls up
forum.xda-developers.com/showthread.php?p=39910331
forum.xda-developers.com/showthread.php?p=34705628
?????? Galaxy S3 ??????
this thread needs a *BUMP* !!
Has anyone checked if ANT+ his working in the I9505XXUEMI8 leak?
http://forum.xda-developers.com/showthread.php?t=2465713
It is showing running for me under running processes. Doesn't seem to make any difference to me though
Sent from my GT-I9505 using xda app-developers app
bennetski said:
It is showing running for me under running processes. Doesn't seem to make any difference to me though
Sent from my GT-I9505 using xda app-developers app
Click to expand...
Click to collapse
Do you have any ANT+ equipment to test with an app? (Believe endomondo supports ant+ HRM)
Considering updating to the leaked firmware, but the whole KNOX thing is making me a bit reluctant...
Unfortunately I don't have any supporting equipment. I am one of the lucky ones to have got the leaked 4.3 without getting knox installed but I wasn't really bothered even if I did. It's just a warranty void. It's actually very hard to brick an S4.
Sent from my GT-I9505 using xda app-developers app
Great news. Another 10 or more MB spent on software which is dedicated to communicate with specific hardware, and if you do not have such, it will be silently running in background consuming the battery and memory.
I have advice foe Samsung: guys, please do not forget about the dedicated BT controller to very common equipment like Boeing 737 or Airbus series 3 (310, 319, 320, 330, 340 380 etc.).
These planes are really popular nowadays and each pilot would really appreciate if he could for example control the flaps while playing Jewels
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).