There exists an Unreal build known as Unreal.098.1997.11.03. It is a subject of some controversy, with some people accusing it of being fake (based on the February 1998 beta, build 99) and some defending it.

There are three scenarios:
A. That it's a real distinct build and no third party has altered it.

B. That it's a real distinct build but it was extensively tampered with.

C. That it's a fake based on the 99 build.

Which one is true? I'm gonna post here a pretty deep research, mostly by comparing it to the later build.

I will be refering to these files: https://drive.google.com/open?id=0B2B8niXknBvTWVg0Y2tKZGZHUFU

I used "fc", a Windows command line tool, to compare the files. The reason you don't see most of the different files in the comparsion logs is that when fc encounters two different binary files, it spits out all the different bytes which takes huge amount of space, so I just delete these files and then repeat the comparsion. Maybe there's a better way, but it's too late anyway.

So here's what I found:

1. Unreal.exe is identical besides the version number, compilation date, and name of the file with password.

2. UnrealEd.exe and Unreal.tlb are identical.

3. All DLL and all U files besides UnrealI.u and Engine.u are identical (see dllcompare.txt).

4. All UAX files are identical (see uaxcompare.txt).

5. Most UTX files are identical (see utxcompare.txt). The only exceptions are Mine (see below), xfx, and NaliCast (which seems to differ only by some random 22 bytes).

6. All UMX files are identical besides one different byte in foundry1 and UTemple (see umxcompare.txt).

7. The modification dates are somewhat weird - you can see groups of 4-5 files having identical dates to the seconds. This is something I've never seen anywhere else. Usually, when e.g. a bunch of files is compiled or copied (by a tool that doesn't preserve the date), the current system date/time is used, and such processes take usually longer than fraction of a second. Let's look for example at U files in Unreal 0.88:
Core.u      18.11.1997, ‏‎04:08:02
Engine.u    ‎18.11.1997, ‏‎04:08:20
Editor.u    ‎18.11.1997, ‏‎04:08:22
Render.u    ‎18.11.1997, ‏‎04:08:24
UnrealI.u   18.11.‎1997, ‏‎04:13:12

And some 99 files (for some reason, these files have the date shifted by 9 hours in Delacroix's version):
Core.u      6.02.‎1998, ‏‎20:43:20
Render.u    ‎6.02.‎1998, ‏‎20:43:36
Editor.u    ‎6.02.‎1998, ‏‎20:43:36 (okay, sometimes it happens)
Fire.u      6.02.‎1998, ‏‎20:43:38

Now build 98 files for comparsion:
Core.u      11.11.1997, ‏‎08:30:02
Editor.u    ‎11.11.1997, ‏‎08:30:02
Engine.u    ‎11.11.1997, ‏‎08:30:02
Fire.u      11.11.1997, ‏‎08:30:02
UnrealI.u   11.11.1997, ‏‎08:30:02

Compiling and copying doesn't happen instantly, so the only explanation for the datestamps being the same is that somebody set them manually.

8. ALC claims that the 98 krall's UV maps are exactly the same as his EarlyKrall.u conversion. That includes the bottom of the staff, which is the one part of the conversion that he didn't make faithful to the tech demo krall. The chance that Epic made exactly the same mistake is extremely small (assuming the UV values are random, it would be 1/2^(8*6) = 1/281474976710656).
Unfortunately, I couldn't get unambiguous results on this one. I used a version of EarlyKrall dated to ‎20.03.‎2013, ‏‎11:14:02. Yes, the bottom of the staff was identical, but there were some other differences, perhaps caused by the multiple conversions (UTPT in particular). See kralluvs\. Still, if the UVs as shown on "new alc.png" were hand made by ALC and the staff error was unique to his work, it's obvious that it's his model that was reused in the 98 build.

9. I compared contents of the UnrealI.u files:
a) I compared existence of objects using a tool included in the attachments. Although this tool allows also to compare contents of the objects, this is not very reliable and often a resave of package is enough to make all objects seem "different". The results: The 98 build has two classes missing and some textures added/removed. See unrealicompare1-3.png.
b) I compared the scripts exported with the AltEd (this included also some scripts from other packages than UnrealI). Only Actor classes were compared. 381 (of 423-425) classes were identical. Almost all of the remaining ones had only visual changes like skins, icons and the HUD. What's even more interesting, the big important classes like Actor, Pawn, ScriptedPawn, PlayerPawn, Weapon, Inventory are unchanged. See scriptcompare.txt.
c) I compared the sounds. No difference. See unrealisoundcompare.txt.
d) I compared the meshes. These are different: AutoMag, AutoMagR, Brute, Krall. All others are identical. See unrealimeshcompare.txt.
e) I compared the textures. 12 of them were different. However, the different ones could have been easily taken from the existing betas and optionally modified a bit.

98 skin        source
--------------------------------------------------
Arc1        99, the palette replaced with grayscale
ekrall      0.871d->Krall
JFemale1    99, the palette was damaged
JFemale2    0.88->JFemale4
JFemale3    0.88
JFemale5    0.88->JFemale2
Jfish1      0.88
JMale1      0.88, the palette was damaged
JMerc1      0.871d
JSlith1     0.88
Krall       0.87
Skj_a02     99, the palette replaced with grayscale

Other textures were identical or nonexistent. See unrealitexcompare.txt and unrealicompare1-3.png.

10. The Mine.mflat1 and Mine.mflat2 textures are different. Now let's take a closer look at both versions of mflat2 using GIMP. First, it's clear that these were made in different programs - the 98 palette is sorted by brightness while the 99 is random. We know that GIMP likes to sort the palette like that. So I did an experiment - I converted both of the textures from indexed to RGB, then back from RGB to indexed using default settings. Turns out that the 98 palette looks identical in both cases - this suggests that GIMP might have been used to palettize it. (See pals.png)
Second, you can see parts of blue color bleeding through the red. Overally, the 98 colors are somewhat ugly. They look a bit like processed by the Hue-Saturation filter in GIMP. Let's see whether this is the case. After experimenting a bit turns out that with these parameters...
Color  Ove  Hue  Lig Sat
------------------------
Master   0,    0, 30, 100
C        0,  180,  0,   0
G        0, -118,  0,   0
...I was able to reconstruct the 98 texture exactly, pixel to pixel.
The conclusion is that the person who did that took the 99 texture and modified it with GIMP in a poor way. And there's no reason Unreal texture artists would take a good texture and screw it up like that only to change it back to the original in 99. Besides, they probably didn't even use GIMP^{[citation needed]}.

As you can see, the scenario A is impossible given the amount of evidence. Scenario B would be possible, but I couldn't find any unfakeable 98 content different from 99 (by unfakeable content I mean DLL/EXE files, or stuff which requires artistic skills to do like completely new maps or textures, or long script sections). So everything leads to one conclusion: the scenario C.

What I didn't put under microscope:

- maps, but when playing I haven't seen anything that could not be done with some simple editing. The SkyCaves map is not hard to replicate.

- non-actor classes, and this is probably the only remaining place where you can still find some hard evidence.

Links:

The original file (mirror)

BetaArchive thread, where the controversy began (warning: lots of emotions there)

nwfalcon's message (mirror)

---

It is suspected that ED2.EXE (the MS-DOS mesh UV editor from MeshTexUtils) contains some earliest fragments of Unreal Engine code. There are many interesting strings:

---

Stuff extracted from the mysterious TEST.U3D file from the november 95 alpha (normally unopenable).
Download

---

Turns out that Bump maps work in 0.871d.