View Full Version : OpCode Validation
deathinc
12-15-2001, 10:42 AM
I'm working on a patch to the current CVS tip to enable OpCode Validation. To start off with, simply verifying structure sizes before they get parsed/decoded, but passing them along regardless. (So, yes it might stil Segfault, but you should know why fist).
Two quick questions:
1. Is anyone else doing this now, and am I duping work?
2. The 'major changes' Ratt & Team are working on -- are the changes to the decode.cpp and other sections severe enough to hold this off until you release?
-- Deathinc
Nearly every file is affected in some way. I would hold off on any patches against the current CVS tree, and wait for the update.
darkangelx
12-15-2001, 11:59 PM
Ratt, can I ask what you think of Adenine's patch that he posted? I personally havent tried it, but other claim it doesnt seg fault, but doesnt decode 100%.
Another question, do you or do you not want the current libEQ.a hosted for everyone. I by no means want to do something that you do not want (refer to rule #1 in a post on sourceforge) to piss off the devs.
Ratt, can I ask what you think of Adenine's patch that he posted? I personally havent tried it, but other claim it doesnt seg fault, but doesnt decode 100%.
I don't approve of it. I'm not sure why he posted it, when it's exactly opposite of what I asked.
Another question, do you or do you not want the current libEQ.a hosted for everyone. I by no means want to do something that you do not want (refer to rule #1 in a post on sourceforge) to piss off the devs.
No, I do not want it hosted on alternate sites. Asking people to not do it is all I'm going to do (or really, all I'm able to do), if you or others choose to go ahead and do it anyway, so be it.
However, personally, I would not use a libEQ.a from an untrusted source. I would especially NOT use the source code from an untrusted source without going over it with a fine toothed comb. It would be trivially easy to add/change code to steal login/password information and send it by a number of methods to a third party.
darkangelx
12-16-2001, 05:12 PM
Originally posted by Ratt
No, I do not want it hosted on alternate sites. Asking people to not do it is all I'm going to do (or really, all I'm able to do), if you or others choose to go ahead and do it anyway, so be it.
If I may be so bold to then ask why? If the libEQ.a isnt going to be avaliable to everyone through CVS (as it is not now) and having the files from the CVS is useless without out the libEQ.a, what is the point. I am by no means trying to be arguementative, nor trying to get on your nerves, but as a SEQ user I want to help everyone I can, I am using a working SEQ right now and I just dont understand why you dont want that for everyone.
I could be wrong and you guys working on SEQ might come out with another libEQ.a and will host it within the CVS in the future. If that is the case I'll stfu and go back to playing and enjoying the version I have until and breaks again.
Also I lack the skills to alter the libEQ.a in any way that could be harmful to anyone. Again I just wanted to be helpful.
awhamilt
12-16-2001, 10:36 PM
Originally posted by darkangelx
I could be wrong and you guys working on SEQ might come out with another libEQ.a and will host it within the CVS in the future.
If they host libEQ.a in the CVS, it won't be using Sourceforge's CVS repository ("Open-Source Only" on Sourceforge).
I believe that's why they took it out in the first place.
deathinc
12-17-2001, 08:26 AM
Originally posted by darkangelx
If the libEQ.a isnt going to be avaliable to everyone through CVS (as it is not now) and having the files from the CVS is useless without out the libEQ.a, what is the point.
I'd hardly call it 'useless' - granted it would run in a 'diminished capacity' (without decode), but it's still very useful for it's GPS functionality.
What is most likely to happen, as I believe awhamilt is correct regarding SourceForge, is that a 'supported' libEQ.a file will be made available via the usuall sources, krisp, trifocus, etc...
darkangelx
12-17-2001, 09:39 PM
Originally posted by deathinc
What is most likely to happen, as I believe awhamilt is correct regarding SourceForge, is that a 'supported' libEQ.a file will be made available via the usuall sources, krisp, trifocus, etc...
Well for me I know 2 places, hackersquest and sourceforge. If there is another place that is "secure' or 'supported' as you stated, hey give me the full site, I'd be glad to look there for future libEQ.a's
Hoihoi
12-18-2001, 02:28 AM
since there is only a need of a md5sum to be posted, you could get it from anywhere and check it by yourself
casey
12-18-2001, 06:47 AM
darkangelx, try reading your README.libeq file next time your compile showeq, it lists the trusted download locations, where you will see the working libEQ repopulate at the proper time.
fuqjak
12-18-2001, 11:28 AM
Where do I always want to get my md5sum code from to be SURE that my libEQ.a is a valid file and not a password stealer? I believe it is off the SourceForge site but I just want a direct link for myself and all the other newbs out there to prevent anyone from getting a 'hacked' libEQ.a
casey
12-18-2001, 06:01 PM
dont know if it will make it into README.libeq, but the libraries i distribute (trifocus.net) will have another file in the same dir with the md5sum in it, and as per README.libeq, i am inherently trusted. if you trust seq developers that is.
darkangelx
12-18-2001, 10:21 PM
I just want to confirm a few things:
1) the snapshot.tar.gz doesnt even come with a libEQ.a, thus if this is one of the sites to get it why is it missing.
2) the other site has a libEQ.a with a md5sum of :
8da5608635e69205807fbf6e41e9bc2f libEQ.a with a size of 6786
is that correct?
The one I have is:
a38ceb68b70e0bc2ea27a5147fa50f73 libEQ.a with a size of 4636
but it doesnt have any issues, this is oddly enough an older one, at least i think, but it works. Just looking for some clarification.
:confused:
darkangelx
12-19-2001, 12:10 AM
ok tried that libEQ.a from the site and it wont compile i get this:
g++ -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/lib/qt/include -I/usr/X11R6/include -DMAPDIR=\"/usr/local/share/showeq\" -DLOGDIR=\"/usr/local/share/showeq\" -I/usr/include/pcap -g -O2 -c gdbmconv.cpp
/bin/sh ../libtool --mode=link g++ -g -O2 -o showeq main.o spawnshell.o spawnlist.o spellshell.o spelllist.o cpreferences.o vpacket.o editor.o filter.o m_spawnshell.o m_spawnlist.o m_spellshell.o m_spelllist.o m_editor.o packet.o m_packet.o interface.o m_interface.o compass.o m_compass.o map.o m_map.o util.o pcap.o experiencelog.o m_experiencelog.o msgdlg.o m_msgdlg.o player.o m_player.o decode.o m_decode.o skilllist.o m_skilllist.o statlist.o m_statlist.o itemdb.o gdbmconv.o -lqt -lEQ -lgdbm -lz -lpcap -lpthread
mkdir .libs
libtool: link: warning: library `/usr/lib/libgdbm.la' was moved.
libtool: link: warning: library `/usr/lib/libgdbm.la' was moved.
g++ -g -O2 -o showeq main.o spawnshell.o spawnlist.o spellshell.o spelllist.o cpreferences.o vpacket.o editor.o filter.o m_spawnshell.o m_spawnlist.o m_spellshell.o m_spelllist.o m_editor.o packet.o m_packet.o interface.o m_interface.o compass.o m_compass.o map.o m_map.o util.o pcap.o experiencelog.o m_experiencelog.o msgdlg.o m_msgdlg.o player.o m_player.o decode.o m_decode.o skilllist.o m_skilllist.o statlist.o m_statlist.o itemdb.o gdbmconv.o -lqt -lEQ /usr/lib/libgdbm.so -lz -lpcap -lpthread
/usr/lib/libEQ.a(libEQ.o)(.eh_frame+0x11): undefined reference to `__gxx_personality_v0'
collect2: ld returned 1 exit status
make[2]: *** [showeq] Error 1
make[2]: Leaving directory `/usr/local/ShowEQ/linux/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/local/ShowEQ/linux'
make: *** [all-recursive-am] Error 2
Just so you know, the old libEQ.a that I have compiles and decodes correctly...
Elberg
12-19-2001, 02:23 AM
It looks like whoever built the ~6k version of the library did it with gcc-3.0.2, whose g++ end isn't really all that compatible with previous versions.
Hint hint.
n-sane
12-19-2001, 05:07 AM
darkangelx -
8da5608635e69205807fbf6e41e9bc2f
Is the md5sum to the libEQ.a that worked up until a few weeks ago.
a38ceb68b70e0bc2ea27a5147fa50f73
Is the md5sum to the libEQ.a that was posted recently. (This is the one that decrypts properly)
Zaphod
12-23-2001, 07:42 AM
The current md5sum of libEQ.a: 8da5608635e69205807fbf6e41e9bc2f.
You have it backwards n-sane.
Enjoy,
Zaphod (dohpaZ)
Powered by vBulletin® Version 4.1.11 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved.