On at 2021-05-06 01:10 +0200, Eric Auer wrote:
Hi!
Also, you can use the 2 kB "CPULEVEL" tool instead of
VINFO but I guess you install VINFO everywhere anyway.
I added a bunch of things to your cpulevel and callver tools. cpulevel
now will detect NEC V20/V30 processors as 186-class too. The commit is
Exotic but nice :-) With upx --8086 the binary still fits in 2 kB :-)
If you have a real or virtual 8086, please verify that the UPX 8086
unpack header has kept the promise of not hurting 8086 compatibility.
>
> https://auersoft.eu/soft/specials/cpulevel_2021-05-06ecm.zip
I added a small feature to my debugger [1] to detect the maximum CPU
level yet used in a given stretch of tracing disassembly. This allowed
me to verify automatically that the UPX depacker in your binary (as well
as the one I created myself with upx --8086) is 8086-clean. Only two
commands are needed to achieve this; first a RE.APPEND with a condition
that will cancel a T/P/G run if the "Maximum Machine Type" variable
changes to nonzero, and then a TP command that runs "forever" (for a
very long count), or until cancelled by the condition, or up to the
process termination. This TP command is specified with the SILENT
keyword to speed up the run, making it so only the very last register
dumps are actually displayed.
This is the output of this run, with part of the register dumps cut for
brevity. (About 8 KiB worth of dumps are included in this way, if no
number is specified after the SILENT keyword.)
-re.append @if (mmt) then r dco2 or= 8000
-re
AX=0000 BX=0000 CX=07C2 DX=0000 SP=FFFE BP=0000 SI=0000 DI=0000
DS=1D98 ES=1D98 SS=1D98 CS=1D98 IP=0100 NV UP EI PL ZR NA PE NC
1D98:0100 81FC940D cmp sp, 0D94
-tp fffff silent
CPULEVEL - public domain by Eric Auer 2004-2008
[...]
AX=F000 BX=2E06 CX=0000 DX=047E SP=FFFC BP=FFFF SI=0450 DI=0CCC
DS=1D98 ES=1D98 SS=1D98 CS=1D98 IP=0147 NV UP DI PL NZ NA PO NC
1D98:0147 9C pushf
AX=F000 BX=2E06 CX=0000 DX=047E SP=FFFA BP=FFFF SI=0450 DI=0CCC
DS=1D98 ES=1D98 SS=1D98 CS=1D98 IP=0148 NV UP DI PL NZ NA PO NC
1D98:0148 58 pop ax
AX=7002 BX=2E06 CX=0000 DX=047E SP=FFFC BP=FFFF SI=0450 DI=0CCC
DS=1D98 ES=1D98 SS=1D98 CS=1D98 IP=0149 NV UP DI PL NZ NA PO NC
1D98:0149 A900F0 test ax, F000
AX=7002 BX=2E06 CX=0000 DX=047E SP=FFFC BP=FFFF SI=0450 DI=0CCC
DS=1D98 ES=1D98 SS=1D98 CS=1D98 IP=014C NV UP DI PL NZ NA PE NC
1D98:014C 746C jz 01BA not
jumping
AX=7002 BX=2E06 CX=0000 DX=047E SP=FFFC BP=FFFF SI=0450 DI=0CCC
DS=1D98 ES=1D98 SS=1D98 CS=1D98 IP=014E NV UP DI PL NZ NA PE NC
1D98:014E C606BE0C03 mov byte [0CBE], 03
DS:0CBE=02
AX=7002 BX=2E06 CX=0000 DX=047E SP=FFFC BP=FFFF SI=0450 DI=0CCC
DS=1D98 ES=1D98 SS=1D98 CS=1D98 IP=0153 NV UP DI PL NZ NA PE NC
1D98:0153 669C pushfd
-
Using the CPULEVEL source or listing file you can verify that this is in
a part of the application, after its 386+ detection has succeeded. Thus
the depacker is 8086-clean.
Just for fun I repacked the same executable using upx without the --8086
switch. The same two commands to the debugger are used, and indeed the
depacker ends up running at least one instruction for the 186:
[...]
AX=00EB BX=8000 CX=0010 DX=0000 SP=FFFC BP=FFFF SI=0121 DI=0CCC
DS=1E06 ES=1E06 SS=1E06 CS=1E06 IP=0D21 NV UP EI NG NZ NA PO NC
1E06:0D21 AC lodsb
AX=00E8 BX=8000 CX=0010 DX=0000 SP=FFFC BP=FFFF SI=0122 DI=0CCC
DS=1E06 ES=1E06 SS=1E06 CS=1E06 IP=0D22 NV UP EI NG NZ NA PO NC
1E06:0D22 2CE8 sub al, E8
AX=0000 BX=8000 CX=0010 DX=0000 SP=FFFC BP=FFFF SI=0122 DI=0CCC
DS=1E06 ES=1E06 SS=1E06 CS=1E06 IP=0D24 NV UP EI PL ZR NA PE NC
1E06:0D24 3C01 cmp al, 01
AX=0000 BX=8000 CX=0010 DX=0000 SP=FFFC BP=FFFF SI=0122 DI=0CCC
DS=1E06 ES=1E06 SS=1E06 CS=1E06 IP=0D26 NV UP EI NG NZ AC PE CY
1E06:0D26 77F9 ja 0D21 not
jumping
AX=0000 BX=8000 CX=0010 DX=0000 SP=FFFC BP=FFFF SI=0122 DI=0CCC
DS=1E06 ES=1E06 SS=1E06 CS=1E06 IP=0D28 NV UP EI NG NZ AC PE CY
1E06:0D28 C10408 rol word [si], 08
DS:0122=2BC1
-
at [1], latest revision at [2]. callver [3] now supports 21.33FC version
setting even if implemented on another DOS version than FreeDOS (none
known, *yet*), and allows running with a new "SHOW" keyword to only list
the current version. And 21.33FF is used to show a version string, if
any, regardless of OEM code too (which is supported by the recent RxDOS
kernel versions already).
I guess you should also test whether AL is not 0xff on return,
as non-supporting DOS would not only leave DX unchanged, but
also return AL as 0xff. To test whether DX is unchanged, it
might be better to pre-set it to for example 0xfffe instead
of zero, if a version string in HMA 0xffff:x or 0:x is used?
A HMA version string (with segment FFFFh, FFFEh, or any other HMA
segment) is supported by my method. I think it is solid enough to check
for non-zero dx. The string is expected in a data or code segment of the
kernel, so there is no reason to ever use a zero segment.
And if somebody from any RBIL update project is listening,
the classic RBIL does not yet list int 21.33ff at all?
I don't know of any such projects yet. If someone does want to document
it elsewhere, they can of course add my support detection condition of
returning a nonzero value in dx.
Beware: The COM file no longer fits in 1 kB, horrible!
Sadface.
https://auersoft.eu/soft/specials/callver_2021-05-06ecm.zip
But... Feel invited to become maintainer of either or both
of the tools. And feel invited to add a readme and LSM and
package the thing into a freedos style ZIP. If you prefer
to stick with the one-time patch donation, also fine :-)
I think I will do so for now.
Regards,
ecm
[1]: https://hg.ulukai.org/ecm/ldebug/rev/a9dc0c52ab83
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
