Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reverse Diablo UI #41

Open
Pehat opened this issue Jun 21, 2018 · 19 comments
Open

Reverse Diablo UI #41

Pehat opened this issue Jun 21, 2018 · 19 comments
Milestone

Comments

@Pehat
Copy link

Pehat commented Jun 21, 2018

Hello! I have a moderate experience in disassembling DOS games and I want to help with the subj. How can I help?

@ghost ghost added this to the 1.0 milestone Jun 21, 2018
@ghost
Copy link

ghost commented Jun 21, 2018

That's great! Seeing as much of the UI is actually battle.net related, we won't need all of it. The UI primarily consists of calls to Storm.dll to post PCX images and then loads a Dialog format from the read only data. This is then posted as a windows message proc to display the elements and fetch user input.

First and foremost, the templates stored in the rdata need to be extracted. This can be done with "Resource Hacker". The resources can then be added to the Visual C project.

Next, if you have a decompiler, it's best to start off reversing the first functions called, and then move down the line. In this case, diablo.cpp is our first candidate:

UiInitialize();
UiTitleDialog(7);

After which the user inputs, it takes us to the title screen and plays music with this:
UiMainMenuDialog("Diablo v1.09", &a2, effects_play_sound, 30)

@sskras
Copy link
Contributor

sskras commented Jun 25, 2018

This reminded me about Wine bugreport #2082. I registered it 14y ago, and it still stays hard to fix. Main reason, I would summarize, is that Diablo is doing blitting some UI stuff to DDraw surface by using classical WinAPI dialog calls.

Guys had some summaries written up here:
https://bugs.winehq.org/show_bug.cgi?id=2082#c84
https://bugs.winehq.org/show_bug.cgi?id=2082#c125 (and below)

Not that it's much worth for your project, but just in case.

@ghost
Copy link

ghost commented Jul 7, 2018

I might get some time tomorrow to look at this DiabloUI stuff.. so far it looks like external calls...

@maristane
Copy link

Hey guys, here's something that can at the same time help me and give you more insight on the workings of Diablo UI: I can't seem to find where some strings in it are coming from.

I've been translating the game to portuguese, and I used ResourceHacker to translate Dialogs and other Strings in DiabloUI.dll. But some of them are nowhere to be found, even though they appear in the game. I also tried searching with a hex editor, with and without the null entries between each letter (since there are those null entries for other strings in the hex view for the file, probably something about encoding).

Do you guys know or can try to find where is DiabloUI.dll reading this information from? Or can give me some directions on how to find out?

It's the text in english below "requisitos:" and the connection types below "conexões":

image

Thanks in advance!

@StephenCWills
Copy link
Member

StephenCWills commented Jul 10, 2018

That text is in Standard.snp, if I'm not mistaken.

EDIT: And I suppose the Battle.net text is probably in Battle.snp.

@maristane
Copy link

Oh, they are indeed there, thx:
image

But there's an even weirder problem now: changing it does nothing.

image

I could edit a lot of strings and Dialogs I wasn't even aware of by opening the .snp with ResHacker, but not those regarding the connection types.

But they really are in the file when I open with the Hex Editor, but they remain the same in-game even after I edit them. As if they are somewhere else. But I doubt they are, since If I somehow corrupt the file in the hex editor in that text (adding/removing letters/bytes instead of just replacing them) a problem occurrs in that precise screen (the list of connections stops at "Battle.net").

I've checked dozens of times that I have the edited file in the game folder and not the original one. This makes 0 sense :/.

I know that Battle.snp is used in a checksum for Battle.net safety purposes. Could it be that there is something like a checksum regarding Standard.snp, but in case it detects changes it uses an unaltered version stored somewhere? But if so, why would it use it when I directly corrupt the file?

@ghost
Copy link

ghost commented Jul 10, 2018

Those same strings are hidden inside an MPQ embedded at the end of the .SNP files. Search for 4D 50 51 1A in a hex editor and then copy everything from that address to the end of the file and save it as a .MPQ. Then you can open it and replace the file with your new strings.

@maristane
Copy link

maristane commented Jul 10, 2018

Perfect! But now I'm having problems putting it back (I'm really noob with hex editing so I can be messing something up in that area). The file inside the hidden .MPQ is called "caps.dat". Here's what I've been trying.

I hex-edited caps.dat (just changed one letter to test it), and then, to try to get it back:

1 - I've put it inside the .MPQ I saved, then opened the .MPQ with a hex editor, copied it and pasted it in STANDARD.snp, replacing the area for the previous .MPQ. Didn't work (game shows only Battle.net connection, as if failing to read the STANDARD.snp).

2 - I've put it straight inside Patch_rt.mpq in hopes the game would read there first. But, by doing this, nothing changed at all.

3 - I noticed that I could open STANDARD.snp using WinMPQ and find caps.dat there hanging around. So I tried to replace it using WinMPQ. Got same problem as test 1.

4 - I've tried 3 again, but this time matching my edition in the corresponding string visible in Standard.snp (the ones @StephenCWills helped me find before - for example, leaving "Dirett" and "Dirett" both in Standard.snp and caps.dat). Same problem as test 1 and 3.

I suspect my attempt 1 would be the best way to go, but I'm clearly failing to do that properly. What is the best way to paste the hex code for the altered .MPQ back into Standard.snp?

@ghost
Copy link

ghost commented Jul 10, 2018

I believe the MPQ is encrypted and signed as there's a file called (Signature). Perhaps @heinermann could drop in and give us some advice. The Brood War API project uses a custom .SNP with the file caps.mpq:
https://github.com/bwapi/bwapi/tree/master/bwapi/SNP_DirectIP/SNP

@maristane
Copy link

I managed to successfully edit the caps.dat inside STANDARD.snp's MPQ! In a very "I have no idea what I'm doing" spirit, here's what I did:

  • I learned here that the MPQ Editor seemed to handle signed MPQ files better than, let's say, WinMPQ, which I was using.
  • So I gave it a shot! I used the win32 version of the MPQ Editor, edited and replaced the caps.dat (keeping the same file size, adding or deleting bytes breaks the thing, as it often does). And voilà, it worked! I could translate all strings there!

But then we have BATTLE.snp, a different beast entirely.

Doing the same thing for the caps.dat inside BATTLE.snp's MPQ... crashes the game when opening the multiplayer menu. The error dialog explicitly says the caps.dat file is corrupted. I wouldn't expect less, I know BATTLE.snp has a heavier security than STANDARD.snp. But, well, I have no idea how to proceed from that.

I did notice some very relevant differences between STANDARD's caps.dat and BATTLE's caps.dat file properties in the MPQ Editor.

Here's the info for STANDARD's caps.dat ("Patch List" is the snp file name, which is renamed in my case - just in case somebody notices and gets confused):
image

And now for BATTLE's caps.dat (same thing as before for the "Patch List"):
image

Well well well... Very different Attributes, and I have no idea what most of them mean. I've noticed that they remain the same after editing the file (only the compressed file size changes, oddly). But that's about all I got for now.

I'm trying to understand those attributes. I found some explanations here. But I'm sensing it might be pointless and my problem is probably related to something else. What do you guys think of all this?

@ghost
Copy link

ghost commented Sep 14, 2018

Started working on reversal of the DiabloUI. However, only small (useful) parts will be reversed so we can reconstruct the UI using Diablo's engine, which won't have that black screen on Linux. The good news is that we have almost all of the file names thanks to the beta. We might be missing only 1-2.

[1.09] artfont.cpp
[1.09] bn_prof.cpp
[1.09] BNetGW.cpp
[1.09] Connect.cpp
[1.09] cr8game.cpp
[Beta] CreaDung.cpp
[1.09] credits.cpp
[1.09] DiabEdit.cpp
*Guess DiabloUI.cpp
[Beta] DirLink.cpp
[Beta] disclaim.cpp
[1.09] Doom.cpp
[1.09] Focus.cpp
[1.09] local.cpp
[Beta] Logon.cpp //probably removed in 1.05+
[Beta] MainMenu.cpp
[1.09] OkCancel.cpp
[1.09] Progress.cpp
[1.09] Sbar.cpp
[1.09] SelConn.cpp
[1.09] SelHero.cpp
[1.09] SelIPX.cpp
[1.09] SelModem.cpp
[1.09] SelRegn.cpp
[Beta] SelYesNo.cpp
[Hell] Support.cpp //hellfire only
[1.09] Title.cpp

@sskras
Copy link
Contributor

sskras commented Sep 14, 2018

Whee! Do you plan to release the work it in separate repo?

@sskras
Copy link
Contributor

sskras commented Oct 21, 2018

OK, I see new commits here in the DiabloUI dir, thanks!

@AJenbo
Copy link
Member

AJenbo commented Oct 29, 2018

@galaxyhaxz : @7keo is starting to work on this, I have told him that we for the most part don't care about the bin exactness of DiabloUI (I see it as just a supporting element like the installer or what not). Do you have any reservations in regard to doing refactoring and renaming in this part of the code?

@ghost
Copy link

ghost commented Oct 30, 2018

My 2¢ is that it would be better to work on the main project. But if keo is dead-set on the UI, it would be best to focus on multiplayer (IPX and battle.net in particular) and just leave what's already finished as it is. Below are the files that have not yet been reversed. It could be useful to reverse the IPX code so a custom dialog can be added to enter the IP address for TCP/IP games.

bn_prof
BNetGW
DirLink
EntDial
Modem
ModmStat
Progress
SelConn
SelDial
SelGame
SelIPX
SelModem
SelRegn

@AJenbo
Copy link
Member

AJenbo commented Oct 30, 2018

Personally I find the menu one of the most annoying things since it's the most broken part on any system. I think he will also be looking at porting it to modern systems at the same time, so that would be very welcome in my opinion 😁

@ghost
Copy link

ghost commented Oct 31, 2018

@galaxyhaxz If I am not mistaken, isn't the Battle.SNP needed too?

Question, @AJenbo do we know how the game communicated with PVPGN? I mean, that would be the ultimate fix and I think knowing this would save the most time.

@AJenbo
Copy link
Member

AJenbo commented Oct 31, 2018

Good point we should probably play around with that to figure out how to do the communication.
https://github.com/pvpgn/pvpgn-server
It would be nice if we didn't have to reverse all of the snp files and could just do it from known network trafic.

@7keo
Copy link

7keo commented Oct 31, 2018

My 2¢ is that it would be better to work on the main project. But if keo is dead-set on the UI, it would be best to focus on multiplayer (IPX and battle.net in particular) and just leave what's already finished as it is. Below are the files that have not yet been reversed. It could be useful to reverse the IPX code so a custom dialog can be added to enter the IP address for TCP/IP games.

bn_prof
BNetGW
DirLink
EntDial
Modem
ModmStat
Progress
SelConn
SelDial
SelGame
SelIPX
SelModem
SelRegn

starting on that list, will take a look at it.

@diasurgical diasurgical deleted a comment from khanduras Apr 6, 2020
@diasurgical diasurgical deleted a comment from HarpyWar Apr 6, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants