Author Topic: Trying another bypass (Read 13349 times)

Plum · « **Reply #20 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.

GhostShip · « **Reply #21 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.

Plum · « **Reply #22 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.

MinersLantern · « **Reply #23 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

GhostShip · « **Reply #24 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.

httpss://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.

MinersLantern · « **Reply #25 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.

MinersLantern · « **Reply #26 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)

MinersLantern · « **Reply #27 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.

Sean · « **Reply #28 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.

White Stripes · « **Reply #29 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..

Sean · « **Reply #30 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.

White Stripes · « **Reply #31 on:** January 24, 2016, 11:21:51 pm »

Quote from: 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.

even on xp?

MinersLantern · « **Reply #32 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

Sean · « **Reply #33 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.

White Stripes · « **Reply #34 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..

WhiteLightningX · « **Reply #35 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.

Sean · « **Reply #36 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.

MinersLantern · « **Reply #37 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.

GhostShip · « **Reply #38 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.

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

White Stripes · « **Reply #39 on:** January 29, 2016, 08:45:16 pm »

Quote from: 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.

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...