> You mean you haven't done a massive hex/ascii dump yet ;)? We've done > analyzers for over a dozen audit trails, and invariably end up doing that. > This is not a joke. > There are no audit trails that are laid out exactly the way they are > documented. This is a very sad situation. I would say that audit trails weren't initially designed with audit trail analysis in mind. This strangely sounds like "Unix wasn't initially designed with security in mind" ;-) In fact, I am presently designing a generic format converter tool. It receives a (C-like) definition of a native audit trail records and allows to produce automatically the code of a program that converts to ASAX's private format. The fact that audit trails are not always confomant to the specs makes the implementation of the generic converter a more desperate task than I expected. I think it is not realistic to have a fully generic converter, but we hope to cover as a great number of audit trails as possible. > Sun has even managed to make this work across Sparc and Intel byte > architectures! (But you'll need to use their macros, or reverse > engineer them, to get the byte ordering stuff right. Maybe that level > of interest is reserved for us commercial vendors.) Which macros do you mean? Are they documented somewhere ? > If you look in Haystack Labs' email responder, there's a (very old) > body of ANSI C code that is a reference implementation of a > converter from SunOS BSM (virtually identical to Solaris BSM) to > Haystack Labs' svr4++ format. I think that code will save you > a LOT of time. Yes thanks very much Steve, this is most apreciated. --------------------------+------------------------------------- | Abdelaziz Mounji | amo@info.fundp.ac.be | | ASAX project | http://www.info.fundp.ac.be/~amo | | Institut d'Informatique | voice: +32 81 724987 | | University of Namur | Fax : +32 81 724967 | ----------------------------------------------------------------