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).
Related
I'm planning to build an app which has a client and a service part. but i have no plan how i should realize the communication. (should be as standardconform as possible).
I looked a bit around and found for now two ways, where each one has pros and contras.
kSOAP
Pro:
Standardconform
Servicedescription
Class Generation
Contra:
External Library
Slow
JSON
Pro:
Lightweight and fast
Buildin Library
Works in combination with a MVC (symfony)
Contra:
No Standard
No Servicedescription
No Class Generation
Kind regards
Ghost
I would use JSON. Most social networks use JSON for communication with apps. Just have a small HTTP server running and send the commands through POST methods and let the server return the JSON objects.
First off, JSON is a open standard, as defined in RFC 4627
Second off, the comparsion doesn't really hold imo, (k)SOAP is a structured information exchange protocol, JSON is merely a data serializer, like YAML. What they try to accomplish are to very different things. As for the added code that you'd have to write, unlike class generation handling JSON/YAML messages can be done very easily in one factory design-pattern setup. Hand the factory a message, it produces an instance of a specific class, if your messages are properly abstracted, this shouldn't be hard.
with JSON i meant to build such an information exchange around JSON. but this would be something selfmade and not a standard. while the information exchange with soap is a standard and each programmer would be able to build easily without much docu an client for that service. after i want to release that software under the gpl and plan the service as something open like jabber, it would make sense to design the data exchange between service and client as easy as possible.
GhostOfTheNet said:
with JSON i meant to build such an information exchange around JSON. but this would be something selfmade and not a standard. while the information exchange with soap is a standard and each programmer would be able to build easily without much docu an client for that service. after i want to release that software under the gpl and plan the service as something open like jabber, it would make sense to design the data exchange between service and client as easy as possible.
Click to expand...
Click to collapse
Go with JSON. Just describe your API / exchanged JSON-Objects and every programmer would be fine with that.
so it seems, that noone thinks that soap is a googd thing... so i'll use json, thanks
if soap is too heavy, try xml-rpc, its like a simple version of soap
Is it already implemented in the android libs? Or is there somewhere an androitd lib for that out?
Regards
Sent from my HTC Desire using XDA App
GhostOfTheNet said:
Is it already implemented in the android libs? Or is there somewhere an androitd lib for that out?
Regards
Sent from my HTC Desire using XDA App
Click to expand...
Click to collapse
No, but the xml-rpc protocol is very simple you could easily write a small class to generate the required xml and send it over http
http://en.wikipedia.org/wiki/XML-RPC
Edit:
theres java classes linked to on that wikipedia page, that should work on android
Since I'm not strong in C++, is it possible in a native/hybrid app to use a P/Invoke call to call native APIs from C# code?
So far what I have seen is COM interop where you have to code the bulk of what you want to do in native C++.
Any possibility here and if so how?
No. At least not that we know of. You have to create COM wrappers for native functions.
Various Marshaling APIs, which makes P/Invoke tick, are off-limits.
WP7 apps run under silverlight - the best place to learn about the security model and why p/invoke is not possible is here:
http://msdn.microsoft.com/en-us/library/dd470128(v=vs.95).aspx
As you can see the restriction is quite deep routed in the framework.
It still might be possible to run proper .NET CF executables in the future though if we can get it installed.
pInvoke
I just met a guy today, who successfully published WP7 app, that uses pInvoke - he just filled the Technical Exception form and ... done
It's used for muting system volume when the phone is in range of specified WiFi network (using BG agent) - for example when in range of school Wifi, turn the speaker off.
http://www.windowsphone.com/en-US/apps/6813ea1f-8d71-4ad5-a6d2-f80c193c6ac9
Can anybody confirm this actually works? He haven't tested it, because it won't work in emulator and even not in default developer unlock.
Here's the code he used, disassembled from the app:
http://pastebin.com/PfFm9Wxg
Do you know about any other apps, except apps from OEMs and Microsoft, that use pInvoke?
This gave me an idea, what else could be possible using small use of pInvoke? Maybe even something lot of users are asking for, like battery status on the start screen, who knows?
Thread Moved To WP7 Q&A
This is a development section, not Q&A. Please post in the correct section!
OK, a few things:
P/Invoke not working is *very* well documented. The DllImport attribute *appears* to be available, but calling a function that uses it invariably fails. The work-around for native code access is to use COM. There's also a project to re-implement DllImport.
Native code access has been available to homebrew developers for about a year, now. There are many apps which use it, ranging from web servers to registery browsers to yes, even an app that shows your battery status as a live tile on your Start screen...
These apps are not, however, permitted by Microsoft's Marketplace rules. It may be possible to get an exemption (some Marketplace apps do use native code) but by default, all apps that try to use native APIs (either via COM or P/Invoke) are automatically detected and rejected during analysis of the app prior to its approval.
As for the code you linked, it doesn't even compile (WP7 doesn't include CharSet.None, apparently). If you remove the CharSet directive, or if you set it to CharSet.Auto, it will compile but fails when used. You also didn't include any of the #using directives (OK, without the # in C#). Better would have been to just send us the XAP directly (yes we can get it, but a copy/pasted smidge is a lot less useful)
Downloaded the XAP. It's a paid app, so many tools won't find it.
Examining now. Nothing exotic so far. Possibly P/Invoke only works on signed apps?
The actual message signature that I see:
[PreserveSig]
[DllImport("coredll.dll", CallingConvention = CallingConvention.Winapi, CharSet = CharSet.Ansi, SetLastError = true)]
private static extern int waveOutGetVolume(IntPtr device, out uint volume);
Note that CharSet.Ansi still doesn't seem to exist. That said, this might simply be due to an outdated interop library that shipped with NoDo, and the Mango one does support this? More investigation...
"Possibly P/Invoke only works on signed apps?"
That's the question! If this actually works, it's possible we can get exception for more pInvoke calls and it might be even possible to certify app in marketplace for showing battery status or similar goodies. It won't be possible using that dllImport project, that's more than sure, but if we use only well defined set of safe pInvoke calls, we might get submission exception. It's definitely worth finding it out, what's possible here
Listen to live FM broadcasts on devices that don't have a built-in FM radio!
Description
SDR Touch turns your mobile phone or tablet into a cheap and portable software defined radio scanner. Allows you to listen to live on air FM radio stations, weather reports, police, fire department and emergency stations, taxi traffic, airplane communications, audio of analogue TV broadcasts, audio amateurs, digital broadcasts and many more! Depending on the hardware used, its radio frequency coverage could span between 50 MHz and 2.2 GHz. It currently demodulates WFM, AM, NFM, USB, LSB, DSB, CWU and CLW signals.
You can get a compatible USB receiver for under $20 online from eBay. Just plug in your rtl-sdr compatible USB DVB-T tuner into your Android device using a USB OTG Cable and turn on SDR Touch. For list of supported Realtek RTL2832U based dongles, please see the end of the description.
Compatible USB DVB-T tuners
- Generic RTL2832U (e.g. hama nano)
- ezcap USB 2.0 DVB-T/DAB/FM dongle
- Terratec Cinergy T Stick Black (rev 1)
- Terratec NOXON DAB/DAB+ USB dongle (rev 1)
- Terratec Cinergy T Stick RC (Rev.3)
- Terratec T Stick PLUS
- Terratec NOXON DAB/DAB+ USB dongle (rev 2)
- PixelView PV-DT235U(RN)
- Compro Videomate U620F
- Compro Videomate U650F
- Compro Videomate U680F
- Sweex DVB-T USB
- GTek T803
- Lifeview LV5TDeluxe
- MyGica TD312
- PROlectrix DV107669
- Zaapa ZT-MINDVBZP
- Twintech UT-40
- Dexatek DK DVB-T Dongle (Logilink VG0002A)
- Dexatek DK DVB-T Dongle (MSI DigiVox mini II V3.0)
- Dexatek Technology Ltd. DK 5217 DVB-T Dongle
- MSI DigiVox Micro HD
- Genius TVGo DVB-T03 USB dongle (Ver. B)
- GIGABYTE GT-U7300
- DIKOM USB-DVBT HD
- Peak 102569AGPK
- SVEON STV20 DVB-T USB & FM
Interaction with battery savers
It turns out some manufacturers such as Huawei and Samsung have very aggressive power saving policies and force close background apps without notice. If the system decides to kill the RTL-SDR (or SdrPlay) driver while SDR Touch is running, the app will stop playing and become unresponsive eventually showing a "Disconnected unexpectedly" error message.
If you are experiencing this issue, the only solution that currently exists is to manually whitelist *both* the SDR driver app and SDR Touch in your phone's power saving settings to prevent the operating system from unexpectedly stopping the apps. More information and instructions on how to do this based on your particular phone make and model can be found on this website: dontkillmyapp.com
Feedback
An article about SDR Touch - Android Meets the RTL2832U from HamRadioScience
A user submitted video showing off advanced features of SDR Touch running on a mobile phone:
Any additional feature suggestions, comments or feedback will be much appreciated!
looking good sir looking good
Fantastic work. I am excited to see squelch on the list of improvements. Is there any chance that you will ever support a plugin architecture or P25 decoding? There is a decoder called DSD which can decode P25. Squelch+P25 would make it replace my scanner entirely. I would pay additional $$ for each of these features and it would still be more affordable and interesting than carrying around a scanner.
daniel_reetz said:
Fantastic work. I am excited to see squelch on the list of improvements. Is there any chance that you will ever support a plugin architecture or P25 decoding? There is a decoder called DSD which can decode P25. Squelch+P25 would make it replace my scanner entirely. I would pay additional $$ for each of these features and it would still be more affordable and interesting than carrying around a scanner.
Click to expand...
Click to collapse
Thanks for the support! Squelch is coming soon! I will look into P25 but we might need to work together on this - you may need to provide me some I/Q recorded samples - but I would say this would be a bit later since I just started my second semester and have some studying to do as well
P.S. Squelch is now on top of my TODO list
Although this seems to be a great app, I couldn't make it to work with Xperia Ray... ("no tuner found" error)
Anyone here had success with making it work on a Xperia phone?
martintzvetomirov said:
Thanks for the support! Squelch is coming soon! I will look into P25 but we might need to work together on this - you may need to provide me some I/Q recorded samples - but I would say this would be a bit later since I just started my second semester and have some studying to do as well
P.S. Squelch is now on top of my TODO list
Click to expand...
Click to collapse
Fanastic, thank you. I can't wait for squelch!
I'll supply whatever data/info you need to implement P25. I/Q samples are no problem. I understand completely that your time is limited and there is a larger audience to serve, but if you need resources, please let me know what you need and I'll see how I can help.
My account here is new, so I can't post links, but "DSD" and "radioreference wiki" will get you to the DSD source.
Amazing work! Well worth the $9.99USD pricetag. Gave you a nice review on the Google Market/Play Store as well.
FYI: Works wonderfully on an Acer A500 w/ Android 4.2.1.
SDR Touch has been removed by Google from Google Play! I will investigate the issue and will report back as soon as I have more information!!!
If somebody needs the latest version of SDR Touch, please download it from the attachment. Keep in mind that as soon as SDR Touch goes back to Android market you might need to reinstall it in order to get the latest updates!
Ok, just to make it clear for everybody that is concerned.
SDR Touch DOES NOT violate the GPL license!
SDR Touch is merely a client for - https://github.com/martinmarinov/rtl_tcp_andro-. rtl_tcp_andro is released under GPL2+. SDR Touch and rtl_tcp_andro are separate works in the sense of GPL. They are neither statically or dynamically linked and they are two separate executables that communicate over a TCP connection. rtl_tcp_andro is bundled with SDR Touch merely to help the user and with accordance to point 2. of GPL Terms and Conditions. You can think of SDR Tocuh as an "installer" of rtl_tcp_andro. It just launches rtl_tcp_andro with Runtime.exec("");. Furthermore SDR Touch could happily work without the bundled rtl_tcp_andro in network mode by connecting to a remote computer running either rtl_tcp_andro or the original rtl_tcp.
Therefore GPL is not violated. Saying that GPL is violated would be like saying that you can't listen to online radio with your proprietary music player because the radio is being streamed with a GPL based software.
A quote from GPL-3.0:
A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an "aggregate" if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.
Click to expand...
Click to collapse
Did you read that quote ?
... and which are NOT combined with it such as to form a larger program, in or on a volume of a storage or distribution medium ...
Click to expand...
Click to collapse
A single .APK _is_ a single distribution medium ... and they definitely _ARE_ combined to form a larger program. The "SDR Touch" .APK is the larger program, containing both your own code and the rtl_tcp_andro binary. That clause is meant for when you ship a CDRom with different stuff on it for example where they have no special relation ship. Here the relation ship and dependency is clear (even says so in the damn description of the app)
The problem is not with SDR Touch or the way it's a client for a rtl_tcp version, that's the right way to do it.
The problem is that both are distributed bundled.
SDR Touch and rtl_tcp_andro need to be two separate packages to be installed independently by the user.
There is also the requirement to make a written offer and include the full license terms when distributing rtl_tcp_andro, usual way is to include both the license in the .APK and also accessible to the user in the UI (menu often).
Cheers,
Sylvain
smunaut said:
Did you read that quote ?
Click to expand...
Click to collapse
But rtl_tcp_andro is a separate binary and the apk is just a container like a CD Rom. That's precisely the point. The binary classes of SDR Touch are separate entities in the apk file and are not linked to rtl_tcp_andro!. The GPL allows using an "installer" to install proprietary software as well as GPLed software in one go. The Android apk installer grabs the contents of the archive (which is like a rar archive) and unrars it ("installs") it onto the device. When the user is using the program, the two entities are still different and separate!
The license is linked in the Help section of SDR Touch. The thing that I haven't done is to put the license physically on the apk as well.
But that's a good point,
Thanks,
Martin
martintzvetomirov said:
But rtl_tcp_andro is a separate binary and the apk is just a container like a CD Rom. That's precisely the point. The binary classes of SDR Touch are separate entities in the apk file and are not linked to rtl_tcp_andro!. The GPL allows using an "installer" to install proprietary software as well as GPLed software in one go. The Android apk installer grabs the contents of the archive (which is like a rar archive) and unrars it ("installs") it onto the device. When the user is using the program, the two entities are still different and separate!
Click to expand...
Click to collapse
Mmm, first, I'm not sure the APK is uncompressed on the flash.
But you're missing the point that in this case it's a single "application", no matter what binaries it's composed of. It's not pulled independently (as a dependency or not) and via that "installer" you can't get it independently, it's just a single package, even presented as a single application to the user (aren't they both under the same 'title' in the "Application" tab of android ?)
So really, I don't see how you could consider this as not being a "whole" without, like I said, distribute it as two different packages (which would also allow other "users" to use the rtl_tcp_andro for eg) and give a undeniable separation between the two.
smunaut said:
Mmm, first, I'm not sure the APK is uncompressed on the flash.
But you're missing the point that in this case it's a single "application", no matter what binaries it's composed of. It's not pulled independently (as a dependency or not) and via that "installer" you can't get it independently, it's just a single package, even presented as a single application to the user (aren't they both under the same 'title' in the "Application" tab of android ?)
So really, I don't see how you could consider this as not being a "whole" without, like I said, distribute it as two different packages (which would also allow other "users" to use the rtl_tcp_andro for eg) and give a undeniable separation between the two.
Click to expand...
Click to collapse
Ok, I see your point and this looks like an option. I still can argue that they are separate but in order to prove that, as you say, I might split them into two packages.
Will see how things go, will keep you posted!
Like smunaut said, this definitely counts as a derivative work as they are being presented to the user as one cohesive application via the Play Store.
This is the same problem that SDR# had some time back, where they tried to distribute the GPL RTL-SDR with their proprietary UI. They thought that, since the UI only communicated with RTL-SDR and wasn't technically part of SDR#, they could include it; but that's not the case. (http://dangerousprototypes.com/2012/08/05/confusion-over-sdr-vs-opensdrsharp/)
The solution in this case will be the same as it was for SDR#: Either make the entire application GPL, or break rtl_tcp_andro into a completely separate package. Make sure that the description for the rtl_tcp_andro package clearly states its license, and make sure you link to the GitHub page for it so the source is clearly available. That should cover all the bases.
MS3FGX said:
Like smunaut said, this definitely counts as a derivative work as they are being presented to the user as one cohesive application via the Play Store.
This is the same problem that SDR# had some time back, where they tried to distribute the GPL RTL-SDR with their proprietary UI. They thought that, since the UI only communicated with RTL-SDR and wasn't technically part of SDR#, they could include it; but that's not the case. (http://dangerousprototypes.com/2012/08/05/confusion-over-sdr-vs-opensdrsharp/)
The solution in this case will be the same as it was for SDR#: Either make the entire application GPL, or break rtl_tcp_andro into a completely separate package. Make sure that the description for the rtl_tcp_andro package clearly states its license, and make sure you link to the GitHub page for it so the source is clearly available. That should cover all the bases.
Click to expand...
Click to collapse
Ok, this makes sense.
Actually this won't be a bad idea after all, I mean if there is a separate app "rtl_tcp_andro" that can do I/Q samples, this might help other developers write their own SDR based applications so therefore help the community.
I don't want to release the processing bit under GPL since it took me quite some time to optimize the algorithms to run on Android so I want to keep my work with this private and this is what Pro users are paying for but rtl_tcp_andro is in the public domain anyways, I will just wrap it around with an apk and release it under GPL.
Please add NetSDR support for RFSpare radios like NetSDR or SDR-IP.
I would pay 10x the Pro price for this! http://sourceforge.net/projects/cutesdr/ and http://cutesdr.svn.sourceforge.net/...face/sdrinterface.cpp?revision=36&view=markup will probably reveal how NetSDR format works.
stejc said:
Please add NetSDR support for RFSpare radios like NetSDR or SDR-IP.
I would pay 10x the Pro price for this! http://sourceforge.net/projects/cutesdr/ and http://cutesdr.svn.sourceforge.net/...face/sdrinterface.cpp?revision=36&view=markup will probably reveal how NetSDR format works.
Click to expand...
Click to collapse
I already have sever requests about this. I will keep this idea in the record. I will first need to make sure SDR Touch is working properly and implement the list of features in the first post.
Also, I was able to rapidly prototype so far but now I'm back in University and I am forced to slow down the development speed. So it may take some time.
Any chance to make the whole app Open Source? This would be a nice recognition of the hard work done by the rtl-sdr folks, and solve your packaging problem.
I have licensed APRSdroid (which btw. can modulate and demodulate Packet Radio using audio in/out) under the GPL, and I can not complain about people not getting the paid version from Google Play.
To the contrary, 80% of my users actually bought the app, and all without evil nag screens!
martintzvetomirov said:
Actually this won't be a bad idea after all, I mean if there is a separate app "rtl_tcp_andro" that can do I/Q samples, this might help other developers write their own SDR based applications so therefore help the community.
Click to expand...
Click to collapse
Absolutely. That is the idea behind the GPL in the first place, that other developers can benefit from improvements made to the code. Having a separate download for rtl_tcp_andro would definitely be a positive for the community, I could personally think of a couple interesting projects with it.
martintzvetomirov said:
I don't want to release the processing bit under GPL since it took me quite some time to optimize the algorithms to run on Android so I want to keep my work with this private and this is what Pro users are paying for but rtl_tcp_andro is in the public domain anyways, I will just wrap it around with an apk and release it under GPL.
Click to expand...
Click to collapse
Of course, it's your right to keep your own software closed source. I don't personally believe in keeping this kind of software closed, but it's your decision.
Though I would like to point out that this type of software is going to get paid downloads either way. The type of users you will attract with this kind of software are the same kinds of users who have no problem donating to open source projects. We aren't talking about some casual game here that just anyone will be downloading, this is an application developed for more technical users who have a pretty good idea of the amount of effort that goes into a project like this.
In any event, I'm glad to see you taking the proper steps to make sure your software is GPL compliant.
FUNcube Pro & FUNcube Pro Plus Support
Any chance FUNcube Pro & FUNcube Pro Plus Dongles Support can be added in the future.
I implemented a browser based encryption solution which runs on Windows RT (and many other Windows computers). All I wrote was the HTML page, I am leveraging Crypto.JS javascript library for encryption algorithm. I am using the HTML 5 File API implementation which Microsoft provides for reading and writing files.
I make no claim on this but seems to work good for me. Feel free to feedback if you have any suggestions. The crypto.js library supports many different algorithms and configuration so feel free to modify it to your own purposes.
You can download the zip file to your surface, extract it and load the TridentEncode.htm file into Internet Explorer.
If you want to save to custom directory you probably need to load it from the Desktop IE instead of metro IE (to get the file save dialog). I usually drag and drop the file onto desktop IE and from there I can make favorite. This should work in all IE 11 and probably IE 10 browsers... if you use other browsers you may need to copy paste into the fields since the File API implementation seems rather browser specific. Running the html page from the local filesystem means that there is no man-in-the-middle which helps eliminate some of the vulnerabilities of using a javascript crypto implementation. You could also copy the attached zip file to your skydrive to decrypt your files from other computers.
Skydrive files in theory are secure (unless they are shared to public) so this might be useful for adding another layer of protection to certain info.
Again, use at your own risk, but feel free to play around and test it, and offer any suggestions or critiques of its soundness, or just use it as a template for your own apps.
Ok... this is really cool! Nice idea, and a good first implementation.
With that said, I have a few comments (from a security perspective). As an aside, minimized JS is the devil and should be annihilated with extreme prejudice (where not actually being used in a bandwidth-sensitive context). Reviewing this thing took way too long...
1) Your random number generation is extremely weak. Math.random() in JS (or any other language I'm aware of, for that matter) is not suitable for use in cryptographic operations. I recommend reading http://stackoverflow.com/questions/4083204/secure-random-numbers-in-javascript for suggestions. The answer by user ZeroG (bottom one, with three votes, as of this writing) gets my recommendation. Unfortunately, the only really good options require IE11 (or a recent, non-IE browser) so RT8.0 users are SOL.
NOTE: For the particular case in question here (where the only place I can see that random numbers are needed is the salt for the key derivation), a weak PRNG is not a critical failing so long as the attacker does not know, before the attack, what time the function is called at. If they do know, they can pre-compute the likely keys and possibly succeed in a dictionary attack faster than if they were able to generate every key only after accessing the encrypted file.
2) Similarly, I really recommend not using a third-party crypto lib, if possible; window.crypto (or window.msCrypto, for IE11) will provide operations that are both faster and *much* better reviewed. In theory, using a JS library means anybody who wants to can review the code; in practice, the vast majority of people are unqualified to either write or review crypto implementations, and it's very easy for weaknesses to creep in through subtle errors.
3) The default key derivation function (as used for CryptoJS.AES.encrypt({string}, {string})) is a single iteration of MD5 with a 64-bit salt. This is very fast, but that is actually a downside here; an attacker can extremely quickly derive different keys to attempt a dictionary attack (a type of brute-force attack where commonly used passwords are attempted; in practice, people choose fairly predictable passwords so such attacks often succeed quickly). Dictionary attacks can be made vastly more difficult if the key derivation process is made more computationally expensive. While this may not matter so much for large files (where the time to perform the decryption will dominate the total time required for the attack), it could matter very much for small ones. The typical approach here is to use a function such as PBKDF2 (Password-Based Key Derivation Function) with a large number of iterations (in native code, values of 20000-50000 are not uncommon; tune this value to avoid an undesirably long delay) although other "slow" KDFs exist.
4) There's no mechanism in place to determine whether or not the file was tampered with. It is often possible to modify encrypted data, without knowing the exact contents, in such a way that the data decrypts "successfully" but to the wrong output. In some cases, an attacker can even control enough of the output to achieve some goal, such as compromising a program that parses the file. While the use of PKCS7 padding usually makes naïve tampering detectable (because the padding bytes will be incorrect), it is not a safe guarantee. For example, a message of 7 bytes (or 15 or 23 or 31 or any other multiple of 8 + 7) will have only 1 byte of padding; thus there is about a 0.4% (1 / 256) chance that even a random change to the ciphertext will produce a valid padding. To combat this, use an HMAC (Hash-based Message Authentication Code) and verify it before attempting decryption. Without knowing the key, the attacker will be unable to correct the HMAC after modifying the ciphertext. See http://en.wikipedia.org/wiki/HMAC
5) The same problem as 4, but from a different angle: there's no way to be sure that the correct key was entered. In the case of an incorrect key, the plaintext will almost certainly be wrong... but it is possible that the padding byte(s) will be correct anyhow. With a binary file, it may not be possible to distinguish a correct decryption from an incorrect one. The solution (an HMAC) is the same, as the odds of an HMAC collision (especially if a good hash function is used) are infinitesimal.
6) Passwords are relatively weak and often easily guessed. Keyfiles (binary keys generated from cryptographically strong random number generators and stored in a file - possibly on a flashdrive - rather than in your head) are more secure, assuming you can generate them. It is even possible to encrypt the keyfile itself with a password, which is a form of two-factor authentication: to decrypt the data that an attacker wants to get at, they need the keyfile (a thing you have) and its password (a thing you know). Adding support for loading and using keyfiles, and possibly generating them too, would be a good feature.
The solutions to 3-5 will break backward compatibility, and will also break compatibility with the default parameters for openssl's "enc" operation. This is not a bad thing; backward compatibility can be maintained by either keeping the old version around or adding a decrypt-version selector, and openssl's defaults for many things are bad (it is possible, and wise, to override the defaults with more secure options). For forward compatibility, some version metadata could be prepended to the ciphertext (or appended to the file name, perhaps as an additional extension) to allow you to make changes in the future, and allow the encryption software to select the correct algorithms and parameters for a given file automatically.
Wow thanks GDTD that's great feedback
Not sure about his minified sources, the unminified aes.js in components is smaller than the minified version (which I am using) in rollups. I'll have to look into what his process for 'rollup' is to see if I can derive a functional set of non-minified script includes. If I can do that it would be easier to replace (what I would guess is) his reliance on Math.random.
His source here mirrors the unminified files in components folder : https://code.google.com/p/crypto-js/source/browse/tags/3.1.2/src
msCrypto that would be great, I had no idea that was in there. I found a few (Microsoft) samples so I will have to test them out and see if I can completely substitute that for crypto.js. Would be more keeping in line with the name I came up with.
Currently this version only works for text files, I am using the FileAPI method reader.readAsText(). I have been trying to devise a solution for binary files utilizing reader.readAsArrayBuffer but as yet I haven't been able to convert or pass this to crypto.js. I will need to experiment more with base64 or other interim buffer formats (which Crypto.js or msCrypto can work with) until I can get a better understanding of it.
Metadata is a great idea, maybe i can accommodate that with a hex encoded interim format.
You seem extremely knowledgeable in the area of encryption, hopefully i can refine the approach to address some of the issues you raised by setting up proper key, salt, and IV configuration... I'm sure I will understand more of your post as i progress (and after reading it about 20 times more as a reference).
Too bad we don't a web server for RT, that would at least open up localStorage for json serialization (mostly for other apps I had in mind). I guess they might not allow that in app store though. Could probably run one of a developers license though (renewed every 1-2 months)?
nazoraios said:
Too bad we don't a web server for RT, that would at least open up localStorage for json serialization (mostly for other apps I had in mind). I guess they might not allow that in app store though. Could probably run one of a developers license though (renewed every 1-2 months)?
Click to expand...
Click to collapse
I cant comment too much on the encryption, GoodDayToDie has covered anything I could contribute and more. But there is a functioning web server on RT. Apache 2.0 was ported: http://forum.xda-developers.com/showthread.php?t=2408106 I dont know if everything is working on it, I dont own an RT device and last time I tried I couldnt get apache to run on 64 bit windows 8 anyway (needed it at uni, spent hours going through troubleshooting guides and it never worked on my laptop, gave up and ran it under linux in virtualbox where it took 2 minutes to have functioning the way I needed it to).
Curious about the performance. Speaking of encryption, 7-Zip has it built-in, and from the discuss in StackExchange, it seems pretty good.
One of the neat things about this thing (local web app? Pseudo-HTA (HTml Application)? Not sure if there's a proper name for such things) is that it runs just fine even on non-jailbroken devices. That's a significant advantage, at least for now.
Running a web server should be easy enough. I wrote one for WP8 (which has a subset of the allowed APIs for WinRT) and while the app *I* use it in won't be allowed in the store, other developers have taken the HTTP server component (I open-sourced it) and packaged it in other apps which have been allowed just fine. With that said, there are of course already file crypto utilities in the store anyhow... but they're "Modern" apps so you might want to develop such a server anyhow so you can use it from a desktop web browser instead.
Web cryptography (window.crypto / window.msCrypto) is brand new; it's not even close to standardization yet. I'm actually kind of shocked MS implemented it already, even if they put it in a different name. It's pretty great, though; for a long time, things like secure random numbers have required plugins (Flash/Java/Silverlight/whatever). Still, bear in mind that (as it's still far from standardized), the API might change over time.
Yep, I think of them as Trident apps since trident is what Microsoft calls their IE rendering engine, but I guess they are sort of offline web apps (which come from null domain). Being from null domain you are not allowed to use localstorage which is domain specific. You also are not allowed to make ajax requests. You just have file api and json object serialization to make do with I/O.
Another app I am working on is a kind of Fiddler app similar to http://jsfiddle.net/ where you can sandbox some simple script programs.
Kind of turning an RT device into a modern/retro version of a commodore 64 or other on-device development environments. Instead of basic interpreter you've got your html markup and script.
I have an attached demo version which makes available jquery, jquery-ui, alertify javascript libraries in a sandbox environment that you can save as .prg files.
I put a few sample programs in the samples subfolder. Some of the animation samples (like solar system) set up timers which may persist even after cleared so you might need to reload the page to clear those.
It takes a while to extract (lots of little files for all the libraries) but once it extracts you can run the html page and I included a sample program 'Demo Fiddle.prg' you can load and run to get an idea.
I added syntax highlighting editors (EditArea) which seems to work ok and let's you zoom each editor full screen.
The idea would be to take the best third party javascript libraries and make them available and even make shortcuts or minimal API for making it easier to use them. Common global variable, global helper methods, ide manipulation. I'd like to include jqplot for charting graphs, maybe for mathematical programs and provide api for user to do their own I/O within the environment.
These are just rough initial demos, and obviously open source so if anyone wants to take the ideas and run with them i'd be interested in seeing what others do. Otherwise I will slowly evolve the demos and release when there are significant changes.
Fair warning: I know only mostly what I want, I have no clue how difficult it will be to achieve, and therefor have no idea how to price the work. There are several people interested in this project though, so I'm sure a good budget can be reached.
I have several copies of Lenovo+Google's ill-fated virtual reality headset, which I would like to turn into actually functional devices. The kernel is Android 8 with some additional hooks (I have a copy with the additional required files). I also have one that has developer access of some kind, which may make the process easier.
The primary problems the device needs fixed:
Needs USB File transfer (disabled completely currently)
Needs access to cameras (Especially necessary for AR passthrough)
Needs Task Manager
Needs better widget and notification area systems (Currently, to skip a song on, say, spotify, you have to exit the app you're in, navigate to spotify, switch the song, restart the app you were in. The notifications are also not context aware, so you can't click on one to go to the referenced app)
Support for alternate controllers (basic, such as keyboard or bluetooth PSX)
According to the last person I attempted to hire for this, it would be easier to start from scratch than to implement an altered rom, but I don't think he understood how the 360 virtual environment and camera tracking systems were integrated (not that I do, but I know enough to know that building them out from scratch would be a massive undertaking).
Here is the current road map document, which is still a work in progress.
Any assistance, direction, or paid work would be appreciated, as I've been stumped on where to even begin for over a year.
MOD ACTION:
Thread closed since bounty threads are not allowed on XDA.
@bridgebrain