Hi All,
I've produced a web form for one of my clients. This is a simple fill in the details and press 'submit' type of affair written in PHP, but is a HTM document hosted on our server.
This works fine on my Touch, but the 'submit' button does not work on the clients Orange m3100. I know that the m3100 is WM5 and the Touch is WM6 but i never knew PIE was different.
Is this a security issue with PIE or do I need to update it? If so, how do I do this without changing the ROM?
BTW my client is miles away, so I can't get my hands on the handset.
Help?!
Steve
Surely it can't be the broswer as PHP is a server-side script??
When you say "Is an HTML file" - is it actually a .html ? Maybe it would work if the file was .php ? I still wouldn't have thought it though, surely the web server should parse the HTML file for any server side script first though?
gumballsteve said:
Hi All,
This works fine on my Touch, but the 'submit' button does not work on the clients Orange m3100.
Click to expand...
Click to collapse
In what way doesn't it work? The outgoing HTTP request to the server isn't happening (probably caused by unhandled HTML/javascript in PIE)? Or an unexpected/no response (probably caused by a broken PHP script)?
How about posting the relevant section of the generated HTML that PIE sees in this thread.
If your button is using javascript, rather than a plain FORM submit button, that could cause problems, as different versions of PIE have varying levels of javascript support.
arghness said:
In what way doesn't it work? The outgoing HTTP request to the server isn't happening (probably caused by unhandled HTML/javascript in PIE)? Or an unexpected/no response (probably caused by a broken PHP script)?
How about posting the relevant section of the generated HTML that PIE sees in this thread.
If your button is using javascript, rather than a plain FORM submit button, that could cause problems, as different versions of PIE have varying levels of javascript support.
Click to expand...
Click to collapse
Yes, the form uses javascript to submit and make sure certain feilds are completed.
Can I update the PIE to a newer version or add the extra support?
gumballsteve said:
Hi All,
I've produced a web form for one of my clients. This is a simple fill in the details and press 'submit' type of affair written in PHP, but is a HTM document hosted on our server.
This works fine on my Touch, but the 'submit' button does not work on the clients Orange m3100. I know that the m3100 is WM5 and the Touch is WM6 but i never knew PIE was different.
Click to expand...
Click to collapse
PIE in WM6 is supposed to have better JS support.
gumballsteve said:
Can I update the PIE to a newer version or add the extra support?
Click to expand...
Click to collapse
Nope, only by flashing to WM6.
Get a browser with better scripting support - Opera Mobile, for example.
Menneisyys said:
Nope, only by flashing to WM6.
Get a browser with better scripting support - Opera Mobile, for example.
Click to expand...
Click to collapse
I'm not much good with this mobile ROM stuff, but is it possible to remove the PIE part from a WM6 ROM and make it into a CAB file that would update a earlier device?
gumballsteve said:
Hi All,
I've produced a web form for one of my clients. This is a simple fill in the details and press 'submit' type of affair written in PHP, but is a HTM document hosted on our server.
This works fine on my Touch, but the 'submit' button does not work on the clients Orange m3100. I know that the m3100 is WM5 and the Touch is WM6 but i never knew PIE was different.
Is this a security issue with PIE or do I need to update it? If so, how do I do this without changing the ROM?
BTW my client is miles away, so I can't get my hands on the handset.
Help?!
Steve
Click to expand...
Click to collapse
IMHO,
It is perhaps fine, to request the customer to upgrade his/her mobile-device/browser to support your php/client-side-javascript document.
But my suggestion is to provide an alternative document, without any javascript, that does all validation on the server-side instead.
Well, an expensive solution will be air-delivering your most compatible mobile-device onto the customer's hand.
~My 2 cents~
mangokun said:
IMHO,
..
But my suggestion is to provide an alternative document, without any javascript, that does all validation on the server-side instead.
..
~My 2 cents~
Click to expand...
Click to collapse
I'm with mango' on this, as you will get better functionality by doing validation server-side, plus anyone who knows about htmlview.dll will tell you that it's not the most forward/backward compatible library that MS have ever written (wm6 htmlview.dll has had several html tag attribute changes/removals).
Other than checking the actual html you're outputting for "wellformedness", you could investigate using the PHP to deliver different html depending upon the version of WM that is calling the PHP. Remember if you do, wm6 shows up as version 5, subversion 2 - and not version 6, subversion x.
So much for MS marketing picking the name Windows Mobile 5 because it bound it together with the CE version.
Dsc.
Do any one has found a way to get the froyo (spell check for second language feature ?)
Or a way to change the spell checking from whatever language is in settings without having to go settings --> input --> spell check --> navigate trough list of languages ?
I tough of adding 140k french words and 100k Spanish words to the custom dict using UDM app but didn't work... the spell checker insist in using its own dict and ignore my custom.
This problem is magnified with the use of the bloody dock keyboard which was the single reason i bought the TF700 (which is on ebay for sale ATM)
I remember the times when Linux meant freedom and flexibility... JB is an Ugly unfinished IOs rip off (and that's in a good day)
Nazeroth said:
Do any one has found a way to get the froyo (spell check for second language feature ?)
Or a way to change the spell checking from whatever language is in settings without having to go settings --> input --> spell check --> navigate trough list of languages ?
I tough of adding 140k french words and 100k Spanish words to the custom dict using UDM app but didn't work... the spell checker insist in using its own dict and ignore my custom.
This problem is magnified with the use of the bloody dock keyboard which was the single reason i bought the TF700 (which is on ebay for sale ATM)
I remember the times when Linux meant freedom and flexibility... JB is an Ugly unfinished IOs rip off (and that's in a good day)
Click to expand...
Click to collapse
The problem your encountering is not a "JB" issue. Rather, it is the fact that the TF700 (and ASUS in general) uses a proprietary subsystem called XT9 (produced by a company called 'Nuance'). For this reason, we cannot create new keyboard layouts nor add more languages. I've been investigating this in my spare time and, though there are some hacks you can do for some modified functionality, the extent you are wanting requires information that is just not available.
Hope this at least gives you a better idea of what the problem is.
Alien, thanks for your reply,
Maybe some of my problems come from the TF but the second language spell check is a feature last since ICS, that was the reason I sold my SG3 after three days.
I use a qwerty layout on all my hardware and my Desire HD2 for example is set to English and second language French.
I still miss spanish but it being my mother language i tend not make many mistakes on it.
There is a Bug report for Android about it http://code.google.com/p/android/issues/detail?id=22707
The problem is that they split the system Spell checker and now we realy a lot on the keyboard used and its suggestions, evidently that magnifies the problem on a Docked Asus TF but it is general to Android.
I think sadly that this is going the wrong way, like the bar not being hidable, or the gmail app not allowing to remove the conversation view... Google is trying to force on users theyir way of what is better for you just as Apple does.
even more Sadly Ubuntu and Unity are taking the same path. (I.E Unity top bar cant be hidden, at least they had the tought of putting it on top, as on android every time i try the OSK on the asus instead of space i hit the bar andallmywordslooklikethis)).
Nazeroth said:
Alien, thanks for your reply,
Maybe some of my problems come from the TF but the second language spell check is a feature last since ICS, that was the reason I sold my SG3 after three days.
I use a qwerty layout on all my hardware and my Desire HD2 for example is set to English and second language French.
I still miss spanish but it being my mother language i tend not make many mistakes on it.
There is a Bug report for Android about it http://code.google.com/p/android/issues/detail?id=22707
The problem is that they split the system Spell checker and now we realy a lot on the keyboard used and its suggestions, evidently that magnifies the problem on a Docked Asus TF but it is general to Android.
I think sadly that this is going the wrong way, like the bar not being hidable, or the gmail app not allowing to remove the conversation view... Google is trying to force on users theyir way of what is better for you just as Apple does.
even more Sadly Ubuntu and Unity are taking the same path. (I.E Unity top bar cant be hidden, at least they had the tought of putting it on top, as on android every time i try the OSK on the asus instead of space i hit the bar andallmywordslooklikethis)).
Click to expand...
Click to collapse
I understand your meaning as I am multilingual myself and Android isn't as versatile as I would like. I'm merely saying that everything that is entered via the dock on your TF700 is handled by the subsystem and not by Android directly. Anything that is entered via "ASUS Keyboard" is available for spell-check in the keyboard language that is selected. Just try opening SuperNote and typing in something like "Eu sou um americano Je suis un américain Yo soy un americano Ich bin eine Amerikaner" then setup your ASUS Keyboard for French, Spanish, Portuguese, and German. While in Supernote, press Left-Control+Left-Shift to bring up the keyboard list, and select a different language. When you change the contents (like add a space at the end) you can see it reparse everything and highlight words that are not known in the selected keyboard language. It's not 100% perfect but it should at least give you a bit of flexibility.
Edit: For clarification, no I don't speak/write in French, German, or Spanish. They were just thrown in for elaborating the test.
Thanks Alien, didn't knew about the CTRL ALT thing, however I did the rational thing... Sold the Asus and got an Ipad after all i only need to do note taking on the go, boor reader and emails and sadly the bloody ipad handles those very well...
BTW: I had removed Super notes after it crashed on me and made me loose a lot of text i had entered, i was using another note app free from the market that did less but did well.
I dont know if im getting older or what but my frustration trying to get the most of my screen while reading books and coherent margins and stuff while my wife laugthed at me reading the same book from her ipad got to me.
Now trying to jailbreak the thing so i can brick it lol...
PS: With a BT apple KB, command space swaps the language im writing in seamless like with the on screen keyboard and the spell check works, thou auto caps not...
Dear devs,
The stock keyboard says it supports Vietnamese, but the encoding method is strange to Vietnamese users, and we can't use it and thus a third party keyboard is needed.
Would any developers be kind enough to merge telex encoding method to the keyboard? It would be great help.
I found this on github but it reads alien to mere mortals like I am.
https://github.com/typester/emacs/blob/master/lisp/language/vietnamese.el
Please help.
Sent from my Nexus 4
nqk said:
Dear devs,
The stock keyboard says it supports Vietnamese, but the encoding method is strange to Vietnamese users, and we can't use it and thus a third party keyboard is needed.
Would any developers be kind enough to merge telex encoding method to the keyboard? It would be great help.
I found this on github but it reads alien to mere mortals like I am.
https://github.com/typester/emacs/blob/master/lisp/language/vietnamese.el
Please help.
Sent from my Nexus 4
Click to expand...
Click to collapse
Unfortunately there's really nothing we can do here, unless there is someone who does understand what this encoding issue is, and knows what it should look like, and how to do that.
That links is for emacs, but really this looks like an entire new characterset, which means we'd need someone who understands this characterset, and can write the initial code for the feature.
pulser_g2 said:
Unfortunately there's really nothing we can do here, unless there is someone who does understand what this encoding issue is, and knows what it should look like, and how to do that.
That links is for emacs, but really this looks like an entire new characterset, which means we'd need someone who understands this characterset, and can write the initial code for the feature.
Click to expand...
Click to collapse
Thank you for your concern.
I understand that this issue should have been fixed by a Vietnamese developer. What a shame that I don't have their contacts.
However, I think if I had said "input method", it would have explained the situation better. I don't think there is a need for a new charset, it's still unicode, the same thing that is used by Android (Roboto font family supports it quite well).
================
I don't know how difficult it may be, but let me explain how it should works when inputting Vietnamese using Telex (we call it) method.
Vietnamese char table include these characters (in addition to English alphabets): â, ă, ê, ô, ơ, ư, and they are combined with accent charracters: ´ (acute), ` (grave), ˜ (tilde), ̉ (hook above), and ̣ (dot below)
Normally, we use the English keyboard, which contains no such characters, so we type:
aa ==> â, aw ==> ă, ee ==> ê, oo ==> ô, ow ==> ơ, uw ==> ư ( or [ ==> ơ, ] ==> ư ), uo ==> ươ
To combine vowels with accents we use s ==> accute, f ==> grave, x ==> tilde, r ==> hook above, and j ==> dot below
==============
Examples:
tooi ==> tôi
toois ==> tối
thor ==> thỏ
hoaf ==> hòa
=================
I know this may be impossible for non-Vietnamese developer, but I still hope for a solution.
=============
This is anothe link to a linux Vietnamese keyboard, which is OpenSource. It is in fact the most popular keyboard software in Vietnam.
http://unikey.org/source.php
http://sourceforge.net/projects/uni...unikey-1.0.4.tar.bz2/download?use_mirror=nchc
An opensource Android keyboard app would be MUCH more useful as a reference.
Otherwise I'm not sure if there's much chance of this getting done properly without a Vietnamese developer who can properly test things as they work.
(similar to why EAP-SIM support still isn't in any custom firmware - only a small subset of developers can even work on EAP-SIM since only a few carriers support it.)
Entropy512 said:
An opensource Android keyboard app would be MUCH more useful as a reference.
Otherwise I'm not sure if there's much chance of this getting done properly without a Vietnamese developer who can properly test things as they work.
(similar to why EAP-SIM support still isn't in any custom firmware - only a small subset of developers can even work on EAP-SIM since only a few carriers support it.)
Click to expand...
Click to collapse
Dear @Entropy512,
I found this https://github.com/AgeOfMobile/Vietnamese-LatinIME
Is it good (enough)?
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).
Hello!
I'm new to this forum as you can see and also dont know much about IT, except that I installed Lineage since years on my phone.
Now my Aquaris X is gone and I need a new phone and I heard that the Xiaomi Redmi product line would be quite good regarding Lineage usage and pricing.
Now when following the news there are permanent new evidence that China phones are loaded with Trojans by default and even if this is not confirmed for a company already it just makes sense that any chinese developer might have all of these inside ...
So my question is:
By replacing a stock ROM with LineageOS will I also get rid of all possible trojans inside of a Chinese Phone or might they be still existing afterwards?
THXXX
Good question. But I think manufacturers can put anything they want into their hardware, so it probably depends.
Btw, why do you "follow" the news? Can't you form your own opinions? You know who owns the news? It's a centralized source and not as individual and separate as they want to appear with their different outlets.
Speaking of built in trojans and "hacking your human OS": you can change a line of code, just like in Xposed. But not with Android phones but humans. Of course it needs a great excuse to install xposed into every human, but that's what the media of the owners is there for. (that's a more persistant trojan.) Watch first 2 minutes of this if you don't understand
Well so it means it cannot be said for sure?
Yeah I know these arguments with media control. But why complain about someone who is afraid of a company from a country which is everything but a democracy? There is no multiple ways of interpreting the policy of China which is the exact opposite of anything where I would like to live. Any reasonable criticism is illegal and results in a ban for marriage or transportation or leaving the country. Any company is intruded by the government and therefore it just makes sense to me that they take any opportunity to use this power that they have over the economy to use it for their own advantage.
So I am living in a quite liberal country in Europe and I dont get arrested for anything I say against my government. Thats quite cool even if I dont use that privilege quite often.
Also I ****ing hate what they do against these Uigur people in Xingiang, sterilizing them against their will or keeping them in prisons just for their religion.
Same as taking the freedom of an athlete who speaks out justice against some high-ranked scum from the government.
Thats just a few examples, but because of this and many other stories I dont really trust these chinese companies. I have Xposed (edit: and Xprivacy Lua) on my Aquaris X but by making this thread I want to understand if it will also protect me against the Chinese Trojans just confirmed by the Lithuanian cyber security etc.
In contrast to so-called Western states China is a central state with 33 administrative units ( without Taiwan ), his political system is a one-party socialist-authoritarian one. You may not like it, but that's the way it is.
I don't think XDA is the right place to discuss whether this suits a user here or not.
BTW: We all know that even in Western states, ethnic minorities are unpopular, persecuted and sometimes exterminated.
*BTW: We all know that even in Western states, ethnic minorities are unpopular, persecuted and sometimes exterminated.*
True but nobody beats the situation in Xingiang (alone writing this word would put me on a blacklist living there) and their suppression of free speech.
*I don't think XDA is the right place to discuss whether this suits a user here or not.*
Ok yo understand, but I just want to know whether replacing a ROM would also eradicate any built-in trojans, thats just a 100 % technical question and I have nothing to do with coding and stuff so I hope to get an answer here, but so far it's not clear.
Does it mean as long as you are not the manufacturer you will never know and hence probably still have any trojans after replacing?
AFAIK Trojans never are part of any pre-installed Android based OS, but exclusively imported to Android OS by user of Android device. That's also TRUE for phones manufactured in China.
BTW: It's easy to find any Trojan on an Android device.
So you mean real Trojans only come on board by wrong user behaviour and cant be part of the system already?
That would be of course good and I have no idea about all of this stuff, it's just that it sounds like many Chinese Phones spy on their user with some default built-in *trojan* - maybe you may call it differently.
Here was a mention of many chinese phones with built in Trojans:
Android: Über 40 China-Smartphones mit Malware ab Werk
Bei über 40 chinesischen Smartphones haben Experten einen vorinstallierten Trojaner gefunden. Welche Geräte betroffen sind, erfahren Sie hier!
www.computerbild.de
Still it is not with Xiaomi ;P
But our German department for Cyber Security (BSI) told that there would be indeed some *additional functions* also in Xiaomi which also pose security / spy issues:
Chinesische Smartphones: Behörde warnt vor Sicherheitslücken
Die Nationale Cybersicherheitsbehörde in Litauen warnt davor, chinesische Smartphones zu kaufen. In zwei Modellen fanden sich eklatante Sicherheitslücken.
www.basicthinking.de
Xiaomi-Smartphones spionieren Nutzer aus: So können Sie sich schützen
Schwere Vorwürfe gegen Xiaomi: Der Hersteller soll das Verhalten von Nutzern aufzeichnen und an eigene Server zur Auswertung weiterleiten. Insbesondere die Internet-Nutzung der User soll genauestens dokumentiert werden.
www.chip.de
But in the first link on top they say:
"Die einzigen Mittel im Kampf gegen den Trojaner sind die Installation einer „sauberen“ Android-Firmware oder ..."
Which means they say installing a clean Firmware would at least resolve the issue in situation 1. So is Firmware = ROM? So installing LineageOS would then remove these spyware at least in the first link example?
Here I found another example:
How to find and remove malware from some chinese smartphones?
I am planning to buy a chinese smartphone. However, I've read that some come with extensive spyware straight from the factory. Will I be able to detect such malware (Android.Trojan.Uupay.D and the...
android.stackexchange.com
*If you want to be 100% sure that the device is clean, then you must remove the OS that came with it and flash a trusted(opensource) ROM like official CyanogenMod*
So IF the Trojans are only inside of the pre-installed Apps, then I should completely remove them by flashing LineageOS?
My understanding of a Trojan is it's a door-opener for malicious softwares packed in an Android app, it in generally does the following:
Download and install other malware, such as Viruses or Worms.
Use the infected device for click fraud.
Record keystrokes and websites visited.
Send information about the infected device to a malicious hacker including passwords, login details for websites, and browsing history.
Give a malicious hacker control over the infected device.
But I may err, as always ...
Reflashing a ROM OEM-pre-installed by a Custom ROM IMHO is an overkill: simply remove Trojans found.
Spassd said:
Hello!
I'm new to this forum as you can see and also dont know much about IT, except that I installed Lineage since years on my phone.
Now my Aquaris X is gone and I need a new phone and I heard that the Xiaomi Redmi product line would be quite good regarding Lineage usage and pricing.
Now when following the news there are permanent new evidence that China phones are loaded with Trojans by default and even if this is not confirmed for a company already it just makes sense that any chinese developer might have all of these inside ...
So my question is:
By replacing a stock ROM with LineageOS will I also get rid of all possible trojans inside of a Chinese Phone or might they be still existing afterwards?
THXXX
Click to expand...
Click to collapse
If you install a custom ROM, your stock operating system(along with any potential trojans that were included in your stock operating system) will be replaced by the custom operating system.
I now bought a Sony Xperia XZ2 Compact for really cheap ... less than 200 € so I guess its fine now.
But when unlocking the Bootloader I get problems.
The Device is listed in *Fastboot Devices* so everything is working correctly, but when I do the unlock command
fastboot oem unlock 0x [... my code]
I just get
FAILED (remote: 'unknown command')
fastboot: error: Command failed
Now I tried the *Sony Flashtool* like in this video:
He has a Button called BLU and just enters IMEI and Unlock Code to unlock the Bootloader. But I dont have this button WTF ?? Just the Flash Icon Button and then the Lock Icon Button.
So any ideas what to do?
THXXX