flat assembler
Message board for the users of flat assembler.

Index > DOS > DPMIST32.BIN

Author
Thread Post new topic Reply to topic
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
Code:
;
; DPMIST32.ASM
;
; END.
    


13.5 KiB source, compiles to just 512 bytes ...

Hi

I ported Japheth's DPMISTUB.ASM / DPMIST32.BIN from MASM to FASM Shocked

Improvements:

- Added test for 80386
- Reduced some assumptions about "nice" behavior of DOS
- Added date
- Made the design more FLAT Shocked
- Reduced compiling cost drastically: now only 1 piece of source, and one assembler file needed (+ DPMI host), no proprietary/commercial stuff, no linker, up to 3 files hogging together 122 KiB at most Shocked
- Fixed horrible "looping-bug"

Tested result, seems to work very well, also "emulated" 16-bit CPU (anyone has a real one Rolling Eyes ), various PATH situations, corrupted DPMILD32.EXE, ...

Made only a 32-bit version, but 16-bit should be possible as well ...

_________________
Bug Nr.: 12345

Title: Hello World program compiles to 100 KB !!!

Status: Closed: NOT a Bug


Last edited by DOS386 on 24 Feb 2008, 01:08; edited 2 times in total
Post 18 Feb 2008, 03:56
View user's profile Send private message Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
EDIT : deleted , was crap, is a shared problem of PESTUB and NT/XP's PE loader , see below Sad


Last edited by DOS386 on 02 Mar 2008, 08:26; edited 2 times in total
Post 18 Feb 2008, 05:07
View user's profile Send private message Reply with quote
Japheth



Joined: 26 Oct 2004
Posts: 151
Japheth
DOS386 wrote:
[code]
; "critical" improvements (added 80386 test, size reduction, reduced
; assumptions about DOS behaving nicely, added date, made code more "flat",
; and, most notably, reduced compiling cost drastically) by DOS386


"size reduction" (32 bytes), "reduced compiling cost" and "added date" are no critical improvements, they are pretty irrelevant. The "reduced assumptions about DOS behaving nicely" is something which I don't understand. What's good is the "made code more flat", indeed there's ways too much segment register changing in this old stuff.

What you apparently didn't improve, although it IS a fault, is the max. path size. It's just 70 (46h) bytes in the original source, but a full short path can be up to 80 bytes (3+64+1+12).
Post 19 Feb 2008, 08:22
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17281
Location: In your JS exploiting you and your system
revolution
DOS386 wrote:
Regrettably my size reduction by 32 bytes will not help over crappy PE loader implementation in NT/XP - such patched apps will no longer work there if total size of ALL headers (MZ header, MZ code, PE header, NT optional header, sectional header, ...) is > then file align ... this means for file align of $200 the stub would have to be cca < $C0 bytes ... no space for any useful code Sad ... and with existing $200/$1E0 stubs, file align of $400 is the minimum Sad The bugginess is very random, from "Not a valid Win32 application", through "Failure to initialize at 43987373984" up to silent abort. Original quality from M$ Shocked
I'm wondering why you can't just extend the header by 0x200 bytes and shift down the rest of the data. Is there some basic flaw in the loader? I have seen many PE files with lots of sections that make the header large.

I can understand if the header goes over the page alignment (0x1000), then you would have much trouble with relocating the following code and data, but as long as the total header size stays under 0x1000 then what is the cause of the problem?
Post 19 Feb 2008, 08:44
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7725
Location: Kraków, Poland
Tomasz Grysztar
revolution wrote:
I'm wondering why you can't just extend the header by 0x200 bytes and shift down the rest of the data. Is there some basic flaw in the loader? I have seen many PE files with lots of sections that make the header large.

I can understand if the header goes over the page alignment (0x1000), then you would have much trouble with relocating the following code and data, but as long as the total header size stays under 0x1000 then what is the cause of the problem?

I have never met such problem - with fasm's "format PE on 'stub.exe'" feature I was able to combine even quite large DOS programs with Win32 ones - some of the early releases of fasm were comibining the DOS version with Win32 version into a single executable this way.
Post 19 Feb 2008, 10:49
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17281
Location: In your JS exploiting you and your system
revolution
This works perfectly on my XP box.
Code:
;filename BigStub-Stub.asm
format MZ
segment zz
entry zz:0
stack 128
heap 0
push cs
pop ds
mov ah,9
mov dx,message
int 21h
mov ax,4cffh
int 21h
message:
db 'Windows 95 or higher required for this program!',0dh,0ah,'$'
db 63 shl 10 dup 0xaa    
Code:
;filename BigStub-App.asm

format PE GUI 4.0 on 'BigStub-Stub.exe'

include 'win32ax.inc'

.code

  start:
   invoke  MessageBox,HWND_DESKTOP,"Hi! I'm the example program!","Win32 Assembly",MB_OK
  invoke  ExitProcess,0

.end start    
Post 19 Feb 2008, 11:09
View user's profile Send private message Visit poster's website Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
EDIT : deleted , was crap Sad


Last edited by DOS386 on 20 Feb 2008, 23:47; edited 1 time in total
Post 20 Feb 2008, 00:57
View user's profile Send private message Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
> "size reduction" (32 bytes), "reduced compiling cost" and
> "added date" are no critical improvements, they are pretty irrelevant.

Confused

> What you apparently didn't improve, although it IS a fault, is the max. path
> size. It's just 70 (46h) bytes in the original source, but a full short path
> can be up to 80 bytes (3+64+1+12).

OK ... but who said it can't be even more ? Confused

C:\ - 3
blah\blah\...\foo\foo\ - 64 ??? "\" at begin doesn't count ?
ZERO at end, not here ??? - 1
ABCDEFGH.BUG - 12

_________________
Bug Nr.: 12345

Title: Hello World program compiles to 100 KB !!!

Status: Closed: NOT a Bug
Post 20 Feb 2008, 01:05
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17281
Location: In your JS exploiting you and your system
revolution
DOS386: You are blaming Windows for something that is your own fault. You didn't properly set the field SizeOfHeaders (offset 0x54) in the PE header. You should take more time to examine why things don't work rather than simply blame the OS.
Post 20 Feb 2008, 02:21
View user's profile Send private message Visit poster's website Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
EDIT : deleted crap, bee below


Last edited by DOS386 on 21 Feb 2008, 00:02; edited 2 times in total
Post 20 Feb 2008, 03:05
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17281
Location: In your JS exploiting you and your system
revolution
In your example, just change offset 0x254 (PE header + 0x54) to 0x400 and the program will run fine on XP.
Post 20 Feb 2008, 03:24
View user's profile Send private message Visit poster's website Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
> DOS386: You are blaming Windows for something that is your own fault.

Thanks for the crucial hint Sad

> You didn't properly set the field SizeOfHeaders (offset 0x54) in the PE header.

Thanks for the crucial hint ... YES and NO Sad

I did set it correctly, RTFS: http://board.flatassembler.net/topic.php?t=6735

> You should take more time to examine why things don't work

Thanks for the crucial hint ... but I did ... just did not examine in the correct direction Sad

> In your example, just change offset 0x254 (PE header + 0x54) to 0x400 and the program will run fine on XP.

Thanks for the crucial hint ... you're right ... it runs ... veni, vidi, vanishing virii ... or criminal bugs at least Sad

Download now: http://board.flatassembler.net/download.php?id=3627

But "this" BUG had been confirmed by Japheth and other people also ... and finally it seems to be at least partially his BUG in PESTUB Sad

PESTUB.TXT wrote:

Quote:

4. Known Problems

If the new stub written to a binary is larger than the old one,
the binary may become unloadable by the Windows NT/XP loader. On
these systems the header may not become larger than the lowest RVA
in the section table (error message is "access denied"). This should
be no issue with DPMIST32.BIN, which just is 200h bytes long, but
may be a problem if the new stub is to be DPMILD32.BIN.


EDIT : removed some false assumptions Sad


Last edited by DOS386 on 22 Feb 2008, 00:17; edited 1 time in total
Post 20 Feb 2008, 23:46
View user's profile Send private message Reply with quote
Japheth



Joined: 26 Oct 2004
Posts: 151
Japheth
DOS386 wrote:
No expert is safe from criminal bugs, and you shouldn't trust anybody Sad


You tend to be a bit "fast" in your assumptions. Don't blame other people for your bugs, that's not the way a brave man should act. There's nothing wrong with what I wrote.
Post 21 Feb 2008, 04:18
View user's profile Send private message Visit poster's website Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
.

Japheth wrote:

> supply a list of at least 2 bugs

ASAP, now I was busy with PESTUB Sad

> You tend to be a bit "fast" in your assumptions.

Maybe Sad

> Don't blame other people for your bugs

It's not "my bug" - RTFS - or if you see a bug in, please point me to it Idea

> that's not the way a brave man should act.

Maybe ... but the world indeed is full of such brave man's Laughing

> There's nothing wrong with what I wrote.

Not really wrong ... it seems pretty correct, it's just not the full truth, and somewhat "misleading" ...

I was at least partially correct with my both "blamings" - NT/XP's PE loader indeed has a bug (or "stupid restriction" at least) - about (header size)<(lowest RVA size) as you wrote, and, PESTUB has bug with not increasing SizeOfHeaders (Commented out ? Not default ?) - it "trashes" my executable as well as all (most) executables coming from FASM (file align=$200).

Tomasz wrote:

Quote:
I have never met such problem - with fasm's "format PE on 'stub.exe'" feature I was able to combine even quite large DOS programs with Win32 ones


YES. Very true and very well done ... Smile FASM indeed increases both SizeOfHeaders and the RVA's if necessary, and the result works.

Now, we have following PESTUB issues:

- Doesn't adjust SizeOfHeaders. Why ? Confused

- Doesn't increase the RVA's. Impossible (?) with "ordinary" Win32 executables because (?) of no fixups, possible but not worth the effort (?) if fixups present ?

- Doesn't warn about too big stub breaking the (header size)<(lowest RVA size) criteria

- Documentation:

> This should be no issue with DPMIST32.BIN, which just is 200h bytes long

except we have absurdly many sections Laughing ?

> but may be a problem if the new stub is to be DPMILD32.BIN.

This seems to be somewhat confusing / "wrong", and soon obsolete Laughing :

- For DOS PE/PX, there is no problem - NP/XP never has to load it Laughing

- For dual-mode PE, there is no point to patch-in more than DPMIST32.BIN (returning to original topic Idea )

So I assume/suggest, that DPMILD32.BIN will get deleted in favor of the new DLL-hell-disabled PELOAD32.BIN anyway Wink

Write a bit more about increasing vs non-increasing SizeOfHeaders, and about the (header size)<(lowest RVA size) criteria - PESTUB is not suitable to create a dual-mode executable because of this - result will be "buggy" and run in DOS, on ME, but not on NT/XP Sad
Post 22 Feb 2008, 00:41
View user's profile Send private message Reply with quote
Japheth



Joined: 26 Oct 2004
Posts: 151
Japheth
DOS386 wrote:
.
... and, PESTUB has bug with not increasing SizeOfHeaders (Commented out ? Not default ?) - it "trashes" my executable as well as all (most) executables coming from FASM (file align=$200).

...

Now, we have following PESTUB issues:

- Doesn't adjust SizeOfHeaders. Why ? Confused



This has been implemented optionally (see -s option for PESTUB) because there is or at least was a problem with WinXP.
Post 22 Feb 2008, 07:48
View user's profile Send private message Visit poster's website Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
Download now: http://board.flatassembler.net/download.php?id=3631 (2008-02-22)

Japheth wrote:

> This has been implemented optionally (see -s option for PESTUB)
> because there is or at least was a problem with WinXP.

Could you write a bit more about this (historical ? Rolling Eyes ) problem, please ? I have always a problem with XP if I don't adjust this, no problem if I do Confused

Example: http://board.flatassembler.net/download.php?id=3628

-- -----------------------------------------------------------------------

Well, the long awaited list with at least 2 bugs I've fixed, not in the version from Feb-18 (deleted, immature, most critical bug was NOT fixed there), but in the one from Feb-22:

- Increased PATH limit from 70 to 80 byes (BUG, but doesn't count as point for me, of course Laughing )
- Using non-8086 compatible instructions without testing before (BUG, minor, 1/2 point for me)
- In your "HEX8" routine, you use "10h", but should be a decimal 10 (BUG, 1 point for me)
- Useless calculations with constants (BUG, minor, 1/2 point for me)
- "Looping-BUG", "RC from overlay" is almost dead code and doesn't really work, accepts happily broken DPMILD32.EXE (BUG, critical, at least 2 points for me Wink )

Image

The looping bug was NOT fixed in my Feb-18 version, even worse, the symptoms were even more malicious in most cases Sad

DOS is stupid and won't reject a broken EXE (size=0, size=infinity, no MZ at all, truncated file, ...) ... loads (in some cases) nothing but still reports "success" and thus your stub doesn't start DPMILD32.EXE, but itself again, raising various random bugginess ... from "invalid optcode" ... through garbage output (see shot) ... up to "rc 2 from overlay" (bad, not informative for an average user, would be "file not found" - still wrong). Actually a failure in this call is almost impossible: previous search excludes file/path not found, anything else seems not be be possible with loading overlay anyway ... dead code Sad ). Added some check for DPMILD32.EXE intactness - ruined my size reduction, much better now, but still not perfect - would have to increase size above $200 bytes, or completely remove the "RC from overlay" code ...
Post 23 Feb 2008, 13:53
View user's profile Send private message Reply with quote
Japheth



Joined: 26 Oct 2004
Posts: 151
Japheth
DOS386 wrote:

- Using non-8086 compatible instructions without testing before (BUG, minor, 1/2 point for me)
- In your "HEX8" routine, you use "10h", but should be a decimal 10 (BUG, 1 point for me)
- Useless calculations with constants (BUG, minor, 1/2 point for me)
- "Looping-BUG", "RC from overlay" is almost dead code and doesn't really work, accepts happily broken DPMILD32.EXE (BUG, critical, at least 2 points for me Wink )


Using "non-8086 compatible instructions" is not a bug. The test for 8086 cpu is intentionally missing. It is documented - and a matter of course - that hx - a DOS extender - won't run on a 8086 system.

I don't accept the "useless calculations" fix, since it is at best an optimization, not a bug fix.

I also don't accept the "looping bug". First, it's not included in your 02/19 version, for which you claimed to have fixed "many bugs" and second, it works with a valid DPMILD32.EXE and relies on DOS to return errors. Implementing additional security checks is possible of course, but this doesn't make the current implementation "buggy".

So just 1 fixed bug remains. "One" is NOT "many"!

Even worse, in your 19/02 version (which you - wisely! - deleted in the meantime), there is:

Code:
             and  al,$0F
             cmp  al,$10
             sbb  al,$69
             das              ; Digital Attack System
             stosb            ; [ES:DI]
             ret
    


which makes me doubt that the one bug which is acceptable was indeed fixed in THAT version already.
Post 23 Feb 2008, 19:52
View user's profile Send private message Visit poster's website Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
Quote:
Using "non-8086 compatible instructions" is not a bug. The test for 8086 cpu is intentionally missing. It is documented - and a matter of course - that hx - a DOS extender - won't run on a 8086 system.


Quote:
; Copyright (C) 1998 DJ Delorie, see COPYING.DJ for details
; * Some code must run on a 8088 without crashing it.


Bug or not bug Confused

Quote:
don't accept the "useless calculations" fix, since it is at best an optimization


YES.

Quote:
don't accept the "looping bug". First, it's not included in your 02/19 version


Preliminary and experimental version ...

Quote:
it works with a valid DPMILD32.EXE


YES.

Quote:
and relies on DOS to return errors.


Something that seems not to happen ... Sad

Quote:
but this doesn't make the current implementation "buggy"


Code that doesn't do what it probably was supposed to ...

Quote:
Even worse, in your 19/02 version (which you - wisely! - deleted in the meantime), there is

Quote:
which makes me doubt that the one bug which is acceptable was indeed fixed in THAT version already.


YES, I deleted "wisely" the version ... because it was buggy ... Idea and it's no secret that that those bugs were not yet fixed there ...

_________________
Bug Nr.: 12345

Title: Hello World program compiles to 100 KB !!!

Status: Closed: NOT a Bug
Post 24 Feb 2008, 01:03
View user's profile Send private message Reply with quote
Japheth



Joined: 26 Oct 2004
Posts: 151
Japheth
DOS386 wrote:
Bug or not bug Confused


You seem to have a rather vague idea of what a bug is. Just citing some text which supports your believes is not the way to go ... it will not intimidate me.

Quote:
Code that doesn't do what it probably was supposed to ...


It is supposed to run with an unmodified DPMILD32.EXE. Isn't this a matter of course?

Quote:
YES, I deleted "wisely" the version ... because it was buggy ... Idea and it's no secret that that those bugs were not yet fixed there ...


IMO deleting posts after other people did respond to it is not very polite, because it makes the responses incomprehensible.
Post 26 Feb 2008, 08:28
View user's profile Send private message Visit poster's website Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
Japheth wrote:
it will not intimidate me.


Was not my goal ... Laughing

Quote:
IMO deleting posts after other people did respond to it is not very polite, because it makes the responses incomprehensible.


I see the problem ... but keeping wrong conclusions is bad also, and I placed bold warnings about my edits Wink

_________________
Bug Nr.: 12345

Title: Hello World program compiles to 100 KB !!!

Status: Closed: NOT a Bug
Post 02 Mar 2008, 08:24
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on YouTube, Twitter.

Website powered by rwasa.