[Bug 15265] MDCrack v1.8(3) reports 'Unable to allocate enough memory' when '--algorithm=NTLM1' is used (broken app passing non-heap memory blocks to HeapReAlloc, works with NT/pre-Vista heap manager)

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=15265

Anastasius Focht <focht at gmx.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |WONTFIX
                URL|http://c3rb3r.openwall.net/ |https://web.archive.org/web
                   |mdcrack/download/MDCrack-18 |/20150220021853/http://c3rb
                   |3.zip                       |3r.openwall.net/mdcrack/dow
                   |                            |nload/MDCrack-183.zip
            Summary|MDCrack v1.8(3) reports     |MDCrack v1.8(3) reports
                   |'Unable to allocate enough  |'Unable to allocate enough
                   |memory' when                |memory' when
                   |'--algorithm=NTLM1' is used |'--algorithm=NTLM1' is used
                   |                            |(broken app passing
                   |                            |non-heap memory blocks to
                   |                            |HeapReAlloc, works with
                   |                            |NT/pre-Vista heap manager)
          Component|-unknown                    |ntdll
             Status|NEW                         |RESOLVED

--- Comment #28 from Anastasius Focht <focht at gmx.net> ---
Hello folks,

rediscovered this after some years. I had another look at this and my
conclusion is that the app is definitely broken. The heap addresses it passes
to HeapReAlloc() from the "cracker" worker thread are from an internal buffer /
area in the .data section of the main executable. There is no code path that
could lead to a real heap address getting passed. It's simply broken app code.

The Windows NT heap manager changed a lot between Windows NT/XP and Windows
Vista/7+. The reason why this app doesn't work under Windows 7+ is simply that
the heap manager no longer tolerates these bugged applications. Wine returning
NULL in this case is perfectly within the documented/tested behaviour of newer
Windows versions. I doubt that MS provides heap manager shims that can restore
the old behaviour on Vista+

Anyway, I hacked Wine's 'ntdll.RtlReAllocateHeap' to return the same pointer in
erroneous case as well (with last error set) and the app works:

--- snip ---
$ wine ./MDCrack-sse.exe --threads=2 --charset=TEStes34 --algorithm=NTLM1
D280553F0103F2E643406517296E7582

System / Starting MDCrack v1.8(3)
System / Running as Z:\home\focht\Downloads\mdcrack\MDCrack-sse.exe --threads=2
--charset=TEStes34 --algorithm=NTLM1 D280553F0103F2E643406517296E7582 8
System / Filtering custom charset... done
System / Charset is: TEStes34
System / Detected processor(s): 8 x INTEL Itanium | MMX | SSE | SSE2 | SSE3
Warning/ Thread number forced to 2
System / Target hash: D280553F0103F2E643406517296E7582
System / >> Using NTLM1 cores: maximal candidate/user salt size: 32/53 bytes
Info   / Press ESC for available runtime shortcuts (Ctrl-c to quit)
Info   / Thread #0: >> Using Core 1
Info   / Thread #1: >> Using Core 1
Info   / Thread #0: Candidate size:  1 ( + user salt: 0 )
Info   / Thread #1: Candidate size:  1 ( + user salt: 0 )
Info   / Thread #0: Candidate size:  2 ( + user salt: 0 )
Info   / Thread #1: Candidate size:  2 ( + user salt: 0 )
Info   / Thread #0: Candidate size:  3 ( + user salt: 0 )
Info   / Thread #1: Candidate size:  3 ( + user salt: 0 )
Info   / Thread #0: Candidate size:  4 ( + user salt: 0 )
Info   / Thread #1: Candidate size:  4 ( + user salt: 0 )
Info   / Thread #0: >> Using Core 2
Info   / Thread #1: >> Using Core 2
Info   / Thread #0: Candidate size:  5 ( + user salt: 0 )
Info   / Thread #1: Candidate size:  5 ( + user salt: 0 )
Info   / Thread #0: Candidate size:  6 ( + user salt: 0 )
Info   / Thread #1: Candidate size:  6 ( + user salt: 0 )
Info   / Thread #0: >> Using Core 3
Info   / Thread #1: >> Using Core 3
Info   / Thread #0: Candidate size:  7 ( + user salt: 0 )
Info   / Thread #1: Candidate size:  7 ( + user salt: 0 )
Info   / Thread #0: Candidate size:  8 ( + user salt: 0 )
Info   / Thread #1: Candidate size:  8 ( + user salt: 0 )
----------------------------------------------------------/ Thread #0 (Success)
\----
System / Thread #0: Collision found: TestTest
Info   / Thread #0: Candidate/Hash pairs tested: 10 131 882 ( 1.01e+007 ) in
657ms
Info   / Thread #0: Allocated key space: 4.53e+028 candidates, 0.00% done
Info   / Thread #0: Average speed: ~ 15 421 387 ( 1.54e+007 ) h/s
--- snip ---

But that's not what Windows Vista/7+ does. I see no point in implementing the
old heap manager behaviour to cater broken apps.

I'm resolving this ticket as 'WONTFIX'. If there are more apps that rely on
this brokenness then we might reconsider it.

$ sha1sum MDCrack-183.zip 
efb7ee159c9d41d210944676a7a1421bc0b709c9  MDCrack-183.zip

$ du -sh MDCrack-183.zip 
808K    MDCrack-183.zip

$ wine --version
wine-5.7-177-gad1fad8a94

Regards

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.