From owner-freebsd-firewire@FreeBSD.ORG Tue Nov 16 22:20:41 2004 Return-Path: Delivered-To: freebsd-firewire@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8BE6E16A4CE for ; Tue, 16 Nov 2004 22:20:41 +0000 (GMT) Received: from main.gmane.org (main.gmane.org [80.91.229.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id E04B043D39 for ; Tue, 16 Nov 2004 22:20:40 +0000 (GMT) (envelope-from freebsd-firewire@m.gmane.org) Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CUBgl-0005Dj-00 for ; Tue, 16 Nov 2004 23:20:39 +0100 Received: from p5480be50.dip.t-dialin.net ([84.128.190.80]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 16 Nov 2004 23:20:39 +0100 Received: from dornseif by p5480be50.dip.t-dialin.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 16 Nov 2004 23:20:39 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-firewire@freebsd.org From: Maximillian Dornseif Date: Tue, 16 Nov 2004 21:30:09 +0100 Lines: 200 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: p5480be50.dip.t-dialin.net User-Agent: Unison/1.0.2a Sender: news cc: freebsd-security@freebsd.org Subject: FireWire Security issues X-BeenThere: freebsd-firewire@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Firewire support in FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2004 22:20:41 -0000 Hello, looking into the issue described in the advisory below I wonder how to tackle this issues. Primarily I ask myself * is there any reason not to filter all physical memory access by default * what would be the appropriate way to change the filter set? a sysctl? Regards Maximillian Dornseif FireWire/IEEE 1394 direct memory access - CAN-2004-1038 Advisory URL: http://pacsec.jp/advisories.html Subject: Potential system compromise by connected FireWire devices CVE #: CAN-2004-1038 Affected: So far all tested Operating Systems with FireWire support Summary: -------- The FireWire/IEEE 1394 specification allows client devices to directly access host memory, bypassing operating system limitations. A malicious client device can read and modify sensitive memory, causing privilege escalation, information leakage and system compromise. Any system with sensitive information or in an unsecured physical location, esp. public access systems, should re-evaluate their system security and consider additional physical security measures if they are equipped with "FireWire" ports. These ports are also called "iLink" on some Sony models. Overview: --------- In the presentation, "0wned by an iPod" which Maximilian Dornseif from Laboratory for Dependable Distributed Systems at RWTH Aachen University held at the PacSec.jp/core04 conference in Tokyo on Nov 11/12, several new techniques involving the IEEE 1394 interface commonly found on laptops, desktops, and some servers were demonstrated. These techniques could be used in both malicious and beneficial applications. The beneficial applications are in the areas of system forensics and external debugging. The malicious applications are that anyone with physical access to the FireWire port could tamper with system operation and compromise security without measures such as power cycling or rebooting. Systems that counted on physical access limitation such as blocking access to reset and power switches and other measures to limit compromise though such procedures as rebooting, need to re-examine their security. As usual, physical access to a computer usually implies the ability for compromise - however, with this new technique, merely plugging in a malicious FireWire client device with special software could be enough to compromise a target. It becomes easier to violate security if the combination of physical access and FireWire interfaces are available. Security policies and procedures should be re-evaluated and consider this new information where needed. Details: -------- Firewire/1394 host adapters which comply to the OHCI specification allow remote devices to initiate direct DMA based memory access to the host computers main memory. This access takes place completely without involvement of the operating system on the host computer. While OHCI supplies certain methods to allow the filtering of such direct memory access requests, most operating systems do not use this filters or do not provide a way for the user to set such filters. This access can be used to read arbitrary memory from a system connected via FireWire and also to modify arbitrary memory contents. Applications of this capability include capture of screen contents, modification of screen contents, induced system crashes, escalation of process privileges and disabling of password queries. A simple application demonstrating screen blanking would look like this: #!/usr/bin/env python # Blank the medium third of a remote computer's screen via FireWire. # Demonstration for an presentation at PacSec 2004, see http://pacsec.jp/ # http://md.hudora.de/presentations/#firewire-pacsec for further # detail. # --Maximillian Dornseif # Take care - this file uses hard coded addresses for just # everything. You will at least have to change values in the addrs # dictionary to suit your own equipment. import sys, time import fw # import simple mapping of Apples FireWire API to Python # module available at http://c0re.23.nu/c0de/pyfw/ # this structure encodes FireWire GUID, start of the actual screen memory # resolution and bits per pixel # example values for a Dell Latitude X 200 running FreeBSD 5.3 addrs = { 0x00065b80030f21aeL: (0xe8000000L, 1024, 768, 4), } # enumerate devices on the FireWire bus and iterate over them for device in fw.scanbus(): print "Found device %r" % (device.guid) if device.guid not in addrs: print "don't now where to look on that machine, add it in the sourcecode" continue else: base, xres, yres, bpp = addrs[device.guid] # we just delete the medium third of the screen for demonstration purposes pos = base + (xres*bpp*(yres/3)) # iterate over screen lines and overwrite them with \0 while pos < base + (xres*bpp*(yres/3)*2): print "\r-> clearing %08x ..." % (pos), device.write(pos, "\0"*(xres*bpp)), sys.stdout.flush() pos += xres*bpp print done Systems Affected: ----------------- We have tested this issue on FreeBSD 5.3 and 5.2.1, MacOS 10.3.5 and 10.3.4 and Knoppix 3.6. All of them allowed memory access and had no obvious way to disable this functionality. We observed that Windows 2000 Professional crashed whenever an Apple Macintosh Computer running MacOS X was connected. Other operating systems where not tested. Any operating system and any hardware with FireWire interfaces should be considered vulnerable as long as statement from the vendor on OHCI filters or similar means of access control are available. Even if the operating system in question does not support the interface, compromise may still be possible if the hardware is powered. Fix: ---- On some systems that require untrusted/unauthenticated physical access by strangers and still require restricted operations, removal of wire headers connecting external case FireWire jacks may provide some limited remigration. On laptops epoxy may be used to permanently disable the external jack if such loss of functionality can be tolerated. The primary precaution is that employees should be warned that they should not plug unknown/untrusted FireWire devices into computers containing sensitive information. Operating system vendors should supply users with a way to control OHCI filters. Default configurations should deny all memory access via FireWire. Credits: -------- * Firestarter by Quinn "The Eskimo!" for demonstrating the potential of FireWire to us - http://www.quinn.echidna.id.au/Quinn/WWW/Hacks.html * Hidetoshi Shimokawa for his FreeBSD FireWire Driver and his revealing post "FireWire for kernel hackers" - http://docs.freebsd.org/cgi/getmsg.cgi?fetch=597886+0+archive/2002/freebsd-hackers/20020414.freebsd-hackers * * Kerneltrap for pointing us to FreeBSD FireWire drivers - http://kerneltrap.org/node/view/145 Contact: -------- Maximillian Dornseif Laboratory for Dependable Distributed Systems RWTH Aachen University, Germany email: dornseif@informatik.rwth-aachen.de Phone: +49-241-80-21431 Web: http://md.hudora.de/ History: -------- - 2004-10-26 initial disclosure - 2004-11-15 updated to contain executive sumary, more details, example code, history and credits section - 2004-11-16 CAN-2004-1038 has been assigned to this issue From owner-freebsd-firewire@FreeBSD.ORG Wed Nov 17 01:40:45 2004 Return-Path: Delivered-To: freebsd-firewire@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8DCF816A4CE; Wed, 17 Nov 2004 01:40:44 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF8FA43D60; Wed, 17 Nov 2004 01:40:43 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 48F7D65211; Wed, 17 Nov 2004 01:40:42 +0000 (GMT) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 36056-02; Wed, 17 Nov 2004 01:40:41 +0000 (GMT) Received: from empiric.dek.spc.org (dhcp120.icir.org [192.150.187.120]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 18410651EB; Wed, 17 Nov 2004 01:40:41 +0000 (GMT) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id 36BFD66A3; Tue, 16 Nov 2004 17:40:37 -0800 (PST) Date: Tue, 16 Nov 2004 17:40:37 -0800 From: Bruce M Simpson To: Maximillian Dornseif Message-ID: <20041117014037.GP1468@empiric.icir.org> Mail-Followup-To: Maximillian Dornseif , freebsd-security@freebsd.org, freebsd-firewire@freebsd.org References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1LKvkjL3sHcu1TtY" Content-Disposition: inline In-Reply-To: cc: freebsd-security@freebsd.org cc: freebsd-firewire@freebsd.org Subject: Re: FireWire Security issues X-BeenThere: freebsd-firewire@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Firewire support in FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2004 01:40:45 -0000 --1LKvkjL3sHcu1TtY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 16, 2004 at 09:30:09PM +0100, Maximillian Dornseif wrote: > looking into the issue described in the advisory below I wonder how to=20 > tackle this issues. Primarily > I ask myself >=20 > * is there any reason not to filter all physical memory access by default > * what would be the appropriate way to change the filter set? a sysctl? This is totally not news, this has been discussed in various circles for the past 5 years, though it's nice to see someone presenting an old attack in a new way. You can only filter the accesses by implementing filter logic in the PCI bridge to main memory to deny the accesses, or the PCI bus arbiter, or failing that, the FireWire to PCI host controller itself. The CPU and operating system are not able to intervene here in any way. Regards, BMS --1LKvkjL3sHcu1TtY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Comment: '' iD8DBQFBmqwUueUpAYYNtTsRApZrAJ9DJzC1b6kBlojXohCfLQOxULm5xgCfUvfI eSN+nOup7hadrXtW0h/oe7c= =mdS6 -----END PGP SIGNATURE----- --1LKvkjL3sHcu1TtY-- From owner-freebsd-firewire@FreeBSD.ORG Wed Nov 17 01:52:36 2004 Return-Path: Delivered-To: freebsd-firewire@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6D97116A4CE; Wed, 17 Nov 2004 01:52:36 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1585843D54; Wed, 17 Nov 2004 01:52:36 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id D18957A41E; Tue, 16 Nov 2004 17:52:35 -0800 (PST) Message-ID: <419AAEE3.9020900@elischer.org> Date: Tue, 16 Nov 2004 17:52:35 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Maximillian Dornseif References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-security@freebsd.org cc: freebsd-firewire@freebsd.org Subject: Re: FireWire Security issues X-BeenThere: freebsd-firewire@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Firewire support in FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2004 01:52:36 -0000 Hi.! yes we've been aware of this problem for a year or so :-) I guess we need to get the filters done.. We do of course use firewire for remote kernel debugging with great success so we need to be able to turn it off sometimes :-) Maximillian Dornseif wrote: > Hello, > > looking into the issue described in the advisory below I wonder how to > tackle this issues. Primarily > I ask myself > > * is there any reason not to filter all physical memory access by default > * what would be the appropriate way to change the filter set? a sysctl? > > Regards > > Maximillian Dornseif > > > > FireWire/IEEE 1394 direct memory access - CAN-2004-1038 > > Advisory URL: http://pacsec.jp/advisories.html > > Subject: Potential system compromise by connected FireWire devices > CVE #: CAN-2004-1038 > Affected: So far all tested Operating Systems with FireWire support > > Summary: > -------- > > The FireWire/IEEE 1394 specification allows client devices to directly > access host > memory, bypassing operating system limitations. A malicious client device > can read and modify sensitive memory, causing privilege escalation, > information leakage and system compromise. Any system with sensitive > information or in an unsecured physical location, esp. public access > systems, should re-evaluate their system security and consider additional > physical security measures if they are equipped with "FireWire" ports. > These ports are also called "iLink" on some Sony models. > > > Overview: > --------- > > In the presentation, "0wned by an iPod" which Maximilian Dornseif from > Laboratory for Dependable Distributed Systems at RWTH Aachen University > held at the PacSec.jp/core04 conference in Tokyo on Nov 11/12, > several new techniques involving the IEEE 1394 interface commonly > found on laptops, desktops, and some servers were demonstrated. > > These techniques could be used in both malicious and beneficial > applications. > The beneficial applications are in the areas of system forensics and > external debugging. The malicious applications are that anyone with > physical access to the FireWire port could tamper with system operation > and compromise security without measures such as power cycling or > rebooting. > > Systems that counted on physical access limitation such as blocking > access > to reset and power switches and other measures to limit compromise though > such procedures as rebooting, need to re-examine their security. > > As usual, physical access to a computer usually implies the ability > for compromise - however, with this new technique, merely plugging > in a malicious FireWire client device with special software > could be enough to compromise a target. It becomes easier to > violate security if the combination of physical access and FireWire > interfaces are available. > > Security policies and procedures should be re-evaluated > and consider this new information where needed. > > > Details: > -------- > > Firewire/1394 host adapters which comply to the OHCI specification > allow remote devices to initiate direct DMA based memory access to the > host computers main memory. This access takes place completely without > involvement of the operating system on the host computer. While > OHCI supplies certain methods to allow the filtering of such direct > memory access requests, most operating systems do not use this filters > or do not provide a way for the user to set such filters. > > This access can be used to read arbitrary memory from a system connected > via FireWire and also to modify arbitrary memory contents. Applications > of this capability include capture of screen > contents, modification of screen contents, induced system crashes, > escalation of process privileges and disabling of password queries. > > A simple application demonstrating screen blanking would look like > this: > > #!/usr/bin/env python > > # Blank the medium third of a remote computer's screen via FireWire. > > # Demonstration for an presentation at PacSec 2004, see http://pacsec.jp/ > # http://md.hudora.de/presentations/#firewire-pacsec for further > # detail. > # --Maximillian Dornseif > > # Take care - this file uses hard coded addresses for just > # everything. You will at least have to change values in the addrs > # dictionary to suit your own equipment. > > import sys, time > import fw # import simple mapping of Apples FireWire API to > Python > # module available at http://c0re.23.nu/c0de/pyfw/ > > # this structure encodes FireWire GUID, start of the actual screen memory > # resolution and bits per pixel > # example values for a Dell Latitude X 200 running FreeBSD 5.3 > addrs = { 0x00065b80030f21aeL: (0xe8000000L, 1024, 768, 4), } > > # enumerate devices on the FireWire bus and iterate over them > for device in fw.scanbus(): > print "Found device %r" % (device.guid) > if device.guid not in addrs: > print "don't now where to look on that machine, add it in the > sourcecode" > continue > else: > base, xres, yres, bpp = addrs[device.guid] > > # we just delete the medium third of the screen for > demonstration purposes > pos = base + (xres*bpp*(yres/3)) > # iterate over screen lines and overwrite them with \0 > while pos < base + (xres*bpp*(yres/3)*2): > print "\r-> clearing %08x ..." % (pos), > device.write(pos, "\0"*(xres*bpp)), > sys.stdout.flush() > pos += xres*bpp > print done > > > > Systems Affected: > ----------------- > > We have tested this issue on FreeBSD 5.3 and 5.2.1, MacOS 10.3.5 and > 10.3.4 and Knoppix 3.6. All of them allowed memory access and had no > obvious way to disable this functionality. We observed that Windows > 2000 Professional crashed whenever an Apple Macintosh Computer running > MacOS X was connected. Other operating systems where not tested. > > Any operating system and any hardware with FireWire interfaces should > be considered vulnerable as long as statement from the vendor on OHCI > filters or similar means of access control are available. Even if the > operating system in question does not support the interface, compromise > may still be possible if the hardware is powered. > > > Fix: > ---- > > On some systems that require untrusted/unauthenticated physical > access by strangers and still require restricted operations, removal > of wire headers connecting external case FireWire jacks may provide > some limited remigration. > > On laptops epoxy may be used to permanently disable the external jack > if such loss of functionality can be tolerated. > > The primary precaution is that employees should be warned that they > should not plug unknown/untrusted FireWire devices into computers > containing sensitive information. > > Operating system vendors should supply users with a way to control > OHCI filters. Default configurations should deny all memory access via > FireWire. > > > Credits: > -------- > > * Firestarter by Quinn "The Eskimo!" for demonstrating the potential > of FireWire to us - http://www.quinn.echidna.id.au/Quinn/WWW/Hacks.html > * Hidetoshi Shimokawa for his FreeBSD FireWire Driver and his > revealing post "FireWire for kernel hackers" - > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=597886+0+archive/2002/freebsd-hackers/20020414.freebsd-hackers > > * > * Kerneltrap for pointing us to FreeBSD FireWire drivers > - http://kerneltrap.org/node/view/145 > > > Contact: > -------- > > Maximillian Dornseif > Laboratory for Dependable Distributed Systems > RWTH Aachen University, Germany > email: dornseif@informatik.rwth-aachen.de > Phone: +49-241-80-21431 > Web: http://md.hudora.de/ > > History: > -------- > > - 2004-10-26 initial disclosure > - 2004-11-15 updated to contain executive sumary, more details, > example code, history and credits section > - 2004-11-16 CAN-2004-1038 has been assigned to this issue > > > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to > "freebsd-security-unsubscribe@freebsd.org" From owner-freebsd-firewire@FreeBSD.ORG Fri Nov 19 12:04:09 2004 Return-Path: Delivered-To: freebsd-firewire@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3EA2A16A4CE for ; Fri, 19 Nov 2004 12:04:09 +0000 (GMT) Received: from ia-notes1.interactive.as (ip-140.interactive.as [195.249.146.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 52D1843D5F for ; Fri, 19 Nov 2004 12:04:08 +0000 (GMT) (envelope-from ts@interactive.as) To: freebsd-firewire@freebsd.org X-Mailer: Lotus Notes Build V70_M2_07222004 Beta 2NP July 22, 2004 Message-ID: From: "Torben =?iso-8859-1?Q?S=F8rensen?=" Date: Fri, 19 Nov 2004 13:03:59 +0100 X-MIMETrack: Serialize by Router on ia-notes1.interactive.as/Interactive(Release 5.0.11 |July 24, 2002) at 19-11-2004 13:04:08 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Subject: /dev/raw1394 and FreeBSD 5.3 X-BeenThere: freebsd-firewire@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Firewire support in FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2004 12:04:09 -0000 Hi, I have a Sony miniDV camera and want to grab movie from the camera (wor= ks with "> fwcontrol -R moviename.dv"), burn the movie to a DVD, take the = DVD disc and put it in my DVD-player and watch it on the tv. I can capture the movie using "> fwcontrol -R moviename.dv" and watch i= t on my monitor but cant convert it to mpeg. I've installed Kino but it will only capture from /dev/raw1394 - I don'= t have a /dev/raw1394. My questions are: How can I mount my firewire to /dev/raw1394? And will it work? Has anyone ever made a DVD movie from a captured DV using fwcontrol -R name.dv ? If yes... how? OS =3D FreeBSD 5.3 Med venlig hilsen Torben S=F8rensen Web/Domino udvikler -------------------------------------------- Par No 1 - interactive a|s Telefon: 8660-0488 Direkte: 8725-5087 Mobil: 2528-6957 ts@interactive.as = From owner-freebsd-firewire@FreeBSD.ORG Fri Nov 19 12:26:35 2004 Return-Path: Delivered-To: freebsd-firewire@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E4E4516A4CE for ; Fri, 19 Nov 2004 12:26:35 +0000 (GMT) Received: from servecml.e-cml.org (servecml.e-cml.org [194.167.168.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C60643D46 for ; Fri, 19 Nov 2004 12:26:35 +0000 (GMT) (envelope-from hmichelon@e-cml.org) Received: (qmail 67682 invoked by uid 98); 19 Nov 2004 12:26:35 -0000 Received: from hmichelon@e-cml.org by servecml.e-cml.org by uid 82 with qmail-scanner-1.22 Clear:RC:1(194.167.168.1):SA:0(?/?):. Processed in 7.065395 secs); 19 Nov 2004 12:26:35 -0000 X-Qmail-Scanner-Mail-From: hmichelon@e-cml.org via servecml.e-cml.org X-Qmail-Scanner: 1.22 (Clear:RC:1(194.167.168.1):SA:0(?/?):. Processed in 7.065395 secs) Received: from unknown (HELO [172.16.0.23]) ([194.167.168.1]) (envelope-sender ) by servecml.e-cml.org (qmail-ldap-1.03) with SMTP for ; 19 Nov 2004 12:26:28 -0000 Message-ID: <419DE699.40908@e-cml.org> Date: Fri, 19 Nov 2004 13:27:05 +0100 From: Henri Michelon Organization: ECML User-Agent: Mozilla Thunderbird 0.9 (X11/20041108) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Torben_S=F8rensen?= References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on servecml.e-cml.org X-Spam-Status: No, score=-102.1 required=12.5 tests=ALL_TRUSTED,AWL,BAYES_00, NO_RDNS2,USER_IN_WHITELIST autolearn=ham version=3.0.1 X-Spam-Level: cc: freebsd-firewire@freebsd.org Subject: Re: /dev/raw1394 and FreeBSD 5.3 X-BeenThere: freebsd-firewire@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Firewire support in FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2004 12:26:36 -0000 Hi, Torben Sørensen wrote: > Hi, > I can capture the movie using "> fwcontrol -R moviename.dv" and watch it on > my monitor but cant convert it to mpeg. > I've installed Kino but it will only capture from /dev/raw1394 - I don't > have a /dev/raw1394. There is no /dev/raw1394 devices on FreeBSD. Just open your .dv (captured with fwcontrol -R or gdvrecv) file with Kino and you will be able to export it in mpeg/divx/etc... HM