Log in

View Full Version : McAfee Proview


Czerno
September 22nd, 2005, 09:57
Hi Reversers !

McAfee's Proview (PV.EXE) is a handy tool for quick viewing/disassembling of DOS/BIOS and other real mode code (& more... The feature that automatically follows a chain of real-mode interrupts for instance is rather unique in such a viewinf tool). The version I have used for many many years is easily found on the net (Google for it; using it freely is even legal, I believe...) For reference, the 'About' box says :

PROVIEW (tm) Version 1.2 Copyright 1992-93 by McAfee Assoc.

The only drawback with this version is this : the disassembler only knows 16-bit, 80286 operations. Strange thing considering the date on the copyright notice!

Do some know of a more uptodate version of this tool which should meaningfully disassemble 386+ opcodes and addressing modes (numerous in modern BIOS code) ?

Has somebody thought of 'reversing' the Proview itself with a goal of adding such extended disassembling (or other) capabilities ?

I mentionned the fascinating interrupt auto-following feature; I would love to rip the piece of code that does it in order to study and possibly adapt it to other tasks. Do you know of good accessible code with similar function ? I'm not into virvs coding - but I guess a 'good' virvs must be able to follow DOS interrupts.

In expectation,

--
Czerno

Kayaker
September 23rd, 2005, 18:52
Hi Czerno,

I found the proggy on Simtel and installed it on Win98 under VMWare. Can't say I fully understood everything I was looking at, but interesting nonetheless . I'm not sure if I figured out exactly what this "interrupt auto-following feature" is. Is that what you see when you view the list of interrupts and double-click on one of them?

In any case, what you describe sounds like "tunneling", would that be how that feature is implemented? To quote from "The Art of Tunneling":

"Tunneling collectively refers to the techniques, algorithms, and ways of tracing code attached to a particular interrupt, and then finding the original DOS/BIOS code."

If so, perhaps you can figure out how it's done and apply the techniques. Another article on the subject of tunneling, which I only know in passing, is "Single Stepping Tunnel Techniques". Googling with the words 'tunneling + virus' should dig up more info as well.


I don't know if this is of any use either, but I've got an article titled
A Study of BIOS Interrupts as used by Microsoft Windows 2000
by Adam Sulmicki
http://www.eax.com

In it he uses a debugger called SourcePoint, which still exists, perhaps it might be of some use to you.

Regards,
Kayaker

Czerno
September 25th, 2005, 04:16
Quote:
[Originally Posted by Kayaker] I'm not sure if I figured out exactly what this "interrupt auto-following feature" is. Is that what you see when you view the list of interrupts and double-click on one of them?


No, double-clicking takes you to the disassembly of the actual active handler for selected interrupt; no great feat!

To see the feature I dubbed "auto follow interrupt chain" or auto-trace, for lack of a best moniker, you do the following steps inside of Proview :

- open the Interrupts window ( Alt_M I)
- in the list, select (single click) an interrupt, one that has a little mark in the second column, just after its number ( try int 10 or int 21 or int 2F, for instances)
- Ctl_Enter the selected line ! A box will open, showing the chain of the selected interrupt. Very impressive and generally accurate analysis.

I assume it is static code flow analysis they do, i.e. I do not believe they can do a live trace of the selected interrupt - and it works on a 80286, which mean no debug registers in CPU, the only kind of live tracing they could achieve would be by manipulating the Trace flag.

Quote:
In any case, what you describe sounds like "tunneling", would that be how that feature is implemented?


Hadn't heard the word tunneling used in this context, but yep, sounds like it.
Thank you for the lead and references :=)

Best,

--
Czerno <czernobyl AT mail.ru>

LLXX
September 28th, 2005, 20:41
You mentioned attempting to reverse the dasm and add new opcodes to it. That is, unfortunately, going to be rather difficult to do, as an inspection of the file (PKlite, I unpacked it first...) yields no obvious mnemonic table. This isn't a simple table-driven dasm like the one in the old DEBUG - it looks more like a code-only implementation with cmp, xlat, and jcc instructions.

Czerno
September 29th, 2005, 03:43
*Too bad* it can't be updated within reasonable efforts, for the look and feel and ease of use of this tool makes it very effective for "dead listing" inspection and even limited live patching of all kind of real mode code. The absence of an assembler can't be counted a defect, since it is by design, but the lack of 32-bit instruction disassembly is what's become reallly annoying, the more so each day :~(

In contrast Borland's TD, which I use extensively for inspecting/debugging foreign code - and even some quick and not so dirty programming, has 32-bit disassembling and integrated assembler (w/ bugs...) but it suffers from a prehistoric interface and annoying limitations, such as, no multiple CPU code windows, and worse, does not stack/unroll visited addresses more than one level deep.

Wish there were a universal, good for all, assembler/disassembler/debugger, with friendly user interface, popup resident mode as well as stand alone execution... name one if you can :=) Maybe the old SICE for DOS could compete, but as I remember when I tried I found it difficult to make it cope well with a modern MS DOS 5+ ... and the interface isn't stellar either.