WinMX World :: Forum

WinMX World Community => Winmxworld.com Strategic Directions => Topic started by: MinersLantern on December 24, 2015, 08:09:28 am

Title: Trying another bypass
Post by: MinersLantern on December 24, 2015, 08:09:28 am
Howdy yall.

Recently I have experimented with brute force ideas such as search for anything, my favorite is 'x' in order to get a list of everything on winmx.

Set the thing to not auto search, and not to queue either. Then select the entire mess to download.

Results in a nice list of files and hashes as well.

I figure I can search that mess on my own pc and KM cant do a damn thing about it.

Grab the hash and plug that into the real winmx, which part still works just fine.

The real problem with the client imo is how horribly slow it is. Not so much as downloading and all that, just simple things, like select a few thousand incompletes and delete them via winmx.

That takes eons of time. If I shutoff winmx and go into the same folder via windows, select all, and delete.. they are all gone instantly.

Restart winmx and it has no problem again.

SAme thing happens when I select a few thousand files all at once to download, actually, index. It chokes. Locks up.

At least it acts locked up, but isnt really locked up. Watch the folder under windows and the file count grows anyway, slowly.

Any new client should be redone to operrate much more quickly. I dont know why winmx is acting like everything is on win95, but that is the way it acts.

If its as slow as to what it does on the WPN, no wonder its a simple matter to flood it offline.



Title: Re: Trying another bypass
Post by: MinersLantern on December 24, 2015, 08:16:20 am
And BTW, it would be fun to keep a current list of all files on the WPN on a website, searchable. Search for something something, get back a list of names and hashes.

KM would not like that I guess, since he doesnt have control of the entire internet.  :P

Title: Re: Trying another bypass
Post by: ..Ñøßߥ.. on December 24, 2015, 07:11:51 pm
KM would not like that I guess, since he doesnt have control of the entire internet.  :P

Much to his annoyance no doubt...
Title: Re: Trying another bypass
Post by: White Stripes on December 24, 2015, 10:31:46 pm
Quote
Any new client should be redone to operrate much more quickly

by virtue of modern compilers alone a clone would be faster... dont forget winmx was designed to run on windows 95 revision A in the days when single core/single thread 400MHZ cpus were a luxury and multiple cpus almost hedonistic for anything but industry use...

Quote
And BTW, it would be fun to keep a current list of all files on the WPN on a website, searchable. Search for something something, get back a list of names and hashes.

fun? yes, doable? actually very yes, but dont forget the one who has this list also takes legal responsibility for it.... ....which is why opennap isnt around as much anymore.....

----

nobby? wow, ltns
Title: Re: Trying another bypass
Post by: GhostShip on December 25, 2015, 02:37:32 am
Sorry to spoil the xmas fun but the idea of using winmx hashes has been tried before in early 2005 by .. KM  (with myself and Me_here acting as human filters to remove any dodgy hash entries) , anyone remember the "P2P-Revolution" site ?

The main drawback of the site was both the potential for legal issues as well as the poor quality of hashing available in the WinMX program itself, in short the hashes can be faked by anyone who knows how (hence the extensive manual checking of hashes - very time consuming but we thought you folks where worth it   :D  ) and in fact media defender had such an application built into their "anti-p2p interdiction system" codenamed "TrapperKeeper", this weakness is well known about and for this reason alone its best we don't rerun this idea.
Title: Re: Trying another bypass
Post by: MinersLantern on December 25, 2015, 06:09:31 am
Darn this legal sillyness.

Oh well, guess ill use that way on my own system and not host a list or expect anyone one else to.

I have been downloading very well again since doing it that way though.  ;)

Title: Re: Trying another bypass
Post by: GhostShip on December 25, 2015, 09:27:11 am
I still rely on the Ping function to dump many entries of junk replay attack traffic, if the clients offline or changed IP obviously the ping will fail.

I think the order of the day is to keep our methods variable and manyfold as I expect as soon as we settle on something in great numbers our enemies will look to that area to maximise their effectiveness, by using multiple methods of operating we force them to work  :yes:
Title: Re: Trying another bypass
Post by: White Stripes on January 12, 2016, 11:45:29 am
Quote
if the clients offline or changed IP obviously the ping will fail.
ping is dropped by many firewalls .. a port probe would be better

Quote
Recently I have experimented with brute force ideas such as search for anything,......

$ cat database.txt | grep -i aerosmith
__INCOMPLETE___Aerosmith - Rag Dollccdabb6fd95................
............
..............


this is actually a somewhat viable method but i could only get around 1500 results for type mp3 on a single test run... a single person would have more than that visible in a browse... it would need to be repeated several times, over quite a span of time, while keeping out duplicates to generate a decent list of files/hashes...
Title: Re: Trying another bypass
Post by: WhiteLightningX on January 13, 2016, 09:38:49 am
I agree with Miners Lantern. I have more than once DL'd multiple files in the hundreds range as a joke, just to find that WinMX just about pukes on itself trying to get the job done. Once the program locks up, its still running fine just unresponsive, but it takes FOREVER. Then you can highlight the files for deletion in the transfers window... You can watch it in Task Manager, it climbs by about 3mb intervals, until it finally highlights the workload, at which point it starts running again and you can select delete, which takes about double that same amount of time to actually delete them. Where as you can close out WinMX, then use Explorer to navigate to the folder and select all/delete, and it takes about 1 second. It also pegs the CPU/core during these operations.

I actually meant to write my own post about this a year or two ago. Just kind of forgot.  :)
Title: Re: Trying another bypass
Post by: Plum on January 17, 2016, 06:11:40 am
This is not a bad idea. Now if you had a custom program that would index the returned files and add them to a database, then we could search the database, whether it is local or on a website or even IRC. The key is, if it is online, you don't give any live links or anything resembling links, and you could have the online version to filter out any incriminating words. Then throw in some light encryption (like a simple ROT). Even a new client could make use of such data.
Title: Re: Trying another bypass
Post by: White Stripes on January 17, 2016, 06:15:23 am
Quote
then we could search the database, whether it is local

local would be best... a program that attaches as secondary to the local primary that indexes the network... since it is running on the users own machine there is no legal bullshittery anyone can pull...
Title: Re: Trying another bypass
Post by: Plum on January 17, 2016, 06:40:13 am

local would be best... a program that attaches as secondary to the local primary that indexes the network... since it is running on the users own machine there is no legal bullshittery anyone can pull...

Agreed, but more costly against an already failing network. I don't think legalities would be a problem, at least if any web version is where there are no treaties. Still, each building their own is safer.

Or a hybrid solution.  What if everyone only built part of the database? Then a client could ask each host to search their own database from the WPN and give over any relevant results. Similar to how filesharing clients already work, but a new primary protocol using databases built from the old network.

Maybe then it could be a secondary to the old and a primary to the new.
Title: Re: Trying another bypass
Post by: White Stripes on January 17, 2016, 07:09:23 am
Quote
What if everyone only built part of the database?

it would still be subject to poisoning by attackers
Title: Re: Trying another bypass
Post by: Plum on January 17, 2016, 07:36:06 am
it would still be subject to poisoning by attackers

Not as likely if it's transported using the new protocol. You build from the old network, and share its results with the new...

This idea is for a stopgap client, not the old nor fully the new. And if you later find that you have found a hybrid client, then you do all further communication using the new. And on such a hybrid, you also do little things to harden the old protocol where possible (but not when downloading a database from the old). Like I said before, keep things as stateless as possible and don't allocate any memory until you know what you are getting is good.

And for those who call this imbalanced or leeching, that's why you put out an upgrade announcement, assuming that functionality still works.
Title: Re: Trying another bypass
Post by: White Stripes on January 17, 2016, 08:00:05 am
one big problem... coders are still needed...
Title: Re: Trying another bypass
Post by: Plum on January 17, 2016, 08:56:38 am
one big problem... coders are still needed...
Oh yes. And if we had the coders, a full break would be more likely.

I wonder, is there any code for the old primary floating around? I wonder, since the old primary is already compromised, would there be any additional harm in releasing a working implementation of it as it stands? If that were circulated, then those who want to code fixes for it can. Or if anyone wants to use it as a basis for a new protocol, they can.

It seems the best of WMP, G2, and others could be used. Add ideas such as "syn cookies" (a TCP hardening trick that will work whether  the other party uses it or not) and my double-checked search idea.

As far as that goes, the minor protocol tweaks and post-processing are compatible with what exists. There are a number of ways to harden the existing implementation, but we all know it cannot last forever and that the hardening only delays the inevitable.

It seems a future idea would be to include some sort of minor encryption that is negotiated upon by hubs. Maybe have it to make a new key each time it loads and then give that key to those who are active with it. If a client has cause to be snubbed, then negotiate a new key. The idea is to prevent casual client eavesdropping and monitoring by rogue clients. So if they cannot tell what you are looking for or doing unless they are directly connected, maybe that would decrease some of the interference, though I admit I don't know. Or better yet, not only a hub group encryption, with regular or provoked key changes, but a individual keys for each connected client that the primary negotiates for it. Thus even if a snubbed attacker knows the old group key, any key changes is made using the individual keys.

Oh, and any snubbing should be done locally only. One you turn it into a "political" thing, you open up all sorts of doors to problems, such as all the attackers being white-listed and all the good sharers being black-listed. If you use a reputation or voting system, it can be intentionally corrupted or subverted (just like any nations politics).
Title: Re: Trying another bypass
Post by: White Stripes on January 17, 2016, 10:36:39 am
Quote
It seems the best of WMP, G2, and others could be used. Add ideas such as "syn cookies" (a TCP hardening trick that will work whether  the other party uses it or not) and my double-checked search idea.

the only real part of the original protocol worth saving is the chat system minus the method to retrieve room names... ourmx filters search but i dont know if it uses syn cookies ...

Quote
I wonder, is there any code for the old primary floating around?

as irony would have it the only primary code is ourmx... unless there is something hidden deep on an old harddrive or lost to the sands of time... the mxsock dll would be the closest you could get as far as historical goes...

Quote
would there be any additional harm in releasing a working implementation of it as it stands?

unfortunately yes... due to the DDoS tool possibility... the original protocol is.. lets say.. very basic in parts... a little too basic... winmx was intended to work with winmx and nothing else so the client blindly trusts that thats what its doing...

Quote
Oh, and any snubbing should be done locally only.
most modern p2p apps do automatic snubbing of bad clients... it wouldnt be political it would be modernizing...

----

you mention G2.. this idea seems to be disliked by certain individuals... however i have been on the side of bolting wpn chat to a modded g2 for quite some time...
Title: Re: Trying another bypass
Post by: GhostShip on January 17, 2016, 01:13:25 pm
G2 is simply a whole new area of operations for me, the terminology is all different and the current sources I have seen are all based around incompatible languages for myself to be able to jump from one client to another thus I have to decline any such work or research for myself, but others may feel that its of benefit and should perhaps try their hand if they have the time, all good comes from staying busy.
Title: Re: Trying another bypass
Post by: Plum on January 17, 2016, 02:13:54 pm
I think my "political" comment was misunderstood. I was calling anything broader than local snubbing/dumping a "political" thing, since that can be exploited. The idea of sacrificing the one for the all works nicely in filesharing. If you dump a misbehaving client for the good of the node cluster, or a misbehaving superpeer/hub for the good of the network, then that is good. But carrying the information about snubs beyond 1 level or using a reputation system only invites trouble. It would be nice if the network could dynamically figure out the disruptors and pass that data around, but that only has the potential to harm. If each machine has a "vote" on those that should go on permanent block lists, then the system to block disruptors can be subverted and used as another type of DOS attack. Hence the disruptors ally and make themselves the "good guys" and the rest of us the "bad guys," thus doing the opposite of what such an arrangement.

So I was only agreeing with what we said a long time ago, that a simple snub is fine, but a system of one hub or  client speaking for others is bad. Now do you get the political metaphor? As long as it acts as individuals and only cleaning up things immediately around them, and not collectively with reputation systems, global snub lists, etc., then we are fine. Such a reputation system would have a potential for harm and would likely be resource hungry.

As for G2 v. WMP, a lot of the terms can be crossed over. We have hubs, they have supernodes, etc. G2 is nice in that it allows for growth and is an extensible protocol. So new clients can add changes to the protocol without breaking it for the others. If a new tag is added, then older clients would be agnostic to it. So the G2 envelope is used by all G2 clients while allowing it to be used as a vehicle for other information that might be specific to a given client software.

And I meant more in taking the concepts from G2, not actually using its code, but what is said about it that sounds good and incorporating those.
Title: Re: Trying another bypass
Post by: GhostShip on January 17, 2016, 02:19:57 pm
And I meant more in taking the concepts from G2, not actually using its code, but what is said about it that sounds good and incorporating those.

Concepts and ideas, I like  :-D
Title: Re: Trying another bypass
Post by: Plum on January 17, 2016, 02:55:54 pm
An no, the new client doesn't do the filtering type I've proposed for many years. Adding an additional box to filter at the back end is not what I mean (that kind of filter is mostly only good for reducing valid hits from many). Mine is to *automatically* check the results against the string and not keep it in ANY buffer until after it passes the string test. Shareaza has a filter box, and that doesn't prevent the internal problems like memory usage. I mean, entering a filter in addition to the search term does not release the memory used by the bogus hits, but only hides them. Mine is to not waste memory in the first place.

Saying you have a filter is not the same as saying you are doing it automatically my way. My idea requires NO user intervention, it is done as the hits come in -- with no misses ever going past the small input buffer and into the display buffer. I dare say that with my type of automated filtering, the old primary would be usable -- even if slow, and it would never crash from being out of memory (unless it truly is a popular search), since DISCARDING worthless hits would happen automatically without ever using up memory. So the input buffer is tested against the original string and nothing is copied to the results buffer unless it matches the original string.

Maybe the protocol could would be best for doing all of what I suggest. I keep saying UI, but maybe it should work like this. The UI passes the string to the protocol with a search command. The protocol constantly vets the received data against the search string and doesn't return any non-matching hits to the UI nor places them in any sort of memory at all. Once they are determined the be crap, they are flushed. They don't go in a buffer in case the user wants to change their criteria, they don't go into the UI memory, and they are not relayed. Only flushed.
Title: Re: Trying another bypass
Post by: GhostShip on January 17, 2016, 04:29:32 pm
The current version of OurMx does a simple search string match on results thus removing much of the junk traffic the winmx users receive but as I keep stating we need to create a system that does not allow fake traffic in the first place and this can be done by a high level network protocol change, I would prefer we directed our efforts at the big problem and get that resolved so we don't have to play catch up with the  attackers again and again as would be the case if we leave the bigger problem unmolested.

I believe we can add the mechanism you suggest pretty trivially however and I think I suggested we would do so when it looked like we had got some of the more time consuming issues out of the way and where ready for another release.
Title: Re: Trying another bypass
Post by: Plum on January 20, 2016, 04:50:58 am
Thanks.

I see that as a way of making the current situation more usable as a stopgap. There are ways to harden the existing protocol and program out some of the damage to make things a tad more usable. However, I also agree with you that we need to get ahead of things too.

And the biggest thing is programmers. If I were good, I'd secretly pressure you to let me have the source, be willing to sign any NDAs, etc. But I don't know C nor C++. I know assembly, but not protected/virtual mode (just x86 real mode, and segmented architecture is quite different), and not under Windows.
Title: Re: Trying another bypass
Post by: MinersLantern on January 23, 2016, 09:16:19 am
I finally got WinZo to compile on win7, what a nightmare.
C# is evil, slow, and plain old weird.

Needs to be translated into plain olde fashioned C imo. To speed it up and remove the weirdness factor.

It refuses to connect to anything just like the original precompiled ones. I guess because of the ips to connect to are hardcoded in the thing.

Im happy anyway, just to get it to compile. Now I can mess about with it and change those ips.

Although, I have no idea wtf is the reason or purpose for such a language as sharp. A silly microsoft invention.

A slow and confusing thing, like java. o.O

Title: Re: Trying another bypass
Post by: GhostShip on January 23, 2016, 09:13:24 pm
Did you try MoonMx as that was based on the same initial work by "Amon Duul" the WinZo programmer.

http://archive.winmxworld.com/MoonMX/beta/

Sir Moon the MoonMx guy was working on trying to convert the strange version of C# to the more standard version and add additional packets to better handle the file transfers and management but those versions although seen by myself in real life never made it to the archive.
Title: Re: Trying another bypass
Post by: MinersLantern on January 24, 2016, 05:49:16 am
ty Ghost. Downloaded for play later.
I changed the old ips to caches on winzo and recompiled it. No joy.
It still connects to nothing. Even ran a local cache, tried the localhost option (127.0.0.1), no connect.
Changed that to the actual local ip of the pc, still no connect.

I wonder if it just hates win7.

Title: Re: Trying another bypass
Post by: MinersLantern on January 24, 2016, 06:22:50 am
Back from trying Moon.

It does connect at least once the winmx patch is in its folder.

Returns search results, the same flooded kind, but I dont care about that. That is what im after, in the fastest most efficient way possible saved as a text file containing the hashes.

The source still looks like pure C# though.

Sorta kinda works, possibly useful to me for my purpose.

Why doesnt winzo work though? That is odd.

Im sure I tried it once years ago and had no problem under win2k.

Guess I will try a virtual win2k or something and try that one again.

(adding the winmx patch dll does nothing to help winzo)

Title: Re: Trying another bypass
Post by: MinersLantern on January 24, 2016, 08:08:41 am
I did notice another thing in the source code. Something very useful and unexpected to me.

I will not mention it here. Is there a place to post which is not open to the public?

Im sure you lot already know it anyway, but this is becoming interesting to me. Just dont want to say the wrong thing in public which could be used as another method of attack or whatever.

Title: Re: Trying another bypass
Post by: Sean on January 24, 2016, 03:19:50 pm
@MinersLantern
The overhead of C# for a WinMX client, and in fact, most applications, is negligible. C#, just like every other language, has pros and cons that are easily discovered with a bit of research. Additionally, Windows 7 is not a likely cause of the connection issue. If you need any help getting it connected, I'd be happy to help.
Title: Re: Trying another bypass
Post by: White Stripes on January 24, 2016, 05:04:45 pm
Quote
The overhead of C# for a WinMX client, and in fact, most applications, is negligible.
even for primary? cos ive found the performance of .NET to be on par with java.. a little too bloated and sluggish for the size and functions of the application..
Title: Re: Trying another bypass
Post by: Sean on January 24, 2016, 11:15:57 pm
A well written .NET primary client should be just fine. I did some testing with my own .NET primary test program and it performed well.
Title: Re: Trying another bypass
Post by: White Stripes on January 24, 2016, 11:21:51 pm
A well written .NET primary client should be just fine. I did some testing with my own .NET primary test program and it performed well.

even on xp?
Title: Re: Trying another bypass
Post by: MinersLantern on January 25, 2016, 07:51:53 am
ya I agree with stripes on this.

I have a very fast computer lately. But I do remember the hell of a normal computer. Most still have a normal computer.

anything NET or Java is ungodly slow, compared to plain C.

It s all too complex to bother with and slow as hell, just to make it "easier" to program in.

I am no fan of anything that involves any type of interpretation in software. All that should be done away with at compile time. Simple (for the CPU) is fast. Even if it means extra work for the programmer.

Extra pretty features on a gui can be added in later.. Speed is critical. The faster, the better.

Like the idea of its too slow to actually test every single connection to see if its real, or filter the files searched for. Fast executing exes can do that in the blink of an eye. Even on XP





Title: Re: Trying another bypass
Post by: Sean on January 25, 2016, 07:42:41 pm
@White Stripes
Yeah XP SP2 has support for .NET 4 and IOCP which can be leveraged for damned efficient network IO.

@MinersLantern
I think you are confusing an unresponsive (probably poorly written) application with one that is responsive. This has nothing to do with the language in which the application was written. Saying "anything x is y" is just wrong. I know of many .NET applications that run just as quickly as any other native application and I have run across many native applications, likely written in C/C++, that have performance issues. That does not, of course, imply that all native code is slow. Additionally, as a developer myself, I can tell you "most" seem to care more about the GUI than whats going on in the background. It's the "extra pretty features" people comment on, not how many milliseconds faster a piece of code runs.
Title: Re: Trying another bypass
Post by: White Stripes on January 25, 2016, 07:59:26 pm
Quote
Yeah XP SP2 has support for .NET 4
run mato on xp on a pentium 3 w/256 mb ram... nearly all 256mb is eaten by the .NET runtime leaving little for other software... matos fault? no.. microsofts.. the runtime is bloated...

native code can do the same but is less deceptive since a large install is a good indicator of how slow that program will be on such hardware...

not bashing any programming methods... just pointing out that .NET is a heavy beast akin to java..
Title: Re: Trying another bypass
Post by: WhiteLightningX on January 26, 2016, 11:46:06 am
Granted, I have to agree with MinersLantern on this. The closer to the language of the processor the better, even if it means harder work. Also granted, higher languages=easier on the programmer, but adds possibility of losing clock cycles. But on XP, which I am quite fond of, .NET and Java (might as well say anything created from Adobe here too just for a laugh) runs like a turtle in crude oil. My XP is rather boss, despite it's age, and .NET and Java still have a tendency to bog it down. My brother has Win7 on a Celeron D, and it runs like garbage of course, but it strangely runs .NET and Java relatively equal to any other low level application in regards to speed(which also means garbage.) Seems it just runs everything at a crappy slow speed. Whereas my XP will run almost all programs off the chain.. way.. WAY faster. Except for .Net and Java applications... Your guess is as good as mine. But for everybody else using a old pc with XP or older, or an alternative OS, low level is the way to go. Yes, lack of speed can be due to bad programming, but that shows up across a wide range majority of machines, instead of just "older hardware that it should run fine on."

Also agree with Sean, short of us junkies, average users only need the program to work, to be responsive, and to do what it's needed to do, and could care less what's under the hood. In their case, the GUI still needs improvement. But really and truly that is something that benefits us all in the end just as much as the underlying code does.  :) Another thins is milliseconds add up over time. In the end, the time lost versus the total time can be read as a fraction, and that part of the fraction can be removed through proper programming.
Title: Re: Trying another bypass
Post by: Sean on January 26, 2016, 08:53:47 pm
@White Stripes
If the runtime is using that much memory, you have a problem. That is not normal. I am running Mato on XP right now with similar specs and I am looking at around 20-40 MB of memory allocated. Of course, you probably know that the runtime allocates more memory than it needs from the available system memory to speed up application requests for memory so looking at RAM usage is not a good indicator of performance however, in your case, it seems to indicate a problem.

You are absolutely correct that native code is faster, I am not attempting to argue that. My point is. under normal circumstances, and on decent hardware, the overhead of the runtime is not significant.
Title: Re: Trying another bypass
Post by: MinersLantern on January 29, 2016, 11:01:28 am
Playing around with MoonMX now.

I couldnt get it to connect without the oledlg patch originally.

Got rid of the list of caches in its settings file and changed that to localhost (running a local peer cache).

Now it connects anyway.

Maybe it was just a bad time to start it up, makes no sense that it would require the patch in the first place.

When I do something silly like queue thousands of files at once (mp3) it just immediately does that without locking up for 20 minutes like WinMX does.

It doesnt act so nice when I try that on movies or video though. It likely crashes instead.

Is it testing something involving avi? Or maybe the pathnames are too long from many sharing video?

In the settings it has some thing to test something on avi files, not selectable on the gui, a setting in an xml file. But that is set to off by default.

Since as WinMX is so slow at queuing anything in the thousands all at once, it makes me wonder what its written in?

First Basic?  o.O

MoonMx is very incomplete and kinda buggy but is damn fast on that part anyway.


Title: Re: Trying another bypass
Post by: GhostShip on January 29, 2016, 02:32:18 pm
Sir Moon paid me a visit some years ago when he was on holiday and so I know a more completed version exists but he never got around to sharing it with anyone, from what i did see its pretty easy to add some of the functions that i believe might not be in there that deal with the file transfer management.

Have a peek here and compare the handled packets.

http://www.winmxworld.com/tutorials/secondary_file_transfer_management.html

   
Title: Re: Trying another bypass
Post by: White Stripes on January 29, 2016, 08:45:16 pm
@White Stripes
If the runtime is using that much memory, you have a problem. That is not normal. I am running Mato on XP right now with similar specs and I am looking at around 20-40 MB of memory allocated. Of course, you probably know that the runtime allocates more memory than it needs from the available system memory to speed up application requests for memory so looking at RAM usage is not a good indicator of performance however, in your case, it seems to indicate a problem.

emphasis mine... yes... windows, or rather avast antivirus, goofed... uninstall avast and all software uses less memory... after some web searches.. older versions of .NET ... particularly 1.1... seem to be troublesome as well... especially with graphically rich applications... will test with .NET 4 and microsofts own AV software.. *waits for windows update to do its thing* .... 4hrs later ... ~40mb still seems a bit much but this is the first time ive seen .NET behave reasonably... especially on hardware so old...