DOS ain't dead

DOS386

20.12.2009, 07:45
(edited by DOS386, 20.12.2009, 08:02)

@ DOS386

OLEeeee, OLEeeeeeeee - 1 more bug - "StringFromGUID2"

Found a NEW cool BUG:

5. "StringFromGUID2" in OLE32.DLL returns EAX=0, should be EAX=39, download now: BUG.ZIP (1'380 Byte's)

System requirements:

- DOS with HX 2.17 (not yet available) or Windaube (ME, XP, Vista (untested, maybe best for now))
- OLE32.DLL :-)
- At least 80386 20 MHz 8 MiB RAM for DOS, P1 100 MHz 128 MiB RAM for ME, P3 400 MHz 512 MiB RAM for XP, P4 >=3 GHz 4 GiB RAM for Vista

You will quickly find out that the thing doesn't even load, because of the "Relox-BUG" (fine in ME and XP), when you fix this one, it will work but not well, because of the "StringFromGUID2-BUG" :hungry:

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

Japheth

Germany (South),
20.12.2009, 16:45

@ DOS386

OLEeeee, OLEeeeeeeee - 1 more bug - "StringFromGUID2"

Post reply

> Found a NEW cool BUG:
>
> 5. "StringFromGUID2" in OLE32.DLL returns EAX=0, should be EAX=39,
> download now:
> BUG.ZIP (1'380
> Byte's)
>

True! Fixed in HXRT v2.17 (just the StringFromGUID2 thing, the DPMILD32 issue is still in the queue).

---
MS-DOS forever!

DOS386

21.12.2009, 08:50

@ Japheth

HX 2.17 improvements | even one more bug

Post reply

I wrote:

> DOS with HX 2.17 (not yet available)

Heh, yesterday I was right and today I'm wrong :crying:

> or Windaube (ME, XP, Vista (untested, maybe best for now))

Rugxulo tested on Vista, works fully, so there is still space for improvements in DPMILD32 and DKRNL32 from 2009-12-20 :hungry:

> True! Fixed in HXRT v2.17

Great :-)

> (just the StringFromGUID2 thing, the DPMILD32 issue is still in the queue).

Good.

DPMILD32:

> __.__.2009: version 3.8
> minor size reduction.

Less bloat is always good :-)

OLEeeee:

> __/__/2009: V1.10
> StringFromGUID2 did always return S_OK (=0).
> stubs CreateItemMoniker + GetRunningObjectTable added.

MPLAYER ^^^ missing imports

DUSER32.DLL:

> __/__/2009: Version 2.14
> EnumDisplayDevicesA added.

Dummy :-|

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

More old issues:

* DPMILD32 needs 2 attempts to load a PE, because it tries NE before :-(

See also debug report: http://freefile.kristopherw.us/uploads/temp/mpwsdl.txt

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

One more BUG just discovered:

* It crashes if commandline is unreasonably long ( > 128 (?) chars )

But what crashes ? Both HX and DOS/32A :confused:
But where ? On both FreeDOS and EDR-DOS

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

Please look into the abovementioned 7-ZIP regression also.

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

DOS386

24.12.2009, 09:59

@ DOS386

GPF in "GetProcessHeapEx" | trun in "GetExitCodeProcess"

Post reply

Well, there are even more:

53. Exit code is truncated to 8 bits only, maybe a flaw rather than BUG, or just documentation bug ... GetExitCodeProcess :-|

54. SET DPMILDR=8 has an evil and undocumented side effect:

> - bit 3 (DPMILDR=8): prevents loader from trying to run another
> application in the current DPMI client. Instead the int 21h, ax=4B00h
> call is routed to the next handler in the chain. This is useful if
> the applications to run cannot share the client, which is mostly the
> case for Win32 applications where the relocation information has
> been stripped from the binary. To make this finally work as expected,
> it must be ensured that the DPMI host will run clients in separate
> address spaces (see HDPMI docs for details).

it (fired by CreateProcessA) stops preferring PE over MZ and if there is no DPMIST32.BIN inside, it will execute just the stub, "Need HX-DOS Extender to run !" is the "optimal" result :-|

55. README.TXT in DKRNL32 source DIR incorrectly writes:

> EXITPROC.ASM PROCESS ExitProcess
> GetExitCodeProcess

at this occasion, EXITPROC.ASM and PROCESSW.ASM could be integrated into PROCESS.ASM, they are ridiculously small :-|

56. GPF:

3014 lstrcpy 3014 lstrcpyA 3044 lstrlen 3044 lstrlenA 3060 GetModuleHandleA 30C8 GetProcessHeap 30D0 IsBadReadPtr dkrnl32: exception C0000005 (AKA GPF ?????), flags=0 occured at B7:12A084 ax=8210 bx=100A7 cx=0 dx=128210 si=126E47 di=126A00 bp=1268CC sp=1268C8 ip = Module 'kernel32.dll'+3084 fs=????????????????????? Filepos: $2484 2460 55 push ebp ; GetModuleHandleA 2461 8BEC mov ebp,esp 2463 8B5508 mov edx,[ebp+8] 2466 23D2 and edx,edx 2468 750A jnz $2474 246A E8CDF3FFFF call $183c 246F 8B4008 mov eax,[eax+8] 2472 EB06 jmp short $247a ;-------------- 2474 66B8824B mov ax,$4b82 2478 CD21 int $21 ; Talk to DPMILD32, if present at all 247A C9 leave 247B C20400 ret 4 247E 8BFF mov edi,edi ; NOPE 2480 55 push ebp ; GetProcessHeapEx (non-public ??????) 2481 8BEC mov ebp,esp 2483 53 push ebx 2484 67648B1E3000 mov ebx,[word fs:$30] ; !!! BOOM !!! here it crashes 248A 8B430C mov eax,[ebx+$0C] 248D 23C0 and eax,eax 248F 7532 jnz $24c3 2491 837D0800 cmp dword [ebp+8],0 2495 742C jz $24c3 2497 6A00 push 0 2499 E8C2FFFFFF call $2460 249E 8BD8 mov ebx,eax 24A0 035B3C add ebx,[ebx+$3c] 24A3 8B4368 mov eax,[ebx+$68] 24A6 23C0 and eax,eax 24A8 7419 jz $24c3 24AA 8B4B6C mov ecx,[ebx+$6c] 24AD 6A02 push 2 24AF 6A00 push 0 24B1 51 push ecx 24B2 50 push eax 24B3 6A00 push 0 24B5 E87A0E0000 call $3334 24BA 67648B1E3000 mov ebx,[word fs:$30] 24C0 89430C mov [ebx+$0C],eax 24C3 5B pop ebx 24C4 C9 leave 24C5 C20400 ret 4 24C8 6A01 push 1 ; GetProcessHeap 24CA E8B1FFFFFF call $2480 24CF C3 ret ; What a sophisticated function

After "some" usage of LoadLibraryA (and a few other), a GPF in DKRNL32 occurs :-( FS is secret, but SET DKRNL32=32 can reveal it: ZERO :surprised:

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

DOS386

25.12.2009, 16:16

@ DOS386

GPF's | buggy thing | "CreateProcessA" | ZERO'izing FS

Post reply

I wrote:

> After "some" usage of LoadLibraryA (and a few other), a GPF

... maybe LoadLibraryA is not that badly needed to exploit this bug ... more likely CreateProcessA is the source of evil:

- It uses FS. Regrettably it also ZERO'izes it after usage so one call is fine but the next one causes the GPF : "ip = Module 'kernel32.dll'+3084" If I preserve FS, the problem is fixed ... almost

- now I can use CreateProcessA more than 1 time. But after 46 calls it GPF's again "ip = Module 'kernel32.dll'+243C" - same GPF on same instruction in other place inside DKRNL32, FS==0 :-(

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

Japheth

Germany (South),
28.12.2009, 16:37

@ DOS386

GPF's | buggy thing | "CreateProcessA" | ZERO'izing FS

Post reply

> I wrote:
>
> > After "some" usage of LoadLibraryA (and a few other), a GPF
>
> ... maybe LoadLibraryA is not that badly needed to exploit this bug
> ... more likely CreateProcessA is the source of evil:
>
> - It uses FS. Regrettably it also ZERO'izes it after usage so one call is
> fine but the next one causes the GPF : "ip = Module 'kernel32.dll'+3084"
> If I preserve FS, the problem is fixed ... almost
>
> - now I can use CreateProcessA more than 1 time. But after 46 calls
> it GPF's again "ip = Module 'kernel32.dll'+243C" - same GPF on same
> instruction in other place inside DKRNL32, FS==0 :-(

There was a change in DPMILD32 v3.3.0: FS register is no longer used/modified.

Since OTOH the values of all segment registers are saved & restored when the DPMI-client switches to real-mode, the only case where FS might be changed outside of DKRNL32 is when another PE application is run in the very same client. Is this true here?

---
MS-DOS forever!

DOS386

29.12.2009, 09:39

@ Japheth

GPF's | buggy thing | "CreateProcessA" | ZERO'izing FS

Post reply

> There was a change in DPMILD32 v3.3.0

COOL :-|

> 07/15/2007, V2.12: HDPMI V3.13, DPMILD32 V3.3.0, DKRNL32 V3.0,
> DADVAPI V2.7, DUSER32 V2.9.13, DGDI32 V1.9.8,
> OLE32 V1.6, OLEAUT32 V1.6, VESA32 V1.9.5, PESTUB V2.8
> don't mix DPMILD32 + DKRNL32 with older versions of these files.

otherwise ...

> 15.07.2007: version 3.3.0
> FS is no longer used/modified by DPMILD32.
> DPMILD32 does no longer allocate and initialize a TIB for DKRNL32.
> This is now handled entirely by DKRNL32.

Yeah ...

> Since OTOH the values of all segment registers are saved & restored when
> the DPMI-client switches to real-mode, the only case where FS might be
> changed outside of DKRNL32 is when another PE application is run in the
> very same client. Is this true here?

YES.

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

DOS386

17.03.2010, 06:02
(edited by DOS386, 17.03.2010, 06:20)

@ DOS386

6 more bugs | PETITE | DGDI32.DLL | docs sugx

Post reply

HX BUG's:

Someone IIRC wrote recently (sorry no time to search for the post just now):

> we deprecate UPX

Then you probably don't know PETITE :clap:

But I found 7 more "strange items maybe worth reporting" in HX:

20. [Critical BUG] PETITE packer (self-packed) and executables packed with it don't work in HX, hard freezer (memory corruption at address ZERO ???), fine in ME and XP.

21. [BUG] Strange complaints from DPMILD32 (maybe already reported a few 1'000 times):

> * pe_map.c, dumps a PE file
> * made with Watcom C32 version 11.0b on NT 4.0
> * (f) by B. Luevelsmeyer 1997, 1998, 1999

COOL ^^^ :-)

> C:\HHH>pemap
> this is a Windows NT character-mode executable

Good ^^^ :-)

> C:\HHH>dpmild32 pemap

> DPMI loader version 3.8.0
> Copyright (C) 1993-2009 Japheth

> dpmild32: import not found: VerLanguageNameA
> dpmild32: file KERNEL32.dll
> dpmild32: g:\hxdos\dgdi32.dll: cannot resolve imports

There is a missing junk import "VerLanguageNameA" in DKRNL32.DLL, but the really bad thing is that DPMILD32 complains about "dgdi32.dll" that is NOT INVOLVED at all. The report probably should be (just 1 line):

> DPMILD32: Import not found: "PEMAP.EXE" needs "VerLanguageNameA" in "KERNEL32.DLL"

22. [BUG] SB16.DLL should be loaded conditionally (flaw, already reported before), but it additionally has a BUG causing "funny" crashes with "some" sound cards. Got a "somewhat SB compatible" ISA card (no crappy SB-EMU), the sound is bad (this might be "unavoidable" because of the crappy SB "design" ???), but additionally PLAYWAVE.EXE crashes (low memory corruption ???) at exit. No problems in ME on very same PC. There were IIRC also plans to add PCI sound card support ...

23. [BUG / incompatibility / crappy design] Function "GetFileAttributes" is inconsistent with Windaube (XP is "mostly" consistent with ME, but still "strange" ... who the **** is the parent of the main directory, BTW ???) see TESTATTR.ZIP, HX could catch some "potentially unsafe" strings like ".." ;-)

24. [Flaw / incompatibility / missing feature ???] HX GUI displays garbage if a SDL app tries to brew a box bigger than the screen size. Im ME and XP it "works" (although far away from great ...). One possible solution would be to "center" the too big box "behind" the screen and discard what is outside.

25. DGDI32.DLL is bugged. For example the "17 Byte's demo" is fine in ME and XP, but doesn't work with HX : crashes in DGDI32.DLL. Depending of screen bitdepth, it crashes at various addresses, but always in the BigBlt function and REP MOVSD instruction - apparently at least one of ECX, ESI and EDI supplied in invalid :crying: If I comment out the call to this BigBlt then it "works" (no screen output at all :clap: ) but exposes 3 more BUG's:
- Double crash in DKRNL32.DLL at exit
- MessageBoxA previously displayed not removed (not available in the version supplied now :-( )
- No margin of the "Window" is visible

BTW, I have a new highly superior version of this application, and I'm going to release it, with full source code, of course, but not before I can be sure that it also works with HX, of course. I'm sure you will love it :-) , for multiple reasons, among others, my version is impossible to pack with UPX :clap:

26. [docs suggestion] BTWW, in HXSRC (from 2009-06) I can see some "notes" on BigBlt and StretchBlt, in the source code and separate text files, but apprently the implementation of both is incomplete and it's also incompletely documented how far they are incomplete :-(

Instead of:

Function Dummy -------- ----- BigBlt StretchBlt Y BrewProcess IsUserAdmin Y DoSomething Y DoMoreEx Y

while the presence of "Y" in the right column is rather random, the docs could reveal more useful info:

Function Limitations -------- ----------- BigBlt StretchBlt no ZOOM, fails if (dest size) <> (source size) BrewProcess processes don't run at same time IsUserAdmin dummy, returns always true DoSomething dummy, does nothing and reports success DoMoreEx dummy, always fails

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

Japheth

Germany (South),
18.03.2010, 08:59

@ DOS386

6 more bugs | PETITE | DGDI32.DLL | docs sugx

Post reply

Thanks for your reports!

---
MS-DOS forever!

DOS386

06.06.2010, 16:04

@ Japheth

6 more bugs | PETITE | DGDI32.DLL | docs sugx

Post reply

> Thanks for your reports!

Seems there is a tiny update from 2010-06-03 :-)

What's new:

- ??? (I'll have to search for previous HXRT.ZIP and compare, and possibly retest ...)

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

DOS386

14.07.2010, 14:38

@ DOS386

discovered 3 more buggs

Post reply

call ?001 ; $0040'1000 E8, 00000009 ?001: pop edi ; $0040'100E 5F push 36 ; $0040'100F 6A, 24 push edi ; $0040'1011 57 call ?002 ; $0040'1012 E8, 0000000B ?002: push 0 ; $0040'1022 6A, 00 call near [?011] ; $0040'1024 FF. 15, 00401106(d) shr eax, 1 ; $0040'102A D1. E8 jc ?003 ; $0040'102C 72, 01 int 3 ; breakpoint or filler ; $0040'102E CC ; INT3 ?003: push 36 ; $0040'102F 6A, 24 push edi ; $0040'1031 57 call ?004 ; $0040'1032 E8, 0000000A ?004: pop eax ; $0040'1041 58 push eax ; $0040'1042 50 adc byte [eax], 0 ; $0040'1043 80. 10, 00 push 0 ; $0040'1046 6A, 00 call near [?011] ; $0040'1048 FF. 15, 00401106(d) shr eax, 1 ; $0040'104E D1. E8 jc ?005 ; $0040'1050 72, 02 ud2 ; $0040'1052 0F 0B ; UD2 ?005: push 36 ; $0040'1054 6A, 24 push edi ; $0040'1056 57 call ?006 ; $0040'1057 E8, 00000009 ?006: pop eax ; $0040'1065 58 push eax ; $0040'1066 50 adc byte [eax], 0 ; $0040'1067 80. 10, 00 push 0 ; $0040'106A 6A, 00 call near [?011] ; $0040'106C FF. 15, 00401106(d) shr eax, 1 ; $0040'1072 D1. E8 jc ?007 ; $0040'1074 72, 01 ; Note: Undocumented opcode icebp ; $0040'1076 F1 ; INT1 ?007: push 36 ; $0040'1077 6A, 24 push edi ; $0040'1079 57 call ?008 ; $0040'107A E8, 00000008 ?008: pop eax ; $0040'1087 58 push eax ; $0040'1088 50 adc byte [eax], 0 ; $0040'1089 80. 10, 00 push 0 ; $0040'108C 6A, 00 call near [?011] ; $0040'108E FF. 15, 00401106(d) push 0 ; $0040'1094 6A, 00 call near [?010] ; $0040'1096 FF. 15, 004010E5(d)

Discovered 3 new bugs:

97. "[eip]" is wrong for INT3 crash. ME has the very same BUG - maybe cloned it from there ??? :clap:

98. INT1 instruction (OBJCONV disassembles it as ICEBP - InterCityExpressBritishPetrol) doesn't work. Either it is completely ignored or it crashes far away from it's location with a wrong exception number far away from the expected 1 (ONE) - maybe related to the "SBEMU" hack in DKRNL32 ???

99. "MessageBoxA" fails to display the buttons if text size is <= 8 char's.

Testcase for those 3 BUG's : http://www.file-pasta.com/file/0/HXBUGS.ZIP

### DKRNL32 ###

INT3 (crashes, but [eip] is wrong ...) :

dkrnl32: exception 80000003, flags=0 occured at B7:40102F
ax=3 bx=401000 cx=146BE8 dx=0
si=400000 di=401005 bp=58B8 sp=126FF4
ip = Module 'hxbugs.exe'+102F
[eip] = 6A 24 57 E8 0A 00 00 00 4D 42 43 44
[esp] = 00112B0D 00000000 00000000 00905A4D 00000003 00000004
dkrnl32: fatal exit!

UD2 (good) :

dkrnl32: exception C000001D, flags=0 occured at B7:401052
ax=3 bx=401000 cx=146BE8 dx=0
si=400000 di=401005 bp=58B8 sp=126FF4
ip = Module 'hxbugs.exe'+1052
[eip] = 0F 0B 6A 24 57 E8 09 00 00 00 4D 42
[esp] = 00112B0D 00000000 00000000 00905A4D 00000003 00000004
dkrnl32: fatal exit!

INT1 (ignored, or "bad" crash - both wrong exception
number and wrong [eip] also)

### HDPMI32 ### (SET DKRNL32=32)

INT3 (ignored)

UD2 (OK)

INT1 (ignored - always ???)

### ME ###

INT3 (crashes, but [eip] is wrong ... cloned the BUG from here ???)

UD2 (OK)

INT1 (crashes, but [eip] is wrong ... also here ???)

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

Japheth

Germany (South),
17.07.2010, 15:58

@ DOS386

discovered 3 more buggs

Post reply

Thanks for your reports!

However, I have to admit that I don't understand what the errors exactly are which you allegedly did find. And your test case download is of little help, because it's a binary only, without source - can't use that!

---
MS-DOS forever!

DOS386

23.07.2010, 07:33

@ Japheth

discovered 3 more buggs

Post reply

> However, I have to admit that I don't understand what the errors exactly
> are which you allegedly did find

Didn't I describe them just above ??? :confused:

> And your test case download is of little
> help, because it's a binary only, without source

There is no source anymore, blame Anger Fog - OBJCONV is great but it has a critical BUG : it overwrites the original source code when disassembling :crying:

> - can't use that!

Just run it and try YES and NO at the 3 questions and check the crashes.

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

DOS386

23.05.2010, 07:07

@ DOS386

Generic horse power 15.CHINA for HX :-)

Post reply

[image]

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

DOS386

17.11.2010, 04:43

@ DOS386

HX bugs

Post reply

9072 wrote:

> Have you ever tried this?

YES.

> Because, AFAIK, it's not a real option - those dlls
> are "unusable" outside of ReactOS

ReactOS 0.3.12 is out (2010-10-20). What's new:

- Fixed some BUG's
- Introduced some BUG's (reportedly mostly due to bad hack removal)

What's not new:

- DLL's don't work with HX

- XCOPY.EXE doesn't work with HX either

### ReactOS 0.3.12 ###

"iexplore.exe" 73'728
55BEEC26EF87CC6D6B0F11CC77F62801

"xcopy.exe" 135'168
60B971E3D89F39F0E353CDC65A52C568

CRTDLL.DLL 188'416
472F7119E5E4DFEC09DF64AEE1C4C571

GLU32.DLL 1'024'000
EDF99645977D2484D3EADB35D3DC3AC4

MSVCRT.DLL 425'984
D92488ED42D4C72FF9A52D094A6C2FAF

OPENGL32.DLL 98'304
B986D17F610B00619E9FAD66DB1519B2

28 missing imports in "NTDLL.DLL" :

RtlAreBitsClear RtlAreBitsSet RtlInitializeBitMap
RtlSecondsSince1970ToTime RtlSetBits RtlTimeToSecondsSince1970
_snwprintf _wcsicmp abs bsearch ceil cos floor labs memcmp
memcpy memset sin sprintf sqrt strcmp strcpy strcspn strlen
vDbgPrintExWithPrefix wcscpy wcsncat wcsncpy

One more: 9051 wrote:

> Running the Perforce client with HX? (wsock32 fatal error)

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

DOS386

17.11.2010, 05:26

@ DOS386

HX bugs

Post reply

> 7143 wrote (1 year ago) :

> Heh, seems that Japheth is just now uploading new files, found
> HXDEV216.zip.filepart 16-Nov-2009 09:52 820K :lol:

PS: latest MediaInfo 0.7.36 works great with HX (+UI21DEB on EDR-DOS)

http://sourceforge.net/projects/mediainfo/

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

DOS386

27.12.2010, 09:25

@ DOS386

HX bugs | GNASH

Post reply

New Win32 binaries of GNASH (SWF player) : http://benjaminwolsey.de/downloads/

Problems with HX:

* Missing DLL

127F08C 127F67C 0 0 1281AFC 127FCF4 wldap32.dll
ilt iat Hint
------------------------------------------------------
127F67C: 128116C 127FCF4: 128116C A ber_free
127F680: 1281178 127FCF8: 1281178 5F ldap_err2stringA
127F684: 128118C 127FCFC: 128118C 6D ldap_first_attributeA
127F688: 12811A4 127FD00: 12811A4 6F ldap_first_entry
127F68C: 12811B8 127FD04: 12811B8 75 ldap_get_dnA
127F690: 12811C8 127FD08: 12811C8 81 ldap_get_values_lenA
127F694: 12811E0 127FD0C: 12811E0 84 ldap_initA
127F698: 12811EE 127FD10: 12811EE 87 ldap_memfreeA
127F69C: 12811FE 127FD14: 12811FE A1 ldap_msgfree
127F6A0: 128120E 127FD18: 128120E A3 ldap_next_attributeA
127F6A4: 1281226 127FD1C: 1281226 A5 ldap_next_entry
127F6A8: 1281238 127FD20: 1281238 D5 ldap_search_sA
127F6AC: 128124A 127FD24: 128124A DD ldap_set_optionA
127F6B0: 128125E 127FD28: 128125E E3 ldap_simple_bind_sA
127F6B4: 1281274 127FD2C: 1281274 E6 ldap_sslinitA
127F6B8: 1281284 127FD30: 1281284 F0 ldap_unbind_s
127F6BC: 1281294 127FD34: 1281294 F4 ldap_value_free_len

http://technet.microsoft.com/en-us/library/cc978399.aspx

http://source.winehq.org/WineAPI/wldap32.html

maybe 17 dummies would fix the problem :-P

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

DOS386

28.12.2010, 07:52

@ DOS386

HX bugs | GNASH

Post reply

> Win32 binaries of GNASH (SWF player) http://benjaminwolsey.de/downloads/
> maybe 17 dummies would fix the problem

Well, found a DLL having those 17 :clap: (38 KiB)

After patching LIBBOOST.DLL , GNASH happily loads and starts ... the problem is ... it does nothing useful, the screen is black :-( Tried some switches (no sound, fullscreen) ... no luck :-(

In XP it works (plays, reacts to clicks if interactive, some frames broken/hanging, sound runs away from the video, ...).

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

DOS386

18.02.2011, 05:03
(edited by DOS386, 18.02.2011, 05:16)

@ DOS386

HX bugs - innounp

Post reply

http://innounp.sourceforge.net/

InnoUnp doesn't work well with HX. Some installers (old 4.xx ???) do extract (at least until the process crashes with NTLFN issues), while other (5.xx ??? CC386 Win32 installer for example) don't, it says "file is corrupt or not Inno at all". It does extract in ME or XP, though. InnoUnp 0.35, same problem for older versions.

OWB: msg=9288 "owb under dos/HX" 2011-02

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

DOS386

19.02.2011, 11:58

@ DOS386

HX issues | MUH-pdf | Is Processor Feature Present

Post reply

msg=9473 "PDF readers for DOS" 2011-02

MUPDF doesn't run although the problems are possibly easy to solve:

> dpmild32: import not found: IsProcessorFeaturePresent
> dpmild32: file KERNEL32.dll

Just return ZERO (or CPUID).

but there is still a crash "behind" this problem ...

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

Japheth

Germany (South),
19.02.2011, 12:48

@ DOS386

HX issues | MUH-pdf | Is Processor Feature Present

Post reply

> msg=9473 "PDF readers for DOS" 2011-02
>
> MUPDF doesn't run although the problems are possibly easy to solve:
>
> > dpmild32: import not found: IsProcessorFeaturePresent
> > dpmild32: file KERNEL32.dll
>
> Just return ZERO (or CPUID).

IIRC this function is implemented in the source already, but somehow didn't make it to table of exports.

The source is in procfeat.asm, but the export is commented out in dkrnl32.def.

---
MS-DOS forever!

DOS386

03.07.2011, 11:18

@ DOS386

HX bugs | PETITE & 7-ZIP PF in Ring0

Post reply

> 20. [Critical BUG] PETITE packer (self-packed) and executables
> packed with it don't work in HX, hard freezer (memory corruption at
> address ZERO ???), fine in ME and XP.

PETITE.ZIP (48 KiB)

Still not fixed in 2.17 2011-May / 2011-Jun

#66. One more in HDPMI32 (the version from 2009-Dec / 2010-Jan):

BUG

Occurs randomly and rarely, NOT specific to content of the file :-(

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

Japheth

Germany (South),
03.07.2011, 20:01

@ DOS386

HX bugs | PETITE & 7-ZIP PF in Ring0

Post reply

> #66. One more in HDPMI32 (the version from 2009-Dec / 2010-Jan):
>
> BUG
>
> Occurs randomly and rarely, NOT specific to content of the file :-(

It occurs in HDPMI32, but is almost certainly a bug in DKRNL32.

;----------------------------------------------------------------
Compressing D1128.TAR 75%Exception 0E in ring 0
next client CS:EIP=00B7:0023C724,SS:ESP=00BF:008A1E98
EAX=008A0000 EBX=00000005 ECX=00002000 EDX=00398000 ESI=00398000
EDI=00012150 EBP=0000FE00 ESP=0000078C EFL=00013006 EIP=00004C8D
CS=0020 (FF801000,000067B3,409B) SS=0028 (00009090,FFFFEFFF,CF93)
DS=00BF (00000000,FFFFFFFF,CFF3) ES=004B (00000000,FFFFFFFF,CFF3)
FS=00EF (007A0000,00000FFF,00F3) GS=0000 (********,********,****)
LDTR=0038 (FF80A000,00000FFF,0082) TR=0030 (00009898,00000067,008B)
ERRC=0000 (********,********,****) PTE 1. Page LDT=0013D467
GDTR=07FF:FF808800 IDTR=07FF:FF809000 PTE CR2=00000006
CR0=80000033 CR2=00398000 CR3=00130000 CR4=00000200 TSS:ESP0=00000804
DR0-3=00000000 00000000 00000000 00000000 DR6=FFFF0FF0 DR7=00000400
LPMS Sel/Cnt=0087/0000 RMS=11F4:0200 open RMCBs=0000/0000 ISR=0000
[EIP]=F3 A5 8A C8 80 E1 03 F3 A4 1F 07 61
[ESP]=00BF 0000 00BF 0000 0000 0000 1215 0000
0000079C=FE00 0000 07B4 0000 0005 0000 8000 0039
000007AC=8000 0000 40F0 008A 3F64 0000 1215 0000
000007BC=8000 0039 00BF 0000 8000 0039 8000 0000
000007CC=8000 0001 8000 0000 40F0 008A 07EC 0000
000007DC=0005 0000 8000 0039 8000 0000 40F0 008A
terminate (c)lient or (s)erver now?
;----------------------------------------------------------------

It's a crash in HDPMI function "copy_far32_2_flat". The value of ECX=2000h (and EDI pointing to conventional memory) tells that it is within a int 21h, ah=40h translation.

The protected-mode int 21h in question can be found in DKRNL32, THREAD.ASM.

There is a - small - chance that setting ?SMOOTH=0 in THREAD.ASM and recreating dkrnl32.dll may fix this issue. Side effect: multi-threading will be less "smooth".

---
MS-DOS forever!

DOS386

20.11.2011, 04:33

@ Japheth

HX bugs | missing imports | Dillo | MUPDF | TryEnter

Post reply

> It occurs in HDPMI32, but is almost certainly a bug in DKRNL32.

> It's a crash in HDPMI function "copy_far32_2_flat". The value of ECX=2000h
> (and EDI pointing to conventional memory) tells that it is within a int
> 21h, ah=40h translation.

> The protected-mode int 21h in question can be found in DKRNL32,
> THREAD.ASM.

> There is a - small - chance that setting ?SMOOTH=0 in THREAD.ASM and
> recreating dkrnl32.dll may fix this issue. Side effect: multi-threading
> will be less "smooth".

Thanks ... :-| could it be related to the SB-hack (in the past off, now on) ?

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

Other issues:

[30] many recent apps don't work because missing GetHandleInformation (trivial, return ZERO ?) and TryEnterCriminalSection (trivial, just duplicate AlwaysEnterCriminalSection post #10308 2011-Aug ?)

Japheth wrote 2011-08-09 :

> Anyway, I don't want to modify any sources of the scheduled HX v2.17

[31] Dillo-Win32 doesn't work because of a missing import in COMCTL32.DLL ... ignoring results in silent exit :-(

[32] MUPDF doesn't work because of a problem in post #10477 2011-Sep CreateWindowEx

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

DOS386

24.11.2011, 06:11

@ DOS386

HX bugs 2 more | ME bugs 1'000'000'000 more

Post reply

2 more in HX:

#33: When a MessageBox is done

[image]

it doesn't vanish ^^^ from screen

CLOSED: fixed #34: GetFileTitleA does almost nothing (I fixed this one)

I also found BUG's in ME:

#ME/4572839478293: PE protection bits are apparently ignored: crash in HX as supposed, "fine" in ME !?!?!?

#ME/4572839478294: Get****FileNameW are dummy only :clap:

#ME/4572839478295: GetFileTitleA doesn't work reliably: it is bugged in all versions of Windaube, just in every version differently :clap:

#ME/4572839478296: The "task manager" is not reliable

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

DOS386

20.11.2012, 11:34

@ DOS386

HX updated

Post reply

> v2.17, release candidate 06/05/2011 HXRT
> Password: japheth HXGUI HXDEV HXD16 HXSRC
> Important Note: HXRT217.zip has to be made password-protected,
> because some anti-virus programs don't like file DKRNL32.DLL (a Win32
> emulation dll), which is contained in the package.

:clap:

PS: hxdll.zip (1 year old)

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

Rugxulo

Usono,
22.11.2012, 05:56

@ DOS386

HX updated

Post reply

> > v2.17, release candidate 06/05/2011 HXRT
> > Password: japheth HXGUI HXDEV HXD16 HXSRC
> > Important Note: HXRT217.zip has to be made password-protected,
> > because some anti-virus programs don't like file DKRNL32.DLL (a Win32
> > emulation dll), which is contained in the package.
>
> :clap:

Horrible that we have to work around lousy antiviruses. (I didn't check, but IMHO, putting the password as plaintext in the .ZIP comment would at least be semi-friendly.) Which ones in particular flag it? I do now see it in my copy of latest Avira (Windows), Expert Mode -> Configuration -> System Scanner -> Scan -> Exceptions (and also DEV_GPC's Win32 UNINSTAL.EXE), so I must've put it there. So at least there's that workaround.

You could probably also just disable heuristics entirely or choose "ignore" to manually ignore the warning (e.g. XPACK/Gen or whatever for TESTDRUG.EXE below).

> PS: hxdll.zip (1 year
> old)

Remind us again what that is supposed to do? (No sources and the text file is fairly useless.)

Japheth

Germany (South),
22.11.2012, 07:03

@ Rugxulo

HX updated

Post reply

> Which ones in particular flag it?

They didn't tell in this case. Just this info:

Da alle verwendeten Virenscanner die Datei als Malware kennzeichnen, können wir die Onlinestellung nicht direkt erlauben. Aus diesem Grund haben wir diesen Fall nun direkt an das zuständige Bundesamt für IT Sicherheit weitergeleitet. Diese werden sich die Datei in kürze genauer anschauen und zusammen mit großen IT Sicherheitsfirmen, wie z.B. Symantec, entscheiden ob die Datei eine Malware ist oder nicht. Entsprechend der Rückmeldung können wir die weitere Onlinestellung dann erlauben oder müssen auf die Entfernung rechtlich bestehen. Aber dies entscheidet, wie geschrieben, dass Bundesamt. Wir werden Sie umgehend informieren sobald wir eine Rückmeldung erhalten haben.

But a month ago ( there was a "problem" with file ENUMMODE.EXE in HXRT216.zip ), they told me:

wir haben die Datei mit folgenden Scannern geprüft: Norton Internet Security 2012 Bitdefender 2013 ESET Pro AVAST Enterprise Kaspersky Antivirus 2013 Dies sind aktuell die 5 TOP Virenscanner auf dem Markt, welche auf den meisten PCs zum Einsatz kommen.

So I guess they used exactly those scanners again.

The "problem" in ENUMMODE.EXE was that the code and data section was "merged" in the link step ( to save 512 bytes space ). This is something you shouldn't do these days if your file is to be public, but back then in 2005 it was pretty innocent.

I guess I'm going to switch to a server in West Samoa.

---
MS-DOS forever!

Rugxulo

Usono,
22.11.2012, 09:32

@ Japheth

HX updated

Post reply

> > Which ones in particular flag it?
>
> They didn't tell in this case. Just this info:

Not sure if this particular DKRNL32.DLL is the same as online, I haven't re-downloaded here locally. Anyways, a quick (re)scan (of the one I do have) via http://www.virustotal.com/ shows 18/43 false positives:

Antivirus Result Update -------------------------------------------------------------- Agnitum Trojan.Monder!9aKet0RsdrA 20121121 DrWeb Trojan.Virtumod.9813 20121122 Fortinet W32/Monder.DKMF!tr 20121122 Ikarus Trojan.Win32.Monder 20121122 K7AntiVirus Trojan 20121121 Kaspersky Trojan.Win32.Monder.dkmf 20121122 Kingsoft Win32.Troj.Monder.(kcloud) 20121119 McAfee Generic.dx!b2r4 20121122 McAfee-GW-Edition Generic.dx!b2r4 20121122 Norman W32/Suspicious_Gen2.FQPJV 20121121 nProtect Trojan/W32.Monder.80896.DZ 20121121 Panda Trj/CI.A 20121121 TheHacker Trojan/Monder.dkmf 20121121 TrendMicro TROJ_GEN.R42Z2JS 20121122 TrendMicro-HouseCall TROJ_GEN.R42Z2JS 20121122 VBA32 Trojan.Monder.dkmf 20121122 VIPRE Trojan.Win32.Generic!BT 20121122 ViRobot Trojan.Win32.S.Monder.80896.B 20121122

> > ... blah blah blah blah blah ... >

rexx -e"do random(1,20) ; say 'Nein sprechen sie Deutsch!' ; end"

(Google Translate helps a little but not much.) :-P :-D

> But a month ago ( there was a "problem" with file ENUMMODE.EXE in
> HXRT216.zip ), they told me:
>
> > ... blah blah blah blah blah ... >

At least that part was fairly obvious. It does actually make sense to avoid false positives, esp. with the five most popular, but even better if it can be recompiled / reassembled without problematic bits (even if it's really their fault, not yours ... dumb $@%@%$Ss heuristics).

> So I guess they used exactly those scanners again.
>
> The "problem" in ENUMMODE.EXE was that the code and data section was
> "merged" in the link step ( to save 512 bytes space ). This is something
> you shouldn't do these days if your file is to be public, but back then in
> 2005 it was pretty innocent.

I can't imagine it being a big deal. They must be really dumb to just search for specific bytes only and blindly assume there is no clash in the (big, complex) real world.

> I guess I'm going to switch to a server in West Samoa.

Please don't. Or do, I have no idea if that would be better or not.

Anyways, a quick brute force attempt at isolating the problematic area was this: I copied a random kilobyte of code from further down in DKRNL32.DLL over the header. Granted, it's not valid code anymore, but it at least was an attempt to see if that was the problem area. I rescanned online via VirusTotal and now it passes with 0/42 (and not 0/43, heh, dunno why).

I don't know if that helps, but it's a small hint (maybe). ;-)

Rugxulo

Usono,
22.11.2012, 10:16

@ Rugxulo

HX updated

Post reply

> Not sure if this particular DKRNL32.DLL is the same as online, I haven't
> re-downloaded here locally.

Okay, quick update:

No, not the same, just re-downloaded latest HXRT217.ZIP, md5sum of DKRNL32.DLL (2011-08-21) is d68b3634dc02ea0f9ea710a559e24e14 (which still flags Avast, dang it, temporarily disabling asinine realtime protection).

VirusTotal now gives 33/43 false positives! Sheesh. :surprised: And to prove how incredibly dumb they are, you can change the text "This is a PE dynamic link library" and it will knock off 10 scanners (only 23/43, heh).

Well, here's a potential simple workaround: change "PE" text signature to "PX". It's only one byte (offset 0x79 or 121). Then I get 0/42 results. I can't test well on this silly laptop, but a quick test of 7ZA.EXE under DOSBox ("7za t ccbi-2~1.7z") with slightly older HX (2009-11-16, 2.16 ??) shows that it still works fine even with "PX". (Can't imagine why it wouldn't, but who knows, heh.) :yes:

P.S. In the boring ol' U.S., today is Thanksgiving. (Yes, I'm awake way too late.) I'm grateful for BTTR, Japheth, FreeDOS, DJGPP, etc. etc! :-)

---
Know your limits.h

Japheth

Germany (South),
23.11.2012, 09:13

@ Rugxulo

HX updated

Post reply

> Well, here's a potential simple workaround: change "PE" text signature to
> "PX". It's only one byte (offset 0x79 or 121). Then I get 0/42 results. I
> can't test well on this silly laptop, but a quick test of 7ZA.EXE under
> DOSBox ("7za t ccbi-2~1.7z") with slightly older HX (2009-11-16, 2.16 ??)
> shows that it still works fine even with "PX". (Can't imagine why it
> wouldn't, but who knows, heh.) :yes:

Ok, thanks for the hint! However, to encrypt the whole package is probably more fool-proved. It's not totally comfortable, but IMO DOS users should be used to - and enjoy - uncomfortable weather.

---
MS-DOS forever!

Rugxulo

Usono,
25.11.2012, 07:09

@ Japheth

HX updated

Post reply

> > Well, here's a potential simple workaround: change "PE" text signature
> to
> > "PX".
>
> Ok, thanks for the hint! However, to encrypt the whole package is probably
> more fool-proved. It's not totally comfortable, but IMO DOS users should be
> used to - and enjoy - uncomfortable weather.

:no:

mkdir -p /tmp/blah && cd /tmp/blah wget http://oldhome.schmorp.de/marc/data/fcrackzip-1.0.tar.gz tar xzf fcrackzip*gz && configure && make wget http://www.japheth.de/Download/HX/HXRT217.zip fcrackzip -b -c a -v -l 1-8 HXRT217.zip

BTW, I cheated somewhat as I already knew the password was all lowercase and length 8 or less. So apparently in less than 10 minutes, it's already told me "possible pw found:" correctly (though keeps running). My previous attempt was apparently expecting more fancy passwords as it's still running (single core) 37 hours later! :lol: (John the Ripper - Jumbo, after zip2john prepares it). I didn't try old fzc from Sac.Sk (DOS!) because I was hoping the other would be better / faster. fcrackzip says it's portable and free unlike fzc (encrypted, asm-only). There's an old article (from 1995?) called kocher-pkzip-attack.txt (link broken in official Info-Zip FAQ) that says PKZIP encryption is fairly weak and shouldn't be relied upon. Especially nowadays with much faster computers, better compilers, multiple cores, SIMD, and things like Amazon EC2.

I really only did this to prove a point: ZIP passwords aren't infallible. Though I don't think "cracking" a .ZIP is justified (legal, moral, etc.) in 99% of cases. Hope this doesn't offend anyone! :confused:

george_breese

07.01.2013, 18:43

@ Japheth

HX updated

Post reply

> > Well, here's a potential simple workaround: change "PE" text signature
> to
> > "PX". It's only one byte (offset 0x79 or 121). Then I get 0/42 results.
> I
> > can't test well on this silly laptop, but a quick test of 7ZA.EXE under
> > DOSBox ("7za t ccbi-2~1.7z") with slightly older HX (2009-11-16, 2.16
> ??)
> > shows that it still works fine even with "PX". (Can't imagine why it
> > wouldn't, but who knows, heh.) :yes:
>
> Ok, thanks for the hint! However, to encrypt the whole package is probably
> more fool-proved. It's not totally comfortable, but IMO DOS users should be
> used to - and enjoy - uncomfortable weather.

I believe that the virus-scanning software changes its scanning strategy when there is no valid PE header. While the removal of a PE header might be a working solution, it would impact the ability to find a real virus in DKRNL32.DLL in the future.

Here is a more subtle change that helps to reduce the false virus reports. I changed "KERNEL32.DLL" to "KERNEL32.dll" at offset 0x106D2 of the v216 version of DKRNL32.DLL. The results at virustotal.com dropped to 8/43. All of the generic errors disappeared, and only the Virumonde trojan reports remained.

I didn't test the resulting DLL yet. My time has been short lately. I have wanted to use HX to build the DOS-based diagnostics I use in my company's lab, but my apps need to survive a McAfee virus scan.

Japheth

Germany (South),
08.01.2013, 08:44

@ george_breese

HX updated

Post reply

> I believe that the virus-scanning software changes its scanning strategy
> when there is no valid PE header.

It doesn't really help - just makes a few warnings disappear.

> Here is a more subtle change that helps to reduce the false virus reports.
> I changed "KERNEL32.DLL" to "KERNEL32.dll" at offset 0x106D2 of the v216
> version of DKRNL32.DLL. The results at virustotal.com dropped to 8/43. All
> of the generic errors disappeared, and only the Virumonde trojan reports
> remained.

I'll try.

---
MS-DOS forever!

DOS386

08.02.2013, 10:50

@ Japheth

HX updated (5 years ago) ... but FFMPEG 1.1.1 works almost

Post reply

FYI, FFMPEG 1.1.1 8 MiB works almost in DOS, and even FFPLAY does :-)

[image]

Tiny problems:

# M$WCRT.DLL (must be from XP, ME is not acceptable)
# More missing DLL's (get 3 KiB)
# Missing imports (DPMILDR=128)
# Crash at earliest run (see report), subsequently "fixed" ???
# Waits for keypress (in XP it doesn't)
# Sometimes hangs on exit (push CTL-ALT-DEL -> BOOM, but output file is 100% correct)

CRASH

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

DOS386

08.02.2013, 14:41

@ DOS386

HX and INNOUNP (yeah: BUG isolated !!!)

Post reply

INNOUNP can't extract or even detect INNO 5.xx files under HX ...

... because ...

... yeah ...

... "LoadLibraryEx" ignores the "LOAD_LIBRARY_AS_DATAFILE" flag (like any other flags).

PS: patch the base address from $0040'0000 to some high value before extracting :-)

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

Japheth

Germany (South),
09.02.2013, 08:48

@ DOS386

HX and INNOUNP (yeah: BUG isolated !!!)

Post reply

> ... "LoadLibraryEx" ignores the "LOAD_LIBRARY_AS_DATAFILE" flag (like any
> other flags).

Good to know. I see that you have become a Windoze expert.

I suggest that you implement the functionality in loadlibx.asm ( there's no reason to bloat dpmild32 with such things ). It's a relatively simple thing, might be done in 50 lines of code. I will happily add your additions to HX and you'll be mentioned as contributor in the readme! :-P

---
MS-DOS forever!

DOS386

10.04.2013, 12:08
(edited by DOS386, 10.04.2013, 16:17)

@ DOS386

HX bugs (3 more)

Post reply

Sorry for bumping this HORRROR-thread, but there are 3 more:

#3333 : apart from the GDI crashing (PF) BUG (see several 1'000'000'000's posts above), there is a similar one in DRDDRDRAW,DLL too, investigated by Sherpya : BUG

#3334: apart from the 7-ZIP crypt+compression crashing (PF) BUG (see several 1'000'000'000's posts above), there is a 7-ZIP decrypt+decompression garbage BUG too

#3335: DPMILD32 crashes (GPF) with a long commandline:

[image]

PS: EDR-DOS also crashes with cca 500 Byte's commandline coming from a BAT'tery file ... but this testcase crashes DPMILD32 only and not DOS alone :-\

PPSS: I discovered this one accidentally ... when trying to "break" my excellent PSTRING example ... I couldn't "break" my code, but could "break" DPMILD32 instead :-(

http://board.flatassembler.net/topic.php?p=156560#156560 (link inside "TESTCMPS.ASM" is bad, the only known BUG so far)

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

DOS386

08.03.2014, 18:52

@ DOS386

HX and MSVCRT.DLL

Post reply

ReactorOS 0.3.16 is out:

"ReactOS-0.3.16-REL-live.zip" 55'714'743
A6DFBC70892DA398699F3F79A033D211

"ReactOS-LiveCD.iso" 179'482'624 2014-02-02 20:27
FFF9313045A22851F30782DF7F6A9B9C

"msvcrt.dll" 580'096 2014-01-03 02:14
D9EB'3111'B9F2'DFE1'DEFE'A705'85D0'2E81

What's new:

* it doesn't work anymore (see shot)
* new MSVCRT.DLL (but still not good enough for HX ... 9 missing imports) (see shot)

[image]
[image]

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

Rugxulo

Usono,
23.03.2014, 06:47

@ DOS386

HX and MSVCRT.DLL

Post reply

> ReactorOS 0.3.16 is out:
>
> "ReactOS-0.3.16-REL-live.zip" 55'714'743
> A6DFBC70892DA398699F3F79A033D211
>
> "ReactOS-LiveCD.iso" 179'482'624 2014-02-02 20:27
> FFF9313045A22851F30782DF7F6A9B9C
>
> "msvcrt.dll" 580'096 2014-01-03 02:14
> D9EB'3111'B9F2'DFE1'DEFE'A705'85D0'2E81

I just tried this with Oxford Oberon, but it still doesn't work (same as 0.3.15). I have no idea why 0.3.14 accidentally works okay in this case.

Rugxulo

Usono,
11.06.2015, 02:15

@ DOS386

WINE and INNOUNP (and Delphi)

Post reply

First of all, sorry for bumping this old thread!

> INNOUNP can't extract or even detect INNO 5.xx files under HX ...
>
> ... because ...
>
> ... yeah ...
>
> ... "LoadLibraryEx" ignores the "LOAD_LIBRARY_AS_DATAFILE" flag (like any
> other flags).
>
> PS: patch the base address from $0040'0000 to some high value before
> extracting :-)

I never looked too closely, so it's not something I'm familiar with. But I did just notice something interesting:

http://sourceforge.net/projects/innounp/files/innounp/innounp%200.42/

Since I'd mentioned Oxford Oberon before, I now see that its Win32 installer is indeed using InnoSetup ("; Version detected: 5500").

http://spivey.oriel.ox.ac.uk/corner/Installing_OBC_release_2.9
http://spivey.oriel.ox.ac.uk/wiki/files/sw/obc-win-2-9-4.exe

You're right that you can't identify/view/unpack the target .EXE under HX. But I did try old WINE 1.3.6 on this old Lucid Puppy Linux, and it seems to unpack there correctly.

I know that's not much consolation, but at least "some" non-Windows systems can run it.

BTW, a quick check the other day revealed that InnoUnp is (mostly) written in Delphi! So I blindly assume that it's technically possible to massage it to recompile with FreePascal (preferably for native DOS). But I didn't even try. For one thing, for all we know, it uses Win32-specific APIs and isn't even portable. (EDIT: "uses Windows", ugh.) But even ignoring that, the source .RAR does (unwisely) include many precompiled binary .OBJs, so you'd have to replace those with suitable substitutes (bzip, lzma, crypt, zlib). Not totally impossible but probably not totally transparent either.

DOS386

22.11.2012, 16:09

@ Rugxulo

HX full of virii

Post reply

> Horrible that we have to work around lousy antiviruses

...

> (I didn't check, but IMHO, putting the password as plaintext in the .ZIP
> comment would at least be semi-friendly

Better idea:

- switch form ZIP to 7-ZIP
- brew a better PWD than "japheth" and hide it better
- hide your HX files into something else looking innocent (PNG? OGV? ...) Hints about suitable tools (usable in DOS) are welcome :hungry:

> You could probably also just disable heuristics entirely or choose "ignore"
> to manually ignore the warning (e.g. XPACK/Gen or whatever for
> TESTDRUG.EXE below)

I don't have any problems with the file. Maybe because I don't use those useless "antivirii" at all?

> Remind us again what that is supposed to do?

nothing

> Because all the virus scanners identify the file as malware, we can not allow
> the online status directly. For this reason we have this case now be passed
> directly to the responsible Federal Office for IT Security. This is the file will
> look in more detail soon, and along with major IT security companies, such
> as Symantec decide whether the file is malware or not. According to the
> feedback we can allow more online or position then must pass law on the
> distance. But this decision, as written, that the Federal Office. We will inform
> you when we receive a response.

Remember some pretty similar "Federal Office" burning down books with "not tolerable content" just cca 80 years ago?

> I guess I'm going to switch to a server in West Samoa.

Please do :hungry:

> > The "problem" in ENUMMODE.EXE was that the code and data section was
> > "merged" in the link step ( to save 512 bytes space ). This is something
> > you shouldn't do these days if your file is to be public, but back then in
> > 2005 it was pretty innocent.

> I can't imagine it being a big deal.

It is. FASM had the same "bug" too :clap:

PS: HX BUG #35:

Tiny WinFloor demo doesn't work (hangs with empty black rectangle, reacts to nothing except CTL-ALT-DEL)

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

Rugxulo

Usono,
23.11.2012, 00:24

@ DOS386

HX full of virii

Post reply

> > Horrible that we have to work around lousy antiviruses
>
> > (I didn't check, but IMHO, putting the password as plaintext in the .ZIP
> > comment would at least be semi-friendly
>
> Better idea:
>
> - switch form ZIP to 7-ZIP

Won't work. Most good ones can unpack various archives and exe packers, esp. the open source kind (.7Z).

> - brew a better PWD than "japheth" and hide it better

.ZIP passwords are incredibly easy to crack. Also, it's a pain trying to remember a billion passwords. If the "PX" hack isn't viable, I'll understand, but so far it seems like the least painful way to fix everything, at least in my naive worldview.

Or just only password protect DKRNL32.DLL and leave others unencrypted. Then the README.1ST could tell the password to unpack the remaining file.

Or just split the actual file into several pieces and let the user manually combine it (hopefully defeating detection).

> - hide your HX files into something else looking innocent (PNG? OGV? ...)

I don't think that will work. Lots of formats have subformats inside them, so smart antiviruses probably still scan them for various things.

> Hints about suitable tools
> (usable in DOS) are
> welcome :hungry:

There was an old one on FASM's forum a few years ago, perhaps by ATV, but I don't remember where. Feel free to search.

> > You could probably also just disable heuristics entirely or choose
> "ignore"
> > to manually ignore the warning (e.g. XPACK/Gen or whatever for
> > TESTDRUG.EXE below)
>
> I don't have any problems with the file. Maybe because I don't use those
> useless "antivirii" at all?

They aren't useless, just overzealous and bloated and slow. It's a sad fact of life.

DOS386

16.12.2012, 13:00

@ Rugxulo

HX full of virii

Post reply

> > Better idea:
> > - switch form ZIP to 7-ZIP

> Won't work. Most good ones can unpack various archives

1. F-PROT DOS can't :clap:
2. 7-ZIP will slow down pwd brute-forcing by factor cca 10'000'000 and prevent plain-text attacks :clap:
3. anyway, I meant use this one together with the other ideas

> just only password protect DKRNL32.DLL and leave others unencrypted

bad idea as the others may get wormed too at any time, as some of them already used to be in the past :clap:

> > - hide your HX files into something else looking innocent (PNG? OGV? ...)

> I don't think that will work. Lots of formats have subformats

It will. There are no subformats in PNG or OGV, and if it's done well, it's impossible to provide any evidence that there is some hidden data at all :clap:

Japheth wrote:

> History HDPMI
>
> 14.12.2012, version 3.17
>
> ■ bugfix: when int 33h, ax=000Ch or ax=0014h was used by a client,
> HDPMI might have corrupted DOS memory on exit.
> ■ Linker switched to jwlink (modified wlink).
> ■ new cmdline switch -x to restrict free memory to 256MB.
>
> 20.01.2009, version 3.16
>
> ■ Assembler switched to JWasm.
>
> 01.03.2008, version 3.15
>
> ■ bugfix: int 31h, ax=507h didn't return number of processed pages
> in ECX if function failed.

COOL.

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

Rugxulo

Usono,
16.12.2012, 22:07

@ DOS386

HX (not) full of virii

Post reply

> > > Better idea:
> > > - switch form ZIP to 7-ZIP
>
> > Won't work. Most good ones can unpack various archives
>
> 1. F-PROT DOS can't :clap:

But most others can unpack lots of archives. (Keep in mind that, IIRC, F-Prot for DOS was discontinued circa 2006, and I'm not sure if the updated data files still work or when last workable data files were available [2009??]. In other words, I don't use it anymore. But most new viruses aren't for DOS, so it's no biggie.)

> 2. 7-ZIP will slow down pwd brute-forcing by factor cca 10'000'000 and
> prevent plain-text attacks :clap:

I don't think Japheth intends to switch to .7z format. And there are newer encryption methods for .ZIP, though I honestly like the fact that it's easy to crack (in case someone forgets).

"Tips for selecting password length" (7z.htm , sounds naive and inaccurate but whatever)

> 3. anyway, I meant use this one together with the other ideas
>
> > just only password protect DKRNL32.DLL and leave others unencrypted
>
> bad idea as the others may get wormed too at any time, as some of them
> already used to be in the past :clap:

Yeah, I forgot others gave false positives too. Still, it shouldn't be too too hard to mask the warnings, but I don't think it's worth my time, esp. since Japheth seems happy with his password .ZIP.

> > > - hide your HX files into something else looking innocent (PNG? OGV?
> ...)
>
> > I don't think that will work. Lots of formats have subformats
>
> It will. There are no subformats in PNG or OGV, and if it's done well, it's
> impossible to provide any evidence that there is some hidden data at all
> :clap:

I don't think he will go for that. That's way too much indirection anyways, esp. for such a "clean" project.

> Japheth wrote:
>
> > History HDPMI
> >
> > 14.12.2012, version 3.17
>
> COOL.

Did you also notice that JWasm and JWlink had new releases?

Japheth

Germany (South),
16.12.2012, 22:24

@ Rugxulo

HX (not) full of virii

Post reply

> Yeah, I forgot others gave false positives too. Still, it shouldn't be too
> too hard to mask the warnings, but I don't think it's worth my time, esp.
> since Japheth seems happy with his password .ZIP.

I'm not "happy", but also don't want to invest more than a reasonable amount of time - it's not one of the things that I regard as "extremely interesting".

> Did you also notice that JWasm and JWlink had new releases?

the hdpmi update was needed because DOS4/GW apps - including the Watcom debugger WD - have difficulties with lots of RAM.

---
MS-DOS forever!

Rugxulo

Usono,
17.12.2012, 21:59

@ Japheth

HX (not) full of virii

Post reply

> > Yeah, I forgot others gave false positives too. Still, it shouldn't be
> too
> > too hard to mask the warnings, but I don't think it's worth my time,
> esp.
> > since Japheth seems happy with his password .ZIP.
>
> I'm not "happy", but also don't want to invest more than a reasonable
> amount of time - it's not one of the things that I regard as "extremely
> interesting".

I would imagine that avoiding HX being flagged / deleted would be important, but I do also understand that it's more of their problem than yours. (One file on VirusTotal reported "VIRUS_UNKNOWN", heh, it "knows" it's a virus but doesn't know what or why or how??)

I also wonder at why they all have the same error. Do they share databases or test cases? They must. I hate this so badly, but whatever, unless "we" (eh?) manually work around it and/or heavily nag the antivirus people, what can we do? :-(

> > Did you also notice that JWasm and JWlink had new releases?
>
> the hdpmi update was needed because DOS4/GW apps - including the Watcom
> debugger WD - have difficulties with lots of RAM.

I've never really used it, dunno. DOS386 claims it doesn't work (well, if at all) under FreeDOS. I don't know what specifically you mean here (DOS4GW.EXE proper? OpenWatcom malloc?). But I do know that dumb ol' paq8o8z reportedly used a lot more MBs of RAM with OW builds than DJGPP, presumably due to differing malloc implementation, page size rounding, or whatever.

DOS386

17.12.2012, 05:32

@ Rugxulo

HX (not) full of virii

Post reply

> And there are newer encryption methods for .ZIP

YES, but you need 7-ZIP anyway to extract such "ZIP" 's because:

1. PKZIP 2.50 can't
2. Wing-ZIP doesn't run in DOS (FYI: Wing-ZIP 17 released. What's new: increased bloat to 100 MiB :clap: )

> "Tips
> for selecting password length" (7z.htm , sounds naive and inaccurate
> but whatever)

It's correct. Igor ASSUME's that ML will continue working to the infinity. RTFF :hungry:

> I don't think he will go for that. That's way too much indirection anyways,
> esp. for such a "clean" project.

It's less bad than providing evidence of innocence to the "federal office" :-)

> Did you also notice that JWasm and JWlink had new releases?

YES, JAWASM 2.09 is out, and JAWASM 2.10 pre-release too, fixing multiple critical BUG's of 2.09. http://japheth.de/Download/JWasm/

Maybe there will be a release of HX 2.17 final too?

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

Japheth

Germany (South),
17.12.2012, 08:47

@ DOS386

HX (not) full of virii

Post reply

> Maybe there will be a release of HX 2.17 final too?

Yes. It has to wait until there exists a release version of jwlink.

---
MS-DOS forever!

Rugxulo

Usono,
17.12.2012, 22:14

@ DOS386

HX (not) full of virii

Post reply

> > And there are newer encryption methods for .ZIP
>
> YES, but you need 7-ZIP anyway to extract such "ZIP" 's because:
>
> 1. PKZIP 2.50 can't

Maybe you specifically need 7-Zip in DOS, maybe not. Dunno what else is out there or how many versions of other tools (cmdline) work under HX. AFAIK, there were (at one time) two competing encryption methods in .ZIP.

Not that I would mind if Japheth switched to .7z, but he doesn't discuss these things with me. It's not my call. I doubt you can convince him. ;-)

> 2. Wing-ZIP doesn't run in DOS (FYI: Wing-ZIP 17 released. What's new:
> increased bloat to 100
> MiB :clap: )

Have you ever tried any of them under HXGUI? (shrug) I mean, who knows what works, heavily doubt it, but I guess it's possible (aren't there cmdline tools add-ons?). ;-)

But yes, you're right, a quick search on Sac.SK shows a lot of WinZIP versions, from 1997 (Win 3.1, v6.3, 629 kb) to 2005 (Win95-XP, v9.0 SR1, 4077 kb) to 2010 ("Windows", v14.0, 13837 kb) to 2011 ("Windows", v15.5, 30254 kb) to 2012 (actually it seems 100 MB is both 32-bit and 64-bit installer, but you can still get them separately for half that each, heh, still very bloated, dunno why, quite ironic).

> > "Tips
> > for selecting password length" (7z.htm , sounds naive and
> inaccurate
> > but whatever)
>
> It's correct. Igor ASSUME's that
> ML will continue
> working to the infinity. RTFF :hungry:

There's no way I believe those stats. And most people don't have anything worth password protecting anyways. With Amazon EC2, IBM Roadrunner, etc., it's probably incorrect to pretend that lots of governments (or Anonymous or whoever) don't have easy access to various brute force methods to crack anyone's data. Though I'm fairly noobish and don't do anything (useful or otherwise), so I'm pretty sure the aliens / criminals / governments don't give a crap about me. ;-)

> Maybe there will be a release of HX 2.17 final too?

With hotfix to disable EMS, I assume. ;-)

Rugxulo

Usono,
18.12.2012, 20:55

@ Rugxulo

HX (not) full of virii

Post reply

> > > "Tips for selecting password length" (7z.htm , sounds naive and inaccurate but whatever)
> >
> > It's correct. Igor ASSUME's that
> > ML will continue
> > working to the infinity. RTFF :hungry:
>
> There's no way I believe those stats. And most people don't have anything
> worth password protecting anyways. With Amazon EC2, IBM Roadrunner, etc.,
> it's probably incorrect to pretend that lots of governments (or Anonymous
> or whoever) don't have easy access to various brute force methods to crack
> anyone's data.

25-GPU cluster cracks every standard Windows password in <6 hours

> "The five-server system uses a relatively new package of virtualization
> software that harnesses the power of 25 AMD Radeon graphics cards. It
> achieves the 350 billion-guess-per-second speed when cracking password
> hashes generated by the NTLM cryptographic algorithm that Microsoft has
> included in every version of Windows since Server 2003. As a result,
> it can try an astounding 95**8 combinations in just 5.5 hours, enough to
> brute force every possible eight-character password containing upper-
> and lower-case letters, digits, and symbols."

HX bugs (DOSX)

OLEeeee, OLEeeeeeeee - 1 more bug - "StringFromGUID2"

OLEeeee, OLEeeeeeeee - 1 more bug - "StringFromGUID2"

HX 2.17 improvements | even one more bug

GPF in "GetProcessHeapEx" | trun in "GetExitCodeProcess"

GPF's | buggy thing | "CreateProcessA" | ZERO'izing FS

GPF's | buggy thing | "CreateProcessA" | ZERO'izing FS

GPF's | buggy thing | "CreateProcessA" | ZERO'izing FS

6 more bugs | PETITE | DGDI32.DLL | docs sugx

6 more bugs | PETITE | DGDI32.DLL | docs sugx

6 more bugs | PETITE | DGDI32.DLL | docs sugx

discovered 3 more buggs

discovered 3 more buggs

discovered 3 more buggs

Generic horse power 15.CHINA for HX :-)

HX bugs

HX bugs

HX bugs | GNASH

HX bugs | GNASH

HX bugs - innounp

HX issues | MUH-pdf | Is Processor Feature Present

HX issues | MUH-pdf | Is Processor Feature Present

HX bugs | PETITE & 7-ZIP PF in Ring0

HX bugs | PETITE & 7-ZIP PF in Ring0

HX bugs | missing imports | Dillo | MUPDF | TryEnter

HX bugs 2 more | ME bugs 1'000'000'000 more

HX updated

HX updated

HX updated

HX updated

HX updated

HX updated

HX updated

HX updated

HX updated

HX updated (5 years ago) ... but FFMPEG 1.1.1 works almost

HX and INNOUNP (yeah: BUG isolated !!!)

HX and INNOUNP (yeah: BUG isolated !!!)

HX bugs (3 more)

HX and MSVCRT.DLL

HX and MSVCRT.DLL

WINE and INNOUNP (and Delphi)

HX full of virii

HX full of virii

HX full of virii

HX (not) full of virii

HX (not) full of virii

HX (not) full of virii

HX (not) full of virii

HX (not) full of virii

HX (not) full of virii

HX (not) full of virii