Re: Bug#506952: Conflicting package and joining effort.
Le vendredi 28 novembre 2008 à 09:10 +0100, Daniel Baumann a écrit : about rifituti2.. either both the source and binary package will be named rifituti2, then we can upload this alongside to rifituti, and once it passed NEW, remove rifituti. advantage: it's fair against previous upstream to not claim his name and distinguish rifituti and rifituti2, disadvantage it has to pass NEW and that will take a couple of weeks :/ or we just name both source and binary package rifituti by 'hijacking' that. i personally would not prefere this. s/rifituti/rifiuti/g I personally prefer the first solution too. I know some projects that use rifiuti (like ptk for exemple) that could be, one day, included in Debian. As those kind packages would depends on rifiuti, it's better to keep 1 and 2 alongside until all interesting projects have moved to rifiuti2. -- Christophe Monniez [EMAIL PROTECTED] FCCU ___ forensics-devel mailing list forensics-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/forensics-devel
Bug#506952: Conflicting package and joining effort.
Hi, I don't know how to resolve the conflicting problem. I think that my old rifiuti package could be removed from Debian as rifiuti2 has the same functionalities and even more. Or maybe you could rename your binary rifiuti2 to let them coexist. By the way, it maybe a good idea to join the Debian Forensics team so your package could be co-maintained by us. The Debian forensics team/project is based here : http://alioth.debian.org/projects/forensics/ -- Christophe Monniez [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#506952: Conflicting package and joining effort.
Hi, I don't know how to resolve the conflicting problem. I think that my old rifiuti package could be removed from Debian as rifiuti2 has the same functionalities and even more. Or maybe you could rename your binary rifiuti2 to let them coexist. By the way, it maybe a good idea to join the Debian Forensics team so your package could be co-maintained by us. The Debian forensics team/project is based here : http://alioth.debian.org/projects/forensics/ -- Christophe Monniez [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
afflib, libewf, libguytools, guymager
Hi, I'm currently working on the four packages mentionned in the subject. The problem that I'm facing is that they are tied together like that : + afflib optionnaly needs libewf to be more complete + libguytools needs libewf + guymager needs libguytools The problem that I'm facing is that I test the packages building with pbuilder. As pbuilder looks in the build-dpends to automaticaly download the ones needed, I cannot test the build of afflib as it needs libewf which is yet to born. The same problem will occur on the Debian build system. The solution might be to upload those packages in the right order and wait that it comes out officially before sending the next one. But it will make a long time before the last package will arrive in testing. For the pbuilder problem, I did not see any option to add extra-custom packages but I might use another way to test it. Do someone have an idea to solve this kind of problem ? I suppose that a lot of 'big' packages have this kind of problem, so I'm sure that a solution exists. -- Christophe Monniez ___ forensics-devel mailing list forensics-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/forensics-devel
Wrong mode
Hi, It seems that the file '/git/forensics/grokevt.git/hooks/post-receive' has wrong permissions on the alioth server. I thing that's the reason why commit doesn't appear on IRC. Unfortunately, I cannot change the permissions by myself because the owner is hanska-guest : $ ls -lhatr hooks/post-receive -rw-rw-r--+ 1 hanska-guest forensics 48 2008-02-24 21:01 hooks/post-receive Can someone with enough privileges fix that ? Thank you. -- Christophe Monniez ___ forensics-devel mailing list forensics-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/forensics-devel
Re: Wrong mode
On Tue, Sep 16, 2008 at 9:53 AM, Daniel Baumann [EMAIL PROTECTED] wrote: Christophe Monniez wrote: Hi, Hi, It seems that the file '/git/forensics/grokevt.git/hooks/post-receive' has wrong permissions on the alioth server. I thing that's the reason why commit doesn't appear on IRC. yes. Unfortunately, I cannot change the permissions by myself because the owner is hanska-guest : me neither. however, this permission thing is a long standing 'broken-by-design' situation with how git is hosted on alioth. if they would use gitosis, all these problems would dissappear immediately.. (and it sucks to need to get alioth admins to cleanup permissions all the time). since this is not happening anytime soon, i'm hosting my own git repositories on git.debian.net (with gitosis) since january. i was thinking of moving the repositories of debian-forensics to git.debian.net. what do you guys think? If it can solve those kind of problem, I vote for a migration to git.debian.net. -- Christophe Monniez ___ forensics-devel mailing list forensics-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/forensics-devel
Re: Bug#479014: Any news?
Le jeudi 17 juillet 2008 à 19:07 +0200, Michael Prokop a écrit : Hi Christophe, are there any news regarding the packaging of guymager? I'm sitting here with Guy Voncken and he has some preliminary Debian packages of guymager and libguytools available. Is there anything we can do to help in getting guymager/libguytools into Debian's pool? BTW: You also filled several other ITPs where the packages aren't available in Debian yet: #469963 rifiuti #469067 revit #468958 dc3dd #468940 ftimes #469062 recoverdm #469063 md5deep Do you have any concret plans regarding packaging and uploading of the packages? thx regards, -mika- Hi, As Daniel already answered, some of them are ready to upload. Concerning guymager, I have to do some work on them (the first one is to upload in our git repository). Right now, I'm on vacation and I have a little problem to find time to work on the packaging. If you want to help us, you can subscribe to the Debian Forensics project (http://alioth.debian.org/projects/forensics). You will have access to the git repos and help us in packaging if you want. I will try to upload guymager this weekend. -- Christophe Monniez [EMAIL PROTECTED] www.d-fence.be - www.lnx4n6.be ___ forensics-devel mailing list forensics-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/forensics-devel
Bug#479014: Any news?
Le jeudi 17 juillet 2008 à 19:07 +0200, Michael Prokop a écrit : Hi Christophe, are there any news regarding the packaging of guymager? I'm sitting here with Guy Voncken and he has some preliminary Debian packages of guymager and libguytools available. Is there anything we can do to help in getting guymager/libguytools into Debian's pool? BTW: You also filled several other ITPs where the packages aren't available in Debian yet: #469963 rifiuti #469067 revit #468958 dc3dd #468940 ftimes #469062 recoverdm #469063 md5deep Do you have any concret plans regarding packaging and uploading of the packages? thx regards, -mika- Hi, As Daniel already answered, some of them are ready to upload. Concerning guymager, I have to do some work on them (the first one is to upload in our git repository). Right now, I'm on vacation and I have a little problem to find time to work on the packaging. If you want to help us, you can subscribe to the Debian Forensics project (http://alioth.debian.org/projects/forensics). You will have access to the git repos and help us in packaging if you want. I will try to upload guymager this weekend. -- Christophe Monniez [EMAIL PROTECTED] www.d-fence.be - www.lnx4n6.be -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#479014: Any news?
Le jeudi 17 juillet 2008 à 19:07 +0200, Michael Prokop a écrit : Hi Christophe, are there any news regarding the packaging of guymager? I'm sitting here with Guy Voncken and he has some preliminary Debian packages of guymager and libguytools available. Is there anything we can do to help in getting guymager/libguytools into Debian's pool? BTW: You also filled several other ITPs where the packages aren't available in Debian yet: #469963 rifiuti #469067 revit #468958 dc3dd #468940 ftimes #469062 recoverdm #469063 md5deep Do you have any concret plans regarding packaging and uploading of the packages? thx regards, -mika- Hi, As Daniel already answered, some of them are ready to upload. Concerning guymager, I have to do some work on them (the first one is to upload in our git repository). Right now, I'm on vacation and I have a little problem to find time to work on the packaging. If you want to help us, you can subscribe to the Debian Forensics project (http://alioth.debian.org/projects/forensics). You will have access to the git repos and help us in packaging if you want. I will try to upload guymager this weekend. -- Christophe Monniez [EMAIL PROTECTED] www.d-fence.be - www.lnx4n6.be -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
New uploads
Thanks for the fixes and upload Daniel ! -- Christophe Monniez ___ forensics-devel mailing list forensics-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/forensics-devel
Need help
Hi all, I have some problems with some packages and need help. I'm really motivated in fixing the two rc bugs of galetta and pasco. The problem is that git doesn't import empty directories but there is one in the upstream package. It causes errors when the package is build on the debian systems. I don't know how to handle that problem and I'm affraid of making mistakes. My first idea is to add something to create the directory in the debian/rules. If you have any idea, I get it. I also need help for another kind of problem: there is a new upstream version of grokevt. I send a mail to David Paleino who is the first maintainer/uploader. He told me to take the package because he is not interested anymore in Debian forensics. The problem is that I don't know how to handle new upstream versions. If someone can give here the steps to do it the right way, it would be of great help. The last one is not really a problem but a general question: the libewf software (http://www.uitwisselplatform.nl/projects/libewf/) have two different branches: - libewf and - libewf-beta The beta one is sometimes interesting and stable enough to replace the normal one. Is it a possible / a good idea to create a libewf-beta package ? Is it a common practice with other softwares ? I know that we are only a few to read this mailing list but I really need some help to go further. Thanks -- Christophe Monniez ___ forensics-devel mailing list forensics-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/forensics-devel
Accepted missidentify 1.0-1 (source i386)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Fri, 22 Feb 2008 08:16:20 +0100
Source: missidentify
Binary: missidentify
Architecture: source i386
Version: 1.0-1
Distribution: unstable
Urgency: low
Maintainer: Debian Forensics [EMAIL PROTECTED]
Changed-By: Christophe Monniez [EMAIL PROTECTED]
Description:
missidentify - a program to find win32 applications
Closes: 468221
Changes:
missidentify (1.0-1) unstable; urgency=low
.
[ Christophe Monniez ]
* Initial release (Closes: #468221).
* Added the autotools-dev in build depends.
* Removed the rule that was deleteing config.{sub,guess} and was
preventing package to build.
* Closed ITP in changelog
* Corrected a typo in control file.
.
[ Daniel Baumann ]
* Readding removal of config.guess and config.sub in rules.
* Completing binary-arch target dependencies in rules.
* Removing unused debhelper call.
* Removing double space.
* Added missing cflags definitions.
* Removing myself from copyright.
* Correcting version number in changelog.
* Rewrapping package description.
* Readding skipped config.guess and config.sub from upstream sources.
Files:
f4233e9c0922667230e59b80b1848084 843 utils optional missidentify_1.0-1.dsc
229123a59af1b538ec93bc98fc6115b4 117797 utils optional
missidentify_1.0.orig.tar.gz
ded2dfd9d93e6d54b1bccfcf57296fee 2001 utils optional missidentify_1.0-1.diff.gz
ae58fb85678681a8907fa37d555b1a69 12098 utils optional
missidentify_1.0-1_i386.deb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFH5NoH+C5cwEsrK54RAlD+AJwJu5+mx8gfffi+hwDqN/H5YI1CfACeNhYw
DMJ6bQJatPFv7I2pSWP34lQ=
=d5Ba
-END PGP SIGNATURE-
Accepted:
missidentify_1.0-1.diff.gz
to pool/main/m/missidentify/missidentify_1.0-1.diff.gz
missidentify_1.0-1.dsc
to pool/main/m/missidentify/missidentify_1.0-1.dsc
missidentify_1.0-1_i386.deb
to pool/main/m/missidentify/missidentify_1.0-1_i386.deb
missidentify_1.0.orig.tar.gz
to pool/main/m/missidentify/missidentify_1.0.orig.tar.gz
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted ssdeep 1.1-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 25 Jan 2008 10:32:15 +0100 Source: ssdeep Binary: ssdeep Architecture: source i386 Version: 1.1-1 Distribution: unstable Urgency: low Maintainer: Debian Forensics [EMAIL PROTECTED] Changed-By: Christophe Monniez [EMAIL PROTECTED] Description: ssdeep - Recursive piecewise hashing tool Closes: 468956 Changes: ssdeep (1.1-1) unstable; urgency=low . [ Christophe Monniez ] * Initial release (Closes: #468956). . [ Daniel Baumann ] * Moving manpages to FHS location. * Adding ITP bug number to changelog. * Correcting make call in install target of rules. * Removing useless debhelper dirs file. * Rewriting rules. * Rewriting copyright file in machine-readable form. * Adding FILEFORMAT to docs. * Setting architecture to any. * Rewrap package description. * Adding homepage field in control. * Adding vcs fields in control. * Updating maintainer fields. * Changing package section to optional. * Bumping package to standards 3.7.3. * Bumping package to debhelper 6. * Removing useless whitespaces. Files: 439a6a606fd83cfea8729f07552c8cce 785 admin optional ssdeep_1.1-1.dsc 2f68c906c9c73fa3ef43794f8c9edbf4 28329 admin optional ssdeep_1.1.orig.tar.gz 2b1c4c18d7aa229555d5b076d304b1a1 1764 admin optional ssdeep_1.1-1.diff.gz b7998ebe50f3fd715cfc0b960250769c 15042 admin optional ssdeep_1.1-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH5Nwf+C5cwEsrK54RApdDAKCxOlypAn80HPJFlJOlMjvlN6bJmwCfSWzN mr11RCkFeERJ+8okJMaiN3c= =o7yD -END PGP SIGNATURE- Accepted: ssdeep_1.1-1.diff.gz to pool/main/s/ssdeep/ssdeep_1.1-1.diff.gz ssdeep_1.1-1.dsc to pool/main/s/ssdeep/ssdeep_1.1-1.dsc ssdeep_1.1-1_i386.deb to pool/main/s/ssdeep/ssdeep_1.1-1_i386.deb ssdeep_1.1.orig.tar.gz to pool/main/s/ssdeep/ssdeep_1.1.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted galleta 1.0+20040505-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 9 Mar 2008 17:03:24 +0100 Source: galleta Binary: galleta Architecture: source i386 Version: 1.0+20040505-1 Distribution: unstable Urgency: low Maintainer: Debian Forensics [EMAIL PROTECTED] Changed-By: Christophe Monniez [EMAIL PROTECTED] Description: galleta- An Internet Explorer cookie forensic analysis tool Closes: 469949 Changes: galleta (1.0+20040505-1) unstable; urgency=low . [ Christophe Monniez ] * Initial release (Closes: #469949). . [ Daniel Baumann ] * Also removing binary doublette in clean target of rules. * Adding manpage debhelper file to install the manpage. * Calling the upstream makefile in clean target of rules rather than removing the binary manually. * Adjusted some a formating issue on the manpage. * Rewrapping copyright file. * Fixing a few typos in package description. * Adding ITP bug number to changelog. * Corrected version number in changelog. Files: 8ab6ec6a0a081a23a144222b1bb40f04 846 utils optional galleta_1.0+20040505-1.dsc 11bc9258fe571fb54377eca64695651c 2813 utils optional galleta_1.0+20040505.orig.tar.gz b5f69fdd9b9db94a961caf0171183a4d 2712 utils optional galleta_1.0+20040505-1.diff.gz ca285ab768b606ea927febc0293d3694 6366 utils optional galleta_1.0+20040505-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH5ORi+C5cwEsrK54RAlFjAJ0fieTW45da8XowU1HmTSPzWOVrSQCg0JRa T3rwhDni9qPhLre0ITqyDlw= =dyTk -END PGP SIGNATURE- Accepted: galleta_1.0+20040505-1.diff.gz to pool/main/g/galleta/galleta_1.0+20040505-1.diff.gz galleta_1.0+20040505-1.dsc to pool/main/g/galleta/galleta_1.0+20040505-1.dsc galleta_1.0+20040505-1_i386.deb to pool/main/g/galleta/galleta_1.0+20040505-1_i386.deb galleta_1.0+20040505.orig.tar.gz to pool/main/g/galleta/galleta_1.0+20040505.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted pasco 1.0+20040505-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 14 Mar 2008 09:41:41 +0100 Source: pasco Binary: pasco Architecture: source i386 Version: 1.0+20040505-1 Distribution: unstable Urgency: low Maintainer: Debian Forensics [EMAIL PROTECTED] Changed-By: Christophe Monniez [EMAIL PROTECTED] Description: pasco - An Internet Explorer cache forensic analysis tool Closes: 469952 Changes: pasco (1.0+20040505-1) unstable; urgency=low . [ Christophe Monniez ] * Initial release (Closes: #469952). . [ Daniel Baumann ] * Added manpage based on the one from galleta. * Synchronised rules with galleta. * Synchronised copyright with galleta. * Harmonized package description with galleta. * Corrected version number in changelog. * Adding ITP bug number to changelog. Files: 28c1c669fcbe660dafa822bcf04d815a 834 utils optional pasco_1.0+20040505-1.dsc dfcc3932c4d93d90a252159b9d8b525c 4032 utils optional pasco_1.0+20040505.orig.tar.gz 95c728e2ab41de6968d716280d912f1b 2511 utils optional pasco_1.0+20040505-1.diff.gz 41af8cb28e9354d3fa644dd7dbd038fd 7386 utils optional pasco_1.0+20040505-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH5Oj8+C5cwEsrK54RAmyXAKCeGTymrCFb75LDDxf59Wpm8De8vgCfTs7z 1Xdr6IN+yXEkpap3XNzjlF8= =4qDH -END PGP SIGNATURE- Accepted: pasco_1.0+20040505-1.diff.gz to pool/main/p/pasco/pasco_1.0+20040505-1.diff.gz pasco_1.0+20040505-1.dsc to pool/main/p/pasco/pasco_1.0+20040505-1.dsc pasco_1.0+20040505-1_i386.deb to pool/main/p/pasco/pasco_1.0+20040505-1_i386.deb pasco_1.0+20040505.orig.tar.gz to pool/main/p/pasco/pasco_1.0+20040505.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: IEEE 1394 (FireWire) Memory Imaging
Le jeudi 22 février 2007 à 11:28 -0500, Tim a écrit : Hello, I recently came across a fantastic (and alarming) tool kit for reading systems' memory over firewire: http://www.storm.net.nz/projects/16 I just used it to dump memory off of my laptop while booted to both Windows XP and Linux. I'm kinda surprised that this vulnerability hasn't been addressed in these OSes, since it has been known for some time, but I guess it's more of a hardware problem. In any case, I was wondering if anyone has used this technique to capture physical memory in investigations. It seems like it could be quite elegant and minimally intrusive, if well tested. If you have used it, how did you account for the possibility of the suspect system reading/writing your acquisition system's memory? It seems it could go both ways. Secondly, have you had problems with specific OSes? (Windows XP doesn't give up it's RAM, until you trick it into thinking you're a mass storage device, then it works fine for me.) thanks, tim PS- I appologize if this has been covered on the list in the past. Please direct me to appropriate threads if so. Hi, I'm the maintainer of the FCCU GNU/Linux boot CD. (www.lnx4n6.be). We use this technique in investigation (thanks to Metlstorm for his help) and the tools are on the latest version of our boot CD (version 11.0). For using it, you need to have a mass storage device to acquire the ROM from before using it (because I didn't provide a ROM on the boot CD to avoid Copyright problems). As far as I know, for win XP, a user have to be logged in first to have windows recognizing the false mass storage device. And if you want to do it again against the same computer, you have to manually uninstall the device from the windows system (we saw that during demonstration of this technique). The next step (we are looking for that and MetlStorm too), is to find the bytes in the ROM that tell Windows that this is mass storage device. The idea is to make an injector without the need of ROM. Metlstorm is also working on a better interface. -- Christophe Monniez [EMAIL PROTECTED] www.d-fence.be - www.lnx4n6.be
Re: [linux] Dump d'un système
Il faudrait essayer quelque chose du genre sur la machine source (en ajoutant peut-être quelques options pour préserver les liens et les attributs) #(cd / ; tar cpz .) | ssh la-machine-destination '(cd / ; tar xvpz)' Bon, c'est discutable parce que j'ai vérifié et je pond ça un peu à la va vite mais je me souviens avoir fait ce genre de truc pour déplacer un système et ça avait fonctionné. Si tu as les machines sous la main, c'est peut être mieux mettre les disques sur la même machine, de booter avec un cd bootable (www.d-fence.be) et de copier les systèmes d'un disque à l'autre. Ca sera en tous cas plus rapide. Le vendredi 15 avril 2005 à 09:14 +0200, Fabian Vilers a écrit : Bonjour à tous, J'aimerais déplacé un système d'une machine vers une autre. Quel pourrais etre la meilleure technique? Je sais que ce genre de question à déjà été débattue mais je ne retrouve plus le mail. A savoir, les disques n'ont pas la même géométrie et il me sera impossible de déplacer physiquement les disques d'une machine l'autre. Merci pour vos conseils avisés, Fabian ___ Linux Mailing List - http://www.unixtech.be Subscribe/Unsubscribe: http://www.unixtech.be/mailman/listinfo/linux Archives: http://www.mail-archive.com/linux@lists.unixtech.be IRC: chat.unixtech.be:6667 - #unixtech NNTP: news.gname.org - gmane.org.user-groups.linux.unixtech -- Christophe Monniez [EMAIL PROTECTED] or [EMAIL PROTECTED] Web site : http://www.d-fence.be #cat /dev/mouth | grep ^[[:truth:]] Really, I'm not out to destroy Microsoft. That will just be a completely unintentional side effect. -- Linus Torvalds -- ___ Linux Mailing List - http://www.unixtech.be Subscribe/Unsubscribe: http://www.unixtech.be/mailman/listinfo/linux Archives: http://www.mail-archive.com/linux@lists.unixtech.be IRC: chat.unixtech.be:6667 - #unixtech NNTP: news.gname.org - gmane.org.user-groups.linux.unixtech
Re: [linux] Qemu
qemu ne présente pas la carte vidéo de ton système mais bien une émulation d'une carte vidéo générique. C'est donc très difficile de démarrer un XP avec qemu. Il faut soit installer XP au travers de qemu ou l'utiliser pour démarrer des systèmes plus souples comme un linux en mode console par exemple. Pour ma part j'utilise qemu pour tester des live cd (www.d-fence.be par exemple :-) ) et ça marche super bien. Le mardi 12 avril 2005 à 08:23 +0200, Michel a écrit : Bonjour, Y'a t il des utilisateurs Qemu sur la liste. Mon probleme, j'ai installer un :-[ Win XP en qemu, mais apparement il ne trouve pas ma carte video. Merci -- Christophe Monniez [EMAIL PROTECTED] or [EMAIL PROTECTED] Web site : http://www.d-fence.be #cat /dev/mouth | grep ^[[:truth:]] Secret hacker rule #11: hackers read manuals. ___ Linux Mailing List - http://www.unixtech.be Subscribe/Unsubscribe: http://www.unixtech.be/mailman/listinfo/linux Archives: http://www.mail-archive.com/linux@lists.unixtech.be IRC: chat.unixtech.be:6667 - #unixtech NNTP: news.gname.org - gmane.org.user-groups.linux.unixtech
Re: [linux] patern matching en perl : help, par où commencer ?
J'ai fait ce petit script et ça passe :
#!/usr/bin/perl -w
$ip=192.168.50.31;
while ()
{
if ( $_ =~ m{\s+(.*?).*$ip.*}i )
{
print It works\n;
}
}
Nommer le script essai.pl et lancer la commande :
#echo poly1/poly1 192.168.50.31D 255.255.255.255
5060 Unmonitored | ./essai.pl
On dirait que le problème vient de la détection du slash.
Le mercredi 30 mars 2005 à 18:28 +0200, Rémi Letot a écrit :
Hello,
pour le background de l'affaire, il faut savoir que je ne suis pas un
programmeur, et encore moins en perl :-) J'ai trouvé un petit script
perl qui me permet de rebooter à distance des téléphones IP que
j'utilise. Ce script ne fonctionnait pas, et j'ai fini par isoler la
portion du code qui ne fait pas ce qu'elle doit :
if ( $testline =~ m{\s+(.*?)\/.*$_[0].*}i ) {
$extension = $1;
Ce bout de code est dans une procédure qui prend l'adresse ip du
téléphone en argument, et les testline sont du format suivant :
poly1/poly1 192.168.50.31D 255.255.255.255 5060
Unmonitored
Dans cet exemple, le paramètre passé à la procédure est 192.168.50.31,
et extension en sortie doit valoir poly1.
Visiblement la condition if n'est jamais validée (j'ai placé un print
dedans qui ne passe jamais), mais je n'ai pas la moindre idée de ce que
représente ce patern, et encore moins de comment aborder ce truc.
Quelqu'un peut m'aider ou me mettre dans la bonne direction ?
Merci,
--
Christophe Monniez [EMAIL PROTECTED] or [EMAIL PROTECTED]
Web site : http://www.d-fence.be
#cat /dev/mouth | grep ^[[:truth:]]
Of course, the best way to get accurate information on Usenet is to
post something wrong and wait for corrections
-- Matthew Austern --
___
Linux Mailing List - http://www.unixtech.be
Subscribe/Unsubscribe: http://www.unixtech.be/mailman/listinfo/linux
Archives: http://www.mail-archive.com/linux@lists.unixtech.be
IRC: chat.unixtech.be:6667 - #unixtech
NNTP: news.gname.org - gmane.org.user-groups.linux.unixtech
Re: [linux] howto video
mplayer commande pour capturer des jpegs : #mplayer -vo jpeg tonfilm.avi mplayer va alors créer des images jpeg dans le pwd pour chaque frame. Lire la doc pour affiner. Le lundi 28 mars 2005 à 11:59 +0200, Michel a écrit : bonjour, tout le monde et joyeuse Paques je suis a la recherche d'un soft pour faire des captures d'ecran en video. Je voudrais faire des howto demo, de type video, par exemple en divx. Que pouvez vous me conseiller Merci Michel -- Christophe Monniez [EMAIL PROTECTED] or [EMAIL PROTECTED] Web site : http://www.d-fence.be #cat /dev/mouth | grep ^[[:truth:]] Before software can be reusable it first has to be usable. -- Ralph Johnson -- (probably talking about windows) ___ Linux Mailing List - http://www.unixtech.be Subscribe/Unsubscribe: http://www.unixtech.be/mailman/listinfo/linux Archives: http://www.mail-archive.com/linux@lists.unixtech.be IRC: chat.unixtech.be:6667 - #unixtech NNTP: news.gname.org - gmane.org.user-groups.linux.unixtech
[linux] FCCU Boot CD
Pour ceux qui sont intéressé par le computer forensic, j'ai placé le cd bootable que nous utilisons et avons réalisé au FCCU sur www.d-fence.be. C'est un remaster de KNOPPIX. -- Christophe Monniez When all else fails, read the instructions. - L. Iasellio - ___ Linux Mailing List - http://www.unixtech.be Subscribe/Unsubscribe: http://www.unixtech.be/mailman/listinfo/linux Archives: http://www.mail-archive.com/linux@lists.unixtech.be IRC: chat.unixtech.be:6667 - #unixtech NNTP: news.gname.org - gmane.org.user-groups.linux.unixtech
Re: [linux] Re: Migration SuSE Linux 9.0 - SLES9 SUX
Le mer 27/10/2004 à 12:58, Didier MISSON a écrit : Faut arreter les amis. Le support d'une societe, la standardisation, l'utilisation d'un truc qu'on paye avec du service et des certificatiosn et tout le caillon (redhat et suse), c'est logique, plein de sens et tout le monde fait comme tel ! Pk ? Parcequ'une serie de serveurs avec un_peut_de_tout, administre par 1 ou 2 personnes, a leur maniere. Qu'est se qu'elle fait le boite quand vous partez / etes vires / mourrez / bref n'etes plus la (je ne souhaite rien a personne hein:) ? Didier tt à fait exact... c'est bien ce qu'ils visent clairement maintenant. On est des pions interchangeables, dc on ne doit pas être les seuls à connaitre qque chose... donc, faut du standard Tout ca pour dire que ce sont les realites du marche et du monde de l'entreprise. Je prefere debian et de loin mais bon, dans un cadre qui paye il faut se plier a des regles qui sont faites avec un certain bon sens, quand on remet les choses dans leur contexte. Certe oui dans un monde ideal, tout serait ouvert, les applications non propietaires, mais, dans la plupart des environnements, on est pas dans ce monde la et on n'est pas en mesure de decider de ce mettre dans ce monde la. J. PS: va vraiment falloir que je sois attentif car la prochaine etape va etre de venir en cravatte au boulot et parler en ebits et autre language de manager.. Je me fais peur kk fois :) Didier nnnoo pas la cravatte ! Tout, même Window$... mais pas la cravatte... lol ;-) C'est étrange cette histoire de cravatte ! Est-ce que tous les gens qui pratiques l'informatique n'aiment pas les cravates ? Ou est-ce que les gens qui n'aiment pas la cravate se dirigent vers l'informatique pour se réfugier ? J'ai pas vraiment de réponse mais je peux dire que je n'aimais déjà pas les cravates avant d'aimer l'informatique ! -- Christophe Monniez On a long enough timeline, the survival rate for everything drops to zero. -- Fight Club -- ___ Linux Mailing List - http://www.unixtech.be Subscribe/Unsubscribe: http://www.unixtech.be/mailman/listinfo/linux Archives: http://www.mail-archive.com/[EMAIL PROTECTED] IRC: chat.unixtech.be:6667 - #unixtech
Re: [linux] Problème disque dur
Le mar 19/10/2004 à 08:34, Simon van der Linden a écrit : Bonjour à tous ! Linux (Woody avec Kernel 2.6.8) me bouffe mon espace disque petit à petit. J'ai un disque de 2Gb en ext3, mon installation Debian faisait au départ +- 500Mb (sans système X). A ça j'ajoute 300Mb de données personnelles = 800Mb Mon ordinateur tourne 24h/24 et l'espace disque libre ne cesse de diminuer, même quand je ne fais rien dessus. Ainsi, hier soir j'avais libéré 90Mb, je l'ai laissé tourner cette nuit et ce matin mon disque est de nouveau plein !!! Est-ce que l'un de vous à une petite idée de solution ? Merci à ceux qui prendront le temps de lire et de répondre... Il faudrait partir à la recherche du/des fichier(s) qui consomment cet espace ! Par exemple, fait un peu de nettoyage, depuis la racine fait un #du /* -sh Attend quelques heures et relance un #du /* -sh Tu auras déjà une idée de l'endroit où se trouvent les fichiers concernés. Dès que tu as trouvé le(s) répertoire(s) concernés, tu peux faire un #lsof nom_du_repertoire pour voir le process qui utilise ce répertoire. Bonne chance -- Christophe Monniez UNIX is an operating system, OS/2 is half an operating system, Windows is a shell, and DOS is a boot partition virus. - Peter H. Coffin - ___ Linux Mailing List - http://www.unixtech.be Subscribe/Unsubscribe: http://www.unixtech.be/mailman/listinfo/linux Archives: http://www.mail-archive.com/[EMAIL PROTECTED] IRC: chat.unixtech.be:6667 - #unixtech
Re: [linux] Problème disque dur (résolu en partie)
Le mar 19/10/2004 à 21:22, Simon van der Linden a écrit : On Tuesday 19 October 2004 09:20, you wrote: Le mar 19/10/2004 à 08:34, Simon van der Linden a écrit : Bonjour à tous ! Linux (Woody avec Kernel 2.6.8) me bouffe mon espace disque petit à petit. J'ai un disque de 2Gb en ext3, mon installation Debian faisait au départ +- 500Mb (sans système X). A ça j'ajoute 300Mb de données personnelles = 800Mb Mon ordinateur tourne 24h/24 et l'espace disque libre ne cesse de diminuer, même quand je ne fais rien dessus. Ainsi, hier soir j'avais libéré 90Mb, je l'ai laissé tourner cette nuit et ce matin mon disque est de nouveau plein !!! Est-ce que l'un de vous à une petite idée de solution ? Merci à ceux qui prendront le temps de lire et de répondre... Il faudrait partir à la recherche du/des fichier(s) qui consomment cet espace ! Par exemple, fait un peu de nettoyage, depuis la racine fait un #du /* -sh Attend quelques heures et relance un #du /* -sh Tu auras déjà une idée de l'endroit où se trouvent les fichiers concernés. Dès que tu as trouvé le(s) répertoire(s) concernés, tu peux faire un #lsof nom_du_repertoire pour voir le process qui utilise ce répertoire. Bonne chance Merci bcp pour les tuyaux, c'était en fait mon répertoire de log qui pesait exactement 1,17Gb ! J'ai nettoyé le /var/log, il y avait un tas de vieux fichiers en gzip... Mais comment prévenir un tel remplissage? Est-ce normal? Simon van der Linden www.ifmy.net [EMAIL PROTECTED] ___ Linux Mailing List - http://www.unixtech.be Subscribe/Unsubscribe: http://www.unixtech.be/mailman/listinfo/linux Archives: http://www.mail-archive.com/[EMAIL PROTECTED] IRC: chat.unixtech.be:6667 - #unixtech Et bien tu peux automatiser le nettoyage dans ton cron mais n'oublies pas la chose la plus importante : Les logs c'est bien mais il faut quelqu'un pour les lires ! Je veux dire par là que si tu te contentes de nettoyer tes logs sans les lires, autant ne pas utiliser de logs du tout. -- Christophe Monniez On a long enough timeline, the survival rate for everything drops to zero. -- Fight Club -- ___ Linux Mailing List - http://www.unixtech.be Subscribe/Unsubscribe: http://www.unixtech.be/mailman/listinfo/linux Archives: http://www.mail-archive.com/[EMAIL PROTECTED] IRC: chat.unixtech.be:6667 - #unixtech
Re: [linux] Toujours a propos du forensic (OT, je sais)
Donc, si ce que vous dites est vrai et en considerant comme ayant du sens mon hypothese de garder une DB contenant les hashes de mon systeme fraichement installe, cela rend le travail de l'administrateur sensiblement plus lourd car tout est unique! Sauf qu'il y a des logiciels tout fait (libre en plus) qui font une partie du boulot à la place de l'admin. (Calculer les hash sur tous les fichiers intéressants, garder le tout dans une database, vérifier l'intégrité, recalculer le hash lors d'une mise à jour ...) Par exemple : http://la-samhna.de/samhain/ En plus, dans le cas ou ces DB en ligne ou une espece d'autorite certifiante des binaires des systemes existent, il est devenu tres difficile de pouvoir avoir une confirmation que le binaire est pourri sauf avec un peu de chance le resultat d'un string sur le fichier ou meme du reverse-engineering. Sauf qu'il y a des logiciels tout fait (libre en plus) qui font ce boulot de chercher des strings identifiant du code malicieux. Par exemple : http://www.chkrootkit.org/ pour le plus connu mais le link ci-dessus fait ça aussi. Je vois pas trop l'intérêt d'une autorité certifiante, sauf pour du logiciel propriétaire. Pour le libre, le résultat de chaque compilation d'un logiciel va être différent d'une machine à l'autre. Mais si tu hash tes fichiers juste après une installation clean et que tu garde ces hash sur un support inaltérable, pas besoin d'autorité certifiante. Dites-moi si je me trompe! :) Il doit manquer quelque chose dans cette demonstration ;o) Merci /robert ___ Linux Mailing List - http://www.unixtech.be Subscribe/Unsubscribe: http://www.unixtech.be/mailman/listinfo/linux Archives: http://www.mail-archive.com/[EMAIL PROTECTED] IRC: chat.unixtech.be:6667 - #unixtech -- Christophe Monniez On a long enough timeline, the survival rate for everything drops to zero. -- Fight Club -- ___ Linux Mailing List - http://www.unixtech.be Subscribe/Unsubscribe: http://www.unixtech.be/mailman/listinfo/linux Archives: http://www.mail-archive.com/[EMAIL PROTECTED] IRC: chat.unixtech.be:6667 - #unixtech
Re: [linux] Retention des logs pour analyse, evidences et normes
Il n'y a pas (à ma connaissance) d'obligation en matière de preuve. Par exemple, en roulage les constatations de l'agent qualifié font foi jusqu'à preuve du contraire. Pas encore en matière judiciaire MAIS le bon sens et la logique sont de rigueur. Il arrive très régulièrement (et croyant bien faire) que des gestionnaire systèmes nous apporte la preuve sur un plateau dès notre arrivée sur les lieux. A savoir, des logs déjà filtrés par leurs soins. A savoir également, les logs ne sont pas tout (ce n'est pas suffisant). Les HD ne sont pas tout non plus. Nous rédigeons des procès-verbaux dans lesquels nous indiquons un maximum de détails de nos constatations, ce qui permet de corroborer les faits et les preuves que nous découvrons. Nous décrivons aussi le contexte (y compris la configuration des lieux. Les locaux sont ils fermés à clefs, qui à les clefs, les badges, qui a badgé ...) Nous devons également évaluer rapidement la situation, faut il couper les serveurs, les laisser tourner. Si il faut les couper, faut il débrancher la machine ou utiliser un shutdown normal ... Chaque situation est différente et doit être évaluée. Donc, si je peux me permettre de donner quelques conseils : - essayer de ne pas tripoter vous même dans les logs. Je préfère des logs entiers que déjà filtré (en effet, il se peut que l'auteur ait utilisé plusieurs machines pour effectuer son méfait, qu'il ait fait des reconnaissances 5 jours avant (ou plus) qu'il ait commis d'autre fait annexes que vous n'avez pas vu ...) - essayer de manipuler au minimum la machine compromise (voire pas du tout si possible). Dans le cas contraire, noter toute vos actions afin de que lors de nos constatations on puisse faire la différence entre les actions de l'auteur et celle du gestionnaire. (ne pas oublier de noter la date et l'heure exacte des action effectuées) - Ne pas effacer les traces laissées par l'auteur. souvent, les gestionnaire sont pressés par leurs chefs hiérarchiques pour ré-installer rapidement un serveur opérationnel pour les client. Il faut savoir ce que l'on veut, on ne peut avoir le beurre et l'argent du beurre. Essayez dans ce cas de changer le(s) disque(s) dur (même si c'est du RAID ou du LVM) - Contacter rapidement un CCU pour déposer plainte (la plainte n'est pas encore dans les moeurs de toutes les entreprises à cause de l'image de marque, c'est pas à nous de convaincre les patrons mais personnellement, en tant que client, j'aurais plus confiance dans une entreprise qui avoue avoir été piratée que dans une entreprise qui me cacherait la chose. Tôt ou tard, ça se saura de toute façon.) - Pour finir, je dirais qu'il faut toujours essayer de s'imaginer un fait concret par analogie pour chercher à rester logique. Par exemple, s'imaginer un meurtre : La preuve est elle meilleure si l'arme du crime est apportée par un témoin (même s'il n'a pas touché l'arme avec les doigts et qu'il l'a emballée dans un sac plastique ...) que si elle est découverte à l'endroit du crime par un policier ? Ne pas oublier que le policier qui constate n'a normalement aucun intérêt dans l'affaire pour laquelle il fait des constatations. Par contre, il serait facile de critiquer un gestionnaire système qui ferait une partie de l'enquête à la place de la police (filtrer les logs, faire du forensic ...) puisqu'il est impliqué dans l'affaire, qu'il le veuille ou non. Christophe Monniez Enquêteur au FCCU section Opérations Le jeu 23/09/2004 à 16:30, Jean-Francois Dive a écrit : la seule peuve qui vaut vraiment kkchose, se sont les HDD de la machine hackee. quand on forensic, on essaye d'avoir un dump de la memoire, on prends un dump du disque, et on eteint la chose, on prends les HDD, on les met dans de beaux sachets scelles et on commence a partir des dump (dd /dev/XXX | netcat ...) . Ce se serait pas logique que les logs decentralises soient pris comme preuves comme tel. Mais bon, un avocat specialise est la seule personne a meme a repondre aux questions a mon sens, ou alors un membre de votre CCU locale la plus proche (computer crime unit). J. On Thu, Sep 23, 2004 at 04:12:34PM +0200, gotfish wrote: Or, si un jour on se fait haquer, comment certifier nos DB pour que son contenu soit exploitable devant les tribunaux? Y a t'il des OSI quelque chose specifiant ce qui doit etre fait et comment? Aucune idee. Mais est-ce meme seulement necessaire ? Si tu devais deoser une plainte un jour, elle serait fondee sur tes logs qui te Mhhh nee, je n'y crois pas. Quelle est la difference entre un log reellement cree suite a un evenement et un log bidon? Preuve bidon alors? Quelque chose ne colle pas! Juste un peu d'imagination... le type qui est appelle devant les tribunaux ne pourrait il pas dire
Re: [linux] Système de fichier
Je crois qu'il y a un patch pour downgrader vers le kernel de MS Windows si tu veux un système qui écrit directement sur le filesystem sans bufferiser :) Le problème c'est qu'il n'y a pas besoin de panne de courant pour tout bousiller. Le mar 07/09/2004 à 09:42, Fabian Vilers a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rémi Letot wrote: | Un pojnt à tenir à l'oeuil, surtout pour un système embarqué, c'est la | taille du média sur lequel tu vas créer ton FS. Dans l'ordre de grandeur | cartes mémoires, certains FS sont éliminés d'office par la place | qu'ils prennent avant même de stocker des données. | | A+, Merci pour ton expérience. J'ai toujours utilisé ext2/3 et il est vrai que je n'ai jamais rencontré de problèmes même après coupure de courant et autres. Je vais légèrement ré-orienté ma question: existe-t-il un filesystem ou un patch kernel pour obliger l'écriture immédiate des données sur le support? Je me doute que ce genre de système va sacrifier les performances, mais dans quelles mesures? Encore merci à tous, Fabian -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBPWZm3Qzx239StfYRAlYJAKDCTbMWPNjamNbMQ6DDJ4k/0fWFvgCfUUmG VmvIA3uBXzE3HIsticVWK50= =tVhs -END PGP SIGNATURE- -- The information contained in this electronic message may be legally privileged and confidential under applicable law, and is intended only for the use of the individual or entity named above. If the recipient of this message is not the above-named intended recipient, you are hereby notified that any dissemination, copy or disclosure of this communication is strictly prohibited. If you have received this communication in error, please notify Keyware, +32 2 526 16 16 and purge the communication immediately without making any copy or distribution. ___ Linux Mailing List - http://www.unixtech.be Subscribe/Unsubscribe: http://www.unixtech.be/mailman/listinfo/linux Archives: http://www.mail-archive.com/[EMAIL PROTECTED] IRC: chat.unixtech.be:6667 - #unixtech -- Christophe Monniez On a long enough timeline, the survival rate for everything drops to zero. -- Fight Club -- ___ Linux Mailing List - http://www.unixtech.be Subscribe/Unsubscribe: http://www.unixtech.be/mailman/listinfo/linux Archives: http://www.mail-archive.com/[EMAIL PROTECTED] IRC: chat.unixtech.be:6667 - #unixtech
Re: [linux] USB
Salut,
non ce n'est pas normal.
As tu {coupé,déconnecté,débranché} le drive USB avant d'essayer le
remontage ?
Si oui, il est possible que le drive soit alors, par exemple sur
/dev/sdb au lieu de /dev/sda
Christophe Monniez
Le ven 25/06/2004 à 10:48, Jean-Marie Lambert a écrit :
Non, tout le monde ne se repose pas ...
Je répète ma question d'il y a qq jours :
est-il normal de devoir rebooter la SuSE 9.0 pour
redétecter un drive USB qui vient d'être démonté ?
Merci à tous ceux qui veillent...
Jean-Marie Lambert
___
Linux Mailing List - http://www.unixtech.be
Subscribe/Unsubscribe: http://www.unixtech.be/mailman/listinfo/linux
Archives: http://www.mail-archive.com/[EMAIL PROTECTED]
IRC: chat.unixtech.be:6667 - #unixtech
___
Linux Mailing List - http://www.unixtech.be
Subscribe/Unsubscribe: http://www.unixtech.be/mailman/listinfo/linux
Archives: http://www.mail-archive.com/[EMAIL PROTECTED]
IRC: chat.unixtech.be:6667 - #unixtech
