storm.dll data section different when loaded from different process
Moderators: Nefarius, Havvoric
storm.dll data section different when loaded from different process
Hi,
I am trying to load the diablo dll's in a different process from within a dll. When Game.exe starts normally (and just loaded storm.dll) the dll .data section of storm.dll is already different then when i load it in my own process. Any insights on how that might happen? I wouldn't expect any changes already at this point (i.e. right after dll load). The problem is that when call some functions the behavior seems to change due to this (did some assembly debugging). I also heard of the debugging trap made by blizzard, but i see the same problem when attaching to Game.exe later on. Do i need specific compilation settings? I am running on windows 10.
Any insights are appreciated!
I am trying to load the diablo dll's in a different process from within a dll. When Game.exe starts normally (and just loaded storm.dll) the dll .data section of storm.dll is already different then when i load it in my own process. Any insights on how that might happen? I wouldn't expect any changes already at this point (i.e. right after dll load). The problem is that when call some functions the behavior seems to change due to this (did some assembly debugging). I also heard of the debugging trap made by blizzard, but i see the same problem when attaching to Game.exe later on. Do i need specific compilation settings? I am running on windows 10.
Any insights are appreciated!
- Necrolis
- Throne
- Posts: 9125
- Joined: Sat Mar 25, 2006 1:22 pm
- Location: The Land of the Dead
- Contact:
Re: storm.dll data section different when loaded from different process
There is a static constructor in storm that triggers when you link to the dll as apposed to LoadLibray'ing it; it changes the MPQ decryption tables. Generally you want to link to storm via dummy lib filea nd import/use a single ordinal so that the linkage is not optimized away by the linker.
Netiquette, Do you USE it?!?! | Nefarius' Fixed TXT Files | Terms Of Service
Blackened | Day of Death | D2GFEx
"What was yours is mine. Your land, your people, and now your life." - Lim-Dul, the Necromancer
Judgement is Final, Death is Eternal
Re: storm.dll data section different when loaded from different process
Thanks for the quick response. I am actually using LoadLibrary, hence i would expect that the .data sections are not changing given your comment. Any other ideas?
- Necrolis
- Throne
- Posts: 9125
- Joined: Sat Mar 25, 2006 1:22 pm
- Location: The Land of the Dead
- Contact:
Re: storm.dll data section different when loaded from different process
If you use LoadLibrary then the tables are invalid, you must statically link to storm; else you need to hex edit it to change the paths taken in DllMain and the static constructors.
Netiquette, Do you USE it?!?! | Nefarius' Fixed TXT Files | Terms Of Service
Blackened | Day of Death | D2GFEx
"What was yours is mine. Your land, your people, and now your life." - Lim-Dul, the Necromancer
Judgement is Final, Death is Eternal
Re: storm.dll data section different when loaded from different process
Ah, if i load it through a different diablo 2 dll i should be fine right? Or are there other diablo 2 dlls with the same behavior?
- Necrolis
- Throne
- Posts: 9125
- Joined: Sat Mar 25, 2006 1:22 pm
- Location: The Land of the Dead
- Contact:
Re: storm.dll data section different when loaded from different process
I actually can't confirm this; but D2Win might work (I can't remember if the lpReserved indicator in DllMain gets passed down the load chain). The mpqedit tools that used storm.dll originally might have more info on this; else you can check the leaked Hellfire source codes storm dll source for what to to to manually fix the data after load (the one shhould be simple as its just un-xor'ing the mpq hash mix tables).
Netiquette, Do you USE it?!?! | Nefarius' Fixed TXT Files | Terms Of Service
Blackened | Day of Death | D2GFEx
"What was yours is mine. Your land, your people, and now your life." - Lim-Dul, the Necromancer
Judgement is Final, Death is Eternal
Re: storm.dll data section different when loaded from different process
I figured it out and i am now loading D2Client.dll instead which loads storm.dll, the problem i have now is that i am unable to initialize the language.
lang.dll#1033 (which initializes the language tables) in 1.12 crashes. It seems to fail on loading "data\\local\\font\\LATIN\\default.map". In advance i already loaded the mpq files by calling win.dll#10059. I tried to compare the load sequence of game.exe and the only difference i noticed that it seems to find this data section within d2data.mpq, while for me it doesn't, maybe i didn't initialize something correctly yet. Any ideas or code examples i could look into?
lang.dll#1033 (which initializes the language tables) in 1.12 crashes. It seems to fail on loading "data\\local\\font\\LATIN\\default.map". In advance i already loaded the mpq files by calling win.dll#10059. I tried to compare the load sequence of game.exe and the only difference i noticed that it seems to find this data section within d2data.mpq, while for me it doesn't, maybe i didn't initialize something correctly yet. Any ideas or code examples i could look into?
- Necrolis
- Throne
- Posts: 9125
- Joined: Sat Mar 25, 2006 1:22 pm
- Location: The Land of the Dead
- Contact:
Re: storm.dll data section different when loaded from different process
Storm is not being initialized properly; I helped someone else with this recently too. I really suggestion just using dumpbin and MSVC librarian to make a dummy lib to link to storm.dlldargonis wrote: ↑Sun Jun 28, 2020 6:33 pmI figured it out and i am now loading D2Client.dll instead which loads storm.dll, the problem i have now is that i am unable to initialize the language.
lang.dll#1033 (which initializes the language tables) in 1.12 crashes. It seems to fail on loading "data\\local\\font\\LATIN\\default.map". In advance i already loaded the mpq files by calling win.dll#10059. I tried to compare the load sequence of game.exe and the only difference i noticed that it seems to find this data section within d2data.mpq, while for me it doesn't, maybe i didn't initialize something correctly yet. Any ideas or code examples i could look into?
Netiquette, Do you USE it?!?! | Nefarius' Fixed TXT Files | Terms Of Service
Blackened | Day of Death | D2GFEx
"What was yours is mine. Your land, your people, and now your life." - Lim-Dul, the Necromancer
Judgement is Final, Death is Eternal
Re: storm.dll data section different when loaded from different process
I am already loading storm.dll by loading D2Client.dll, shouldn't that solve this problem? Or are you saying that the dll loading itself breaks it? E.g. i should compile by linking storm.dll statically instead otherwise it will be broken? Is that what game.exe is actually doing? Because i see it being loaded in game.exe. My conclusion: I think i am missing your pointNecrolis wrote: ↑Mon Jun 29, 2020 2:36 pmStorm is not being initialized properly; I helped someone else with this recently too. I really suggestion just using dumpbin and MSVC librarian to make a dummy lib to link to storm.dlldargonis wrote: ↑Sun Jun 28, 2020 6:33 pmI figured it out and i am now loading D2Client.dll instead which loads storm.dll, the problem i have now is that i am unable to initialize the language.
lang.dll#1033 (which initializes the language tables) in 1.12 crashes. It seems to fail on loading "data\\local\\font\\LATIN\\default.map". In advance i already loaded the mpq files by calling win.dll#10059. I tried to compare the load sequence of game.exe and the only difference i noticed that it seems to find this data section within d2data.mpq, while for me it doesn't, maybe i didn't initialize something correctly yet. Any ideas or code examples i could look into?
ps. the code i am using is old code and should have been working previously, do you know of any changes in this area in windows 10 (or at least later than windows xp?)
Re: storm.dll data section different when loaded from different process
For future reference. I changed from loading all the dll's within a dll to loading the dll's within an .exe (still don't know why that helped).
I also set the variable at offset 0x53120 (diablo 1.13c) in storm.dll to NULL, which ensures the storm mpq hashing isn't performed. Afterwards it worked beautifully
Thanks for the help.
I also set the variable at offset 0x53120 (diablo 1.13c) in storm.dll to NULL, which ensures the storm mpq hashing isn't performed. Afterwards it worked beautifully
Thanks for the help.