Oh the Joys of Assembler!

[DaemonCantor]

I was digging thru the Wow.exe under IDA Pro and found this about halfway thru the Source:

.rdata:009E9330 aASpecialNoteAb db 0Ah         ; DATA XREF: .text:004749DBo
.rdata:009E9330         db '*** A special note about internal error number 1007 ***',0Ah
.rdata:009E9330         db 0Ah
.rdata:009E9330         db 'Experience suggests that a common cause of i.e. 1007',0Ah
.rdata:009E9330         db 'is unreliable memory or other hardware. The 1007 assertion',0Ah
.rdata:009E9330         db 'just happens to cross-check the results of huge numbers of',0Ah
.rdata:009E9330         db 'memory reads/writes, and so acts (unintendedly) as a stress',0Ah
.rdata:009E9330         db 'test of your memory system.',0Ah
.rdata:009E9330         db 0Ah
.rdata:009E9330         db 'I suggest the following: try compressing the file again,',0Ah
.rdata:009E9330         db 'possibly monitoring progress in detail with the -vv flag.',0Ah
.rdata:009E9330         db 0Ah
.rdata:009E9330         db '* If the error cannot be reproduced, and/or happens at different',0Ah
.rdata:009E9330         db ' points in compression, you may have a flaky memory system.',0Ah
.rdata:009E9330         db ' Try a memory-test program. I have used Memtest86',0Ah
.rdata:009E9330         db ' ([url=http://www.memtest86.com]www.memtest86.com[/url]). At the time of writing it is free (GPLd).'
.rdata:009E9330         db 0Ah
.rdata:009E9330         db ' Memtest86 tests memory much more thorougly than your BIOSs',0Ah
.rdata:009E9330         db ' power-on test, and may find failures that the BIOS doesn',27h,'t.',0Ah
.rdata:009E9330         db 0Ah
.rdata:009E9330         db '* If the error can be repeatably reproduced, this is a bug in',0Ah
.rdata:009E9330         db ' bzip2, and I would very much like to hear about it. Please',0Ah
.rdata:009E9330         db ' let me know, and, ideally, save a copy of the file causing the',0Ah
.rdata:009E9330         db ' problem -- without which I will be unable to investigate it.',0Ah
.rdata:009E9330         db 0Ah,0
.rdata:009E9751         align 8
.rdata:009E9758 aBzip2Libbzip2I db 0Ah         ; DATA XREF: .text:004749BDo
.rdata:009E9758         db 0Ah
.rdata:009E9758         db 'bzip2/libbzip2: internal error number %d.',0Ah
.rdata:009E9758         db 'This is a bug in bzip2/libbzip2, %s.',0Ah
.rdata:009E9758         db 'Please report it to me at: [email][email protected][/email]. If this happened',0Ah
.rdata:009E9758         db 'when you were using some program which uses libbzip2 as a',0Ah
.rdata:009E9758         db 'component, you should also report this bug to the author(s)',0Ah
.rdata:009E9758         db 'of that program. Please make an effort to report this bug;',0Ah
.rdata:009E9758         db 'timely and accurate bug reports eventually lead to higher',0Ah
.rdata:009E9758         db 'quality software. Thanks. Julian Seward, 30 December 2001.',0Ah
.rdata:009E9758         db 0Ah,0
.rdata:009E9912         align 4
.rdata:009E9914 ; char aCombinedCrcsSt[]
.rdata:009E9914 aCombinedCrcsSt db 0Ah         ; DATA XREF: sub_474A00+138o

That's putting it back a couple years for an Error Note!

[TheLuda]

Well, that simply means Blizzard statically linked quite an old version of the bzip2 compression library which does not include the recent security fixes, which means: yay, attack vectors ahoy!

[DaemonCantor]

ROFL...That's Good!

I'm trying to go thru it so that maybe I can help on some of this. I have found that they used C not C++ to make it and that's up till the last update for WoTLK, I don't have Cata or farther, Also I have found a HUGE block of LUA Programming( as best as I can figure) which I think may contain all of the Scripts but deciphering it is a bear because I have no idea about LUA Programming other than it compiles down to Assembler easily and it doesn't look like C or in other words the trees are completely different than C or C++.

The beginning Trees are all about sign on and Realm Selection along with the Security Subs to BattleNet. Next comes some Trees dealing with Graphics Handling and DB Utilization, Then Character Interaction followed by Audio Processing and finally the Scripts Packages

I guess the biggest complaint I have at this point is the Data Caches are all over the place! They were nowhere tidy in the least, like the Message I posted earlier was about in the middle of the dang program( what idiot puts a note like that in the middle of a program). I have multiple Arrays even in the Security section that deal with World Generation or Player Positioning and the like. It's a mess, this is why I prefer Assembly over C or C++ and I can see that debugging it is a Pain in the posterior. Nowhere is it anywhere close to modular but seems to made in this fashion to prevent hacking or reverse engineering.

The other problem I'm having is that I think the Security Sub's were written in assembler and then compressed, possibly with bzip, but the Data Streams are pretty straight forward as in I've identified several that use the internal DB during game play like World Generation around the Player but unsure as to which packets are used IE what is the Graphic displayed for a chair in the Inn at Goldshire but the link to a LUA Script is present for X-NPC's interaction with the player in Goldshire.

What I see is it might be better to make a Client that doesn't need the Internals but instead gets everything from the Server Core, As it stands I see a conflict between the Core and Wow.exe because of the external DB versus the Internal with-in Wow.exe. Maybe not everything to play is in the Local DB but enough is along with the LUA Scripts contained within the Client to make the game pretty much self sufficient and only need an external channel to update the Server as to the changes in the Local Player and Non-Local Players.