Re: raw disk access
El sáb, 08 de feb de 2003, a las 23:49 +0100, Christian decía que: What about cp /dev/sdx /dev/sdy cp, dd and every command use the system calls, and system calls use the drivers, and i am not sure the drivers don't modify structure. example: step 1) you read a block of data from one of the hard-disks step 2) when you are going to write the block on the other, the sector has a hardware error, so the driver mark the sector as useless and write the information on other sector. The data on both is the same for sure, but the structure is not the same. One solution is to simulate a hard-disk on top of another hard-disk (or memory or whatever), something like a virtual hard-disk that allow you to forget about these hardware differences. -- Alberto Cortés Martín | Ing. en Telecomunicación email: [EMAIL PROTECTED] | Universidad Carlos III Jabber y MSN: alcortes43 | Madrid ICQ#: 101088159 | Spain url: http://montoya.aig.uc3m.es/~acortes/index.html 1A8B 0FE6 2094 8E48 38A2 7785 03CD 07CD 6CA4 E242 msg08609/pgp0.pgp Description: PGP signature
Re: raw disk access
On Mon, 10 Feb 2003 at 01:24:29PM +0100, Alberto Cort?s wrote: cp, dd and every command use the system calls, and system calls use the drivers, and i am not sure the drivers don't modify structure. dd, cat, etc. do modify the structure. One common way I rip an ISO is: cat /dev/cdrom myfile.iso The geometry of the HD and the cdrom are almost certainly different. -- Phil PGP/GPG Key: http://www.zionlth.org/~plhofmei/ wget -O - http://www.zionlth.org/~plhofmei/key.txt | gpg --import -- Excuse #82: Vendor no longer supports the product msg08612/pgp0.pgp Description: PGP signature
Re: raw disk access
On Mon, Feb 10, 2003 at 08:43:22AM -0500, Phillip Hofmeister wrote: On Mon, 10 Feb 2003 at 01:24:29PM +0100, Alberto Cort?s wrote: cp, dd and every command use the system calls, and system calls use the drivers, and i am not sure the drivers don't modify structure. dd, cat, etc. do modify the structure. One common way I rip an ISO is: cat /dev/cdrom myfile.iso The geometry of the HD and the cdrom are almost certainly different. They don't modify any structure. There is no structure, just a linear array of bytes. The partition table says where on the disk the sub-arrays called partitions start and end. There are various ways of addressing this byte array, such as Cylinder/Head/Sector addresses and Linear Block Addressing. These are only used in the partiton table and in PC BIOS APIs. They have no relevance to anything other than fdisk and lilo (and the partition detection code in the kernel). The byte array that is a partition can of course be any sequence of bytes whatsoever, but usually partitions hold filesystems. Filesystems (AFAIK) only use relative offsets; e.g. an ext3 filesystem stores the free block list in terms of where the blocks are relative to the start of the partition, not in terms of CHS or LBA addresses. You can dd a filesystem from a partition into a file, and mount it with the loopback device, without modifying the data from the partition, and it works. (Somebody has probably written a filesystem that deals with absolute disk addresses, but I hope there aren't any like that in common use!) Hard drives don't store their size in the byte array that is accessable. They can report it (as when you run hdparm -I /dev/hdx) via a channel other than normal reads and writes. This is how fdisk can tell how big it should let you make your partitions, not by reading the size of the old partition table. (there won't be a part table on a new hard drive: they come filled with zero bytes (as would result from dd if=/dev/zero of=/dev/hdx)). Also note that CDROMs don't use partition tables. Thus, CDROMs don't have geometry. Incidentally, the data on a CDROM is physically in one long spiral, like a vinyl record. The data is logically broken up into 2kB blocks, each with its own error correction data. (audio CDs use 2352B blocks, with less error correction or something...) The difference between dd and cp is that you can tell dd what block size to use. If you are writing to a flash device, cp (which reads 4kB, then writes 4kB, etc.) will take a lot longer than dd bs=32k. Why? (some) flash devices have a block size of 32kB, so you have to rewrite the whole block to modify any part of it. If you write in small chunks, you have to do several read-modify-write cycles, instead of just one write cycle. Hard drive block sizes are 512B, so cp vs. dd doesn't make a difference. (bigger block sizes results in fewer system calls, and probably lower CPU overhead, though. I usually use dd bs=1024k.) -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , ns.ca) The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces! -- Plautus, 200 BC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: raw disk access
El sáb, 08 de feb de 2003, a las 23:49 +0100, Christian decía que: What about cp /dev/sdx /dev/sdy cp, dd and every command use the system calls, and system calls use the drivers, and i am not sure the drivers don't modify structure. example: step 1) you read a block of data from one of the hard-disks step 2) when you are going to write the block on the other, the sector has a hardware error, so the driver mark the sector as useless and write the information on other sector. The data on both is the same for sure, but the structure is not the same. One solution is to simulate a hard-disk on top of another hard-disk (or memory or whatever), something like a virtual hard-disk that allow you to forget about these hardware differences. -- Alberto Cortés Martín | Ing. en Telecomunicación email: [EMAIL PROTECTED] | Universidad Carlos III Jabber y MSN: alcortes43 | Madrid ICQ#: 101088159 | Spain url: http://montoya.aig.uc3m.es/~acortes/index.html 1A8B 0FE6 2094 8E48 38A2 7785 03CD 07CD 6CA4 E242 pgpO5gYGm16fq.pgp Description: PGP signature
Re: raw disk access
On Mon, Feb 10, 2003 at 08:43:22AM -0500, Phillip Hofmeister wrote: On Mon, 10 Feb 2003 at 01:24:29PM +0100, Alberto Cort?s wrote: cp, dd and every command use the system calls, and system calls use the drivers, and i am not sure the drivers don't modify structure. dd, cat, etc. do modify the structure. One common way I rip an ISO is: cat /dev/cdrom myfile.iso The geometry of the HD and the cdrom are almost certainly different. They don't modify any structure. There is no structure, just a linear array of bytes. The partition table says where on the disk the sub-arrays called partitions start and end. There are various ways of addressing this byte array, such as Cylinder/Head/Sector addresses and Linear Block Addressing. These are only used in the partiton table and in PC BIOS APIs. They have no relevance to anything other than fdisk and lilo (and the partition detection code in the kernel). The byte array that is a partition can of course be any sequence of bytes whatsoever, but usually partitions hold filesystems. Filesystems (AFAIK) only use relative offsets; e.g. an ext3 filesystem stores the free block list in terms of where the blocks are relative to the start of the partition, not in terms of CHS or LBA addresses. You can dd a filesystem from a partition into a file, and mount it with the loopback device, without modifying the data from the partition, and it works. (Somebody has probably written a filesystem that deals with absolute disk addresses, but I hope there aren't any like that in common use!) Hard drives don't store their size in the byte array that is accessable. They can report it (as when you run hdparm -I /dev/hdx) via a channel other than normal reads and writes. This is how fdisk can tell how big it should let you make your partitions, not by reading the size of the old partition table. (there won't be a part table on a new hard drive: they come filled with zero bytes (as would result from dd if=/dev/zero of=/dev/hdx)). Also note that CDROMs don't use partition tables. Thus, CDROMs don't have geometry. Incidentally, the data on a CDROM is physically in one long spiral, like a vinyl record. The data is logically broken up into 2kB blocks, each with its own error correction data. (audio CDs use 2352B blocks, with less error correction or something...) The difference between dd and cp is that you can tell dd what block size to use. If you are writing to a flash device, cp (which reads 4kB, then writes 4kB, etc.) will take a lot longer than dd bs=32k. Why? (some) flash devices have a block size of 32kB, so you have to rewrite the whole block to modify any part of it. If you write in small chunks, you have to do several read-modify-write cycles, instead of just one write cycle. Hard drive block sizes are 512B, so cp vs. dd doesn't make a difference. (bigger block sizes results in fewer system calls, and probably lower CPU overhead, though. I usually use dd bs=1024k.) -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , ns.ca) The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces! -- Plautus, 200 BC
Re: raw disk access
On Sábado, 8 de Febrero de 2003 23:49, Christian Storch wrote: What about cp /dev/sdx /dev/sdy It works very well on two identical drives - - perhaps when the second one is larger, too. You don't need any permissions. The result is really a clone including partition table! I used this from a floppy with a full version of cp. AFAIK, the result is the same as dd'ing it. In different devices, it will fail due to geometrical reasons when the size of the cylinders in each device is different. i.e., different H and S parameters in CHS terminology. However, it will work if: a) They are geomtrically identical devices (same cylinders, heads and sectors). Or b) One device has more cylinders than the other, but they both have the same number of heads and sectors. This is how I see the matter. Of course, I could be wrong. Regards Pope -- Luis Gomez Miralles InfoEmergencias - Technical Department Phone (+34) 654 24 01 34 Fax (+34) 963 49 31 80 [EMAIL PROTECTED] PGP Public Key available at http://www.infoemergencias.com/lgomez.asc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: raw disk access
On Sábado, 8 de Febrero de 2003 23:49, Christian Storch wrote: What about cp /dev/sdx /dev/sdy It works very well on two identical drives - - perhaps when the second one is larger, too. You don't need any permissions. The result is really a clone including partition table! I used this from a floppy with a full version of cp. AFAIK, the result is the same as dd'ing it. In different devices, it will fail due to geometrical reasons when the size of the cylinders in each device is different. i.e., different H and S parameters in CHS terminology. However, it will work if: a) They are geomtrically identical devices (same cylinders, heads and sectors). Or b) One device has more cylinders than the other, but they both have the same number of heads and sectors. This is how I see the matter. Of course, I could be wrong. Regards Pope -- Luis Gomez Miralles InfoEmergencias - Technical Department Phone (+34) 654 24 01 34 Fax (+34) 963 49 31 80 [EMAIL PROTECTED] PGP Public Key available at http://www.infoemergencias.com/lgomez.asc
Re: raw disk access
El mar, 07 de ene de 2003, a las 19:51 -0800, Blars decía que: In article [EMAIL PROTECTED] [EMAIL PROTECTED] writes: i am looking for forensics tools that can be used in computer crime investigations, and am particularly interesting in a tool that provides raw drive (hard, floppy, CD, DVD, etc.) access in order to create complete and accurate drive images. Low level tools are no trick at all. If you are root or root has given you access (recomended), you can use any normal tools (dd, grep, perl) on the appropriate /dev/hd* or /dev/sd* . You can mount the filesystem read-only if you don't want to access deleted files, etc. As far as i know, when u do something like: dd if=/dev/org_dev of=/dev/dest_dev You are pasing through 2 interfaces u don't control, at least u don't have direct control of them. I am talking about the drivers of the devices, which can do some modifications of the data. A look to the drivers, driver_open() driver_close(), driver_read() and so on has to be done to fully understand what they are doing with the data, not to mention the hardware functionality implemented by the hardware, like error checking and other things. I have never look at any hard disk driver but i think u will have to do it if u want to be sure. Maybe u can disable some hardware functionality with some IOCTL. -- Alberto Cortés Martín | Ing. en Telecomunicación email: [EMAIL PROTECTED] | Universidad Carlos III Jabber y MSN: alcortes43 | Madrid ICQ#: 101088159 | Spain url: http://montoya.aig.uc3m.es/~acortes/index.html 1A8B 0FE6 2094 8E48 38A2 7785 03CD 07CD 6CA4 E242 msg08590/pgp0.pgp Description: PGP signature
Re: raw disk access
El mar, 07 de ene de 2003, a las 19:51 -0800, Blars decía que: In article [EMAIL PROTECTED] [EMAIL PROTECTED] writes: i am looking for forensics tools that can be used in computer crime investigations, and am particularly interesting in a tool that provides raw drive (hard, floppy, CD, DVD, etc.) access in order to create complete and accurate drive images. Low level tools are no trick at all. If you are root or root has given you access (recomended), you can use any normal tools (dd, grep, perl) on the appropriate /dev/hd* or /dev/sd* . You can mount the filesystem read-only if you don't want to access deleted files, etc. As far as i know, when u do something like: dd if=/dev/org_dev of=/dev/dest_dev You are pasing through 2 interfaces u don't control, at least u don't have direct control of them. I am talking about the drivers of the devices, which can do some modifications of the data. A look to the drivers, driver_open() driver_close(), driver_read() and so on has to be done to fully understand what they are doing with the data, not to mention the hardware functionality implemented by the hardware, like error checking and other things. I have never look at any hard disk driver but i think u will have to do it if u want to be sure. Maybe u can disable some hardware functionality with some IOCTL. -- Alberto Cortés Martín | Ing. en Telecomunicación email: [EMAIL PROTECTED] | Universidad Carlos III Jabber y MSN: alcortes43 | Madrid ICQ#: 101088159 | Spain url: http://montoya.aig.uc3m.es/~acortes/index.html 1A8B 0FE6 2094 8E48 38A2 7785 03CD 07CD 6CA4 E242 pgpEDDmZhswaD.pgp Description: PGP signature
Re: raw disk access
What about cp /dev/sdx /dev/sdy It works very well on two identical drives - - perhaps when the second one is larger, too. You don't need any permissions. The result is really a clone including partition table! I used this from a floppy with a full version of cp. Christian - Original Message - From: Alberto Cortés [EMAIL PROTECTED] To: Debian-security debian-security@lists.debian.org Sent: Saturday, February 08, 2003 12:43 PM Subject: Re: raw disk access El mar, 07 de ene de 2003, a las 19:51 -0800, Blars decía que: In article [EMAIL PROTECTED] [EMAIL PROTECTED] writes: i am looking for forensics tools that can be used in computer crime investigations, and am particularly interesting in a tool that provides raw drive (hard, floppy, CD, DVD, etc.) access in order to create complete and accurate drive images. Low level tools are no trick at all. If you are root or root has given you access (recomended), you can use any normal tools (dd, grep, perl) on the appropriate /dev/hd* or /dev/sd* . You can mount the filesystem read-only if you don't want to access deleted files, etc. As far as i know, when u do something like: dd if=/dev/org_dev of=/dev/dest_dev You are pasing through 2 interfaces u don't control, at least u don't have direct control of them. I am talking about the drivers of the devices, which can do some modifications of the data. A look to the drivers, driver_open() driver_close(), driver_read() and so on has to be done to fully understand what they are doing with the data, not to mention the hardware functionality implemented by the hardware, like error checking and other things. I have never look at any hard disk driver but i think u will have to do it if u want to be sure. Maybe u can disable some hardware functionality with some IOCTL. ...
Re: raw disk access
yes you can :) On Sun, Jan 12, 2003 at 07:50:38PM +0100, Joshua SS Miller wrote: Just a thought, but could one just use cat? I know that you can write disk image to a floppy with cat, so why should one not be able to cat /dev/hda1 imagefile Any ideas? Thank you, Joshua SS Miller On Mon, 2003-01-13 at 03:19, Jean-Francois Dive wrote: already answered but dd | nc (to send it to another box) is a classical. Otherwise, some other tools can give you as well memory dumps which may sometimes be very usefull. JeF On Tue, Jan 07, 2003 at 10:08:22PM -0500, viv wrote: Hi. As a Debian user, i am posting to this list first in the hopes that what i am looking for can be found as a Debian package. i am looking for forensics tools that can be used in computer crime investigations, and am particularly interesting in a tool that provides raw drive (hard, floppy, CD, DVD, etc.) access in order to create complete and accurate drive images. If such a tool does not exist within Debian, is anyone aware of any application (GPLed, please) that does? Failing that, i am willing to write my own tool, if necessary, and would appreciate any pointers to good reference material (raw drive access and how to work with the images created). If it helps, i am running with the latest 'unstable' packages. Many thanks. -- viv [EMAIL PROTECTED] -- - Jean-Francois Dive -- [EMAIL PROTECTED] There is no such thing as randomness. Only order of infinite complexity. - _The Holographic Universe_, Michael Talbot -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- - Jean-Francois Dive -- [EMAIL PROTECTED] There is no such thing as randomness. Only order of infinite complexity. - _The Holographic Universe_, Michael Talbot -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: raw disk access
yes you can :) On Sun, Jan 12, 2003 at 07:50:38PM +0100, Joshua SS Miller wrote: Just a thought, but could one just use cat? I know that you can write disk image to a floppy with cat, so why should one not be able to cat /dev/hda1 imagefile Any ideas? Thank you, Joshua SS Miller On Mon, 2003-01-13 at 03:19, Jean-Francois Dive wrote: already answered but dd | nc (to send it to another box) is a classical. Otherwise, some other tools can give you as well memory dumps which may sometimes be very usefull. JeF On Tue, Jan 07, 2003 at 10:08:22PM -0500, viv wrote: Hi. As a Debian user, i am posting to this list first in the hopes that what i am looking for can be found as a Debian package. i am looking for forensics tools that can be used in computer crime investigations, and am particularly interesting in a tool that provides raw drive (hard, floppy, CD, DVD, etc.) access in order to create complete and accurate drive images. If such a tool does not exist within Debian, is anyone aware of any application (GPLed, please) that does? Failing that, i am willing to write my own tool, if necessary, and would appreciate any pointers to good reference material (raw drive access and how to work with the images created). If it helps, i am running with the latest 'unstable' packages. Many thanks. -- viv [EMAIL PROTECTED] -- - Jean-Francois Dive -- [EMAIL PROTECTED] There is no such thing as randomness. Only order of infinite complexity. - _The Holographic Universe_, Michael Talbot -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- - Jean-Francois Dive -- [EMAIL PROTECTED] There is no such thing as randomness. Only order of infinite complexity. - _The Holographic Universe_, Michael Talbot
Re: Cryptoswap -- was Re: raw disk access
Hi! * Hubert Chan [EMAIL PROTECTED] [20030115 04:20]: Rolf == Rolf Kutz [EMAIL PROTECTED] writes: Rolf * Quoting Joshua SS Miller ([EMAIL PROTECTED]): Cryptoswap? Hmm sound like something I was thinking about earlier today. Do you have a good resource for this? Rolf http://www.kerneli.org/index.php Do the kerneli modules (officially) work with encrypted swap? I know loop-AES does, but I couldn't find anything about the kerneli (cryptoapi/cryptoloop) modules. (For loop-AES, do a Google search for it.) When encrypting swap, you need to make sure that you don't allocate new memory. Otherwise, it may cause some swapping, which makes you do encryption, which may allocate new memory, ad infinitum. loop-AES takes care of that explicitly, by preallocating memory, but I don't think cryptoapi/cryptoloop does, so you may be taking your chances with it. FUD alert! I like loop-AES, too, and would REALLY love general inclusion into Debian kernels, but this doesn't mean the authors of alternatives are/may be idiots. Please don't spread Fear, Uncertainty and Doubt without referring to facts you're sure of. Leave that to Mickeysoft ;) My EUR 0.02. Count -- Andreas Kotes - ICQ: 3741366 - The views expressed herein are (only) mine. Unser Leben ist das, wozu unser Denken es macht. -- OpenPGP key 0x8F94C228 Our Life is what our thinking makes it.. Your mind is a weapon! Load it .. msg08428/pgp0.pgp Description: PGP signature
Re: Cryptoswap -- was Re: raw disk access
* Quoting Hubert Chan ([EMAIL PROTECTED]): Do the kerneli modules (officially) work with encrypted swap? I know It works for me. encryption, which may allocate new memory, ad infinitum. loop-AES takes care of that explicitly, by preallocating memory, but I don't think cryptoapi/cryptoloop does, so you may be taking your chances with it. You can use loop-jari with it. With loop-aes you're bound to one cipher. YMMV. - rk -- Ahahahahaha! Ahahahaha! Aahahaha! BEWARE! Yrs sincerely The Opera Ghost -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Cryptoswap -- was Re: raw disk access
Andreas == Andreas Kotes [EMAIL PROTECTED] writes: [...] Andreas FUD alert! I like loop-AES, too, and would REALLY love general Andreas inclusion into Debian kernels, but this doesn't mean the Andreas authors of alternatives are/may be idiots. Andreas Please don't spread Fear, Uncertainty and Doubt without Andreas referring to facts you're sure of. Leave that to Mickeysoft ;) I wasn't trying to spread FUD. See how my first sentence was a question, and my use of I couldn't find [information] and I don't think, all of which are asking for more clarification. All I know is that when Jari first announced that loop-AES officially supports swap encryption, and detailed what the issues involved were, he mentioned that cryptoapi did not, at that time, handle things properly. Recently, I searched the kerneli.org page, and did a Google search, and could find nothing resembling an official statement, or even an implication from an official source, that cryptoapi/cryptoloop supports swap encryption. Glancing through the changelogs, I did not find anything that suggested that cryptoapi/cryptoloop supports encrypted swap. The author(s) of cryptoapi were aware of Jari's announcement and, to my knowledge, didn't try to refute anything. You can find all the details on the linux-crypto list (do a Google search for it, and I think it's even linked from the kerneli page), around August 2001. A google search for encrypted swap actually brings Jari's announcement as the first result. (Looking back, I see that there are actually a few relevant posts by Jari, in August/September 2001. If you can point me to an official statement, please let me know. Things to the effect of it works for me don't count, since the issue doesn't seem to be terribly likely to occur. Since you have asked me not to spread FUD without referring to facts, I would ask that you return the same courtesy and not call someone on spreading FUD without referring to facts. -- Hubert Chan [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA Key available at wwwkeys.pgp.net. Encrypted e-mail preferred. msg08431/pgp0.pgp Description: PGP signature
Re: Cryptoswap -- was Re: raw disk access
Hi! * Hubert Chan [EMAIL PROTECTED] [20030115 21:33]: Andreas == Andreas Kotes [EMAIL PROTECTED] writes: Andreas FUD alert! I like loop-AES, too, and would REALLY love general Andreas inclusion into Debian kernels, but this doesn't mean the Andreas authors of alternatives are/may be idiots. Andreas Please don't spread Fear, Uncertainty and Doubt without Andreas referring to facts you're sure of. Leave that to Mickeysoft ;) I wasn't trying to spread FUD. See how my first sentence was a question, and my use of I couldn't find [information] and I don't think, all of which are asking for more clarification. [..] If you can point me to an official statement, please let me know. Things to the effect of it works for me don't count, since the issue doesn't seem to be terribly likely to occur. Since you have asked me not to spread FUD without referring to facts, I would ask that you return the same courtesy and not call someone on spreading FUD without referring to facts. have a look at the sourcecode in e.g. http://www.kernel.org/pub/linux/kernel/people/hvr/testing/patch-int-2.4.20.1.bz2 .. the only places where memory allocation occurs at all is during initialization and when using a digest. for a read or write access memory pointers are set up and are passed to the function implementing the cipher algorithm. none of these do any memory allocation at all, but work on existing memory. no need to find a statment saying `the code does what the code says`. Count -- Andreas Kotes - ICQ: 3741366 - The views expressed herein are (only) mine. Unser Leben ist das, wozu unser Denken es macht. -- OpenPGP key 0x8F94C228 Our Life is what our thinking makes it.. Your mind is a weapon! Load it .. msg08432/pgp0.pgp Description: PGP signature
Re: Cryptoswap -- was Re: raw disk access
Andreas == Andreas Kotes [EMAIL PROTECTED] writes: [...] Andreas have a look at the sourcecode in e.g. Andreas http://www.kernel.org/pub/linux/kernel/people/hvr/testing/patch-int-2.4.20.1.bz2 Thanks. I'll take a look at that. If you don't mind clarifying something for me, what is the relationship between patch-int, and cryptoapi and cryptoloop? -- Hubert Chan [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA Key available at wwwkeys.pgp.net. Encrypted e-mail preferred. msg08433/pgp0.pgp Description: PGP signature
Re: Cryptoswap -- was Re: raw disk access
Andreas == Andreas Kotes [EMAIL PROTECTED] writes: [...] Andreas here's how I understand it: [...] Andreas patch-int is all of the above combined, for (optional) Andreas compilation into the kernel. That would have been my guess too. BTW, I've also grepped through the cryptoapi and cryptoloop sources, and they seem to be only allocating memory at initialization and in the digest functions too (which would be expected). Yay! I guess I'll be setting up encrypted swap soon! :-) Thanks -- Hubert Chan [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA Key available at wwwkeys.pgp.net. Encrypted e-mail preferred. msg08435/pgp0.pgp Description: PGP signature
Re: Cryptoswap -- was Re: raw disk access
Hi! * Martin Hermanowski [EMAIL PROTECTED] [20030116 01:18]: On Wed, Jan 15, 2003 at 06:26:32PM -0500, Hubert Chan wrote: Andreas == Andreas Kotes [EMAIL PROTECTED] writes: Andreas patch-int is all of the above combined, for (optional) Andreas compilation into the kernel. That would have been my guess too. BTW, I've also grepped through the cryptoapi and cryptoloop sources, and they seem to be only allocating memory at initialization and in the digest functions too (which would be expected). Yay! I guess I'll be setting up encrypted swap soon! :-) (sure - patch-int is cryptoapi+cryptoloop+ipsec_tunnel - see http://www.kerneli.org/about/) Is it possible to use swsusp and crypto-swap? I'ld say no, because there is no way for the kernel to get the key before swsusp resumes. d'accord. It there any other way to do this? unless you use nvram or an external (cryptographic) token - no (storing it on harddisk would be ridiculously stupid) .. I know of no current implementation, but this could be done using e.g. Java iButtons, SmartCards (e.g. Schlumberger Cryptoflex), USB Tokens and the like. You'd want to authenticate against the USB Token on resume, thou. Count -- Andreas Kotes - ICQ: 3741366 - The views expressed herein are (only) mine. Unser Leben ist das, wozu unser Denken es macht. -- OpenPGP key 0x8F94C228 Our Life is what our thinking makes it.. Your mind is a weapon! Load it .. msg08437/pgp0.pgp Description: PGP signature
Re: Cryptoswap -- was Re: raw disk access
Hi! * Hubert Chan [EMAIL PROTECTED] [20030115 04:20]: Rolf == Rolf Kutz [EMAIL PROTECTED] writes: Rolf * Quoting Joshua SS Miller ([EMAIL PROTECTED]): Cryptoswap? Hmm sound like something I was thinking about earlier today. Do you have a good resource for this? Rolf http://www.kerneli.org/index.php Do the kerneli modules (officially) work with encrypted swap? I know loop-AES does, but I couldn't find anything about the kerneli (cryptoapi/cryptoloop) modules. (For loop-AES, do a Google search for it.) When encrypting swap, you need to make sure that you don't allocate new memory. Otherwise, it may cause some swapping, which makes you do encryption, which may allocate new memory, ad infinitum. loop-AES takes care of that explicitly, by preallocating memory, but I don't think cryptoapi/cryptoloop does, so you may be taking your chances with it. FUD alert! I like loop-AES, too, and would REALLY love general inclusion into Debian kernels, but this doesn't mean the authors of alternatives are/may be idiots. Please don't spread Fear, Uncertainty and Doubt without referring to facts you're sure of. Leave that to Mickeysoft ;) My EUR 0.02. Count -- Andreas Kotes - ICQ: 3741366 - The views expressed herein are (only) mine. Unser Leben ist das, wozu unser Denken es macht. -- OpenPGP key 0x8F94C228 Our Life is what our thinking makes it.. Your mind is a weapon! Load it .. pgpqXXiCyd3oO.pgp Description: PGP signature
Re: Cryptoswap -- was Re: raw disk access
On Tue, Jan 14, 2003 at 10:08:22PM -0500, Hubert Chan wrote: Rolf == Rolf Kutz [EMAIL PROTECTED] writes: Rolf * Quoting Joshua SS Miller ([EMAIL PROTECTED]): Cryptoswap? Hmm sound like something I was thinking about earlier today. Do you have a good resource for this? Rolf http://www.kerneli.org/index.php Do the kerneli modules (officially) work with encrypted swap? I know loop-AES does, but I couldn't find anything about the kerneli (cryptoapi/cryptoloop) modules. (For loop-AES, do a Google search for it.) When encrypting swap, you need to make sure that you don't allocate new memory. Otherwise, it may cause some swapping, which makes you do encryption, which may allocate new memory, ad infinitum. loop-AES takes care of that explicitly, by preallocating memory, but I don't think cryptoapi/cryptoloop does, so you may be taking your chances with it. Yes they do. I don't know if it's in the current release, but I wrote a sample rc script and notes on it which should be included in the package. I never build a machine without it.
Re: Cryptoswap -- was Re: raw disk access
* Quoting Hubert Chan ([EMAIL PROTECTED]): Do the kerneli modules (officially) work with encrypted swap? I know It works for me. encryption, which may allocate new memory, ad infinitum. loop-AES takes care of that explicitly, by preallocating memory, but I don't think cryptoapi/cryptoloop does, so you may be taking your chances with it. You can use loop-jari with it. With loop-aes you're bound to one cipher. YMMV. - rk -- Ahahahahaha! Ahahahaha! Aahahaha! BEWARE! Yrs sincerely The Opera Ghost
Re: Cryptoswap -- was Re: raw disk access
Andreas == Andreas Kotes [EMAIL PROTECTED] writes: [...] Andreas FUD alert! I like loop-AES, too, and would REALLY love general Andreas inclusion into Debian kernels, but this doesn't mean the Andreas authors of alternatives are/may be idiots. Andreas Please don't spread Fear, Uncertainty and Doubt without Andreas referring to facts you're sure of. Leave that to Mickeysoft ;) I wasn't trying to spread FUD. See how my first sentence was a question, and my use of I couldn't find [information] and I don't think, all of which are asking for more clarification. All I know is that when Jari first announced that loop-AES officially supports swap encryption, and detailed what the issues involved were, he mentioned that cryptoapi did not, at that time, handle things properly. Recently, I searched the kerneli.org page, and did a Google search, and could find nothing resembling an official statement, or even an implication from an official source, that cryptoapi/cryptoloop supports swap encryption. Glancing through the changelogs, I did not find anything that suggested that cryptoapi/cryptoloop supports encrypted swap. The author(s) of cryptoapi were aware of Jari's announcement and, to my knowledge, didn't try to refute anything. You can find all the details on the linux-crypto list (do a Google search for it, and I think it's even linked from the kerneli page), around August 2001. A google search for encrypted swap actually brings Jari's announcement as the first result. (Looking back, I see that there are actually a few relevant posts by Jari, in August/September 2001. If you can point me to an official statement, please let me know. Things to the effect of it works for me don't count, since the issue doesn't seem to be terribly likely to occur. Since you have asked me not to spread FUD without referring to facts, I would ask that you return the same courtesy and not call someone on spreading FUD without referring to facts. -- Hubert Chan [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA Key available at wwwkeys.pgp.net. Encrypted e-mail preferred. pgpAKPIbOjdc0.pgp Description: PGP signature
Re: Cryptoswap -- was Re: raw disk access
Hi! * Hubert Chan [EMAIL PROTECTED] [20030115 21:33]: Andreas == Andreas Kotes [EMAIL PROTECTED] writes: Andreas FUD alert! I like loop-AES, too, and would REALLY love general Andreas inclusion into Debian kernels, but this doesn't mean the Andreas authors of alternatives are/may be idiots. Andreas Please don't spread Fear, Uncertainty and Doubt without Andreas referring to facts you're sure of. Leave that to Mickeysoft ;) I wasn't trying to spread FUD. See how my first sentence was a question, and my use of I couldn't find [information] and I don't think, all of which are asking for more clarification. [..] If you can point me to an official statement, please let me know. Things to the effect of it works for me don't count, since the issue doesn't seem to be terribly likely to occur. Since you have asked me not to spread FUD without referring to facts, I would ask that you return the same courtesy and not call someone on spreading FUD without referring to facts. have a look at the sourcecode in e.g. http://www.kernel.org/pub/linux/kernel/people/hvr/testing/patch-int-2.4.20.1.bz2 .. the only places where memory allocation occurs at all is during initialization and when using a digest. for a read or write access memory pointers are set up and are passed to the function implementing the cipher algorithm. none of these do any memory allocation at all, but work on existing memory. no need to find a statment saying `the code does what the code says`. Count -- Andreas Kotes - ICQ: 3741366 - The views expressed herein are (only) mine. Unser Leben ist das, wozu unser Denken es macht. -- OpenPGP key 0x8F94C228 Our Life is what our thinking makes it.. Your mind is a weapon! Load it .. pgpNMVLOz1Tly.pgp Description: PGP signature
Re: Cryptoswap -- was Re: raw disk access
Andreas == Andreas Kotes [EMAIL PROTECTED] writes: [...] Andreas have a look at the sourcecode in e.g. Andreas http://www.kernel.org/pub/linux/kernel/people/hvr/testing/patch-int-2.4.20.1.bz2 Thanks. I'll take a look at that. If you don't mind clarifying something for me, what is the relationship between patch-int, and cryptoapi and cryptoloop? -- Hubert Chan [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA Key available at wwwkeys.pgp.net. Encrypted e-mail preferred. pgpVMOhtghSjg.pgp Description: PGP signature
Re: Cryptoswap -- was Re: raw disk access
Hi! * Hubert Chan [EMAIL PROTECTED] [20030115 22:55]: Andreas == Andreas Kotes [EMAIL PROTECTED] writes: Andreas have a look at the sourcecode in e.g. Andreas http://www.kernel.org/pub/linux/kernel/people/hvr/testing/patch-int-2.4.20.1.bz2 Thanks. I'll take a look at that. If you don't mind clarifying something for me, what is the relationship between patch-int, and cryptoapi and cryptoloop? here's how I understand it: the cryptoapi is the crypto infrastructure for the kernel, including some ciphers .. this code can be used by other stuff, for example cryptoloop (the loopback crypto device implementation) or ipsec_tunnel. all of this can be compiled as a module, and loaded into (almost) any kernel. patch-int is all of the above combined, for (optional) compilation into the kernel. Count -- Andreas Kotes - ICQ: 3741366 - The views expressed herein are (only) mine. Unser Leben ist das, wozu unser Denken es macht. -- OpenPGP key 0x8F94C228 Our Life is what our thinking makes it.. Your mind is a weapon! Load it .. pgplFh24JFeFU.pgp Description: PGP signature
Re: Cryptoswap -- was Re: raw disk access
Andreas == Andreas Kotes [EMAIL PROTECTED] writes: [...] Andreas here's how I understand it: [...] Andreas patch-int is all of the above combined, for (optional) Andreas compilation into the kernel. That would have been my guess too. BTW, I've also grepped through the cryptoapi and cryptoloop sources, and they seem to be only allocating memory at initialization and in the digest functions too (which would be expected). Yay! I guess I'll be setting up encrypted swap soon! :-) Thanks -- Hubert Chan [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA Key available at wwwkeys.pgp.net. Encrypted e-mail preferred. pgpGpm04yDGiS.pgp Description: PGP signature
Re: Cryptoswap -- was Re: raw disk access
On Wed, Jan 15, 2003 at 06:26:32PM -0500, Hubert Chan wrote: Andreas == Andreas Kotes [EMAIL PROTECTED] writes: [...] Andreas here's how I understand it: [...] Andreas patch-int is all of the above combined, for (optional) Andreas compilation into the kernel. That would have been my guess too. BTW, I've also grepped through the cryptoapi and cryptoloop sources, and they seem to be only allocating memory at initialization and in the digest functions too (which would be expected). Yay! I guess I'll be setting up encrypted swap soon! :-) Is it possible to use swsusp and crypto-swap? I'ld say no, because there is no way for the kernel to get the key before swsusp resumes. It there any other way to do this? Regards, Martin pgpluKYMtpl44.pgp Description: PGP signature
Re: Cryptoswap -- was Re: raw disk access
Hi! * Martin Hermanowski [EMAIL PROTECTED] [20030116 01:18]: On Wed, Jan 15, 2003 at 06:26:32PM -0500, Hubert Chan wrote: Andreas == Andreas Kotes [EMAIL PROTECTED] writes: Andreas patch-int is all of the above combined, for (optional) Andreas compilation into the kernel. That would have been my guess too. BTW, I've also grepped through the cryptoapi and cryptoloop sources, and they seem to be only allocating memory at initialization and in the digest functions too (which would be expected). Yay! I guess I'll be setting up encrypted swap soon! :-) (sure - patch-int is cryptoapi+cryptoloop+ipsec_tunnel - see http://www.kerneli.org/about/) Is it possible to use swsusp and crypto-swap? I'ld say no, because there is no way for the kernel to get the key before swsusp resumes. d'accord. It there any other way to do this? unless you use nvram or an external (cryptographic) token - no (storing it on harddisk would be ridiculously stupid) .. I know of no current implementation, but this could be done using e.g. Java iButtons, SmartCards (e.g. Schlumberger Cryptoflex), USB Tokens and the like. You'd want to authenticate against the USB Token on resume, thou. Count -- Andreas Kotes - ICQ: 3741366 - The views expressed herein are (only) mine. Unser Leben ist das, wozu unser Denken es macht. -- OpenPGP key 0x8F94C228 Our Life is what our thinking makes it.. Your mind is a weapon! Load it .. pgp33I7l32ZAV.pgp Description: PGP signature
Re: raw disk access
On Wed, Jan 08, 2003 at 04:16:58AM +, Andrew Sayers wrote: Or search a floppy disk for intelligible-looking strings: strings /dev/fd0 | less Precisely why one should always use cryptoswap. -- -- Nuke bin Laden: Dale Amon, CEO/MD improve the global Islandone Society gene pool. www.islandone.org --
Cryptoswap -- was Re: raw disk access
Cryptoswap? Hmm sound like something I was thinking about earlier today. Do you have a good resource for this? Thank you, Joshua SS Miller On Tue, 2003-01-14 at 16:15, Dale Amon wrote: On Wed, Jan 08, 2003 at 04:16:58AM +, Andrew Sayers wrote: Or search a floppy disk for intelligible-looking strings: strings /dev/fd0 | less Precisely why one should always use cryptoswap. -- -- Nuke bin Laden: Dale Amon, CEO/MD improve the global Islandone Society gene pool. www.islandone.org -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Cryptoswap -- was Re: raw disk access
* Quoting Joshua SS Miller ([EMAIL PROTECTED]): Cryptoswap? Hmm sound like something I was thinking about earlier today. Do you have a good resource for this? http://www.kerneli.org/index.php - rk -- Ahahahahaha! Ahahahaha! Aahahaha! BEWARE! Yrs sincerely The Opera Ghost
Re: Cryptoswap -- was Re: raw disk access
Rolf == Rolf Kutz [EMAIL PROTECTED] writes: Rolf * Quoting Joshua SS Miller ([EMAIL PROTECTED]): Cryptoswap? Hmm sound like something I was thinking about earlier today. Do you have a good resource for this? Rolf http://www.kerneli.org/index.php Do the kerneli modules (officially) work with encrypted swap? I know loop-AES does, but I couldn't find anything about the kerneli (cryptoapi/cryptoloop) modules. (For loop-AES, do a Google search for it.) When encrypting swap, you need to make sure that you don't allocate new memory. Otherwise, it may cause some swapping, which makes you do encryption, which may allocate new memory, ad infinitum. loop-AES takes care of that explicitly, by preallocating memory, but I don't think cryptoapi/cryptoloop does, so you may be taking your chances with it. -- Hubert Chan [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA Key available at wwwkeys.pgp.net. Encrypted e-mail preferred. pgpconAr587vP.pgp Description: PGP signature
Re: raw disk access
already answered but dd | nc (to send it to another box) is a classical. Otherwise, some other tools can give you as well memory dumps which may sometimes be very usefull. JeF On Tue, Jan 07, 2003 at 10:08:22PM -0500, viv wrote: Hi. As a Debian user, i am posting to this list first in the hopes that what i am looking for can be found as a Debian package. i am looking for forensics tools that can be used in computer crime investigations, and am particularly interesting in a tool that provides raw drive (hard, floppy, CD, DVD, etc.) access in order to create complete and accurate drive images. If such a tool does not exist within Debian, is anyone aware of any application (GPLed, please) that does? Failing that, i am willing to write my own tool, if necessary, and would appreciate any pointers to good reference material (raw drive access and how to work with the images created). If it helps, i am running with the latest 'unstable' packages. Many thanks. -- viv [EMAIL PROTECTED] -- - Jean-Francois Dive -- [EMAIL PROTECTED] There is no such thing as randomness. Only order of infinite complexity. - _The Holographic Universe_, Michael Talbot msg08422/pgp0.pgp Description: PGP signature
Re: raw disk access
already answered but dd | nc (to send it to another box) is a classical. Otherwise, some other tools can give you as well memory dumps which may sometimes be very usefull. JeF On Tue, Jan 07, 2003 at 10:08:22PM -0500, viv wrote: Hi. As a Debian user, i am posting to this list first in the hopes that what i am looking for can be found as a Debian package. i am looking for forensics tools that can be used in computer crime investigations, and am particularly interesting in a tool that provides raw drive (hard, floppy, CD, DVD, etc.) access in order to create complete and accurate drive images. If such a tool does not exist within Debian, is anyone aware of any application (GPLed, please) that does? Failing that, i am willing to write my own tool, if necessary, and would appreciate any pointers to good reference material (raw drive access and how to work with the images created). If it helps, i am running with the latest 'unstable' packages. Many thanks. -- viv [EMAIL PROTECTED] -- - Jean-Francois Dive -- [EMAIL PROTECTED] There is no such thing as randomness. Only order of infinite complexity. - _The Holographic Universe_, Michael Talbot pgpUMWwpOlWQX.pgp Description: PGP signature
Re: raw disk access
Just a thought, but could one just use cat? I know that you can write disk image to a floppy with cat, so why should one not be able to cat /dev/hda1 imagefile Any ideas? Thank you, Joshua SS Miller On Mon, 2003-01-13 at 03:19, Jean-Francois Dive wrote: already answered but dd | nc (to send it to another box) is a classical. Otherwise, some other tools can give you as well memory dumps which may sometimes be very usefull. JeF On Tue, Jan 07, 2003 at 10:08:22PM -0500, viv wrote: Hi. As a Debian user, i am posting to this list first in the hopes that what i am looking for can be found as a Debian package. i am looking for forensics tools that can be used in computer crime investigations, and am particularly interesting in a tool that provides raw drive (hard, floppy, CD, DVD, etc.) access in order to create complete and accurate drive images. If such a tool does not exist within Debian, is anyone aware of any application (GPLed, please) that does? Failing that, i am willing to write my own tool, if necessary, and would appreciate any pointers to good reference material (raw drive access and how to work with the images created). If it helps, i am running with the latest 'unstable' packages. Many thanks. -- viv [EMAIL PROTECTED] -- - Jean-Francois Dive -- [EMAIL PROTECTED] There is no such thing as randomness. Only order of infinite complexity. - _The Holographic Universe_, Michael Talbot
RE: raw disk access
The best that can be achieved is via 'dd'. however it is actually impossible to get _real_ raw disk access due to the disk IO controllers. As far as I know, all disk IO controllers have automatic data correction etc and so do hard disks. An accurate copy of the surface of the disk cannot be gained by this method. Has anyone any ideas on whether it's possible to bypass the automatic checks performed by the IO controllers? Colin Solution City Ltd http://www.solution-city.com -Original Message- From: viv [mailto:[EMAIL PROTECTED]] Sent: 07 January 2003 21:08 To: DebianSecurity Subject: raw disk access Hi. As a Debian user, i am posting to this list first in the hopes that what i am looking for can be found as a Debian package. i am looking for forensics tools that can be used in computer crime investigations, and am particularly interesting in a tool that provides raw drive (hard, floppy, CD, DVD, etc.) access in order to create complete and accurate drive images. If such a tool does not exist within Debian, is anyone aware of any application (GPLed, please) that does? Failing that, i am willing to write my own tool, if necessary, and would appreciate any pointers to good reference material (raw drive access and how to work with the images created). If it helps, i am running with the latest 'unstable' packages. Many thanks. -- viv [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: raw disk access
Thanks to all for your quick replies. i thought originally that dd would work and tried to 'image' a couple of CDs, but they came out to different sizes although both were 650MB CDs. The disk sizes differed by about 3 MB, so i assumed dd was missing something. Imaging 2 floppies yielded different sized images as well. From the replies thus far, it seems that dd is exactly what i am looking for. However, i am still at a loss to explain the differences in image sizes. Does dd copy every bit from a device from start to finish, or does it skip / miss something somewhere? Thanks again. On Wed, 2003-01-08 at 11:29, Colin Ellis wrote: The best that can be achieved is via 'dd'. however it is actually impossible to get _real_ raw disk access due to the disk IO controllers. As far as I know, all disk IO controllers have automatic data correction etc and so do hard disks. An accurate copy of the surface of the disk cannot be gained by this method. Has anyone any ideas on whether it's possible to bypass the automatic checks performed by the IO controllers? Colin Solution City Ltd http://www.solution-city.com -Original Message- From: viv [mailto:[EMAIL PROTECTED]] Sent: 07 January 2003 21:08 To: DebianSecurity Subject: raw disk access Hi. As a Debian user, i am posting to this list first in the hopes that what i am looking for can be found as a Debian package. i am looking for forensics tools that can be used in computer crime investigations, and am particularly interesting in a tool that provides raw drive (hard, floppy, CD, DVD, etc.) access in order to create complete and accurate drive images. If such a tool does not exist within Debian, is anyone aware of any application (GPLed, please) that does? Failing that, i am willing to write my own tool, if necessary, and would appreciate any pointers to good reference material (raw drive access and how to work with the images created). If it helps, i am running with the latest 'unstable' packages. Many thanks. -- viv [EMAIL PROTECTED] -- viv [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
RE: raw disk access
This may have something to do with the block size. I'm not sure of the default options for dd, but it does allow you to specify the size of blocks you are copying. Another thing to check is the options for padding blocks for newline terminated records. You might also need the 'noerror' option. Good Luck :) Colin http://www.solution-city.com -Original Message- From: viv [mailto:[EMAIL PROTECTED]] Sent: 08 January 2003 07:19 To: DebianSecurity Cc: Colin Ellis Subject: RE: raw disk access Thanks to all for your quick replies. i thought originally that dd would work and tried to 'image' a couple of CDs, but they came out to different sizes although both were 650MB CDs. The disk sizes differed by about 3 MB, so i assumed dd was missing something. Imaging 2 floppies yielded different sized images as well. From the replies thus far, it seems that dd is exactly what i am looking for. However, i am still at a loss to explain the differences in image sizes. Does dd copy every bit from a device from start to finish, or does it skip / miss something somewhere? Thanks again. On Wed, 2003-01-08 at 11:29, Colin Ellis wrote: The best that can be achieved is via 'dd'. however it is actually impossible to get _real_ raw disk access due to the disk IO controllers. As far as I know, all disk IO controllers have automatic data correction etc and so do hard disks. An accurate copy of the surface of the disk cannot be gained by this method. Has anyone any ideas on whether it's possible to bypass the automatic checks performed by the IO controllers? Colin Solution City Ltd http://www.solution-city.com -Original Message- From: viv [mailto:[EMAIL PROTECTED]] Sent: 07 January 2003 21:08 To: DebianSecurity Subject: raw disk access Hi. As a Debian user, i am posting to this list first in the hopes that what i am looking for can be found as a Debian package. i am looking for forensics tools that can be used in computer crime investigations, and am particularly interesting in a tool that provides raw drive (hard, floppy, CD, DVD, etc.) access in order to create complete and accurate drive images. If such a tool does not exist within Debian, is anyone aware of any application (GPLed, please) that does? Failing that, i am willing to write my own tool, if necessary, and would appreciate any pointers to good reference material (raw drive access and how to work with the images created). If it helps, i am running with the latest 'unstable' packages. Many thanks. -- viv [EMAIL PROTECTED] -- viv [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: raw disk access
viv [EMAIL PROTECTED] writes: i thought originally that dd would work and tried to 'image' a couple of CDs, but they came out to different sizes although both were 650MB CDs. The disk sizes differed by about 3 MB, so i assumed dd was missing something. Imaging 2 floppies yielded different sized images as well. CDs are different from floppies. It's normal that different CDs have different sizes (and AFAIK, there's no clear end marker, so I wouldn't be surprised if the readable area is larger with some drivers than with others). -- Florian Weimer[EMAIL PROTECTED] University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/ RUS-CERT fax +49-711-685-5898 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: raw disk access
The best that can be achieved is via 'dd'. however it is actually impossible to get _real_ raw disk access due to the disk IO controllers. As far as I know, all disk IO controllers have automatic data correction etc and so do hard disks. An accurate copy of the surface of the disk cannot be gained by this method. Has anyone any ideas on whether it's possible to bypass the automatic checks performed by the IO controllers? Colin Solution City Ltd http://www.solution-city.com -Original Message- From: viv [mailto:[EMAIL PROTECTED] Sent: 07 January 2003 21:08 To: DebianSecurity Subject: raw disk access Hi. As a Debian user, i am posting to this list first in the hopes that what i am looking for can be found as a Debian package. i am looking for forensics tools that can be used in computer crime investigations, and am particularly interesting in a tool that provides raw drive (hard, floppy, CD, DVD, etc.) access in order to create complete and accurate drive images. If such a tool does not exist within Debian, is anyone aware of any application (GPLed, please) that does? Failing that, i am willing to write my own tool, if necessary, and would appreciate any pointers to good reference material (raw drive access and how to work with the images created). If it helps, i am running with the latest 'unstable' packages. Many thanks. -- viv [EMAIL PROTECTED]
RE: raw disk access
Thanks to all for your quick replies. i thought originally that dd would work and tried to 'image' a couple of CDs, but they came out to different sizes although both were 650MB CDs. The disk sizes differed by about 3 MB, so i assumed dd was missing something. Imaging 2 floppies yielded different sized images as well. From the replies thus far, it seems that dd is exactly what i am looking for. However, i am still at a loss to explain the differences in image sizes. Does dd copy every bit from a device from start to finish, or does it skip / miss something somewhere? Thanks again. On Wed, 2003-01-08 at 11:29, Colin Ellis wrote: The best that can be achieved is via 'dd'. however it is actually impossible to get _real_ raw disk access due to the disk IO controllers. As far as I know, all disk IO controllers have automatic data correction etc and so do hard disks. An accurate copy of the surface of the disk cannot be gained by this method. Has anyone any ideas on whether it's possible to bypass the automatic checks performed by the IO controllers? Colin Solution City Ltd http://www.solution-city.com -Original Message- From: viv [mailto:[EMAIL PROTECTED] Sent: 07 January 2003 21:08 To: DebianSecurity Subject: raw disk access Hi. As a Debian user, i am posting to this list first in the hopes that what i am looking for can be found as a Debian package. i am looking for forensics tools that can be used in computer crime investigations, and am particularly interesting in a tool that provides raw drive (hard, floppy, CD, DVD, etc.) access in order to create complete and accurate drive images. If such a tool does not exist within Debian, is anyone aware of any application (GPLed, please) that does? Failing that, i am willing to write my own tool, if necessary, and would appreciate any pointers to good reference material (raw drive access and how to work with the images created). If it helps, i am running with the latest 'unstable' packages. Many thanks. -- viv [EMAIL PROTECTED] -- viv [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
RE: raw disk access
This may have something to do with the block size. I'm not sure of the default options for dd, but it does allow you to specify the size of blocks you are copying. Another thing to check is the options for padding blocks for newline terminated records. You might also need the 'noerror' option. Good Luck :) Colin http://www.solution-city.com -Original Message- From: viv [mailto:[EMAIL PROTECTED] Sent: 08 January 2003 07:19 To: DebianSecurity Cc: Colin Ellis Subject: RE: raw disk access Thanks to all for your quick replies. i thought originally that dd would work and tried to 'image' a couple of CDs, but they came out to different sizes although both were 650MB CDs. The disk sizes differed by about 3 MB, so i assumed dd was missing something. Imaging 2 floppies yielded different sized images as well. From the replies thus far, it seems that dd is exactly what i am looking for. However, i am still at a loss to explain the differences in image sizes. Does dd copy every bit from a device from start to finish, or does it skip / miss something somewhere? Thanks again. On Wed, 2003-01-08 at 11:29, Colin Ellis wrote: The best that can be achieved is via 'dd'. however it is actually impossible to get _real_ raw disk access due to the disk IO controllers. As far as I know, all disk IO controllers have automatic data correction etc and so do hard disks. An accurate copy of the surface of the disk cannot be gained by this method. Has anyone any ideas on whether it's possible to bypass the automatic checks performed by the IO controllers? Colin Solution City Ltd http://www.solution-city.com -Original Message- From: viv [mailto:[EMAIL PROTECTED] Sent: 07 January 2003 21:08 To: DebianSecurity Subject: raw disk access Hi. As a Debian user, i am posting to this list first in the hopes that what i am looking for can be found as a Debian package. i am looking for forensics tools that can be used in computer crime investigations, and am particularly interesting in a tool that provides raw drive (hard, floppy, CD, DVD, etc.) access in order to create complete and accurate drive images. If such a tool does not exist within Debian, is anyone aware of any application (GPLed, please) that does? Failing that, i am willing to write my own tool, if necessary, and would appreciate any pointers to good reference material (raw drive access and how to work with the images created). If it helps, i am running with the latest 'unstable' packages. Many thanks. -- viv [EMAIL PROTECTED] -- viv [EMAIL PROTECTED]
Re: raw disk access
viv [EMAIL PROTECTED] writes: i thought originally that dd would work and tried to 'image' a couple of CDs, but they came out to different sizes although both were 650MB CDs. The disk sizes differed by about 3 MB, so i assumed dd was missing something. Imaging 2 floppies yielded different sized images as well. CDs are different from floppies. It's normal that different CDs have different sizes (and AFAIK, there's no clear end marker, so I wouldn't be surprised if the readable area is larger with some drivers than with others). -- Florian Weimer[EMAIL PROTECTED] University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/ RUS-CERT fax +49-711-685-5898
Re: raw disk access
In article [EMAIL PROTECTED] [EMAIL PROTECTED] writes: i am looking for forensics tools that can be used in computer crime investigations, and am particularly interesting in a tool that provides raw drive (hard, floppy, CD, DVD, etc.) access in order to create complete and accurate drive images. Low level tools are no trick at all. If you are root or root has given you access (recomended), you can use any normal tools (dd, grep, perl) on the appropriate /dev/hd* or /dev/sd* . You can mount the filesystem read-only if you don't want to access deleted files, etc. -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html Text is a way we cheat time. -- Patrick Nielsen Hayden -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: raw disk access
What you're asking for is trivially available on all Linux systems. Through the /dev filesystem, the kernel makes many hardware devices available to ordinary programs. For example, if you had mounted your target disk as the secondary master hard drive, you could create an image of the disk by doing: cp /dev/hdc ~/disk-image Or search a floppy disk for intelligible-looking strings: strings /dev/fd0 | less Note: speaking from experience, it's *very* important to pipe the results to less - you wouldn't believe how many false-positives you get in 1.44MB of data :) You could also make an image of a single partition and mount the image: fdisk -l /dev/hdb (to examine the partition table) cat /dev/hdb1 ~/disk-image mount -o ro,loop ~/disk-image /mnt/misc It is traditional to use dd for direct hardware access because it supports even very complex operations - e.g. to look for text between the 27th and 33rd megabyte from the fourth partition of a SCSI disk, logging your output to logfile, do: dd if=/dev/sda4 bs=1M skip=27 count=6 | strings | tee logfile | less It's a common trick to backup a system by pointing tar straight at a device: tar jcvvf /dev/tape /home/* The program file (yes, it is a confusing name) can be used to diagnose many common file formats, though you have to trick it into looking beyond the fact that it's looking at a device instead of a normal file: cat /dev/cdrom | file If you intend to examine ext2 filesystems which have had files recently deleted, you should look at 'debugfs', and the various undeletion-related HOWTOs available from the LDP. Of course, the other side of the forensic coin is also well represented under Linux. To destroy a file with little or no trace, do: shred filename The /dev filesystem is an example of the general Unix philosophy that everything is either a file or a process. This simple, universal rule makes it possible to use the full range of standard Unix tools everywhere - for example, I can use cat record sound from my microphone and (using inetd) I can create a message-of-the-day server with echo :-) This simplicity even extends to the source-code level. If you do choose to write your own tools, you need only open a device like any other file. The only thing you need to know is that some devices are character special files, which means that they can't be randomly accessed (e.g. it makes no sense to seek to the 5th byte in /dev/mouse). Good luck! - Andrew Sayers msg08397/pgp0.pgp Description: PGP signature
Re: raw disk access
man dd On Tue, 7 Jan 2003, viv wrote: Hi. As a Debian user, i am posting to this list first in the hopes that what i am looking for can be found as a Debian package. i am looking for forensics tools that can be used in computer crime investigations, and am particularly interesting in a tool that provides raw drive (hard, floppy, CD, DVD, etc.) access in order to create complete and accurate drive images. If such a tool does not exist within Debian, is anyone aware of any application (GPLed, please) that does? Failing that, i am willing to write my own tool, if necessary, and would appreciate any pointers to good reference material (raw drive access and how to work with the images created). If it helps, i am running with the latest 'unstable' packages. Many thanks. -- viv [EMAIL PROTECTED] [-] Steve Mickeler [ [EMAIL PROTECTED] ] [|] Todays root password is brought to you by /dev/random [+] 1024D/9AA80CDF = 4103 9E35 2713 D432 924F 3C2E A7B9 A0FE 9AA8 0CDF
Re: raw disk access
Is the `dd` command what you are looking for (in combination with /dev/loop?), or is there some requirement that wasn't mentioned in your message? viv [EMAIL PROTECTED] writes: i am looking for forensics tools that can be used in computer crime investigations, and am particularly interesting in a tool that provides raw drive (hard, floppy, CD, DVD, etc.) access in order to create complete and accurate drive images. If such a tool does not exist within Debian, is anyone aware of any application (GPLed, please) that does? Failing that, i am willing to write my own tool, if necessary, and would appreciate any pointers to good reference material (raw drive access and how to work with the images created). -- /* Dale Southard Jr. [EMAIL PROTECTED] 925-422-1463 fax 422-9429 */ /* Computer Scientist, Advanced Simulation and Computing Program */ /* L-073, Lawrence Livermore National Lab, Livermore CA 94551 */
Re: raw disk access
In article [EMAIL PROTECTED] [EMAIL PROTECTED] writes: i am looking for forensics tools that can be used in computer crime investigations, and am particularly interesting in a tool that provides raw drive (hard, floppy, CD, DVD, etc.) access in order to create complete and accurate drive images. Low level tools are no trick at all. If you are root or root has given you access (recomended), you can use any normal tools (dd, grep, perl) on the appropriate /dev/hd* or /dev/sd* . You can mount the filesystem read-only if you don't want to access deleted files, etc. -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html Text is a way we cheat time. -- Patrick Nielsen Hayden
Re: raw disk access
What you're asking for is trivially available on all Linux systems. Through the /dev filesystem, the kernel makes many hardware devices available to ordinary programs. For example, if you had mounted your target disk as the secondary master hard drive, you could create an image of the disk by doing: cp /dev/hdc ~/disk-image Or search a floppy disk for intelligible-looking strings: strings /dev/fd0 | less Note: speaking from experience, it's *very* important to pipe the results to less - you wouldn't believe how many false-positives you get in 1.44MB of data :) You could also make an image of a single partition and mount the image: fdisk -l /dev/hdb (to examine the partition table) cat /dev/hdb1 ~/disk-image mount -o ro,loop ~/disk-image /mnt/misc It is traditional to use dd for direct hardware access because it supports even very complex operations - e.g. to look for text between the 27th and 33rd megabyte from the fourth partition of a SCSI disk, logging your output to logfile, do: dd if=/dev/sda4 bs=1M skip=27 count=6 | strings | tee logfile | less It's a common trick to backup a system by pointing tar straight at a device: tar jcvvf /dev/tape /home/* The program file (yes, it is a confusing name) can be used to diagnose many common file formats, though you have to trick it into looking beyond the fact that it's looking at a device instead of a normal file: cat /dev/cdrom | file If you intend to examine ext2 filesystems which have had files recently deleted, you should look at 'debugfs', and the various undeletion-related HOWTOs available from the LDP. Of course, the other side of the forensic coin is also well represented under Linux. To destroy a file with little or no trace, do: shred filename The /dev filesystem is an example of the general Unix philosophy that everything is either a file or a process. This simple, universal rule makes it possible to use the full range of standard Unix tools everywhere - for example, I can use cat record sound from my microphone and (using inetd) I can create a message-of-the-day server with echo :-) This simplicity even extends to the source-code level. If you do choose to write your own tools, you need only open a device like any other file. The only thing you need to know is that some devices are character special files, which means that they can't be randomly accessed (e.g. it makes no sense to seek to the 5th byte in /dev/mouse). Good luck! - Andrew Sayers pgpxkDdK5Y9Mn.pgp Description: PGP signature
