Here is what I found from the source code, anymore?
*#06# Display IMEI
*#*#8351#*#* Voice Dialer Logging Enabled
*#*#8350#*#* Voice Dialer Logging Disabled
*#*#4636#*#* Phone Setting
*#*#7262626#*#* FieldTest
android.provider.Telephony.SECRETE_CODE
Already know that 5 Secret Code but could not find any thing which can out it into Diagnostic Mode which was there in Windows Mobile.
Please Upload the Source code also so every body also start searching for something very usefull.
hetaldp said:
android.provider.Telephony.SECRETE_CODE
Already know that 5 Secret Code but could not find any thing which can out it into Diagnostic Mode which was there in Windows Mobile.
Please Upload the Source code also so every body also start searching for something very usefull.
Click to expand...
Click to collapse
The source code is online and available VIA git
And if you are trying to use the field test use anycut to make a shortcut on the desktop and it has a menu item to output diagnostics.
Of course if you have DDMS or Eclipse you can output diagnostics as well.. I believe they have a linux boot image on open handset alliance
those aren't that secret, and aren't anything special.
Any app can register a "secret code" and they are specified in the manifest.xml file.
most of the time those numbers are things like "INFO" and are a lot easier to remember if you think of them that way instead of the digits.
We talking abiut the Diagnostic Mode of Phone Radio so we can plug the Phone into USB and get QxDM (Qualcomm Extendible Diagnostic Mode) Software and look into Radio NVItem from 0 to 4000. DDMS is useless for that kinda Stuff. Radio Software is build using Some Different Core other then Linux, i have seen commnet of CMonex He said it the same as General other Radio, Remeber Radio and Android is connected with RIL (Radio Interface Layer) using Internally Exposed Serials Ports.
did somebody say exposed serial port?
Over my head a bit, but sounds cool, internally exposed serial ports sound useful, id assume you,d get i/o from both sides radio/droid. Back on the WIZ you could find a radio that works with the rom ver. and carrier to get best clarity, call handling, stability and battery life. This is cool reminds me of the early days of palm os rom hacking/cooking (we didn't call it that back then)
I'm glad I got it and I'm glad its an htc, so the homies at xda-dev will have this bad boy totally tricked out and custom...I love this plave, in a non homo way
Will we all be adding db9 ports on pur g1s
Bhang
no, i do not believe we will ever see a db9 on the G1. First of all, that connector went out of style in the late 90's and second, its rather huge (want do drill a hole in your screen to make room for it??). I would however like to see usb host, but someone commented that it is probably not enabled in the kernel and if it is, there are no drivers for it (hint hint driver g writers). cmonex (is a girl by the way) has been looking into methods to get root on RC30 and many other things so we hope to see some fun new hacks from that.
nice shrring,this is a good source where someone can learn something about their mobile secret functions,meantime i would like to share something which i found last week this is a site where it has network unlock code for all mobiles find further
Find included a 2.6.27 kernel and corresponding wlan.ko with serial port enabled. This will work with JF, mikhael's build and so on that use the 2.6.27 kernel. Wifi works, bluetooth works, all that stuff works.
Serial port is /dev/ttyMSM2 with default at 9600 baud. I am turning my ADP into the brains of a UAV, so this should let me control servos with it.
Have fun! 2.6.29 (or whatever will be current) coming when I get off my lazy bum and move to it.
Installation is the usual "rename to update.zip, put in sdcard, start the phone in recovery mode" dealie.
BACK UP YOUR BOOT.IMG AND /SYSTEM/LIB/MODULES/WLAN.KO if you want to revert!
Here's a newer version with a terminal program (dterm, recompiled for g1/g2), or just the terminal by itself. If you flash the terminal ends up in /system/sbin and automatically goes to /dev/ttyMSM2 (see source), again it's just dterm with some cleanups.
By the way, does anyone care about this stuff at all?
I couldn't upload the kernel so here it is http://www.spirit-plumber.com/portfolio/robotics/kernel_serial_term.zip
It sounds very promising/interesting but I'm not exactly sure what it does. Does is it enable accessing the baseband via serial or something? This is something that was used on the original iPhone to try to unlock it.
I think if you explain more clearly what it does then more people will seem interested, & remember no contribution here is a bad one, someone will have a use for it.
It gives you a serial port that can be used as a device rather than just for debugging, as shown here
http://www.instructables.com/id/Android_G1_Serial_Cable/ (not by me btw) This software stuff makes it usable for general purpose IO. That allows a G1 and an inexpensive microcontroller, arduino/picaxe/etc to control servos, talk to a second GPS, and so on.
I develop autopilots for RC planes and the G1 would be a great platform for that since it has a gps, compass, accelerometer and camera already integrated in a relatively small/light package.
Also, ROBOTS! http://hackaday.com/2009/01/25/forknife-android-g1-controlled-robot/ This was done using the audio port, but having a serial port on board bypasses all the DTMF stuff and allows for a lot more bandwidth. (Also not by me, if you do want to see stuff by me, search spiritplumber on youtube!)
I'm also very interested in such a kernel as a friend and I are interested in interfacing a phone to a serial robot controller.
However, I am currently running Cyanogen 4.0.4 on a MyTouch and loading this kernel effectively breaks the phone. No radio, GPS, etc. and many apps are missing/broken. The serial port does work and we got it talking with our robot but otherwise it's not much use to me.
So atm it's either a phone or an overly expensive microcontroller but not both.
You could submit the patches to cyanogen to see if he'd be willing to incorporate it in his build.
this is kernel version 2.6.27 and i think the build you use has kernel 2.6.29 which is why everything'd break. i will build 2.6.29 at some point, for now use a build that still use .27? i useJF151 with good results.
Hi, I'm interested in this stuff, I just wonder how can I use this to interface G1 to Arduino? any idea/tips will be helpful. TIA.
You end up with a new device, /dev/ttyMSM2 which is a standard issue serial port that can be used to talk to microcontrollers. The voltage is 2.8V which means it will work with a 5V micro in the phone-->micro direction, but if you want to go the other way you'll need a divider.
(see the other thread i posted in for a schematic)
I should probably get cracking on a donut version
Wow
Interesting stuff. I just wish I had the ability to take advantage of this. I think this would bring it one step closer to being able to use the G1 as an OBD-II car scanner. But I'm afraid that will take way more technical ability than I have.
Not really...
http://www.suntekstore.com/OBD2-16Pin-to-DB9-Serial-Port-Adapter-Cable-.html
http://www.instructables.com/id/Android_G1_Serial_Cable/
+ my kernel
Nice work
spiritplumber said:
...
I develop autopilots for RC planes and the G1 would be a great platform for that since it has a gps, compass, accelerometer and camera already integrated in a relatively small/light package.
Click to expand...
Click to collapse
Genius! Well done for bringing this all together!!!!
I found your thread while trying to investigate the same project you've done already - making an autonomous drone using the G1 !!!
- I'd be very interested to see videos/info/photos of your drone.
I've seen all the bespoke UAV controllers on DIYdrone.com, but was more interested in the challenge of making my G1 with all it's sensors directly control a servo controller board via serial.
I'm a bit worried that the screen must stay on, which will burn through the G1's battery in no time! - is this still necessary?
I'm really impressed and thankful for what you have done, and making it public!!!
I'm currently on Cyanogen 4.0.4. so I guess the first step is to back track to an earlier Kernel version...
Unless you're close to rebuilding 2.6.29 ???
Thanks for the 'instructables' for the cable too, I've ordered the bits and hope to test in the next few days - ironically I found that before this thread!
Hmmm...
I've just studied your cable making instructions and have some questions!
The USB-Serial converter board... is that any use at all other than a PC interface?
I shouldnt actually need this to talk directly to another serial device from my G1?
- I got the impression the USB/Serial board was to convert the G1's USB to Serial...
Could I send a serial TX messages directly from the break-out board to a serial RX pin... (Servo controller) does that sounds correct?
Sorry for the torrent of questions...
If you want to talk to a different device you just need to flip pins 2 and 3 on the serial port and use a male rather than female connector so yes you can definitely do that!
In fact you can do two at the same time: Here's me using the G1 to relay data from a GPS to a servo controller. If you'd like the schematics for that let me know. If you have any sort of work related to this DEFINITELY let me know.
By the way, I'm using a 74HTC14 for doing the level shifting and inverting: it's a very cheap part and also has the advantage of cleaning up the waveform nicely. Or you can use some transistors.
EDIT: Attachment is being stupid so go here for photos: http://spirit-plumber.com/robotseverywhere/gallery/images/other/gphone/
spiritplumber said:
If you want to talk to a different device you just need to flip pins 2 and 3 on the serial port and use a male rather than female connector so yes you can definitely do that!
In fact you can do two at the same time: Here's me using the G1 to relay data from a GPS to a servo controller. If you'd like the schematics for that let me know. If you have any sort of work related to this DEFINITELY let me know.
By the way, I'm using a 74HTC14 for doing the level shifting and inverting: it's a very cheap part and also has the advantage of cleaning up the waveform nicely. Or you can use some transistors.
EDIT: Attachment is being stupid so go here for photos: http://spirit-plumber.com/robotseverywhere/gallery/images/other/gphone/
Click to expand...
Click to collapse
Hi Spiritp,
Thanks for your comments, I'll give that a whirl then!
I'll definitely keep you posted!
My basic plan is:
Use accelerometer for auto-leveling control, use pre-defined GPS routes so I know the take-off / landing site altitude above sea level, and eventually get the G1 to take photo's at GPS waypoints.
Probably ambitious considering my electronics knowledge, but I'll keep you posted with progress.
If you have any pointers of how to send Serial commands from within the Android App layer, I'd really appreciate it.
With so many 'rooted' applications doing kernel based tasks I'm pretty sure it'll be possible... but I'm also fairly green on linux & java, so this will be a challenge for sure. (Time to hack my way through other people's work and understand what's going on!!!)
Thanks for your response,
Andy
spiritplumber said:
By the way, I'm using a 74HTC14 for doing the level shifting and inverting: it's a very cheap part and also has the advantage of cleaning up the waveform nicely. Or you can use some transistors.
Click to expand...
Click to collapse
Question 1:
When you say 'level shifting' is this to bring the TX/RX voltage to the same level? (i.e. 5v --> 5v, rather than 2.8v --> 5v)
Question 2:
If I plugged a 5v serial device into the G1's RX connector, would this damage the G1?
Question 3:
Please help explain how non-printing byte-level data (Servo commands) can be sent from DTerm... I've had a poke around on the internet but with no success...
Question 4:
I have installed your Kernel/DTerm... which runs DTerm ok, but the commands 'ls' return the error 'not found'.
- which worked before adopting your kernel..
Is this normal? How can I fix this?
EDIT:
Ok, I think I'm half way there... I've now bought one of these:
http://www.coolcomponents.co.uk/catalog/product_info.php?products_id=194
//
spiritplumber said:
If you want to talk to a different device you just need to flip pins 2 and 3 on the serial port and use a male rather than female connector so yes you can definitely do that!
Click to expand...
Click to collapse
Reminds me of the HP48 token ring networks. http://www.hpcalc.org/details.php?id=3603 In essence, device 1 would transmit data to device 2. Device 2 would see that the packet was meant for a different device and retransmit the packet to device 3, the intended recipient. If device 2 had been transmitting a packet to device 1, it would have passed through 3 on the way back around. Adding another device to the network was as simple as breaking the chain and adding a new one. Building the cables to do that wouldn't be too difficult.
Level shifting:
Internally the G1 uses 2.8 volts. This is nice if you've a 5V interface because:
On going G1--->other part, 2.8 is high enough to register as "high", you may need a pullup resistor (try 10k).
On going other part--->G1 you just need a voltage divider! That's two resistors of equal value, this makes the other part effectively output at 2.5v which the G1 will happily accept! (If this confuses you, see "voltage divider" on wikipedia..... it's literally just 2 parts). Here's a picture on page 5: http://forum.xda-developers.com/showthread.php?t=496976&page=2
If you need to do stuff in that sense I recommend just having the servo controller take in ascii stuff. Or you can modify dterm. Or I can give you a modified copy of dterm that has that functionality let me know!
If you use a 3.3V microcontroller such as the Parallax Propeller, just slap two 1KOhm resistors on the rx and tx lines and go do stuff: it works.
Controlling servos via G1 is very painless and easy, I already do that, let me know if you want tips.T
spiritplumber said:
Level shifting:
Internally the G1 uses 2.8 volts. This is nice if you've a 5V interface because:
On going G1--->other part, 2.8 is high enough to register as "high", you may need a pullup resistor (try 10k).
On going other part--->G1 you just need a voltage divider! That's two resistors of equal value, this makes the other part effectively output at 2.5v which the G1 will happily accept! (If this confuses you, see "voltage divider" on wikipedia..... it's literally just 2 parts). Here's a picture on page 5: http://forum.xda-developers.com/showthread.php?t=496976&page=2
Click to expand...
Click to collapse
That's excellent, I think I have a solution for the voltage, but thanks a lot for your electronics expertise!!!!!!!
spiritplumber said:
If you need to do stuff in that sense I recommend just having the servo controller take in ascii stuff. Or you can modify dterm. Or I can give you a modified copy of dterm that has that functionality let me know!
Click to expand...
Click to collapse
I'm actually using a Pololu micro serial servo controller (SSC) - I'm fairly sure it doesnt support ASCII characters, the manual only explains how to compile a '3 byte sequence' :
To set the servo position, send a sequence of three bytes. The first byte is a syncronization value that must always be 255. Byte 2 is the servo number, and it can be 0-254. Byte 3 is the position to which you want the servo to move, also 0-254. (sync= 0xFF,servo= 0x00-0xFE,position= 0x00-0xFE)
If you can help / let me know how to modify dterm I would really appreciate it!!
Although I'm still not sure how I'm going to access this from the Android Application layer - making calculations from accelerometer & GPS, then sending the calculated servo movement down to a kernel app?
Any help in this area would be greatly appreciated!
spiritplumber said:
Controlling servos via G1 is very painless and easy, I already do that, let me know if you want tips.T
Click to expand...
Click to collapse
I would find any tips interesting !!!
Thanks again for your comments & help, you're making this project far easier than I could have hoped!!!!! hopefully I will be able offer you help in my areas of expertise some day!
- I'm an application developer by day, using VB.net/Sybase Powerbuilder/Pocketbuilder/SQL/Microsoft-based network admin.
Just a quick final question (for today!!) - my Wlan seems to have been knocked out by your kernel image... the android manager can see AP's but always reports that it was unsuccessful when trying to connect.. and ideas?
- I'm on JF1.51 ADP1, no other mods or changes.
Andy
(I would have posted this in the development forums but apparently I don't yet have enough "karma" or something {grin})
I'm on a project to use Android tablets to exchange data via USB with an embedded microcontroller environment. At present I'm using a Nexus 7 (because it supports USB Accessory mode, so it can be powered by the other end) and an Arduino Due (because it has two USB interfaces). I've read countless articles and scoured everything I can find on the topic of programming for USB, but still have some fundamental questions.
The biggest one concerns how the host and device interfaces "identify" each other. Seems like each end needs to expose a USB interface with VID/PID values that the other end knows about and looks for during initialization. This implies that the code on each end would need to control the PID and VID values, as well as other USB descriptor values. Yet none of the code examples I've found ever discuss this.
Example: I've found that the Nexus 7 exposes one PID value (0x4E42) when its USB port is configured in "media device (MTP)" mode, and a different PID value (0x4E44) when its USB port is configured in "camera (PTP)" mode. The protocols for interacting with these two configurations is different, and the code on the other end of the wire needs to know how to handle that. I haven't checked yet but I suspect the values in the usb_interface and usb_interface_descriptor structures also change along with the PID value, since usb.org defines a whole bunch of standardized values for various device types. A connecting device would retrieve these values, potentially from multiple exposed logical interfaces on the same physical USB port, and select a compatible one.
Since I'm writing the code on both ends of the wire, doesn't my code need to somehow convey these values into the USB interface hardware? How is that done, for example, under Android? Do the code examples just omit this because everyone but me knows how to do it?
If I just "ignore" this question, then when the Arduino (acting as USB Host) polls the Nexus 7 it will have to select from whatever interfaces are offered. So... whose code is in charge of those interfaces? How does my code tell the Android OS which of these "default" interfaces it will be handling? My suspicion is that, if a USB interface is being advertised, there is *already* code behind it. That brings me full circle to the question of "How does my code inform Android that it wants to use certain VID/PID values?"
I hope I've explained this clearly. It's a pretty detailed question, so if it's unclear I can try to ask it differently. Thanks in advance for any guidance, tips, RTFM's, etc.!
For interacting arduino with android device, it can be written under eclipse, you can learned it from "Beginning Android ADK with Arduino" which can be downloaded from torrent market. VID/PID mostly used to allow your device to be recognised to your computer.
koklimabc said:
For interacting arduino with android device, it can be written under eclipse, you can learned it from "Beginning Android ADK with Arduino" which can be downloaded from torrent market.
Click to expand...
Click to collapse
Thanks, I'll look for that reference!
VID/PID mostly used to allow your device to be recognised to your computer.
Click to expand...
Click to collapse
Yes, but those parameters (along with a couple of others) are used to 1) confirm that the two devices recognize each other, and 2) in some cases to launch the proper code to handle that interface/protocol. So you must have control over them, and must initialize the USB system with the proper values in some manner. I presumed it would be in the Android API but I can't find any reference to setting the low-level values for USB connections.
Thanks again for the response! Anyone with additional data? It would be greatly appreciated!
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).