LiveView reverse-engineering effort

Search This thread

archivator

Member
Mar 16, 2010
14
27
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! :))
 
Last edited:

cezor

Member
Apr 12, 2011
13
2
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
 
  • Like
Reactions: DSR!

archivator

Member
Mar 16, 2010
14
27
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.
 
Last edited:
  • Like
Reactions: askaguilr

pedrodh

Retired Recognized Developer
Oct 19, 2009
194
226
www.pedronveloso.com
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
Reactions: kadofl

pedrodh

Retired Recognized Developer
Oct 19, 2009
194
226
www.pedronveloso.com
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:
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) ;)
 
Last edited:
  • Like
Reactions: yohai75 and psycmos

archivator

Member
Mar 16, 2010
14
27
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.

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 :)
 
Last edited:
  • Like
Reactions: yohai75

pedrodh

Retired Recognized Developer
Oct 19, 2009
194
226
www.pedronveloso.com
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.
 

archivator

Member
Mar 16, 2010
14
27
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 :D

Edit: Implemented Display Properties Request and Clear Display Request (doesn't do anything). I think I'm out of low-hanging fruit :(
 
Last edited:

tj80

Senior Member
Jun 20, 2006
54
3
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
 

archivator

Member
Mar 16, 2010
14
27
So, I had a brilliant idea today. You know how the LiveView Manager app is full of debug messages. Turns out, they are disabled by means of a constant in ElaineUtils. My idea was to change that constant, put the apk back on my phone and rejoice from all the extra info I'd have.

Turns out, that's not how it works. I changed the constant (bumped it to 0x100 - literally a single bit change) and re-signed the apk. I got some output out of it but not all, and none of the useful ELEMENT_ID_* messages :(

Any help on that front would massively speed up the reverse-engineering effort.

EDIT: Scratch that, I'm stupid. I forgot that the .field annotations are not executable code - I was changing the wrong bit so to speak. Changed the value in <cinit> and voila, proper logcat! :D

EDIT: Here's some food for thought - http://pastebin.ca/2099804 - it's the log from startup + a bit of moving around and opening/closing the mediaplayer control.
 
Last edited:

cyansmoker

Inactive Recognized Developer
Sep 18, 2010
501
636
Los Angeles
nexus.zteo.com
Very cool project.

I believe, for the damn thing to be usable, focusing on improving Bluetooth performance would be quite good. By "performance" I mean "power consumption." Having to give up on the watch after two hours of light use is really unacceptable.
 
Jan 6, 2009
32
2
I would love it if you got this thing working efficiently like SmartWatchm/OpenWatch did for my MBW-150. I ordered my LiveView from the UK when it first released there instead of waiting for the US release. The darn thing disappointed the hell out of me and has been sitting in my garage for almost a year now.

Hopefully you get something going on with this. :cool:
 

pedrodh

Retired Recognized Developer
Oct 19, 2009
194
226
www.pedronveloso.com
So, I had a brilliant idea today. You know how the LiveView Manager app is full of debug messages. Turns out, they are disabled by means of a constant in ElaineUtils. My idea was to change that constant, put the apk back on my phone and rejoice from all the extra info I'd have.

Turns out, that's not how it works. I changed the constant (bumped it to 0x100 - literally a single bit change) and re-signed the apk. I got some output out of it but not all, and none of the useful ELEMENT_ID_* messages :(

Any help on that front would massively speed up the reverse-engineering effort.

EDIT: Scratch that, I'm stupid. I forgot that the .field annotations are not executable code - I was changing the wrong bit so to speak. Changed the value in <cinit> and voila, proper logcat! :D

EDIT: Here's some food for thought - http://pastebin.ca/2099804 - it's the log from startup + a bit of moving around and opening/closing the mediaplayer control.

Wow, that's very useful thank you. I've been very occupied and did not work more with the Android Side application since my last post, I intend to return to it soon enough though, that output is very welcome when it comes to understanding then the icons are sent and the whole mechanism itself.
 

aj256

Member
Apr 7, 2007
13
12
I've been doing a bit of reverse engineering work on the liveview as well, and I think I have a complete (although i fear possibly slightly corrupt) firmware dump! :)

I have been able to extract was some PNG images from the firmware (Thanks to their rather distinctive %PNG Header and ending with IEND).
It would appear that the menus and stuff are in fact definitively transferred over bluetooth!

I've attached the images I've extracted if anyone's interested in seeing them!

I'm currently trying to work through it in IDA to disassemble it, which is a pain in the arse!

Is anyone else also interested in completely rewriting the firmware?
 

archivator

Member
Mar 16, 2010
14
27
@aj256, nice work! I thought I had a dump as well but mine looked compressed :\ Mind uploading yours somewhere for all to see? :) (edit: sorry, saw it in the archive)

It would appear that the menus and stuff are in fact definitively transferred over bluetooth!

That's correct - I almost have that part of the protocol figured out but I'm low on spare time.

Is anyone else also interested in completely rewriting the firmware?

Well.. I'd be interested in modifying it and isolating the Bluetooth stack but don't really have the time OR the chops to write the whole firmware from datasheets and disassembly.

As for where I'm standing, I know what I need to decompile next (renderShowUi) but it's a couple of thousand lines of smali. There are so many branches, it's easy to get lost. I need to write better tools for decompiling smali first :D
 
Last edited:
X

x942

Guest
Just bought a Live View! I know it may not be the best but I got it cheap and mainly want the Caller ID portion of it. I hope this reverse engineering pays off. Once I get mine I may start poking around and see if I can help out! Thanks for the post OP!
 

boombuler

Senior Member
Jul 16, 2008
161
224
Hi,

do you guys have some irc channel or anything else? Just got my LiveView and want to help you with this...
 

aj256

Member
Apr 7, 2007
13
12
I've quickly put together a project website at openliveview (dot) com (apparently I don't have enough posts for an external link!) with some forums as well to help to document peoples progress!

I've done a quick writeup on my progress so far (which isn't very much!)

@archivator, glad you found the firmware in the zip, I was just about to reply that it was there!
 

pedrodh

Retired Recognized Developer
Oct 19, 2009
194
226
www.pedronveloso.com
I've quickly put together a project website at openliveview (dot) com (apparently I don't have enough posts for an external link!) with some forums as well to help to document peoples progress!

I've done a quick writeup on my progress so far (which isn't very much!)

@archivator, glad you found the firmware in the zip, I was just about to reply that it was there!

Nice. I've been on your website and the documentation is getting in good shape. When I got some free time I'll try and read it more carefully and complement the Android project.

Talking about that, I've uploaded my progress so far to github: https://github.com/pedronveloso/OpenLiveView

bare in mind that apart from pairing with the Device not much is actually working by now, contributions are welcome of course :D
 
  • Like
Reactions: benwade

Top Liked Posts

  • There are no posts matching your filters.
  • 23
    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! :))
    10
    Well just a brief status update. The project I've started on github has been progressing, greatly in part from the contributions of boombuler.

    You can go there ( https://github.com/pedronveloso/OpenLiveView ) and check the README, and I've compiled and attached an APK so you guys can test for yourselves without having to clone the repo and compile ;). Right now that APK only asks for connecting with the device (has to be paired first of course) and then sends a Vibrate command to the LiveView. There's more commands done in the source then just that but the functionality has not yet received a dedicated UI since the whole thing is on a very early stage.

    Bare in mind that theres no point in reporting any bugs at this stage since I myself keep finding them with ease :p

    NOTE : You might have to uninstall LiveView first in order to test the app, at least I had to uninstall it because of Broadcasts that where getting in the way sometimes when the LiveView app was installed.
    9

    its not done yet. will need to enable getpixel in chibios gfx in order to have clean alpha overlapping. (well you cant see it anyways on a video)
    9
    Update!

    Here you go, the next update! :)

    Visible changes:
    I added mediacontrols (play/pause, previous track and next track) to the menu.

    Invisible changes (protocol):
    - Implemented brightness controll for the liveview display (off, dim and on)
    - Implemented ClearDisplay command
    - Implemented DisplayBitmap command

    Invisible changes (gui):
    - Added mediacontrolls like in the sony app when you long press the select key.

    Now the problem I am currently experiencing:
    The LiveView does not send back the navigate commands for left, right and select (short press) when in menu mode AND when out of menu mode (zero menuitems).

    My question to the original developer of the "net.sourcewalker.olv" app is if he can tell me how to make the liveview send those keypresses to the service.



    Something that I found out:
    the device sends DEVICESTATUS_ON back in stead of DEVICESTATUS_MENU when there are zero menu items, in that mode you have full controll over the screen (blanking and sending bitmaps).


    EDIT:
    Small bugfix (next button didn't work)
    9
    I'm sorry for being a noob again but what is OLV?
    Can there be a rom for the LiveView in the coming years?
    Is the LiveView open source?
    + can anyone provide me a detailed spec sheet of the LiveView... Like the processor and alll..

    Sent from my ST25i using Tapatalk 2

    1. OLV means: OpenLiveView wich is our project name (we have a custom android app that fully replaces sony's app)
    2. a rom is currently in developement as you can see within this post.
    3. the liveview itself is not opensource. our stuff however is.
    4. i cannot provide you a detailed spec sheet right now but will do it when i have some time digging out that info.

    so.. now to what i want to post:



    current snapshot of my firmware folder in attachments.

    current binary of the firmware is also in the attachments. (for thoose who just want to try it without compiling and know what they do)


    how to use the firmware folder:
    http://xdaforums.com/showpost.php?p=38341041&postcount=731

    (yes, i suck at english. digg through it or wait till i explain it on http://openliveview.com)



    stuff that is on my todo:

    • display timeout (aprox 5 minutes to implement it)
    • bluetooth (need help)
    • write access to the internal storage (need help)
    • access to the current battery charge info (need help)
    • basic menu system (i'm on it)
    • stopwatch (i'm on it after the menu)
    • digital clock (will do it after i did the stopwatch)
    • other stuff