Related
Hi guys,
I've searched this forum and haven't found an answer to my question, so I'm gonna post it here. (Hopefully I did the search right and didn't commit the felony of a double post. )
I'm planning on buying a new phone, mainly because my old HTC Charmer (WM 6.1) doesn't support SDHC cards and the maximum of 4GB of the cards I can use with it is just not enough any more.
So far, I've read quite some disappointing details about Windows Phone 7:
- No more "free" apps (by which I mean apps programmed by someone and offered somewhere, now it's the same sh** as with an iPhone or an Android phone)
- No direct USB-sync, which means you have to send your private information to the cloud in order to sync
- No "real" support for SD-Cards (and getting more storage space is the whole da** point here, otherwise I'm quite happy with my Charmer)
So, basically I thought about getting a second hand HTC Touch Pro II running WM 6.5 AND supporting NORMAL SDHC cards (meaning ALL cards which comply with the standard, not just the ones "certified by Microsoft").
But there might be one killer feature which could make me, well, not really forget, but maybe turn a blind eye to WP7's SHAMEFUL flaws: The new Microsoft Office Mobile. Often, I have some Excel spreadsheets which I need for work at different places. This is the only reason I have to take a laptop computer with me, apart from that my phone would be fine.
Office Mobile in WM 6.1 (or 6.5) couldn't display / make use of all the features the Desktop-Version offered (like extremely complicated formulae or spreadsheets and of course macros), and, moreover, after having worked on and saved an Office document on a phone, the features would even have been removed from the file in the conversion process, so the file was useless on the desktop as well.
Thus, I'm asking the following questions (which surprisingly haven't been answered on the net so far, or am I just too stupid to google it right?):
- Is the Office in WM 7 fully functional, meaning you can work on Excel sheets with the most complicated formulae and macros, or, asked more simple, can you do everything you can do with the Desktop version on your phone as well?
- If it doesn't offer everything the desktop versions offers, does it at least keep everything that was there in the original file after you change and save it on your phone? I mean, even if I can't use macros on the Windows Phone, it might still be helpful to open an .xls file on the phone, make a few changes (which don't require macros), save the file on the phone and after putting it back on a desktop computer having the file "unharmed" (meaning except for the small change I made on the phone everything else is as it was)?
Hopefully, I made my point clear enough, if not, I'm happy to answer questions on what it is exactly that I want to know. I think many users here already having a Windows phone will have tried working on Office documents on their phones and I hope those will share their experiences with me.
Many thanks for reading my post and even more thanks for answering.
Peter
Firstly,in terms of the functionalities of the excel,I don't think WP7 is suitable for you.
Furthermore,personally I prefer USB drag and drop the documents to my device,maybe you can call me old school.I just find the office useless for me since I don't have sharepoint,I don't want create a dropbox account just to upload my file to cloud and download it to my device again and I don't have a data plan.Therefore,until now, I still didn't use the office app once.
In your situation,I think you need an android phone to handle your job this moment,you can just purchase quick office,docs to go,depends on your personal preference.In addition,the only office app available is just microsoft office,no other choices.furthermore,as you said,you want transfer it back to your desktop unharm,therefore it is good to have drag and drop file transfer function rather than rely on dropbox,upload to the cloud and download on your desktop again.
On the other hand,there is no clear information about the mango updates which add more features to the office.So,I'll would suggest you to go with Android or iOS for this moment.
Thank you for the answer.
No more "free" apps (by which I mean apps programmed by someone and offered somewhere, now it's the same sh** as with an iPhone or an Android phone)
Click to expand...
Click to collapse
Free, in cost, there are plenty. Free as in not first checked by MS, kinda but no. You can developer unlock your device and sideload apps. However, that being said, MS are pretty good, they're only blocking apps which don't meet quality control standards (which I think is a good thing) or, somewhat contentiously, are "adult". They're not playing the same game as Apple.
I'm confused by you saying Android though. You can easily download and install programs (apk) on your device from any source (you just have to choose that option in the settings).
Office in Mango is improving - specifically:
1. Better support for formulae
2. Skydrive sync
So, yes, formulae can be created and manipulated in Excel, though I wouldn't say it's a replacement for the real Excel. It certainly can't run macros.
Skydrive is still "in the cloud" however, you're automatically registered to the free account by the virtue of having a live id. I still believe we should have USB file transfer but at least this is better than nothing.
Casey
Hi there,
This software is an Antitheft and you can use it to track your device when it was lost or stolen. It works catching a formated SMS/EMail sent from any phone/computer and then receiving useful informations back.
You can use it to others objectives, like keep your eye in your child. Use your imagination!
You can set up to four emergengy contacts to receive SMS if the thief change your SIM card and you still can track your device.
The RemoteTracker for Android is an evolution from an old project for Windows Mobile 6 (If you want to see the entire history, please click here).
I'm justing starting this project. There are much more to come.
To send a command to RemoteTracker, send a SMS with the syntax: RT#(command)#(phone or e-mail)#(password). Example: RT#EGP#[email protected]#1234. This version answer the commands below:
help - send to you a list of commands available in Android platform;
ehelp - same as 'HELP', but send the list by e-mail;
fhelp - same as 'HELP', but send the list to your FTP server;
gp - try to get GPS coordinates and send back to cel number passed as parameter;
egp - same as 'GP', but send the list by e-mail;
fgp - same as 'GP', but send a file to your FTP server;
gi - Send informations about your phone: IMSI, IMEI and ICCID;
egi - Same as 'GI' but the answer goes by e-mail;
fgi - Same as 'GI' but the answer goes to your FTP server;
cb - your phone will make a Call Back to you. Just make a call and let the microphone open;
cellid - Retrieve informations (CELLID, LAC, MNC and MCC codes) about the tower your phone are connected. Send to you by SMS;
ecellid - same as 'CELLID', but the answer goes by e-mail;
fcellid - same as 'CELLID', but the answer goes to your FTP server;
secret - if you forget your password you can use this command to receive by SMS your personal secret question;
lostpass - used to receive your password if you forgot it. You must send the answer for your secret question, so, you can use the secret command to help you;
Commands available only in PRO version:
PICSON - Makes RemoteTracker (only PRO version) watch for new photos and send them to Default EMail Address;
PICSOFF - Makes RemoteTracker (only PRO version) stop to watch for new photos;
EPICSON - Same as PICSON, but send an E-Mail back;
EPICSOFF - Same as PICSOFF, but send an E-Mail back;
FPICSON - Same as PICSON, but send the answer to FTP server;
FPICSOFF - Same as PICSOFF, but send the answer to FTP server;
PCALLSON - Makes RemoteTracker (only PRO version) takes a photo on a call is receive or made and send it to Default EMail Address;
PCALLSOFF - Makes RemoteTracker (only PRO version) stop to take photos on calls;
EPCALLSON - Same as PCALLSON, but send an E-Mail back;
EPCALLSOFF - Same as PCALLSOFF, but send an E-Mail back;
FPCALLSON - Same as PCALLSON, but send the answer to FTP server;
FPCALLSOFF - Same as PCALLSOFF, but send the answer to FTP server;
WIPEDATA - This command will return your device to factory default and format your SD Card.
There are another features inside RemoteTracker, like:
- SIM CARD change observer;
- Automatically restore your preferences if you reinstall it. This feature is particular useful if you have a custom ROM with RemoteTracker inside. Once configured, everytime your devices boots up, your preferences will be restored;
- Works as Device Admin, so it can't be uninstalled if you don't know the password;
- And more...
This project can be multi-language. In this version there is only English (sorry about it, my english is very bad because this is not my mother language). If you want to make your own translate, I can tell how. Very simple.
If you decide to try RemoteTracker, I would like to read reviews, comments and suggestions. Remember this is a beta version and may contain bugs. Use at your own risk and with caution.
--> It is a work in progress. In future versions I will make a lot more.
Support this project
You can support this project making a donation clicking here or clicking the banners in the project website: http://remotetracker.sourceforge.net
All the best,
Joubert Vasconcelos
Hello friends!
To test RemoteTracker please download it from here:
http://remotetracker.sourceforge.net/RemoteTracker.apk
Before your tests, please turn on the Debug option. It will make RemoteTracker write the remotetracker.txt file in the root of your memory card.
All the best,
Joubert
I just released the second beta!!!
Now, RemoteTracker can automatically turn on the Mobile and WiFi network to try get location and send EMails!
For older phones RemoteTracker also will automatically turn on the GPS! Unfortunately this is impossible if you are using new Android versions (2.3.x or so).
A few minor bugs was fixed.
All the best,
Joubert
joubertvasc said:
For older phones RemoteTracker also will automatically turn on the GPS! Unfortunately this is impossible if you are using new Android versions (2.3.x or so).
Click to expand...
Click to collapse
GPS can be enabled in 2.3+ - but only if device is rooted. That's what it says in the Cerberus entry in "AppStore" [edit: AndroidMarket].
Hi!
Yes, if you have a rooted device is very easy to enable GPS remotely. But I do not recommend in any way for users to root the phones for security reasons.
I think you are talking about Market, not AppStore We are talking about Android not Apple
All the best,
Joubert
New beta 0.3!!!
Hello again,
I just released version 0.3. Now we got FTP answers back!
In Configurations I added a session to input your FTP server details. The example commands GI and GP now works with FGI and FGP as well.
Once again minor bugs was fixed. If you want to try please download the APK here: http://remotetracker.sourceforge.net/RemoteTracker.apk
As soon as possible I'll make a TODO list and a Road Map.
All the best,
Joubert
Copying my post form the old thread so I can subscribe to this one:
Wow, nice to see this make it to Android.
Some suggestions,
1: Name it something that isn't obvious in the market. Don't want a thief easily finding it in the installed apps list. Going to the market and then buying "my apps" shows you exactly what's installed. So you should name it something totally different that nobody would suspect or want to remove. Like "memory maximizer" or something like that. Probably want to keep it in the middle of the alphabet so it's not at the top or bottom of the list.
2: Maybe make a way to remotely monitor the front/rear camera. Then you could get the thief on video (and also see if it's a crowd, or some huge guy you don't want to mess with, lol).
I'll try to help test when I get another phone and more time. Right now I don't have a lot of time to work out bugs. And more importantly I only have the 1 phone, and I can't afford to have it malfunctioning (I need it for work). I'll buy a used extra phone for testing and then I'll help test.
Thank's!
Be sure I'm worry about the Name I'll post on Market. Not now. I'm trying to make it working and I'll see what I can do later.
About cameras, yes, I think we can control them. At least take pictures and send to an e-mail account. To remotely monitor the cameras, may be I need a server to receive/transmit stream. Of course this is in my todo list
All the best,
Joubert
joubertvasc said:
Thank's!
Be sure I'm worry about the Name I'll post on Market. Not now. I'm trying to make it working and I'll see what I can do later.
About cameras, yes, I think we can control them. At least take pictures and send to an e-mail account. To remotely monitor the cameras, may be I need a server to receive/transmit stream. Of course this is in my todo list
All the best,
Joubert
Click to expand...
Click to collapse
I would rather set up my own server (or even directly stream peer to peer from the device). That way you don't get stuck with hosting fees and the app doesn't die if you decide to stop supporting it someday (not that you would).
There are many possibilities. I'll try all of them.
All the best
Joubert
Another beta
Hi all,
I release another beta. Once again, if you decide to try it, please download from http://remotetracker.sourceforge.net/RemoteTracker.apk.
I edited the first post to add new features. And I have a notice...
I created a free and pro versions. The free version will have the most common commands we had in Windows Mobile. Only specific commands for Windows Mobile I can't write for Android. Pro version will have new features to come (I don't know yet).
But I don't want to charge my friends, so, if you are a beta tester or help me with anything, I'll give the PRO version for free. But it's for future now I'm engaged to finish RemoteTracker free as best as I can do.
All the best,
Joubert
Possible Bugs
Hi Joubert,
Thank you for have been developing so useful application. I believe everyone here is excited about what you are doing.
I tried your better version and here what I have to say:
1) You stated that the command format is RT#EGP#[email protected]#1234, but what if I want to use command to upload that info to FTP? Then,theoretically, I don't need to indicate my email or phone in the command. At the same time commands like "RT#FGP#1234{this is a password}", "RT#FGP##1234{this is a password}" are not recognized as valid RT commands or even failed with fatal exception. How can I upload this info to FTP, what should be the format of the command in this case?Indicating an email inside the command or phone number when sending to FTP seems a kind of redundancy.
2) Once an Fatal error appeared, it started appearing for each further VALID command which were working before. Error states the following:
Fatal error: Call to a member function query() on non-object in /celerra/webstor/root.dev/usr/sms core.php on line 234, most likely there it has some null reference there.
3) In the log file I see that its trying to send messages to invalid address substituting "@" at "?". Does it mean it sends to correct address but it writes to the logs incorrectly or is it really a bug? Because I don't receive any emails at all.For example, when sending RT#EGI#[email protected]#De41Be02AF in the logs I see that it mentioned it sent the message to "test?test.ru" instead of "[email protected]"
This is it for now. I can try to help you out with programming. I have no experience in Android development but have been developing in C# for 7+ years.
Again thanks for you effort.
ser-j said:
Hi Joubert,
Thank you for have been developing so useful application. I believe everyone here is excited about what you are doing.
Click to expand...
Click to collapse
I'm stuck right now. I can not go ahead because I'm not finding some answers. But soon I return to search. Very good to know there are people wainting my work to be done, because there are lots of good programs in Google Market (now Google Play).
ser-j said:
I tried your better version and here what I have to say:
1) You stated that the command format is RT#EGP#[email protected]#1234, but what if I want to use command to upload that info to FTP? Then,theoretically, I don't need to indicate my email or phone in the command. At the same time commands like "RT#FGP#1234{this is a password}", "RT#FGP##1234{this is a password}" are not recognized as valid RT commands or even failed with fatal exception. How can I upload this info to FTP, what should be the format of the command in this case?Indicating an email inside the command or phone number when sending to FTP seems a kind of redundancy.
Click to expand...
Click to collapse
You should use: rt#fgp##1234 The double # are still necessary. I'm working on a simpler syntax to be used in final version.
I'm worried about fatal errors. That's why I released beta versions. Please use Configurations Menu and check the Debug Options. After that you will see in the root of your memory card a file named remotetracker.txt. Send that file to me please.
ser-j said:
2) Once an Fatal error appeared, it started appearing for each further VALID command which were working before. Error states the following:
Fatal error: Call to a member function query() on non-object in /celerra/webstor/root.dev/usr/sms core.php on line 234, most likely there it has some null reference there.
Click to expand...
Click to collapse
I really don't know what is this. Please send the log file to me. I wrote RemoteTracker for Android in Java, not PHP!!!
ser-j said:
3) In the log file I see that its trying to send messages to invalid address substituting "@" at "?". Does it mean it sends to correct address but it writes to the logs incorrectly or is it really a bug? Because I don't receive any emails at all.For example, when sending RT#EGI#[email protected]#De41Be02AF in the logs I see that it mentioned it sent the message to "test?test.ru" instead of "[email protected]"
Click to expand...
Click to collapse
Are you sending the command using another phone, the same phone or using some WEB service (like your carrier website)? There is no code to change '@' to '?'.
ser-j said:
This is it for now. I can try to help you out with programming. I have no experience in Android development but have been developing in C# for 7+ years.
Again thanks for you effort.
Click to expand...
Click to collapse
Thank you very much for your tests. I need that! There are lots of Androids around the world and make something secure for everyone will be a journey.
All the best,
Joubert
Notices
I almost finished writing the commands that existed in RemoteTracker for Windows Mobile (at least the ones Android can execute).
But I'm still trying to make the security of RemoteTracker to be more robust. I had Features in Windows I can't write for Android yet:
- Prompt for password when uninstalling;
- Lock / Unlock the unit with the LOCK / UNLOCK commands;
I'm not able to use the camera without the need to provide a preview to the user. According to the source code of Android that is impossible, but I saw some programs doing that, so there is a way to do that and I'm looking for this information.
If anyone knows how please help me
All the best,
Joubert
Answers to the questions
Hi Joubert,
Sorry for being silent for so long.
joubertvasc said:
Are you sending the command using another phone, the same phone or using some WEB service (like your carrier website)? There is no code to change '@' to '?'.
Click to expand...
Click to collapse
I am using Web service of my sim provider to send SMS. Didn't have a chance to try with sending SMS from the phone.
joubertvasc said:
Thank you very much for your tests. I need that! There are lots of Androids around the world and make something secure for everyone will be a journey.
Click to expand...
Click to collapse
Yes, you are right.
As to the log file I will send it to you shortly.
Thank you. I'll wait for your log to see details. You can send it directly to my e-mail.
All the best,
Joubert
Hide Remote Tracker Application
Hi Joubertvasc:
Are you planing to make a feature to hide the Remote Tracker from the drawer and from any place of the phone. Like with the Theft Aware; you can access the application by dialing from the Phone Dialer. You enter your four code number then hit call. This will open the apllication without calling the number.
Regards;
Willie
Sounds good. I will take a look about how to do that.
Thank you.
Hi!
After a long time I'm back with a new version. This one has lots of bug fixes:
http://remotetracker.sourceforge.net/RemoteTracker.apk
My problem now is Android 3.1 and later, because they don't intercept messages all the time. They need human access the configuration module once to work. Security issue Google said... I'm trying to find an exit.
Best regards,
Joubert
G'day mate.
Long time no see. Great work on this app so far.
I've finally gotten around to installing it and play around with it a little.
I'm testing this on HTC One X with Revolution HD ROM
Here are a few ideas and tips for you to incorporate into your next version.
1. Include an option that allows users to set how many replies to get back from your software.
For Example. If I were to use #RT#GPS#1234, it currently only sends 1 reply. The problem with this is that most GPS units are accurate withing 5 - 10 meters. I tested it on myself where I am and it picks me up as being 2 houses down. If there was an option to send me 3 replies, in 60 second intervals, at least I would get the average GPS location of the phone. If your phone is stolen, it would also be a good idea to have unlimited SMS replies with 60 second intervals so I can get real time minute by minute location on where my phone is. Maybe this might be an idea for your Pro version. Have the option for how many replies to get and also an option for interval time between each reply.
2. Another idea for Pro version. Hide the RemoteTracker Icon from the Apps menu, or disguise it as a useless setting so if a thief were to look in the Apps menu, they wouldn't see it straight away, so wouldn't be forced to reset the ROM. Most thieves aren't smart enough to reset the phone as soon as they steal it, They normally wait till they get home..... but if he saw a tracking program, it would make them either turn the phone off right away, or reset the ROM right away.
3. I dont know much about Android programming, but an idea for capturing the Camera is to embed the photo into an MMS, or as an attachment in an email. Trying to muck around with FTP would be a waste of time because the average user wont have an FTP server, and you dont want to set up a central one because it would give every noob hacker a target to try and get into.
I will keep playing around and get back to you with any other problems or ideas for you.
Keep up the great work.
Loved the software on WinMo and looks like the Android version will be just as great.
I want to download a FREE application (Orange Cineday & Orange et Moi) in section "Orange" ... but i can't show it !
Have you a soluce to do please ... or just give me a soluce to have the GUID of these apps ?
Thankx,
Poloche,
If your phone is for some reason not showing the carrier marketplace, it may be possible to get it to appear using a XAP similar to the OEM Marketplaces XPs (see my signature). It'll require a little investigation, and the file that specifies MO marketplaces is a slightly than the one for OEM marketplaces, but it's not that complex.
If you'll read through the thread, you'll find enough info to get started yourself.
@GoodDayToDie Can you make XAP for different carriers (similar to the OEM XAP you made so far)? I have 2 Samsung Focus on Tmobile network but couldn't see the carrier marketplace. Thanks!
Also, now that an Omnia W ROM is available, can you look into why Call Blocking is not working on 1st gen Samsung devices? The newest Call Blocking app version is 1.8 from Marketplace.
@nepi: The MO marketplaces typically don't have their own section, but "ought" to load automatically on the phone. If you're on TMO-US, even if the phone wasn't originally TMO-branded, do a search in the Marketplace for "Family Room" or "T-Mobile TV". If they don't show up, then you can't access the TMO-US marketplace. I guess I can make a XAP for that one easily enough (it's my carrier, so I just pull the the relevant file off my phone, package it into a XAP, and post it). Honestly though, the only TMO-US app that I've found worth having at all is My Account, and that rarely (and it wouldn't be useful to anybody not on TMO).
Call Blocking (and the other gen2-specific Samsung apps) can't be used on gen1 phones pretty much by design. Samsung changed the drivers in their firmware that apps (both official and homebrew) with ID_CAP_INTEROPSERVICES use to do things outside their sandbox (call blocking is definitley not allowed from within the sandbox!). Some (but not all) of the gen1 apps are compatible with a backward-compatiblity interface in the gen2 firmware, but the gen2 apps are never going to be compatible with gen1 until/unless those new drivers are back-ported. That's not something we can do (at least, not until the Samsung bootloader is unlocked) ourselves, because the drivers are baked into the ROM, and nobody has yet figured out how to make a driver that's not in the ROM work.
I have a few theories, but it'll be some time before I can do anything with them. They're related to my current project, which is executing native homebrew EXEs on WP7 (specifically, I'm currently looking at modifying the Policy system to allow this). It may be that the Policy system is also behind the driver issue, but until I manage to modify the policies, that's a moot point.
poloche said:
I want to download a FREE application (Orange Cineday & Orange et Moi) in section "Orange" ... but i can't show it !
Have you a soluce to do please ... or just give me a soluce to have the GUID of these apps ?
Click to expand...
Click to collapse
- Install WireShark traffic sniffer
- "Reverse tether" your phone to PC (connect via USB cable)
- Start WireShark to listen http traffic
- Install these apps on your phone
Post whole request data here and I'll answer your question
I want to download "Orange Cineday" specific ORANGE Marketplace... Can you please give me the GUID ?
@GoodDayToDie
Please, explain me the registry key to show the "Orange Section" in my phone ? ... I have an interOP-Unlock Omia 7
Please read the OEM Marketplace XAPs thread (linked in my sig). The file that needs to be replaced is different from the one those XAPs replace (OEM market, you need the MO market) but it's stored in the same location and the structure of the file is similar.
I don't know what the identifier for ORANGE is, although "ORANGE" would be a decent thing to try! This is a pretty basic hack, requiring mostly just some time to experiment; give it a shot yourself. I prefer to use 7-Zip for modifying the XAP files, as it handles the path traversal nicely.
@GoodDayToDie: I'm in Seatte, too. The first day when I carrier unlocked my Focus and put in T-mobile SIM I saw the T-mobile My Account app on the Marketplace. However, after I reset the phone it's no longer there and I can't find it again. Can you post the appID for My Account app here? I want that app to check account status, etc.
Also, here is the app ID for Call Blocking version 1.8 from marketplace. I can't post direct link because of my poor post count. I just post this incase anyone wants to download it but can't find it in the marketplace. (I can see the app when the link is opened in my Focus but no option to install it "Not compatible with your phone..etc...")
Call Blocking version 1.8: appID=e23ef9a7-e785-4fc6-ab6c-500034b5226d
So you want to run your own server, eh? Whether you want to free yourself from data mining, commercialising, monetising, greedy be-tied-and-suited media moguls or from the spiritual successors of J. Edgar Hoover and Yuri Andropov does not matter. You want your data to be just that, *your* data. While this might seem extreme to some the idea is actually not far fetched, nor is it impossible to realise. After all, the 'net and the web were conceived as a decentralised network of services. This model, while good in allowing diversity and freedom, is less than ideal from a profitability standpoint so you should not expect those who stand to profit from hoarding your data to lend a helping hand here You're on your own here.
Well, not really on your own of course as there is a metric ton of information on this subject to be found on the 'net. Everything from how to turn that old laptop into a server through using single-board computers as servers through re-purposing whatever you happened to find dumpster-diving. Suffice to say that you need hardware, software and a network connection. A separate router, preferably one under your own control, running known software (OpenWRT, DD-WRT, Tomato, etc) on stable and not to anemic hardware so it can be used to run a VPN to your phone. You'll want your own domain name as well, either one from the free services which are (still) around or something more 'personal'.
Network connection and domain
Here you often don't have that much choice. If possible, choose a wired connection over a wireless one, both for the higher reliability as well as the usually more acceptable use policies and the fact that wireless connections often change IP address. Choose a connection without a traffic cap over one which has one. Choose the connection with the highest upload rate, even if this means settling on a lower download rate - servers send traffic up the net after all.
There are many ways to get a domain name. You can buy one, of course. For a personal server this might be overkill, but the choice is yours. One advantage of having your own domain is that it enables you to keep your mail/jabber/web/whatever addresses no matter what happens (as long as you pay the registrar, of course). You're totally free here as you can simply point your domain elsewhere if you happen to move to another ISP (and/or country...). Cheaper - as in 'free' - is to use one of the many free dynamic DNS services. As long as you have an address to feed your phone and other devices which will make use of your server you're fine.
Router
Best here is to use a router which is fully under your own control. While some ISP routers might be marginally usable, these devices are often at the whim of the ISP as they can be remotely controlled and configured. This is not what you want for your network, so just use the thing in bridge mode if possible, otherwise forward all traffic to your own router. With one of the free and open router firmwares on a reliable device you can do interesting things, ranging from port knocking on the router to VPN tunnels to your mobile devices.
Hardware, storage
Power consumption. heat- and noise production are of more importance than raw power here. There should be enough memory to keep the thing from paging (or 'swapping') on the intended work load on the chosen OS. The same goes for storage: If it fits in the box, fine. If it does not (external drives on laptops, Raspberries, etc) make sure the whole contraption is stable so you don't get any sudden 'disconnects'. For a personal server, power consumption, noise and heat production (which directly relates to reliability) are - again - more important than raw performance.
OS
Any 'unix' of choice is fine here. Linux, *BSD, doesn't matter. Even MacOS would do. Windows, not so much. It is not impossible to use Windows but it is more of a hassle given that a lot of the software is tailored to a unix environment. If you really insist on running Windows, at least make sure it is patched up to the hilt and that all - and that means all - unnecessary services have been switched off.
Software
This is the interesting bit, and the reason why this message is here in the first place. On one of the forum threads here someone was surprised by the fact that I don't run any of the Google apps on my devices, wondering how I got by without Google Play, GMail, contacts and calendar sync etc. Part of the answer to that question involves running your own server, part is covered by using alternatives for the Google-provided apps and services. I would have put this all in a table but it seems this silly forum does not support those...
Commercial service: Alternative (Remarks)
Google Play: F-Droid (The F-Droid store only contains free software. It does not provide a full alternative to the Play Store. If you really want to run the Play Store but still have a notion of privacy on your device, consider enabling Google Services only when required, disabling them afterwards. You can also designate one device as the one which gets to run the Play Store and side-load apps from this device to all others. Theoretically this should be possible using an emulator on your server as well, automating the whole process and creating a 'playstore by proxy'. I have not tried this.)
GMail: IMAP to your own server, eg the Debian standard dovecot daemon. K9 or the standard Android email client on your device.
Contacts: CardDav to your own server (service is provided by ownCloud, amongst others), DAVdroid on your phone or tablet.
Calendar: CalDav to your own server (service is provided by ownCloud, amongst others), DAVdroid on your phone or tablet.
Cloud storage (Dropbox, Google Drive, etc): WebDav to your own server (service is provided by ownCloud, amongst others), one of the many webdav clients on your phone. There is a specific ownCloud app as well.
Photo sharing (Flickr, Smugmug, etc): Trovebox to your own server, Trovebox app on phone
Streaming service (Spotify, Google Music, etc): subsonic on your own server, dSub or Subsonic app on phone (there is a rudimentary streaming service in ownCloud as well, based on Ampache)
More will follow...
If you get in the game on time you might be able to join the Reset the Net initiative!
Reserved #2
This position is reserved for a more thorough list of services
Reserved #3
This position is reserved for a more thorough list of services
YetAnotherForumUser said:
Commercial service: Alternative (Remarks)
Google Play: F-Droid (The F-Droid store only contains free software. It does not provide a full alternative to the Play Store. If you really want to run the Play Store but still have a notion of privacy on your device, consider enabling Google Services only when required, disabling them afterwards. You can also designate one device as the one which gets to run the Play Store and side-load apps from this device to all others. Theoretically this should be possible using an emulator on your server as well, automating the whole process and creating a 'playstore by proxy'. I have not tried this.)
GMail: IMAP to your own server, eg the Debian standard dovecot daemon. K9 or the standard Android email client on your device.
Contacts: CardDav to your own server (service is provided by ownCloud, amongst others), DAVdroid on your phone or tablet.
Calendar: CalDav to your own server (service is provided by ownCloud, amongst others), DAVdroid on your phone or tablet.
Cloud storage (Dropbox, Google Drive, etc): WebDav to your own server (service is provided by ownCloud, amongst others), one of the many webdav clients on your phone. There is a specific ownCloud app as well.
Photo sharing (Flickr, Smugmug, etc): Trovebox to your own server, Trovebox app on phone
Streaming service (Spotify, Google Music, etc): subsonic on your own server, dSub or Subsonic app on phone (there is a rudimentary streaming service in ownCloud as well, based on Ampache)
More will follow...
More later, no time now,
Click to expand...
Click to collapse
This is an interesting topic mainly because android has the potential to become non dependant of google services and I would be nice to keep personal data really personal.
Also there is a No Gapps project here in xda that is quite interesting.
YetAnotherForumUser said:
Router
Best here is to use a router which is fully under your own control. While some ISP routers might be marginally usable, these devices are often at the whim of the ISP as they can be remotely controlled and configured. This is not what you want for your network, so just use the thing in bridge mode if possible, otherwise forward all traffic to your own router. With one of the free and open router firmwares on a reliable device you can do interesting things, ranging from port knocking on the router to VPN tunnels to your mobile devices.
Click to expand...
Click to collapse
This reminded me of something that happened in my dad's office recently:
http://arstechnica.com/civis/viewtopic.php?f=10&t=1209257
The ISP guys configured it that way because dad wanted to run a webserver on one system, the one directly connected to the modem on bridged mode. They apparently didn't think it was necessary to also add a router betweenthe modem and the network of computers :/
Lessons:
1. Don't trust anything the ISP guys do
2. Always us a standalone router or firewall
3. Don't use XP. Seriously.
TJKV said:
This reminded me of something that happened in my dad's office recently:
http://arstechnica.com/civis/viewtopic.php?f=10&t=1209257
The ISP guys configured it that way because dad wanted to run a webserver on one system, the one directly connected to the modem on bridged mode. They apparently didn't think it was necessary to also add a router betweenthe modem and the network of computers :/
Lessons:
1. Don't trust anything the ISP guys do
2. Always us a standalone router or firewall
3. Don't use XP. Seriously.
Click to expand...
Click to collapse
I can recommend something like this. They come with web-face, but you need have atleast base knowledge of how network things work.
slph said:
I can recommend something like this. They come with web-face, but you need have atleast base knowledge of how network things work.
Click to expand...
Click to collapse
Nah when I realised what the ISP guys had done I bought a D-Link 2750U and set it up properly in NAT mode
Wifi also works now since it isn't bridged to a computer anymore
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).