Difference between revisions of "Windows 95 build 224"

From BetaWiki
Jump to navigation Jump to search
Tags: Mobile edit Mobile web edit
m
 
Line 19: Line 19:
  
 
So, by measuring alot of activity happening in the system during booting using the checked/debug USER.EXE by attaching terminal to WDEB386, and tracing where it might be faulting in, we ended into the following code in USER32.DLL:
 
So, by measuring alot of activity happening in the system during booting using the checked/debug USER.EXE by attaching terminal to WDEB386, and tracing where it might be faulting in, we ended into the following code in USER32.DLL:
{{Code|
+
<pre>
013F:BFF64320&nbsp;&nbsp;MOV&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;EAX,DWORD PTR [BFF6614E]<br/>
+
013F:BFF64320&nbsp;&nbsp;MOV&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;EAX,DWORD PTR [BFF6614E]
013F:BFF64325&nbsp;&nbsp;MOV&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;AX,WORD PTR [EAX+0000024E]<br/>
+
013F:BFF64325&nbsp;&nbsp;MOV&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;AX,WORD PTR [EAX+0000024E]
013F:BFF6432C&nbsp;&nbsp;SUB&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;AX,0EAA<br/>
+
013F:BFF6432C&nbsp;&nbsp;SUB&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;AX,0EAA
013F:BFF64330&nbsp;&nbsp;CMP&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;AX,0001<br/>
+
013F:BFF64330&nbsp;&nbsp;CMP&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;AX,0001
013F:BFF64334&nbsp;&nbsp;SBB&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;EAX,EAX<br/>
+
013F:BFF64334&nbsp;&nbsp;SBB&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;EAX,EAX
013F:BFF64336&nbsp;&nbsp;NEG&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;EAX<br/>
+
013F:BFF64336&nbsp;&nbsp;NEG&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;EAX
 
013F:BFF64338&nbsp;&nbsp;RETD
 
013F:BFF64338&nbsp;&nbsp;RETD
}}
+
</pre>
  
 
Looking at the code in kernel-debugger, the area where it gets information from (i.e. address stored in DS:BFF6614E + 0x24E to it) was figured to be from a text: "'''St'''atus = .Terminate =", and then subtracting 0xEAA from it and negation? looks like it's where the issue is located since before it returns, AX is 00000000. When we set it to 1 manually (r ax=1) and continuing booting the build, it showed the GUI.
 
Looking at the code in kernel-debugger, the area where it gets information from (i.e. address stored in DS:BFF6614E + 0x24E to it) was figured to be from a text: "'''St'''atus = .Terminate =", and then subtracting 0xEAA from it and negation? looks like it's where the issue is located since before it returns, AX is 00000000. When we set it to 1 manually (r ax=1) and continuing booting the build, it showed the GUI.
  
 
But we still have encountered a Trap14 (0x0E). This time it was due to invalid address:
 
But we still have encountered a Trap14 (0x0E). This time it was due to invalid address:
{{Code|Trap 14 (0EH) - Page Fault 0004, Not Present, Read Access, User Mode<br/>
+
<pre>
AX=91EFA600&nbsp;&nbsp;BX=0066FA96&nbsp;&nbsp;CX=815E173C&nbsp;&nbsp;DX=00040990&nbsp;&nbsp;SI=00540494&nbsp;&nbsp;DI=0066FBA0<br/>
+
Trap 14 (0EH) - Page Fault 0004, Not Present, Read Access, User Mode
IP=BFF6467E&nbsp;&nbsp;SP=0066F7B8&nbsp;&nbsp;BP=0066FA18&nbsp;&nbsp;CR2=91EFA646&nbsp;&nbsp;CR3=003EE&nbsp;&nbsp;IOPL=0&nbsp;&nbsp;F=-- --<br/>
+
AX=91EFA600&nbsp;&nbsp;BX=0066FA96&nbsp;&nbsp;CX=815E173C&nbsp;&nbsp;DX=00040990&nbsp;&nbsp;SI=00540494&nbsp;&nbsp;DI=0066FBA0
CS=013F&nbsp;&nbsp;SS=0147&nbsp;&nbsp;DS=0147&nbsp;&nbsp;ES=0147&nbsp;&nbsp;FS=1CBF&nbsp;&nbsp;GS=1B57 -- NV UP EI NG NZ NA PE NC<br/>
+
IP=BFF6467E&nbsp;&nbsp;SP=0066F7B8&nbsp;&nbsp;BP=0066FA18&nbsp;&nbsp;CR2=91EFA646&nbsp;&nbsp;CR3=003EE&nbsp;&nbsp;IOPL=0&nbsp;&nbsp;F=-- --
 +
CS=013F&nbsp;&nbsp;SS=0147&nbsp;&nbsp;DS=0147&nbsp;&nbsp;ES=0147&nbsp;&nbsp;FS=1CBF&nbsp;&nbsp;GS=1B57 -- NV UP EI NG NZ NA PE NC
 
013F:BFF6467E&nbsp;&nbsp;MOVZX&nbsp;&nbsp; EAX,WORD PTR [EAX+46]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;DS:91EFA646=INVALID
 
013F:BFF6467E&nbsp;&nbsp;MOVZX&nbsp;&nbsp; EAX,WORD PTR [EAX+46]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;DS:91EFA646=INVALID
}}
+
</pre>
  
 
Looking back into code that was prior to this line, we saw this:
 
Looking back into code that was prior to this line, we saw this:
{{Code|013F:BFF6468D&nbsp;&nbsp;MOV&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;EAX,DWORD PTR [BFF6614E]}}
+
<pre>
 +
013F:BFF6468D&nbsp;&nbsp;MOV&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;EAX,DWORD PTR [BFF6614E]
 +
</pre>
 
So now we knew that this address (BFF6614E) has something important to do with the issue, if it's not even the cause.
 
So now we knew that this address (BFF6614E) has something important to do with the issue, if it's not even the cause.
  
Line 58: Line 61:
  
 
* We look for any code with this layout:
 
* We look for any code with this layout:
{{Code|MOV reg, DWORD PTR [BFF6614E]<br/>
+
<pre>
ADD reg, offset}}
+
MOV reg, DWORD PTR [BFF6614E]
 +
ADD reg, offset
 +
</pre>
 
Or
 
Or
{{Code|MOV reg1, DWORD PTR [BFF6614E]<br/>
+
<pre>
MOV reg2, (D)WORD PTR [reg1+offset]}}
+
MOV reg1, DWORD PTR [BFF6614E]
 +
MOV reg2, (D)WORD PTR [reg1+offset]
 +
</pre>
  
 
* Now we look into 'offset' value. If it was between 0xAD and 0x452 we need to add 0x2CE to it. If it was between 0x452 and 0xEAA we should add 0x540 to it, and if it's beyond 0xEAA (e.g. 0x10000 was one of our results) then this should be left unchanged since it now points to another segment, which might be correct.
 
* Now we look into 'offset' value. If it was between 0xAD and 0x452 we need to add 0x2CE to it. If it was between 0x452 and 0xEAA we should add 0x540 to it, and if it's beyond 0xEAA (e.g. 0x10000 was one of our results) then this should be left unchanged since it now points to another segment, which might be correct.

Latest revision as of 19:54, 14 January 2020

4.00.224
Build of Windows 95
4.00.224
OS family
Architecturex86
Compiled1994-10-28
Timebomb1995-03-31 (+154 days)
Works in
About
Windows95-4.0.224-About.png
Key
Beta ID: 186349
Password: 94730fb34
TCB.png TCBGallery.png BA.png

Windows 95 build 224 is the official Beta 2 build of Windows 95. It is available in both free and check/debug versions. However, the Check/Debug version of the build is not usable and refuses to boot due to a missing USER32.DLL.

Check/Debug Mode bug[edit | edit source]

Before getting into the reason of the problem, let's first get some more information about both free USER.EXE and Check/Debug USER.EXE, since the Blue Screen Of Death (BSOD)'s error was occurring in USER.EXE's memory range.

It's worth saying that the debug files can operate and the system can boot without overwriting the free USER.EXE with Check/Debug one. But we're not going to get any statement mentioning that the build is (Debug), nor we'll see watermark which says "Debug Windows 4.00.224" at the right-bottom side of the screen since these strings are located in USER.EXE itself.

So, by measuring alot of activity happening in the system during booting using the checked/debug USER.EXE by attaching terminal to WDEB386, and tracing where it might be faulting in, we ended into the following code in USER32.DLL:

013F:BFF64320  MOV     EAX,DWORD PTR [BFF6614E]
013F:BFF64325  MOV     AX,WORD PTR [EAX+0000024E]
013F:BFF6432C  SUB     AX,0EAA
013F:BFF64330  CMP     AX,0001
013F:BFF64334  SBB     EAX,EAX
013F:BFF64336  NEG     EAX
013F:BFF64338  RETD

Looking at the code in kernel-debugger, the area where it gets information from (i.e. address stored in DS:BFF6614E + 0x24E to it) was figured to be from a text: "Status = .Terminate =", and then subtracting 0xEAA from it and negation? looks like it's where the issue is located since before it returns, AX is 00000000. When we set it to 1 manually (r ax=1) and continuing booting the build, it showed the GUI.

But we still have encountered a Trap14 (0x0E). This time it was due to invalid address:

Trap 14 (0EH) - Page Fault 0004, Not Present, Read Access, User Mode
AX=91EFA600  BX=0066FA96  CX=815E173C  DX=00040990  SI=00540494  DI=0066FBA0
IP=BFF6467E  SP=0066F7B8  BP=0066FA18  CR2=91EFA646  CR3=003EE  IOPL=0  F=-- --
CS=013F  SS=0147  DS=0147  ES=0147  FS=1CBF  GS=1B57 -- NV UP EI NG NZ NA PE NC
013F:BFF6467E  MOVZX   EAX,WORD PTR [EAX+46]                DS:91EFA646=INVALID

Looking back into code that was prior to this line, we saw this:

013F:BFF6468D  MOV     EAX,DWORD PTR [BFF6614E]

So now we knew that this address (BFF6614E) has something important to do with the issue, if it's not even the cause.

This address was later recognized to be the Shared Table address of USER32.DLL, and its pointer is to code segment 21 in USER.EXE, so now we need to do a comparison between the two USER.EXEs.

Thanks to Watcom Binary files dumper (wdump.exe) for its detailed report about USER.EXE. We've got the following information about this specific segment:

  • Segment 21h in free USER.EXE starts at offset 0x67440 in the file and has a size of 0x452 and allocation of 0xEAA.
  • Segment 21h in check/debug USER.EXE starts at offset 0x7E080 in the file, and has a size of 0x992 and allocation of 0x13EA.

By the help also of HxD, we copy/pasted segments from the files and compared them, and we discovered that the beginning of reserved area for data in the segment itself in free USER.EXE starts at 0xAD, while at check/debug one is 0x37B. So now we have the following two clues:

  • The difference between allocations of free USER.EXE and check/debug is 0x13EA - 0xEAA = 0x540.
  • The difference between data locations between the two USER.EXEs is 0x37B - 0xAD = 0x2CE.

Now, by looking into the code, we can imagine the following: If all pointers between 0xAD and 0x452 in free USER.EXE should point to a location in the spare area in the segment, and between 0x452 and 0xEAA should point in the additional allocation by the operating system outside the segment's data, then in Check/debug USER.EXE should has its corresponding locations.

It's IDA time now. We loaded USER32.DLL into IDA and searched for all codes that have BFF6614E into it, and we got around 20 results. What we're going to do now is the following:

  • We look for any code with this layout:
MOV reg, DWORD PTR [BFF6614E]
ADD reg, offset

Or

MOV reg1, DWORD PTR [BFF6614E]
MOV reg2, (D)WORD PTR [reg1+offset]
  • Now we look into 'offset' value. If it was between 0xAD and 0x452 we need to add 0x2CE to it. If it was between 0x452 and 0xEAA we should add 0x540 to it, and if it's beyond 0xEAA (e.g. 0x10000 was one of our results) then this should be left unchanged since it now points to another segment, which might be correct.
  • By using HxD to edit manually most of the results that can satisfy our needs, the build booted up completely without any issue. And functioning properly in all its ways.

Gallery[edit | edit source]

Miscellaneous[edit | edit source]