Attend XDA's Second Annual Developer Conference, XDA:DevCon 2014!
5,740,547 Members 46,103 Now Online
XDA Developers Android and Mobile Development Forum

LiveView reverse-engineering effort

Tip us?
 
archivator
Old
(Last edited by archivator; 24th January 2012 at 10:25 PM.)
#1  
Junior Member - OP
Thanks Meter 29
Posts: 14
Join Date: Mar 2010
Default LiveView reverse-engineering effort

Hi all,

A few weeks ago I started taking apart the LiveView software and manager. I'm really unhappy with the current plugin system, the menu structure and more. So, I started to reverse-engineer the Bluetooth protocol. I'm at the very beginning but it's looking promising.

Here's the repo: https://github.com/BurntBrunch/LivelierView

The protocol is not very difficult - just request-acknowledge-response serial communication over RFCOMM. Also, the kind people from SE didn't run the manager through Proguard (wink, wink, nudge, nudge ).

I also have what I *think* is a dump of the firmware but it seems either compressed or encrypted. Binwalk didn't find anything in it. If someone would be kind enough to take apart the software updater, we might figure out what's running on the actual device as well.

Overall, I'm just starting but so far it's looking good (got time syncing working! it's at least a watch, if nothing else! :P ).

Any help would be greatly appreciated (pull requests are more than welcome! )
The Following 24 Users Say Thank You to archivator For This Useful Post: [ Click to Expand ]
 
cezor
Old
#2  
Junior Member
Thanks Meter 2
Posts: 12
Join Date: Apr 2011
Location: Odense
thinking of doing something similar with one of my gadgets.
What did you use to reverse-engineer the Bluetooth protocol, just wireshark and a bluetooth dongle
The Following User Says Thank You to cezor For This Useful Post: [ Click to Expand ]
 
archivator
Old
(Last edited by archivator; 1st January 2012 at 10:26 PM.)
#3  
Junior Member - OP
Thanks Meter 29
Posts: 14
Join Date: Mar 2010
Neither Did it from disassembly of the manager - much easier than sniffing and guessing.

If you don't have that option and said gadget connects to an Android phone, put on a decent ROM with the full BlueZ stack (e.g., Cyanogen) and use hcidump. It's really, really useful!

Come to think of it, Wireshark might be good enough - the only thing I found useful about hcidump was the SCO audio dump.
The Following User Says Thank You to archivator For This Useful Post: [ Click to Expand ]
 
pedrodh
Old
#4  
Retired Recognized Developer
Thanks Meter 213
Posts: 190
Join Date: Oct 2009
Nice effort. I've already forked your work on github, might have a look at it soon, I got some geeky ideas for myself as well, and I think integrating this functionality natively on CyanogenMod or even a custom app to replace the SE's one would be great to have as well.
Like my work and have bitcoin? Please donate: 152A5eh6QgLXYuNVxhgHtM1XxM8o85RoLL
The Following User Says Thank You to pedrodh For This Useful Post: [ Click to Expand ]
 
AleyKsi
Old
#5  
AleyKsi's Avatar
Member
Thanks Meter 14
Posts: 52
Join Date: Dec 2011
Location: Strasbourg
Nice,
i'm was disapointed by the liveview manager myself, i hope something good emerges from your work
 
pedrodh
Old
(Last edited by pedrodh; 3rd January 2012 at 06:32 PM.) Reason: added led request ID
#6  
Retired Recognized Developer
Thanks Meter 213
Posts: 190
Join Date: Oct 2009
I've also decompiled the APK, and it seems that everything that displays on screen comes from the application, which means everything could be costumized. Seems like SE is using a PNG lib LodePNG to convert images and pushing them to the phone. Also, when it comes to strings, I've found some useful references in JerryProtocol that might indicate how the correct text encoding (not that we can push it right now, but just for the record):

Code:
Select Code
private static final String mEncoding = "iso-8859-1";
private static final char cCarriageReturn = '\r';
private static final char cLineFeed = '\n';
Controlling the led seems quite simple to, it seems message's data is divided in 3 parts:
[RGB] [DELAY = Integer Number] [ON STATE = 0|1]

[old]although I've not figured out the ID of the LED control yet[/old].

LED request ID is 40 and LED response ID is 41. Hope this is enough for you to get started on that one too

I've not yet tested the app, but I've read your code and gave a shot at decompiling trying to see what I could dig up, will try it later (not very used to running python scripts though, will have to see how to install pyserial first and all that)
Like my work and have bitcoin? Please donate: 152A5eh6QgLXYuNVxhgHtM1XxM8o85RoLL
The Following 2 Users Say Thank You to pedrodh For This Useful Post: [ Click to Expand ]
 
archivator
Old
(Last edited by archivator; 3rd January 2012 at 10:57 PM.)
#7  
Junior Member - OP
Thanks Meter 29
Posts: 14
Join Date: Mar 2010
Quote:
Originally Posted by pedrodh View Post
it seems that everything that displays on screen comes from the application
Yup, the main stuff is on the phone - the state machine is clearly isolated (on a side note, the manager is rather well-written, thankfully). On the other hand, I'm somewhat confused by all the constants - it almost feels as if the device has native navigation or icon cache or something.

Quote:
Originally Posted by pedrodh View Post
Controlling the led seems quite simple to, it seems message's data is divided in 3 parts:
[RGB] [DELAY = Integer Number] [ON STATE = 0|1]

LED request ID is 40 and LED response ID is 41. Hope this is enough for you to get started on that one too
Thanks for the interest and the tip, I'll look into it soon - I need to figure out a good way to send commands from stdin. It seems that I'll need to figure out non-blocking reading in Python anyway (good news for you - I might drop pyserial! )

In any case, I'll add it to protocol.txt, unless you beat me to it!

Lastly, the only reason it's in Python is 'cause I'm productive in it *and* it has good, fast bindings (I try to stay away from gobject in C!). Whatever comes out of this effort would be running on the phone, surely

Edit: You *did* beat me to it!

Edit: Implemented LED, vibration, and a pretty good scheme for sending commands from the CLI
The Following User Says Thank You to archivator For This Useful Post: [ Click to Expand ]
 
pedrodh
Old
#8  
Retired Recognized Developer
Thanks Meter 213
Posts: 190
Join Date: Oct 2009
Nice work, saw quite a few commits in a small amount of time.

I've not yet been able to run it sucefully, I (think) have installed pyserial correctly, but maybe the problem is that the bluez that comes with my ubuntu is somewhat newer than the one you used, anyway here's as far as I got http://pastebin.com/uVRdr5T3 if you by chance know just by looking at it what it is would be great .

I've started an Android applicatoin Project in hopes of porting this to an Android application as well, but I'm somewhat new to Bluetooth handling on Android, still working it out. I'm already able to connect and pair with device (noob stuff), but it fails to READ from it. I've used java's DataOutputStream and DataInputStream since they deal with data in a big-endian notation, but I haven't understood yet how the initialization process goes. I've looked to your code, I get some parts but not the whole thing yet. Do you have to wait for the LiveView to tell something back, or you can just start to send commands at random? Also, does the script act as a bluetooth server or client (it seems that they are distinct when coding in Android, I've choosen to Connect as a Client, and yes I used the same UUID that you got from decompiling so at least that part I guess to be correct) ?

Anyway is just a bunch of very ugly code at the moment, after I get it to do something usefull I'll clean up the project and host it on github as well.
Like my work and have bitcoin? Please donate: 152A5eh6QgLXYuNVxhgHtM1XxM8o85RoLL
 
archivator
Old
(Last edited by archivator; 4th January 2012 at 08:02 PM.)
#9  
Junior Member - OP
Thanks Meter 29
Posts: 14
Join Date: Mar 2010
Hmm, that error is rather suspicious. Looking at the docs, Connect() is not even supposed to throw org.bluez.Failed, let alone with that message. And service discovery supposedly finished successfully..

Was the device in pairing mode (with the arrows/circle turning)? Was the computer the last thing it paired with (once you pair with the computer, the phone shouldn't be able to connect to it, since the device only remembers the last authorization)?

Install d-feet, the DBus browser, go under System bus, org.bluez, find the device, verify that it has the org.bluez.Serial interface and try calling Connect() with the proper UUID from there. Other than that, I've really no idea what it's on about.. Do you have more than one LiveView device by any chance (weird things might happen then)?

I don't actually think it's the difference in bluez versions (the Serial interface hasn't changed in the past 2 and something years) but it might be a (driver) bug you're hitting. I *think* I'm doing everything right as far as communication with BlueZ is concerned. Try running `hciconfig hci0 reset`.

Sorry I couldn't be more helpful..

Regarding your Java effort, if I recall my Bluetooth terminology correctly, you are a client, since the server is the thing advertising the service. You should *not* be reading immediately from the device. The phone/computer sends the first message - in my case, my first message is always STANDBY. Then and only then can you start reading back.

Lastly, I hope Android abstracts the whole RFCOMM pipe thing, 'cause it's a pain to use (and the reason I still need pyserial) - select() would sporadically tell me it has data to read and when I try to read it, I get ERRIO :/ I suspect RTS triggers select()..

Make sure you're only reading as many bytes as you know are in the next packet (take a look at consume() - it returns the number of bytes it expects next) and not more than that - it would either block or throw an exception. I've not done any Bluetooth work on Android, so that's as much as I can help, I'm afraid.

Lastly, as big as the temptation is, do not under any circumstances reuse code from the official manager. "Sony" is in the name of the company after all. I'm half-expecting a Cease & Desist any moment now

Edit: Implemented Display Properties Request and Clear Display Request (doesn't do anything). I think I'm out of low-hanging fruit
 
tj80
Old
#10  
Member
Thanks Meter 3
Posts: 54
Join Date: Jun 2006
Location: UK
Really interesting work, guys. The Liveview is a fantastic idea and is almost brilliant - if only it worked properly! If you could get the basics working properly so we don't have to use the Sony software that would be fantastic, it's got so much potential.

Cheers,
Tim

Tags
github, livelierview, liveview, reverse-engineer
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes