Related
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 am trying to implement a simple system call hook. My method was the same method used by standard linux rootkits like adore. this method worked for hooking sys_open and other file IO system calls. but when i tried to hook sys_fork and other process related system calls my android phone crashes (Nexus one, Motorola Milestone, and emulator). Something inherently different about Android either ARM or android kernel is different from basic linux machines which wont allow me to use the same method to hook the system call fork. Basically my method is below, this is implemented via a LKM on a phone that i have root access on.
//save pointer to original function
orig_fork = sys_call_table[__NR_fork];
//point sys_fork to my my_fork function
sys_call_table[__NR_fork] = my_fork;
//call original fork call (simplest case)
asmlinkage int my_fork(struct pt_regs *regs)
{
pid_t pid;
pid = (*orig_fork)(regs);
return pid;
}
Some how i think the stack is getting messed up. I looked at the source code for the kernel and found that the sys_fork isnt actually in the system call table. Instead it is a sys_fork_wrapper. This wrapper is an assembler function with two commands which lead it to branching to sys_fork. Sys_fork in turn calls another function called do_fork. Through debugging methods i was able to confirm that my call to the original fork function was returning correctly, but when i try to return the pid within my own function the crash occurs. Now whats interesting is that I was able to confirm that do_fork is called many times without calling sys_fork for many processes on the phone. So when i do the simplest process i can think of by starting up a shell the phone didnt crash. But it wont open up a shell. The terminal locks up when i try to open the shell. Starting up a shell will call a sys_fork_wrapper->sys_fork->do_fork like expected. Starting up another more complicated process such as calculator it will call sys_fork_wrapper->sys_fork->do_fork->do_fork->do_fork->do_fork.... so bacially i am left with lots of questions about why hooking sys_fork is not working.
In reality I am hooking an assembler "function" and not a c function. The sys_fork_wrapper does branch command without link which led me to believe that there is no return from it, from the program counter perspective.
Did you ever resolve this issue?
Maybe you could try some inline asm in your code to just jmp to the orig_fork, if it is an assembly function that doesn't return, i.e. just a jmp stub itself.
I would like to hook sys_fork as well, to present a dialog box every time a new app runs and to allow me to block certain apps from starting.
Android Kernel rootkit.
Awesome
@michaelmotes Thanks so much for posting this link! I'm in the process of trying to do a little hooking hack in order to... well bypass a restriction on most phones prior to ICS. I won't say what for because if it works... I'll be putting out an app lol. But I really appreciate you sharing this.
Hi kernel hackers,
it is getting very silent recently about possible security hacks on the Milestone platform.
Today i stumbled over some kernel code located in /drivers/misc/sec.
Maybe this had been discussed already.... anyway
There're some interesting functions in the source code and i wonder which application is using this module to enter the secure world of OMAP.
Some of the functions are accessing registers, that are also involved in low level routines of the bootcode (e.g. mbmloader).
Some questions:
Which application in android userspace is using this module?
Could we tweak this module to get access to some of the protected OMAP registers?
Is it a signed module?
Would be nice to use a modified module and activate some of the blocked features (e.g. DAP controller for debugging).
Any comments welcome!!!
Regards,
scholbert
scholbert said:
Hi kernel hackers,
it is getting very silent recently about possible security hacks on the Milestone platform.
Today i stumbled over some kernel code located in /drivers/misc/sec.
Maybe this had been discussed already.... anyway
There're some interesting functions in the source code and i wonder which application is using this module to enter the secure world of OMAP.
Some of the functions are accessing registers, that are also involved in low level routines of the bootcode (e.g. mbmloader).
Some questions:
Which application in android userspace is using this module?
Could we tweak this module to get access to some of the protected OMAP registers?
Is it a signed module?
Would be nice to use a modified module and activate some of the blocked features (e.g. DAP controller for debugging).
Any comments welcome!!!
Regards,
scholbert
Click to expand...
Click to collapse
Well, I'm not a kernel hacker, but I have an educated guess...
I believe that the radio system uses those functions to check whether the kernel is valid or not, so, we have the radio not working with a replacement kernel that is loaded using kexec...
Perhaps, if it is possible to "change" this function using a module, we could get a function always telling the kernel is valid and have kexec working on Milestone. Again, I'm not a kernel hacker, but that is my guess.
Hi, I'm sorry that I wont be much help but these guys might;
https://www.droid-developers.org/
irc://irc.freenode.net/#milestone-modding
Hi,
thanks for your comments so far.
To be more precisely i think this kernel driver is calling the secure monitor in some way. See here:
https://www.droid-developers.org/wiki/Secure_Monitor
There's also a structure defined in that driver. I think i'll have to compare some of the ioctl entries.
https://www.droid-developers.org/wiki/Secure_Services
I'll do some investigation on this issue and search the web for some userland source code using this driver.
Again, if someone knows more about it, your welcome
Cheers,
scholbert
scholbert said:
Hi,
thanks for your comments so far.
To be more precisely i think this kernel driver is calling the secure monitor in some way. See here:
https://www.droid-developers.org/wiki/Secure_Monitor
There's also a structure defined in that driver. I think i'll have to compare some of the ioctl entries.
https://www.droid-developers.org/wiki/Secure_Services
I'll do some investigation on this issue and search the web for some userland source code using this driver.
Again, if someone knows more about it, your welcome
Cheers,
scholbert
Click to expand...
Click to collapse
you don't have to search for the source, it's on SourceForge:
http://sourceforge.net/projects/milestone.motorola/files/
SophT said:
you don't have to search for the source, it's on SourceForge:
http://sourceforge.net/projects/milestone.motorola/files/
Click to expand...
Click to collapse
Yeah sure, i knew this
Anyway, thanks for the hyperlink!
In the meantime i grepped all binaries from the latest distribution.
I found out, that two applications are using /dev/sec.
1. dbvc_atvc_property_set
2. tcmd
If someone knows which package of source code they belong to... would save some time searching.
EDIT:
O.K. Google did it for me...
Seems that both binaries are proprietary code. Some early conclusions:
1. dbvc_atvc_property_set
This one is started as a service in init.mapphone_umts.rc and seems to use /dev/sec for granting rights to access OMAP secure world (e.g. read eFuse values for unique device id, IMEI etc.).
This binary contains a certificate which is not Milestone specific (XT720 uses the same).
So right now i don't know, if this certificate is needed to access /dev/sec or the application itself identifies itself as trusted application (signed app).
Would make sense, if the BP uses signed applications to access certain low level functions, e.g. read/write the eFuse bank.
2. tcmd
This one is also started as a service in init.mapphone_umts.rc to access a variety of devices. Seems to be related to data streaming or stuff.
As stated it has an entry for /dev/sec and it got no certifcate.
Would be interesting to get some more info about that.
Further comments....
P.S.: This bloody security stuff is making me sick
Regards,
scholbert
Hi again,
i just compared some of the defines in the kernel driver headers (/drivers/misc/sec/sec_core.h) with the ones xvilka reversed inside mbmloader.
Code:
...
#define API_HAL_KM_SOFTWAREREVISION_READ 33 // 0x21
...
#define API_HAL_NB_MAX_SVC 39 // 0x27
#define API_HAL_MOT_EFUSE (API_HAL_NB_MAX_SVC + 10) // 0x31
#define API_HAL_MOT_EFUSE_READ (API_HAL_NB_MAX_SVC + 15) // 0x36
...
For comparison see the table here:
https://www.droid-developers.org/wiki/Secure_Services
It is obvious that /dev/sec allows to access OMAP secure world and uses the above mentioned API calls to push information to userspace apps.
The question would be, if ioctl must be certified through the API using some key ...
O.K. i see this is deep down code creeping, but maybe someone understands what i try to work out
See ya,
scholbert
scholbert said:
O.K. i see this is deep down code creeping, but maybe someone understands what i try to work out
Click to expand...
Click to collapse
I think I know what you are trying to work out, but I can't think of any way to help
You're pretty much comparing the results of your findings with that of the mbmloader dump right?
I would like so much to fully understand what you are doing, but I can understand just a little..
btw I hope that you'll be glad to know that you have all my psychological support!
mystichobo said:
I think I know what you are trying to work out, but I can't think of any way to help
You're pretty much comparing the results of your findings with that of the mbmloader dump right?
Click to expand...
Click to collapse
Yeah, kind of... we know for sure there's an API to access security functions on OMAP. I just digged out some parallels in kernel code and mbmloader.
If we could make use of security functions from within kernel space (by using a tweaked module) this would be a nice playground.
Perhaps, there's any bug or backdoor we could shamelessly exploit to:
a. boot custom kernel with second boot
b. tweak the security system and enable some hidden functions inside OMAP
puffo81 said:
I would like so much to fully understand what you are doing, but I can understand just a little..
btw I hope that you'll be glad to know that you have all my psychological support!
Click to expand...
Click to collapse
Thanks a lot for pointing out
Best regards,
scholbert
scholbert said:
Yeah, kind of... we know for sure there's an API to access security functions on OMAP. I just digged out some parallels in kernel code and mbmloader.
If we could make use of security functions from within kernel space (by using a tweaked module) this would be a nice playground.
Perhaps, there's any bug or backdoor we could shamelessly exploit to:
a. boot custom kernel with second boot
b. tweak the security system and enable some hidden functions inside OMAP
Click to expand...
Click to collapse
That's what I thought
Surprised noone has looked into it earlier really
Anyway good luck with it, adding my moral support too.
Cheers,
hobo
mystichobo said:
Surprised noone has looked into it earlier really
Anyway good luck with it, adding my moral support too.
Click to expand...
Click to collapse
I got into contact with xvilka.
Obviously there'd been some investigations concerning this issue.
To be honest, i don't know if it's worth to digg a little deeper or if it will ever led to something useful in the end. Could be fun though
Perhaps it would be nice idea to tweak the driver and put some debug message in the code.
Another interesting thing to do would be a logging function.
This way it would be possible to get some insights of the API to secure monitor.
Anyway, i think it's never useless to discuss about some hacking here. At least were at xda-developers
If you like to tweak some kernel code, join in!!!
Have fun!
scholbert
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).