CVS Commit Nov 11, 2002 ShowEQ 4.3.3 EQDecode sanity, new libEQ and other updates

[fee]

fee (floyd) 11/11/2002
-----------------------
+ ShowEQ 4.3.3
+ Bug Fixes
- updated EQDecode to be more sane about accepting user keys
in conjunction with a new libEQ (ddaac48baaa3e9b015984a366748ed72)

+ Features
- HotKeys F12 to load key from file
- HotKeys CTRL+F12 to bring up key dialog

ratt 10 Nov 2002
----------------------

+ Bug Fixes
- Fixed walk path length record option (Thanks Nok)

+ Features and Updates
- Added Nok's Speedometer
- Catt's spell update
- Catt's filter update
- Bluevulpines raid channel update



casey 11/07/2002
----------------------
+ conf/seqdef.xml
- fixed typo (a property tag was missing the y, thx fippy)








A new libEQ will be hitting the ftp servers hopefully in the next day or so. Using this new code with current libEQ should still work although it will not have any fault tolerance for bad keys. The new libEQ used with the updates in this cvs commit will provide better fault tolerance for handling bad keys. In other words no more lock-ups if you enter a key twice OR enter a bad key. Entering a bad key will now be detected and proper error handling will ensure you can re-enter the correct key.



ls -ls libEQ.a
8 -rw-r--r-- 1 root root 4688 Nov 11 22:19 libEQ.a
md5sum libEQ.a
ddaac48baaa3e9b015984a366748ed72 libEQ.a

[fee]

The new libEQ is available in the usual pleaces. See the md5sum posted above and README.libeq for locations to get the file.

enjoy
fee

[guice]

Ah, I downloaded the patch last night, but skeptic about compiling it cause I wasn't sure what more sane about accepting user keys really ment.

Doing everything automated, so manual entering of keys was never a problem.

However, the F12 will be of great help when the SEQ thinks I'm zoning again (while in the middle of a zone).

[spectre]

for clarification, is this a new decode via libEQ, or do we still need to sniff the packets to get a valid decode?

[spectre]

i mean does it decode or do we still have to sniff keys (not packets) from memory (damn those trials, must.. beat... executioner....)

[DebianSEQ]

You still have to sniff. This is not likely to change. Verant is finally getting smart.

[devnul]

This was smart how?

I don't see how forcing more people to learn to dissect the workings of their product is smart.

I don't see how setting the table for winseq is smart.

I don't see how wasting development resources in a useless encryption attempt is smart.

I don't see how risking the wrath of The Ratt was smart

In the short run it will reduce use some.. but in the long run it will increase it, as people will be forced to take the leap to windows and people will inevitably start to pass around winseq versions.

dn

[Circles]

Originally posted by devnul
This was smart how?


I don't see how wasting development resources in a useless encryption attempt is smart.

dn

they didnt waste development resources on the encryption, they just rotated keys. what htey added was compression, which HELPS modem users, as less data over time is now sent to the client... this is seen in my monthly bandwidth useage, I was at 8gb per week from having a mule in the bazaar, im down to under 7gb. I think thats a awesome improvement.

Some bright boy getting the idea to roll encryption with compression is where they screwed the pooch.

[Cryonic]

You might want to double check that info Circles. It has been pointed out that the packets they are compressing aren't very large to begin with and make up a very small percentage of the overall bandwidth.

[high_jeeves]

Yeah.. bazaar is a VERY extreem case of bandwidth savings.. the newly compressed packet is the NewSpawn packet. Given the number of people who zone in/out of bazaar vs. any other zone (except perhaps nexus and/or PoK), it will be one of the highest. The EQ devs who occasionally stop by the ShowEQ irc channel flat out said that this was done to break ShowEQ.. I think we can take their word on that. If they wanted bandwidth saving they would have compressed all their packets, or atleast many of the larger ones.. they didnt. They compressed the ONE packet that ShowEQ was using do attack the encryption.

--Jeeves

[sauron]

The ironic thing is that ShowEQ is actually BETTER than it was before they tried to stop it (as far as "decoding" quickly and reliably). They pushed our hand, and only made it worse for themselves. Thanks Devs, for all the hard work! You guys are truly geniuses.

Sauron

[Resiliant]

You know, I have to agree. Before the change, it sometimes took several seconds, even minutes, before the key resoloution occured due to the fact that it had to wait for a spawn packet to get the tool to break the encryption. There were times in Kedge that I would actually have to spawn something in order to get the decode which NEVER happend automatically.

Now, all I have to do is press F12 immdiately upon zoning and *bingo* the whole zone is decoded instantly. If i can figure out the correct code to get SEQ to do a key load (Im great at C and less good at C++), then I won't even have to press F12... it just instantly and automatically rips the key and PRESTO! It resolves every time.

Quite a nice addition! I actually like SEQ MORE now than I did before. Thanks SoE!

[lane]

ROFL That last post is going to piss someone off, but I have to agree. I decode now with just a few seconds of zoning. The only thing I don't like is having to wait at the char select screen for the first key grab.

Resiliant, go get some code for the UDP port send, and stop pressing keys.

-Lane

[baelang]

most of the time i now get full decodes before my client has finished zoning. (using udp)

[Resiliant]

Hmm UDP would be cool. I've Looked in the Sniffer thread, but I cant seem to decipher which entry it is that is the UDP source.