Stopping encrypted packets
 

That may stop the packets from being sent on, but it still doesn't seem to stop the upgrade popup, when receiving a 'normal' encrypted packet from someone else, or should it?

JD

Ignorance is so lame
 

You haven't the foggiest notion of what you're talking about. That "other forum" does not censor anything but extreme foul language and racist remarks, and even then it's only the offending word(s) that are edited - not entire posts or threads. Go ahead, post your opinions over there. You'll never see them deleted. Guaranteed!

That censorship crap was a stupid rumor started by a disgruntled forumite who had a post or two deleted, and rightly so. But don't assume that censorship is a common event there. In fact, it is extremely rare these days - I'd even go as far as to say it's non-existent.

Try it out. Prove me wrong.

Yes, it stops it because Bearshare can't decrypt the packet!

As for censorship, it wasn't a rumor, vinnie was going to do it and if it wasn't for this forum being open and all the complaints it would have happened. Everyone from there came over here in protest, and vinnie lost control of his little world. Boo hoo, lesson learned, spanking and all.

Free speech wins again!

Encrypted packets
 

Any more hints of which area to look for exactly?
I tried several 'near the end', to no avail.

In fact I removed the whole last section, the upgrade notice still pops up.

This is with V2.23 and V2.25.

Any more info please, would be greatly appreciated.

I think 'reverse-engineering the encrypted upgrade behaviour' out of this program will not in the least cause anybody any worries, won't it.

So where is this RSA code and what's it look like, or preceeded by???

Thanks in advance

JD

I'm a little confused about this, why is it important that it knows its talking to a real Bearshare client but not important to know if you are talking to a real LimeWire client? Is it because newer bearshare clients hold information about where to get the update or updates are recieved through gnutella entirely? And isnt that considered an automated search?

I think he means the spy control packets are encrypted with BS. Yes that's right, it's all BS anyway, so change a few BS bytes and everyone will be happy.

I assume you look for strings like "RSA", but since the BSing dude probably reads this forum they probably did a bit shift on the bytes so you can't read them.

Someone want to write something that does this for me?

mysterious
 

Vinnie said on the GDF:

> Damn these people that didn't learn from BearShare's mistakes!

> If you recall, the "problem" version of BearShare would send a binary
> query of fixed length ONCE to EACH new connection that was
> established.

> This is identical to the proposal that John Marshall suggested (a new
> query per new host connection).

Is this update behaviour still built into newer bearshare servents ? don't know, i don't use bearshare, but it would seem very strange to me as vinnie said it "screwed up the network" and as he didn't want it to be used for automated researching. I am very confused about this thing as well, for several reasons:

1) there is absolutely no sense in broadcasting version numbers in order to look for an update. it causes too much traffic and it would be way easier to just connect to the home server on startup (like other servents do).

2) there is even less sense in <I>encrypting version numbers with an RSA key.</I> this is simply ridiculous.

3) if it were to block fake versions, why is this protocol enhancement secret ? it would protect bearshare servents, but every other servent would still connect to the fake version (which might be a virus or something even worse...) because they don't have a notion of what these packets mean.

4) a fake version of bearshare could just send normal messages, identifying itself as "SomeNewClient", and noone would notice it!
The user running the fake would never know what messages it sends to other servents (if he is not a hacker himself), and those servents (including bearshare!) would connect to it because they think it is just a new unknown servent. If it is published under the name of bearshare but sends messages identifying itself as gnotella or gnucleus, then every version of bearshare would connect to it because gnotella and gnucleus have no encrypted authentification feature. As a blocking mechanism, it is absolutely ineffective, it is useless.

but if the packets would contain information about the user's system or downloads or something else which all these sp***re fanatics claim (i can't hear the word anymore), why should it be broadcasted to other servents instead of sending it home? that makes no sense either.

what could these packets ever be good for ? :confused: