Can't connect to 230 with ops for linux

it gets worse
I hate to bring even worse news, but with Ubuntu 7.10, just released, the alpha avidownload doesn't even get as far: dave@dave-desktop:~$ ls avidownload Documents Music Pictures pv2tool-for-linux Videos Desktop Examples ops-for-linux Public Templates dave@dave-desktop:~$ gksudo ./avidownload DEBUG: init device and probe via libusb dave@dave-desktop:~$ ops-for-linux doesn't get as far either: dave@dave-desktop:~/ops-for-linux$ gksudo ./ops Closing device No device to close usb device with VID==045e PID==0053 usb device with VID==0000 PID==0000 usb device with VID==167b PID==0101 Found the camcorder: Pure Digital Inc. Saturn , VID:167B PID:0101 Found camcorder. Connected to camcorder. External key file, saturnkeys.txt was found and will be loaded dave@dave-desktop:~/ops-for-linux$ This all that came out - I tried open, no messages; I tried unlock, no messages; I tried close, no messages. pv2tool-for-linux also doesn't get as far - shows no messages in the console and won't do anything except completely shutdown the program when you just click the "close" button (should only close the camera connection). This new release of Ubuntu is kernel 2.6.22-14 and libusb package libusb-0.1-4 version 2:0.1.12-7 Not good news.

weird. something's getting mangled. i'll check my devkit and ask around... this is not good.

The day before I plan to build my new computer with Ubuntu/WinXP dual-boot...

don't let me stop you. i'll have the problem solved, just let me work it.

Given this from the libusb documentation: usb_control_msg -- Send a control message to a device Description int usb_control_msg(usb_dev_handle *dev, int requesttype, int request, int value, int index, char *bytes, int size, int timeout); usb_control_msg performs a control request to the default control pipe on a device. The parameters mirror the types of the same name in the USB specification. Returns number of bytes written/read or < 0 on error. And, given this (only slightly modified version of a program from Linux Journal): /* * * ------------------------------------------------ * - camera interface program - * - - * - This program and it's source are free and - * - anyone can do what ever they want with it, - * - noting that some pieces of code are from - * - Set LED Copyright Greg Kroah-Hartman 2004 - * - (greg@kroah.com). Those pieces are under - * - the GNU GPL as published by the Free - * - Software Foundation, version 2 of the license- * - - * - - * ------------------------------------------------ * * */ #include <stdio.h> #include <string.h> #include <usb.h> #define LED_VENDOR_ID_CAMCORDER 0x167b #define LED_PRODUCT_ID_CAMCORDER 0x0101 #define LED_VENDOR_ID_CAMERA 0x0dca #define LED_PRODUCT_ID_CAMERA 0x0027 static void change_color (struct usb_dev_handle *handle, unsigned char color) { char *dummy; usb_control_msg(handle, 0x000000c8, 0x00000012, (0x02 * 0x100) + 0x0a, 0xff & (~color), dummy, 0x00000008, 5000); } static struct usb_device *device_init(void) { struct usb_bus *usb_bus; struct usb_device *dev; usb_init(); usb_find_busses(); usb_find_devices(); for (usb_bus = usb_busses; usb_bus; usb_bus = usb_bus->next) { for (dev = usb_bus->devices; dev; dev = dev->next) { if ((dev->descriptor.idVendor == LED_VENDOR_ID_CAMCORDER) && (dev->descriptor.idProduct == LED_PRODUCT_ID_CAMCORDER)) { fprintf(stderr,"Found Camcorder....\n"); return dev; } else if ((dev->descriptor.idVendor == LED_VENDOR_ID_CAMERA) && (dev->descriptor.idProduct == LED_PRODUCT_ID_CAMERA)) { fprintf(stderr,"Found Camera....\n"); return dev; } } } return NULL; } int main(int argc, char **argv) { struct usb_device *usb_dev; struct usb_dev_handle *usb_handle; int retval = 1; int i; usb_dev = device_init(); if (usb_dev == NULL) { fprintf(stderr, "Device not foundn\n"); goto exit; } usb_handle = usb_open(usb_dev); if (usb_handle == NULL) { fprintf(stderr, "Not able to claim the USB device\n"); goto exit; } * * * check lock status * * retval = 0; exit: usb_close(usb_handle); fprintf(stderr,"Closed and released camera....\n"); return retval; } And given the usb commands given at: http://www.maushammer.com/systems/cvscamcorder/usb.html What is the code that would be needed to the authentication challenge as shown on that webpage using the 0xfe? I can get the code (nothing I wrote!!) to recognize that either the camcorder or the still camera is plugged in and can be opened. A little help with a very foggy C programmer would be appreciated, as I think (I know - that's dangerous!! :) ) I might be able to figure out more of it from there and try to at least unlock the device. Anything beyond that will leave me out in la-la land for a while! :). BTW - is it possible they removed the old kernel stuff and went purely with libusb now, and that is causing a problem? I really appreciate the help you've been and continue to be!! :) :)

nah, it's all libusb. and if you're interested in pulling down the source to the las-*test*-('") stable, go to the sourceforge site, i think the link's in the avidownload thread somewhere. sorry, i'm on the run.

nah, it's all libusb. and if you're interested in pulling down the source to the las-*test*-('") stable, go to the sourceforge site, i think the link's in the avidownload thread somewhere. sorry, i'm on the run. I may check out that source, but I'm so rusty I can barely read what I found! :) Please oh please don't take my last post wrong, either! I'm in no position to even try to help on the problems, I just wanted to slowly work my way back into C and thought what the heck, it's a hard project, but maybe it will help me understand things better. We NEED YOU!!!! :)

partial success
Hey, I tried something tonight and at least got better keys! I downloaded the avidownload and source from sourceforge, then made 2 changes and recompiled: Both of these changes are in cam_unlock.c - I think you were getting a dirty buffer: in the code for the function GetKey and function PutKey, change the loop from t < 0x80 to t <= 0x80 The result seems to be clean keys, and it also unlocks my cameras. Something I haven't found yet is why it aborts afterwords. At any rate, the key problem seems to be solved with this 2 changes. Here is the output from the -*test*-('"): dave@dave-desktop:~/avidownload/src$ ls /.saturnkeys ls: /.saturnkeys: No such file or directory dave@dave-desktop:~/avidownload/src$ sudo ./avidownload INFO: Closing any opened devices... INFO: Open devices closed. INFO: Scanning USB bus 0 ... INFO: Scanning USB bus 1 ... INFO: USB device with VID: 0x167b, PID: 0x0101 on bus 1 INFO: Device found: Pure Digital Inc. VID: 0x167B, PID: 0x0101 INFO: Device successfully opened. INFO: Loading .saturnkeys from home directory... INFO: Challenge retrieved successfully. C 04905f02135eb4ff66cb838ffc7485db6e6522f395de2bb8e457cbf9fbc1bbdc C 7a0fb68013f52de0e4ef3bfb0386db325acf59f1b53406911976307d58f35194 C e22587cfde6c4424790d47aa7e7acbfd28d4fee434aeb43139145de93ccb34a5 C 7fdbba389b4b6392ce2c8fe596d9bb067f7cf91539d49d60ed363a85d1d2cdd7 INFO: Device unlocked! INFO: Challenge and response pair being used: C2R_10-02-2007_00:23:14 *** stack smashing detected ***: ./avidownload terminated Aborted (core dumped) dave@dave-desktop:~/avidownload/src$ Now don't think I'm a genius or anything - I just found a sample like yours in another sample program and noticed it was doing the <= 0x80 (maushammer's page on the usb commands for the camera and some pseudo-code). If you need something else from me based on this, please let me know. I wonder if this is the problem with ops-for-linux and pv2tool-linux as well - I haven't checked their sources yet. Also, I don't have a clue on how to compile them! :) EDIT: Indeed, the same code needs to be changed in ops-for-linux. I changed it, but I can't for the life of me figure out how to compile it. Do I need some extra libraries for the "form" used on the screen?

Change back the second 0x81 to 0x80, and resize the challenge/respose buffers to 0x81. That should avoid the stack smash. Possibly the last read word of the challenge isn't somehow being completed until the next read. Your extra read seems to have fixed that. Your hack isn't 'correct', since we C folk count from 0 instead of 1 like normal folks, but it's been instructive!

Change back the second 0x81 to 0x80, and resize the challenge/respose buffers to 0x81. That should avoid the stack smash. Possibly the last read word of the challenge isn't somehow being completed until the next read. Your extra read seems to have fixed that. Your hack isn't 'correct', since we C folk count from 0 instead of 1 like normal folks, but it's been instructive! I'm not sure exactly what I'm supposed to do (I feel pretty stupid at this point!). BTW - the USB commands for the camera on maushammer's site shows the pseudo code for retrieving the keys starting at 0, incrementing by 4, but using the <= 0x80 for the loop. Must be like you said - perhaps it needs one last read to return null and thereby terminate the string being built for the key (this would explain the corrupted buffer if no null was found until after those last 3 screwy bytes). I did change back the put-keys loop to < 0x80, as I realized after reading your post that indeed it shouldn't need it on the put of the keys back to the camera. Unfortunately it still crashes with the stack smashing. I put some debug lines in the next function called and it never gets there, so I guess I need to do some more looking at the unlock functions. Been quite a LONG time since I've done any C programming, so I feel like an idiot because it looks familiar yet some just looks the "junk". I remember things being relative zero - I did systems programming on main frames for many years and went through that, EBCDIC hex, ASCII hex, octal, binary conversions, dump traces, etc., but it's been SO long that everything is mostly gone. I guess 13 years of not thinking or worrying about any of that has caused me to be green all over again! :) Thanks again for your help, BillW!! :)

Getting closer! I did like you said and changed the challenge and response def in the unlock function from 128 to 132, This got past that set of stack smashing. Now it finds a file on my camera but then aborts again with stack smashing. I assume this is something similar that causes the generatefilelist function to cause the abort. :) EDIT: Forgot to include the console output: dave@dave-desktop:~/avidownload/src$ sudo ./avidownload INFO: Closing any opened devices... INFO: Open devices closed. INFO: Scanning USB bus 0 ... INFO: Scanning USB bus 1 ... INFO: USB device with VID: 0x167b, PID: 0x0101 on bus 1 INFO: Device found: Pure Digital Inc. VID: 0x167B, PID: 0x0101 INFO: Device successfully opened. INFO: Loading .saturnkeys from home directory... INFO: Challenge retrieved successfully. C 04905f02135eb4ff66cb838ffc7485db6e6522f395de2bb8e457cbf9fbc1bbdc C 7a0fb68013f52de0e4ef3bfb0386db325acf59f1b53406911976307d58f35194 C e22587cfde6c4424790d47aa7e7acbfd28d4fee434aeb43139145de93ccb34a5 C 7fdbba389b4b6392ce2c8fe596d9bb067f7cf91539d49d60ed363a85d1d2cdd7 INFO: Device unlocked! INFO: Challenge and response pair being used: C2R_10-02-2007_00:23:14 INFO: Searching for media... INFO: Media found: PICT0001.AVI (1067KB) INFO: Media found: PICT0002.AVI (510KB) *** stack smashing detected ***: ./avidownload terminated Aborted (core dumped) dave@dave-desktop:~/avidownload/src$

Good call... I was just about to report that my 0x81 shoud have been 0x84. I think you've given Mr. Nights enough to chew on. Perhaps there's some new libusb flush command, or a way to turn off the buffering.

hmm. now i know how i'm spending my monday. thank you!

Got this far now: dave@dave-desktop:~/avidownload/src$ sudo ./avidownload DEBUG: main, init INFO: Closing any opened devices... INFO: Open devices closed. INFO: Scanning USB bus 0 ... INFO: Scanning USB bus 1 ... INFO: USB device with VID: 0x167b, PID: 0x0101 on bus 1 INFO: Device found: Pure Digital Inc. VID: 0x167B, PID: 0x0101 DEBUG: main, open INFO: Device successfully opened. DEBUG: main, unlock INFO: Loading .saturnkeys from home directory... INFO: Challenge retrieved successfully. C 04905f02135eb4ff66cb838ffc7485db6e6522f395de2bb8e457cbf9fbc1bbdc C 7a0fb68013f52de0e4ef3bfb0386db325acf59f1b53406911976307d58f35194 C e22587cfde6c4424790d47aa7e7acbfd28d4fee434aeb43139145de93ccb34a5 C 7fdbba389b4b6392ce2c8fe596d9bb067f7cf91539d49d60ed363a85d1d2cdd7 INFO: Device unlocked! INFO: Challenge and response pair being used: C2R_10-02-2007_00:23:14 DEBUG: main, generate file list INFO: Searching for media... INFO: Media found: PICT0001.AVI (1067KB) INFO: Media found: PICT0002.AVI (510KB) DEBUG: get file info, last file DEBUG: end generate file list DEBUG: main, download all movies INFO: Downloading media to /home/dave/saturn_vids/2007.10.22_09.49.37AM/ INFO: Downloading PICT0001.AVI to /home/dave/saturn_vids/2007.10.22_09.49.37AM/PICT0001.AVI ... INFO: Success retrieving file PICT0001.AVI ERROR: failed to bulk read file info INFO: Successfully downloaded all media! DEBUG: main, format DEBUG: main, power down INFO: Powering down device... DEBUG: main, close INFO: Closing any opened devices... INFO: Open devices closed. dave@dave-desktop:~/avidownload/src$ The file it creates is only 64 bytes long and is not a valid avi file. I'll keep looking - maybe I can find something. :)

huh...that's how far my copy, unmodified, got. i didn't even do any of your or billw's changes. i wonder why it worked on my side. i have no idea. in any case, the failed read and the 64 byte long file does contain the first 64 bytes of the avi file. it just quits after it. still looking.

View Full Version: Can't connect to 230 with ops for linux