S
Sietse Fliege
REM said:
<SNIP>
Thanks, REM!
It looks like the latest version is 2.70, released on 29 July 2000.
Downloadable from the author's site:
http://www.pcuf.fi/~heiska/shs/shaid.htm
<SNIP>
Thanks, REM!
It looks like the latest version is 2.70, released on 29 July 2000.
Downloadable from the author's site:
http://www.pcuf.fi/~heiska/shs/shaid.htm
S
Sietse Fliege
Sietse Fliege wrote:
(About Archive Identifier)
For programmers, Dirk Paehl's DPINFO95.DLL may be of interest
http://www.paehl.de/home.htm
"This DLL is for all 32Bit Windows version. This Version identfies 216
archive independent of the extension. incl SFX. (This DLL can be use in
C++, VB, Delphi and so on). Simplyzip and Unpacker use this DLL. The DLL
is 33KB including two demos with source."
(About Archive Identifier)
For programmers, Dirk Paehl's DPINFO95.DLL may be of interest
http://www.paehl.de/home.htm
"This DLL is for all 32Bit Windows version. This Version identfies 216
archive independent of the extension. incl SFX. (This DLL can be use in
C++, VB, Delphi and so on). Simplyzip and Unpacker use this DLL. The DLL
is 33KB including two demos with source."
S
Sietse Fliege
(About Archive Identifier)
There is also the commandline program GT2
http://philip.helger.com/gt/gt2.htm
+ File format analyzer
+ Commandline program
+ Especially for archives (> 50) and executable modifier (~600)
+ Detection of many COM/DOS-EXE/PE-EXE/NE-EXE/LE-EXE modifier and
compiler
+ External data DLL -> easy updates
+ < 5 milliseconds per file on a current machine
There is also the commandline program GT2
http://philip.helger.com/gt/gt2.htm
+ File format analyzer
+ Commandline program
+ Especially for archives (> 50) and executable modifier (~600)
+ Detection of many COM/DOS-EXE/PE-EXE/NE-EXE/LE-EXE modifier and
compiler
+ External data DLL -> easy updates
+ < 5 milliseconds per file on a current machine
J
John Fitzsimons
Excellent detective work REM. 
Or maybe better ....
http://www.pcuf.fi/~heiska/shs/shaid.htm
Version 2.7
Well, an .exe file is IMO a program and/or a compressed file.
So I would have said "list all .exe files on a drive, excluding
sfx of any kind."
It sounds like the above is a good start to solving my query. I don't
however know enough about batch files to adapt the program to do
what I asked for.
Maybe the OP knows enough about programming to create a batch file
and/or GUI to make things work ? If not then hopefully we have a
programmer here with the required expertise.
Regards, John.
Or maybe better ....
http://www.pcuf.fi/~heiska/shs/shaid.htm
Version 2.7
Well, an .exe file is IMO a program and/or a compressed file.
So I would have said "list all .exe files on a drive, excluding
sfx of any kind."
It sounds like the above is a good start to solving my query. I don't
however know enough about batch files to adapt the program to do
what I asked for.
Maybe the OP knows enough about programming to create a batch file
and/or GUI to make things work ? If not then hopefully we have a
programmer here with the required expertise.
Regards, John.
R
REM
Ok, I think I have it straight now. You want a list of each ".exe
file" on a drive that executes a program, but not those that execute
self extraction routines that uncompress files stored in a sfx?
Correct?
I'm pretty rusty in batch myself. I emailed a guy in alt.msdos.batch,
as he seems to enjoy solving such a problem in tutorial form, but I
haven't heard back yet. He would be able to write a professional batch
file that would use the utility, along with correct batch syntax for
Win98-ME, or 2000-XP, depending on what OS the user was using.
I'll be lucky if I can hack it out for XP. I'm going to give it a try
though, and possibly anyone else here that wants to.
It's pretty easy to obtain a text list of all .exe files on a drive:
dir /b /s c:\*.exe > exe.txt
This returns a list with the full file path for each .exe, but they
are in long file name format, which means they will need to be placed
within parenthesis.
C:\PROGRA~1\Adobe\Acrobat 7.0\Reader\AcroRd32.exe
C:\PROGRA~1\Adobe\Acrobat 7.0\Reader\AcroRd32Info.exe
C:\PROGRA~1\Adobe\Acrobat 7.0\Reader\AdobeUpdateManager.exe
C:\PROGRA~1\Adobe\Acrobat 7.0\Reader\reader_sl.exe
C:\PROGRA~1\Adobe\Acrobat 7.0\Reader\Updater\acroaum.exe
Feat 1: To use in a batch file these paths need to be enclosed in
parenthesis, due to spaces within some of the long file paths. This is
a batch requirement:
"C:\PROGRA~1\Adobe\Acrobat 7.0\Reader\AcroRd32.exe"
"C:\PROGRA~1\Adobe\Acrobat 7.0\Reader\AcroRd32Info.exe"
"C:\PROGRA~1\Adobe\Acrobat 7.0\Reader\AdobeUpdateManager.exe"
"C:\PROGRA~1\Adobe\Acrobat 7.0\Reader\reader_sl.exe"
"C:\PROGRA~1\Adobe\Acrobat 7.0\Reader\Updater\acroaum.exe"
It's probably easier for me to do this in C++, but I'll bet there is a
way to do it in batch too.
Feat 2: After the list is prepared a bat file needs to call the
resulting text file as input, with looping, reading one line from this
list in at a time and passing it as a parameter to the utility. If the
file is identified as a sfx, there is no further action taken. If the
file is not identified as any compressed .exe, then a line in the
report needs to be written with the path.
I'm going to play with this and see what I can do. If anyone is more
experienced in batch, why not have a go at it also?
R
REM
Cool! I'll grab that version to work with!
A
Al Klein
The question remains, though: do you have to be insane to be good at
FORTH or does using it drive you insane?
FORTH itself is quite easy to extend. Look at the original breakout
in FORTH - just the verb Breakout, which was an extension of a few
previous words which ... eventually it relied on the primitives.
That's why someone invented Behead, I guess.
A
Al Klein
Would it include compressed files that are just compressed
executables, not installers? And how does one identify an installer
that's an .exe but not compressed?
R
REM
The process of elimination will leave only executable program files
that all known extraction routines with a test switch fail on. Any
file that is successful in testing as an archive will not be listed in
the report.
The utility is pretty nifty! Only the routines for sfx files are
needed. ie: all files tested will have an .exe extension, not .zip,
..arj, etc. The utility has more sfx archivers than I've ever heard of,
so it's highly probable that a list of program executable files will
be the result.
I'm not up at all on "compressed executables." Can you provide a link
for resrarch?
I'm suspecting this refers to a compressed partition, or one of those
programs that compresses .exe files for speed. In this case, if a
known archiver is used to compress a program .exe file, and it
extracts with the test switch, it will be difficult to determine. I
have no compressed program files. Are these common?
It's interesting to kick it around and try to hack out a solution
anyway.
R
REM
Or, are you referring to say, a self extracting file of text files, or
something like that, that does not install anything, and is not a
program file, except for the extraction?
If so, I "think" these are to be excluded, as he only wants a list of
programs that do something, other than extract.
A
Al Klein
Unless those are just compressed programs, not compressed installers.
Meaning that it's not in *known* compressed format.
There aren't that many compressed executables, but more and more
compression schemes will be coming on line, so the program will be
missing more and more valid programs or compressed installations.
BTW, why the insistence on a batch file, when doing it in C (or almost
any 3rd generation language) is almost trivial? Walk the directory
(or the computer) for all .exe files - that's pretty much canned. As
each one is returned, <do whatever>.
A
Al Klein
So any file compressed with a new scheme will be reported as an
executable. Any compressed executable will be unreported.
Phil Katz, I believe, invented the idea. You compress an executable
and hang a decompressor on the front end. The decompressor
decompresses the file on the go, then forks to its (uncompressed)
entry point (in memory). It's basically compressing each file, rather
than compressing the entire volume.
Not very, but it's one of the two ways in which the algorithm will
fail. (Unknown compression signatures is the other way.)
A partial solution is possibly doable - a complete one probably isn't.
Only people who think that it's trivial to tell a compressed
installation from a compressed program from compressed data tend to
think so.
J
John Fitzsimons
Wow ! That would be nice. I use 98SE.
< snip >
Regards, John.
J
John Fitzsimons
If one were able to exclude all .exe files that are compressed then
one should be left with .exe files that aren't compressed.
Regards, John.
R
REM
The program is several years old, so yes, it can miss new archivers.
On the other hand, it has all of the older ones.
True, but the list can greatly narrow the search.
John, is your interest here looking for suspicious .exe files on your
drive? As in spyware\adware that is silently installed, or something
like that?
R
REM
I'm trying C++ now, using a system call to the utility. The utility
..exe identifies the compression, where I originally thought that it
used the test switch.
Have a go at it yourself, if you are interested!
I probably should email the author, who asked to be notified if using
the program. I'll bet that he has some good insight, and possibly the
interest in updating the program.
I
In_Parentheses
Hi John, et all,
Having followed this thread loosely, I may have missed something, but
the aim was to have a list of exe-files (being non-SFX) on a given
system, AFAIK...
No arguing about that logic, however to complicate things: Compressed
exe files aren't necessarilly SFX-files, they might be stand-alone
program files too, compressed to save diskspace.
Now, if there were a program capable of creating such a list, then it
would be great if the list included program files, even if they were
compressed, but would exclude the SFX-type files
I
In_Parentheses
The program is several years old, so yes, it can miss new archivers.
On the other hand, it has all of the older ones.
True, but the list can greatly narrow the search.
John, is your interest here looking for suspicious .exe files on your
drive? As in spyware\adware that is silently installed, or something
like that?
Hi REM!
Although my name ain't John, but the purpose of such a program - for me -
would go beyond that: Think of all the "no-install" programs that can
accumulate on a drive over time; after a certain amount of time a user
may loose his/her view on what's exactly on the system, a program like
tis could restore that.
So, the program could be very well multi-purpose; although its use (if
executed from the Windows environment) would be limited in respect to
finding rootkit using ad/spyware, since they are hidden for the system.
R
REM
I am terrible at physical filing. I lose things as large as books all
of the time.
I have managed to file pretty nicely in my downloading. I use a main
archive directory, with subdirectories named the same as the program.
If the version number is not in the filename I create a subdir with
program name and version. This helps greatly, as I know most of the
program names. There are quite a few that I don't really know, but a
quick scroggle will put me on the right path.
I am having a bit of difficulty in passing long file paths to the bat
file at the moment, but if I get it going the idea will be to boot up
with a boot disk, so it might have some value as a rootkit detector.
The main reason for using a boot disk is that many executables are in
use when the machine is booted from the boot partition. These files
generally return an unspecified error when the program hits them.
NT file systems will require something like the Ultimate Boot CD 4
Win.
Al, I'm passing an array with the bat file name and the path for each
..exe in a system call. I'm placing parens around the path, but it's
not working. The only files that are processing correctly are 8.3
filenames and 8.3 paths:
system(command);
command array =
run.bat "C:\archive\loooooooongname\foo.exe" - no go
run.bat "C:\archive\short\name\bar.exe" - works fine
Any idears?
I
In_Parentheses
Hi REM,
Uhmm, now why does this sound familiar ;-D. I store the programs (or other
items) somewhere, but then I need the system to tell me where the h.ll I
left it <grin>; and that is why this program comes in handy too, to find
all those wonderful, stand-alone, no-install programs again on your hard
drive(s).
Since my download directory resembles very much the structure I eventually
burn to CD, I have added a layer to that structure: a category (for
instance: File Recovery), under which the programs are stored in the
directories similar to the way you do. I also put (in parentheses ;-) ) the
name of the web site I got it from in the directory name, like BlahBlah
1.2.3 (www.blahblah.com), and "Disclib" (available from
http://www.lyrasoftware.com) for for storing the Cd-data and easy
retrieval!
Wasn't there a limit in a command prompt path?
Absolutely right, although "open for read" still should be possible if you
would go along that road; the problems start when you try to write to the
file-in-use (as in deleting it), then the infamous "locked error" appears.
Take NTFS4DOS to create a floppy with full R/W support on NTFS volumes from
DOS (available at:
http://www.datapol-technologies.com/dpe/recovery/ntfs/index.html )
Then you could read the exe-files from the drive and possibly create the
list on the NTFS-volume (so the floppy can be write-protected)
REM, how long is "loooooooongname" plus the remainder of the path??? Is it
<= 128?
I am terrible at physical filing. I lose things as large as books all
of the time.
Uhmm, now why does this sound familiar ;-D. I store the programs (or other
items) somewhere, but then I need the system to tell me where the h.ll I
left it <grin>; and that is why this program comes in handy too, to find
all those wonderful, stand-alone, no-install programs again on your hard
drive(s).
Since my download directory resembles very much the structure I eventually
burn to CD, I have added a layer to that structure: a category (for
instance: File Recovery), under which the programs are stored in the
directories similar to the way you do. I also put (in parentheses ;-) ) the
name of the web site I got it from in the directory name, like BlahBlah
1.2.3 (www.blahblah.com), and "Disclib" (available from
http://www.lyrasoftware.com) for for storing the Cd-data and easy
retrieval!
Wasn't there a limit in a command prompt path?
Absolutely right, although "open for read" still should be possible if you
would go along that road; the problems start when you try to write to the
file-in-use (as in deleting it), then the infamous "locked error" appears.
Take NTFS4DOS to create a floppy with full R/W support on NTFS volumes from
DOS (available at:
http://www.datapol-technologies.com/dpe/recovery/ntfs/index.html )
Then you could read the exe-files from the drive and possibly create the
list on the NTFS-volume (so the floppy can be write-protected)
REM, how long is "loooooooongname" plus the remainder of the path??? Is it
<= 128?