* David Kirschbaum writes to All, on Thursday May 08 1997
at 14:32:
>> Has anyone disassembled this bogus utility? (It purports to
>> somehow magically change your system so your 486 now runs as
>> well as a 586 .. and the most recent versions say it'll run
>> like a Pentium.)
>> It's a total fraud, of course .. but I just wondered what the
>> program is _actually_ doing (and a disassembly would be the
>> best way to find out, I suppose).
I found my original message, I guess I'm a little embarrassed posting it now
when I re-read it: here I was tracing through thinking this program was
attempting all sorts of nasty things, when it was probably perfectly normal
HLL startup code.
The comments on the documentation are valid though.
Date: 20th February 1995
----begin 486TO586.TXT-------------------------------------------------------
Some of you may have seen 486TO586.* floating around the boards, I got
it today and had a bit of a play around with it. This program claims to
'convert' your 486SX to a P5, by software alone. This is the
FILE_ID.DIZ:
.......ú.ú.ú.ú. 486 to 586 .ú.ú.ú.ú.......
Welcome to a FIRST in PC TECHNOLOGY. Your
computer is capable of doing much more than
you think, and the companies that make them
don't tell U everything. Well WE WILL. What
if we told you that there is a program that
converts your 486SX into a real Pentium.
Well throw away all those programs, because
486TO586.COM is the right choice. Yes, this
little program, under 10K will convert your
486 SX into a Pentium, SAFELY.
And the propaganda doesn't end there.....but more of that later. Now for
a detailed analysis.
OK, firstly, 486TO586.EXE is a packed executable. Nothing particularly
unusual about that, however it is packed *twice*. First with LZEXE, then
with "PROTECT! COM/EXE". Here's what UNP shows when it unpacks the file:
processing file : 486TO586.EXE
file size : 5594
file structure : executable (EXE)
EXE part sizes : header 32 bytes, code 5562 bytes, overlay 0 bytes
processed with : PROTECT! COM/EXE V1.0
action : removing scrambling... done
new size : 5312
processing file : 486TO586.EXE
file size : 5312
file structure : executable (EXE)
EXE part sizes : header 32 bytes, code 5280 bytes, overlay 0 bytes
processed with : LZEXE V0.91 or V1.00a
action : decompressing... done
new size : 7136
Now why would a program need to be packed twice? Perhaps the author
doesn't want people to reverse engineer his hard work - perhaps he
has something to hide.
Note that when an executable is packed, it can often mask virii or
trojans.
OK, so I settled down for a heavy debugging session, which I have been
doing for the past 90 minutes.
------begin debug of 386TO486.EXE--------------------------------------
o May have self modifying code, uses several writes to the data segment.
o Saves following vectors in order:
INT 00h CPU-generated - DIVIDE ERROR
INT 02h external hardware - NON-MASKABLE INTERRUPT
INT 1Bh KEYBOARD - CONTROL-BREAK HANDLER
INT 21h [ various DOS functions ]
INT 23h DOS 1+ - CONTROL-C/CONTROL-BREAK HANDLER
INT 24h DOS 1+ - CRITICAL ERROR HANDLER
INT 34h FLOATING POINT EMULATION - OPCODE D8h
INT 35h FLOATING POINT EMULATION - OPCODE D9h
INT 36h FLOATING POINT EMULATION - OPCODE DAh
INT 37h FLOATING POINT EMULATION - OPCODE DBh
INT 38h FLOATING POINT EMULATION - OPCODE DCh
INT 39h FLOATING POINT EMULATION - OPCODE DDh
INT 3Ah FLOATING POINT EMULATION - OPCODE DEh
INT 3Bh FLOATING POINT EMULATION - OPCODE DFh
INT 3Ch FLOATING POINT EMULATION - INSTRUCTIONS WITH SEGMENT
VERRIDE
INT 3Dh FLOATING POINT EMULATION - STANDALONE FWAIT
INT 3Eh FLOATING POINT EMULATION - Borland LANGUAGES "SHORTCUT" CALL
INT 3Fh Overlay and DLL manager
INT 75h IRQ13 - MATH COPROCESSOR EXCEPTION (AT and up)
o Hooks following vectors in order:
INT 00h CPU-generated - DIVIDE ERROR
INT 23h DOS 1+ - CONTROL-C/CONTROL-BREAK HANDLER
INT 24h DOS 1+ - CRITICAL ERROR HANDLER
INT 3Fh Overlay and DLL manager
[Note: further vectors may be hook further in the code, but I didn't
get to the end of it]
o Has several suspicious writes to ES, then calls into the area just
written to (self modifying code). Does it in a rather strange and
roundabout way, too:
cs:039E 26FF19 call es:far [bx+di]
es:[bx+di] evaluates as cs:03AB, which is only a short jump or call
away, from cs:039E.
o Still more suspicious writes to the same area:
cs:0407 B8B704 mov ax,04B7
cs:040A 33C9 xor cx,cx
cs:040C 8BD9 mov bx,cx
cs:040E C74502B2D7 mov word ptr [di+02],D7B2
cs:0413 894514 mov [di+14],ax
cs:0416 8C4D16 mov [di+16],cs
cs:0419 894D18 mov [di+18],cx
cs:041C 895D1A mov [di+1A],bx
cs:041F C7451CFC04 mov word ptr [di+1C],04FC
cs:0424 8C4D1E mov [di+1E],cs
cs:0427 33C0 xor ax,ax
o Again calls to cs:03AB, the self modified code.
o Performs INT 21h with AX=4400: DOS 2+ - IOCTL - GET DEVICE INFORMATION
o Performs INT 10h with AH=0F: VIDEO - GET CURRENT VIDEO MODE
o Performs INT 10h with AX=1130: VIDEO - GET FONT INFORMATION (EGA, MCGA,
A)
o Meanwhile, still more apparent code is being written to the data area.
It's being done in patches - a little bit here, a little bit there.
Almost designed to foil someone snooping, wouldn't you say?
o Performs INT 10h with AH=08: VIDEO - READ CHARACTER AND ATTRIBUTE AT
CURSOR POSITION
NOTE: There has been no screen output from this code yet.
o Yet another patch of apparent code being written. It's building
slowly.
o Reads 0040:006C (timer counter), compares it with same address.
Possibly part of a speed test, also uses short software loops in this
part of the code. Note that I am single stepping this code, so it will
bugger up any speed testing!
o Hooks INT 1Bh vector: KEYBOARD - CONTROL-BREAK HANDLER
o Yet another part of the apparent "self modifying code" is built.
o Clears the screen and homes the cursor to (0,0), writes the string
"486 to Pentium Converter -=- from the makers of 386to486"
o Gets stuck in an eternal loop, reading data from 0040:0000 (serial
port info). That's where my machine locked hard.
----------------------------------------end debug----------------------
I unplugged my HD, and ran it from a floppy drive - it reported that I
needed to run it on a 486SX (I have a 386DX40).
Without looking at it more closely (if the above is not considered
close... :) ), I would hazard a guess and say that it simply emulates a
math floating point unit (FPU). The difference between a 486DX and a
486SX is that, tadaa, a 486SX doesn't have a FPU. Note that it saves the
floating point emulation vectors, and may hook them later in the
program.
Ah, I just looked at the 'documents':
----------------------------------------------------------------------
> The program also features a MATH CO PROCESSOR emulator, even better
> than Q387.EXE, it is as fast as the real math chip itself, this also
> is installed.
----------------------------------------------------------------------
I still can't comprehend how software _emulating_ a coprocessor can be
faster than the hardware version. When it's done in software, it's not
even "CO"-processing, there is only one CPU.
I can't suggest where this "protected memory area" might be; possibly it
assigns an extended memory block, and executes from there. (EMBs are not
freed when a program terminates, so code/data can remain in memory).
Here's some more of the docs.
-----------------------------------------------------------------------
> And it's not all!!! This TSR does more than free the load out of
> your CPU, it also features a graphic processor and sound processor.
> 2 independant built-in modules that take care of graphic manipulations
> in all modes including CGA, EGA, VGA, SVGA, XVGA, and modes up to 24 bit
> color. It's like having a seperate GRAPHIC CPU, so imagine all the
> work load taken off your regular CPU. It also features a built-in
> sound processor, that takes care of sound processing, for programs
> that use sound cards and PC SPEAKER as well.
-----------------------------------------------------------------------
Total and utter crap. You quite simply, cannot make two independent
CPUs, out of one.
It may be just a 'joke' or 'fake' program, it may do something more
malicious. It's impossible to tell at this stage. From a technical point
of view, I would be very sceptical if TSR software was able to double the
normal hardware processing speed of my machine. Worth a miss.
Author of document: Rowan Crowe, 3:635/727.@fidonet
---------------------------------------------------------end 486TO586.TXT----
... rowan@sensation.net.au
---
---------------
* Origin: Sensation: Melbourne AUSTRALIA. (3:635/728.1)
|