Accessing Dive Info on the UEMIS SDA

Please register or login

Welcome to ScubaBoard, the world's largest scuba diving community. Registration is not required to read the forums, but we encourage you to join. Joining has its benefits and enables you to participate in the discussions.

Benefits of registering include

  • Ability to post and comment on topics and discussions.
  • A Free photo gallery to share your dive photos with the world.
  • You can make this box go away

Joining is quick and easy. Log in or Register now!

Ok, a friend just told me about this thread.
I think if will join our efforts everything will work out just fine ;-)
I'm optimistic it will.

You all seem to be logging the traffic to the servers by making use of the fact that the required SSL keys are stored in the testkeys file on the SDA.
Actually, no, that's not what we are doing. We are trying to talk directly to the device. The command structure is pretty straight forward. Commands are written to /req.txt and responses are in /ANS/ANSxx.txt
We need to figure out exactly how to initialize the device (and based on the traces we have, that has to be done by the SyncSDA.jar - so if you are better at interpreting decompiled java then your help there would be very welcome) and we need to make sure that the session ID that is being used is not a cryptographic cipher (without the init code mentioned above we can't test that part).

I just returned from a dive trip (technically still sitting at SFO since my original flight was canceled) and hope to have time to do more tracing of the actual dive uploading in the next few days.

I decompiled the SyncSDA.jar and I am certain that I can come up with a solution to communicate with device itself.
It's quite easy to circumvent the VPI infrastructure by calling the Methods of the ininet.tinyRPC.tinyRPCMaster class.
This class use the USBFileCommunication class to access the ANS/ANS*.TXT files for direct communication with the SDA.
The USBFileCommunication is doing "strange" things I don't dare to access directly, but tinyRPCMaster uses the XML Strings you saw within
Applet-Server communication.
I guess it all depends what you are comfortable with - I'd much rather figure out the weird communication protocol through tthe USB file system :-)

I implemented some Parsers to create basic pojos. Just a few more hours and I hopefully dare to run some request directly against my device.
If you guys figure out how to interpret the "file_content" parts and all other binary information we should not have to worry anymore ;-)
Jef from libdivecomputer is very well versed in deciphering those binary pieces - so if you get to something that works quicker than we do, by all means post pointers here. Since we can get the corresponding XML from their server I'm sure this is relatively easy to parse.
 
Hi,
after spending one or two hours to it, i am now able to read the xml-divelog direct from the device - without the need of the "SyncSDA.jar". My problem is now how to parse the "file_content" binary stuff in the xml. Does anyone have an idea about this? My first try was just do decode the base64 stuff and hope for a usable result - but the result was not what i expected :)

As i am new to this board: My name is Fabian , i am from munich / germany and working as software developer - and i use the the UEMIS since it was available :)
 
  • Like
Reactions: BB1
If you guys figure out how to interpret the "file_content" parts and all other binary information we should not have to worry anymore ;-)

For reverse engineering the binary data, anyone who owns an Uemis can help me collecting the necessary data. You simply have to upload one or more new dives (as far as we know it's not possible to upload the same dive twice, so you need a new dive for this procedure). Once the upload is finished, send me this data:
  1. A copy of the content of the Uemis drive, packaged in a zip file.
  2. The logfile generated by the java applet. If my information is correct, you should be able to access this log directly from the applet at the end of the transfer.
  3. For each uploaded dive, download the "divelog" and "dive" xml files.
You can find my email address on the libdivecomputer website.

As explained in several previous posts (#25 and #29), you can download the xml files from these links:

http://www.uemis.com/en/sda_logbook/data_src/xxxxx/dive
http://www.uemis.com/en/sda_logbook/data_src/xxxxx/divelog

where the xxxxx, needs to be replaced with the correct number.
 
How many dives do you want? I am able to read all of my dives from the SDA...

I am not sure if the UEMIS drive content is really usefull for you - this device gets reset on every connect...
 
after spending one or two hours to it, i am now able to read the xml-divelog direct from the device - without the need of the "SyncSDA.jar".

Do you mean the xml data that is send to the server (and the ones you can see in the logfile too)? These are obtained by reading the ANS files. What we really need to figure out at the moment is how we can make the device populate these ANS files for us, without running the applet. And we don't know how to do that yet.

I am not sure if the UEMIS drive content is really usefull for you - this device gets reset on every connect...

After the upload, they should still contain the data that was uploaded. It should be in the logfile as well, but it's always better to be able to double check.

How many dives do you want? I am able to read all of my dives from the SDA...
I mainly need dives with as much variation as possible (e.g. air/nitrox, deco/non-deco, gas switches, violations, etc). The actual number of dives is less important.

Note that it's very important that the xml files match with the data in the other files (e.g. represent the same dive)! Otherwise I'll be just wasting my time on trying to find a correspondance which isn't there in the first place.
 
Do you mean the xml data that is send to the server (and the ones you can see in the logfile too)? These are obtained by reading the ANS files. What we really need to figure out at the moment is how we can make the device populate these ANS files for us, without running the applet. And we don't know how to do that yet.

Yes, i am talking about this xml data.
I have build my own application which gets me the xml without the applet over the ANS files.

Code:
xxxx@wintermute >java -jar myuemis.jar 
Initialize RPC...
DeviceID : 37623xxxxx
Geting device data...
Device: 
<string>ae6b30eb6efdd8dcaf25d0bf614b4a18</string>
<list>
<hash ref="device" version="1.0">
<val key="computer_id">
<int>xxxxx</int>
</val>
<val key="computer_type">
<string>14</string>
</val>
<val key="hardware_version">
<string>100</string>
</val>
<val key="firmware_version">
<string>1.20</string>
</val>
</hash>
</list>
Start Session...
Process Sync...
Trying to get divelog...
Downloaded 8 logs

LOG-XML:

<string>ae6b30eb6efdd8dcaf25d0bf614b4a18</string>
<list>
<hash ref="divelog" version="1.0">
<val key="computer_id">
<int>xxxxx</int>
</val>
<val key="object_id">
<int>161</int>
</val>
<val key="date">
<ts>2011-06-19T13:18:37</ts>
</val>
<val key="duration">
<float>26.000000</float>
</val>
<val key="depth">
<int>1237</int>
</val>
<val key="gas">
<int>0</int>
</val>
<val key="water">
<int>0</int>
</val>
<val key="file_content">
<bin format="base64">RGl2ZQEAAKEAbY5B4GQAAAA....


You got mail with some logs...
 

Back
Top Bottom