PDA

View Full Version : WineX users: is showeq working now?



fee
01-05-2003, 03:50 PM
Just a quick survey to see if the 4.3.4 changes fixed up the problems showeq had sniffing a winex client. Please post back here if they did or did not.

fee

cbreaker
01-09-2003, 10:03 AM
This actually doesn't matter anymore - the new changes to the DirectX stuff in today's patch completely break EQ on WineX and it doesn't look like it's going to be fixed for a good long time.

EQ isn't officially "supported" by winex, so it's not a priority for them. Not to mention there's some things Sony put in to the new directx stuff that wine doesn't and can't do (limitations in current drivers or whatever on the linux side, like off-screen rendering)

Vonma
01-09-2003, 12:58 PM
Naturally, prior to today, I had WineX + SEQ + EQ working in full featured mode (IE, non GPS mode). All the spawns and such were showing up, timers were working, and it was pretty much flawless, save for the method of keysniffing (which is a pain in the ass, though I'm working on it). I haven't tried WineX with the latest eq executable, but I plan on it sometime tonight or tomorrow.

Catharz
01-09-2003, 11:35 PM
Originally posted by cbreaker
This actually doesn't matter anymore - the new changes to the DirectX stuff in today's patch completely break EQ on WineX and it doesn't look like it's going to be fixed for a good long time.

EQ isn't officially "supported" by winex, so it's not a priority for them. Not to mention there's some things Sony put in to the new directx stuff that wine doesn't and can't do (limitations in current drivers or whatever on the linux side, like off-screen rendering) Umm, I just tested EQ on WineX to make sure. It works fine. I don't have SEQ looking at my Linux machine, but at my Windoze machine so I don't have a problem with SEQ +Winex on Linux.

cbreaker
01-12-2003, 04:51 AM
Well, that's good. People are saying that it's completely broken, on the WineX forums. /shrug

cide
01-12-2003, 05:46 AM
What? I dont see any of those topics... It works fine for me.









ALSO.


do people who use WineX EverQuest + ShowEQ on the same machine usually make their own Linux/WineX key sniffer?

Because ive done a bunch of searching in the key sniffer forums, and their is nothing for linux/winex. :/

that would kick some ass though.... having it all their, Eq on desktop one windowed, and Seq on the 2nd :)

Vonma
01-12-2003, 10:51 PM
I had a friend write a shell script to activate gdb and spit out the key (But for some reason when SEQ reads the keyfile.dat, it totally fudges up, so I end up inputting it manually, but no big deal). It's an extremely easy process, just if you have a slow machine, or you're in a shitty zone (Seru, Bazaar) don't even think about using it...gdb has to halt the process to debug it and this usually results in EQ disconnecting if you don't do it soon enough, and furthermore, it's probably an easy way to get busted for using SEQ. If someone knows of a better way to read the memory, I'm open to suggestion, but this is the way it's worked for me:


#! /bin/bash
#
# Shell script to get the encryption key from memory in everquest.exe
#
#

# ------------------------------------------------------------------
# ---- EQ variables that will change from time to time -------------
# ------------------------------------------------------------------


# offset of the encryption in memory
KEY_LOCATION="0x007acc38"

# full path to the file conatining the decryption key
# set the path and filename to a place where SEQ wants to find it
DECRYPTION_FILE="/usr/local/share/showeq/keyfile.dat"

# ------------------------------------------------------------------
# ---- system dependent variables that should not have to change ---
# ------------------------------------------------------------------

# name of everquest process
EQ_PROCESS_NAME="eqgame.exe"

# full path of gdb
GDB="/usr/bin/gdb"

# full path of temp file to be feed to gdb on stdin
TEMP_FILE_IN="/tmp/seq-gdb-input"

# full path of temp file to capture output of gdb
TEMP_FILE_OUT="/tmp/seq-gdb-output"


# ------------------------------------------------------------------
# ---- anything below this comment block should not change ---------
# ------------------------------------------------------------------

# find the pid of the eqgame process
EQ_PID=`ps ax | grep -i $EQ_PROCESS_NAME | grep -v grep | awk '{ print $1 }' | sort -n | head -1`

# check to see if we were successful in finding the EQ process
if ( test -z $EQ_PID ) then
echo "Unable to find \""$EQ_PROCESS_NAME"\" in process list."
exit
fi

# print some info
echo $EQ_PROCESS_NAME" pid = "$EQ_PID
echo "key offset = "$KEY_LOCATION
echo ""

# create a temp file to feed to gdb
cat > $TEMP_FILE_IN << EOF
attach $EQ_PID
x / $KEY_LOCATION
q
y
EOF

# run gdb and capture output
$GDB < $TEMP_FILE_IN > $TEMP_FILE_OUT 2>&1

# check to see if the key location was accessable by GDB
IS_KEY_FOUND=`grep -i "Cannot access memory at address" $TEMP_FILE_OUT`
if ( test -n "$IS_KEY_FOUND" ) then
# key was not able to be read
echo "Unable to read key at location "$KEY_LOCATION"."
else
# key was able to be read
# get the key from the output of gdb
#cat $TEMP_FILE_OUT
KEY=`grep ":" $TEMP_FILE_OUT | grep -v "Detaching" | awk '{ printf("0xffffffff%s\n", substr($3,3)) }'`
echo "Decryption key = "$KEY
echo $KEY > $DECRYPTION_FILE
fi

# clean up temp files
rm -f $TEMP_FILE_IN $TEMP_FILE_OUT

Flash2002
01-28-2003, 06:02 PM
The reason why the keyfile.dat doesn't work for you is the way you are outputting it.

The keyfile.dat is not read in plain ASCII text, like the display of the key is.

Its actually saved in binary byte format, 8 bytes long, thats what ShowEQ expects, not ASCII.

-Flash

fester
01-28-2003, 06:50 PM
Fee,

Showeq can not presently handle device=any to get packets from a local keysniffer. I submitted some local edits I have been using for a while in this thread: http://seq.sourceforge.net/showthread.php?s=&threadid=2861

If you add these edits, showeq can properly sniff and see key sniffer packets coming from the localhost. This releaves the need to hit a button to pluck the key from a local file.