Question about ripcord

[Joe Emenaker]

So, I discovered RIPCORD last night, the tool that reports the version
numbers of all of the programs on your machine. Got a few questions:

1 - Is it just inspecting the meta-data installed with the packages? If
it is, then isn't that a function which should be rolled into FPKG?
Also, if it is, is it verifying any MD5 or CRC values to make sure that
the binary hasn't been replaced by the user?

2 - I was thinking of writing a little program which would be sort of
like a smart version of STRINGS.EXE (is there a FreeDOS package for
that, by the way?) which would find the strings inside of an EXE or COM
file, select the most "version numbery" of them, and report that. Is
there already a tool that does that?

3 - Is there a way to find out the version of the kernel that's
currently running? I keep a few different kernels as I try to figure out
which one best suits my needs... but I sometimes forget which one I booted.

- Joe


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Freedos-user mailing list
Freedos-user@...
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Bernd Blaauw]

Op 6-11-2009 20:33, Joe Emenaker schreef:
> 1 - Is it just inspecting the meta-data installed with the packages?
> If it is, then isn't that a function which should be rolled into FPKG?
> Also, if it is, is it verifying any MD5 or CRC values to make sure
> that the binary hasn't been replaced by the user?
No idea, didn't look at the sourcecode. To me it looked like a
pre-defined list that was internally kept, then compiled into this
program. The program is pretty old, from beta8 or beta9 era.

> 2 - I was thinking of writing a little program which would be sort of
> like a smart version of STRINGS.EXE (is there a FreeDOS package for
> that, by the way?) which would find the strings inside of an EXE or
> COM file, select the most "version numbery" of them, and report that.
> Is there already a tool that does that?

Don't think so. FreeDOS developers have used/defined many different
version numbering methods for their own programs.

> 3 - Is there a way to find out the version of the kernel that's
> currently running? I keep a few different kernels as I try to figure
> out which one best suits my needs... but I sometimes forget which one
> I booted.

ver /r , but doubt that tells the full story. I remember Bart Oldeman
(kernel developer) mentioning some RERROR tool that would save a
screenshot of fresh booted kernel messages into a textfile. Can't find
the program anymore, it's as hidden as Lucho's TUNZ (Tiny UNZipper)
project nowadays.

Bernd

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Freedos-user mailing list
Freedos-user@...
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Kenneth J. Davis]

On 11/6/09, Bernd Blaauw <bblaauw@...> wrote:
> Op 6-11-2009 20:33, Joe Emenaker schreef:
> > 1 - Is it just inspecting the meta-data installed with the packages?
> > If it is, then isn't that a function which should be rolled into FPKG?
> > Also, if it is, is it verifying any MD5 or CRC values to make sure
> > that the binary hasn't been replaced by the user?
> No idea, didn't look at the sourcecode. To me it looked like a
> pre-defined list that was internally kept, then compiled into this
> program. The program is pretty old, from beta8 or beta9 era.

I would not use it; the existing version does use hard coded
information (and doubtful its been updated) as I never got beyond
including the LSMs in the packages, so never added the parsing logic
for a dynamic version display.

>
> > 2 - I was thinking of writing a little program which would be sort of
> > like a smart version of STRINGS.EXE (is there a FreeDOS package for
> > that, by the way?) which would find the strings inside of an EXE or
> > COM file, select the most "version numbery" of them, and report that.
> > Is there already a tool that does that?
>
> Don't think so. FreeDOS developers have used/defined many different
> version numbering methods for their own programs.

no and it would be difficult to get correct as there is no
standarization for versions, some programs may use basic integers,
other multiple separated numbers, others dates, names or usually some
combination of these

>
> > 3 - Is there a way to find out the version of the kernel that's
> > currently running? I keep a few different kernels as I try to figure
> > out which one best suits my needs... but I sometimes forget which one
> > I booted.
>
> ver /r , but doubt that tells the full story. I remember Bart Oldeman
> (kernel developer) mentioning some RERROR tool that would save a
> screenshot of fresh booted kernel messages into a textfile. Can't find
> the program anymore, it's as hidden as Lucho's TUNZ (Tiny UNZipper)
> project nowadays.
>
> Bernd
>

There is a simple int21h AH=33h AL=FFh call you can make (no program I
know of off hand that does it but from debug you should be able to get
it easy) to get a pointer to the version string displayed at boot.

Something like (completely untested, possibly simpler ways) this in debug:
a
    mov ax, 33ff
    int 21
   <enter on blank line>
t
t
r
d <value in DS>:<value in AX>

All it does is use a to switch debug to assembly mode, input the
instructions to execute the kernel interrupt that returns the version
string, then trace just those two instructions (do not run with g),
display the registers so you can see the values returned in DS:AX, and
then using those values display (dump) the data there.

Jeremy

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Freedos-user mailing list
Freedos-user@...
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Joe Emenaker]

Kenneth J. Davis wrote:

On 11/6/09, Bernd Blaauw bblaauw@... wrote:
  

Op 6-11-2009 20:33, Joe Emenaker schreef:
    

1 - Is it just inspecting the meta-data installed with the packages?
If it is, then isn't that a function which should be rolled into FPKG?
Also, if it is, is it verifying any MD5 or CRC values to make sure
that the binary hasn't been replaced by the user?
      

No idea, didn't look at the sourcecode. To me it looked like a
pre-defined list that was internally kept, then compiled into this
program. The program is pretty old, from beta8 or beta9 era.
    

I would not use it; the existing version does use hard coded
information (and doubtful its been updated) as I never got beyond
including the LSMs in the packages, so never added the parsing logic
for a dynamic version display.
  

Well, here's something that I've been pondering. It wouldn't be tough to write a script to go through all of the FreeDOS packages, generate MD5 hashes from all of the binaries (or maybe *all* files which shouldn't change) and also note the version numbers from the LSM file contained therein. Because the 1.0 release of FreeDOS is the only real official one out there, we wouldn't have to go try to hunt down tons of old versions of packages. These could be put into some big database so that another tool could look up hashes and identify files.

There are a few other advantages that could be reaped from this. In Debian linux, the packages contain a list of all of the MD5's for all non-config files for the package. So, it can be used to catch files which had been modified by viruses (like tripwire for unix)... unless someone writes a virus which goes and updates the MD5 lists. Another handy feature (again, there's a tool in Debian which does this) is that, if there's a list of all of the files that came with a package, we could have a tool which could find stray files which aren't part of any package.

Does this strike anybody as having any kind of merit, or is this just a dumb idea? Given how there's been recent discussion regarding changing the package format (to include binaries and sources, for example), I figure this would be as good a time as any to make any other improvements to the package format.

2 - I was thinking of writing a little program which would be sort of
like a smart version of STRINGS.EXE (is there a FreeDOS package for
that, by the way?) which would find the strings inside of an EXE or
COM file, select the most "version numbery" of them, and report that.
Is there already a tool that does that?
      

Don't think so. FreeDOS developers have used/defined many different
version numbering methods for their own programs.
    

no and it would be difficult to get correct as there is no
standarization for versions, some programs may use basic integers,
other multiple separated numbers, others dates, names or usually some
combination of these
  

True. There'd have to be some kind of fuzzy logic, where it finds different candidate strings and promotes or demotes their probability based upon:
1 - Single or pairs of numbers separated by dots... optionally appended by some alpha chars, like "MyProg 3.02" or "MyProg 3.02pre"
2 - Containing something which looks like a date, "MyProg 3.02pre 2008-02-03"
3 - Containing a string that matches the name of the exe, like "MYPROG.EXE" having "MyProg 3.02".

Sure, it wouldn't work every time. And it would fail for anything which was run through and exe-compressor. But it would sure beat "strings myprog.exe | more", which is what I have to do right now.

- Joe


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Freedos-user mailing list
Freedos-user@...
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Bernd Blaauw]

Op 7-11-2009 0:44, Joe Emenaker schreef:

Sure, it wouldn't work every time. And it would fail for anything which was run through and exe-compressor. But it would sure beat "strings myprog.exe | more", which is what I have to do right now.

how we love UPX (and use it extensively) :)

some programs were updated (like Edit 0.9something) and released without UPX-compression on the executable. For a moment I wondered why I lacked space on bootdisk..

Bernd



------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Freedos-user mailing list
Freedos-user@...
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Christian Masloch]

> There is a simple int21h AH=33h AL=FFh call you can make (no program I
> know of off hand that does it but from debug you should be able to get
> it easy) to get a pointer to the version string displayed at boot.
>
> Something like (completely untested, possibly simpler ways) this in  
> debug:
> a
>     mov ax, 33ff
>     int 21
>    <enter on blank line>
> t
> t
> r
> d <value in DS>:<value in AX>
>
> All it does is use a to switch debug to assembly mode, input the
> instructions to execute the kernel interrupt that returns the version
> string, then trace just those two instructions (do not run with g),
> display the registers so you can see the values returned in DS:AX, and
> then using those values display (dump) the data there.

The pointer is returned in the DX:AX register pair, not DS:AX. With  
FreeDOS DEBUG, the registers can directly be used in the d command, too.  
These lines can be entered on FreeDOS DEBUG's prompt then:

> a
> mov ax, 33ff
> int 21
>t
> t
> d dx:ax

The first ASCII zero (00 in the hex view) ends the returned string. Enter  
a single "q" on DEBUG's prompt to exit DEBUG.

Regards,
Christian

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Freedos-user mailing list
Freedos-user@...
https://lists.sourceforge.net/lists/listinfo/freedos-user