RoLex

Member
  • Content count

    139
  • Joined

  • Last visited

Posts posted by RoLex


  1. You remind me of American and European politicians who blame Russia for everything, trying to make the rest of the world to hate them. But you seem to be forgetting about the reason why this happens. In that case I can suggest you investigating about expression "rivalry" if you haven't been in such situation in your life before. Remember two things:

    1. You can't take down someone who is right about something.
    2. You can't take down the strong one who defend himself.

    If something or someone was hacked, there probably was a good reason to do so. Most likely to stop our enemy from pointing their small "guns" at us, alternatively to proof that there is a weak link in the chain. Team Elite is also a hacking team, that is correct.

    It seems that you are still using some of that vulnerable software. Maybe it is time to start moving to another, better, more protected software. Or you intend to use broken and abandoned YnBug forever? :-)


  2. @AnOldFriend

    You are damn right about Team Elite being the most active team on DC these and previous days. Hublist and 3 hub softwares you are talking about are not the only projects we are currently developing, there are also many scripts, plugins and bots for DC, aswell as the best anonymization software on market, a low level programming language and antivirus database specifically for DC. Don't forget about the most crucial exploits in history of DC that we discovered. Fixes for these exploits are present in all hub softwares and clients today thanks to our team. I will even tell you more, next project will be a DC client, that is to cover the whole range of DC related products. ;-)

    What I don't understand though, is what you have against my team. Did anyone piss on your car last night? To me is seems obvious that you are just afraid to admit that we are the best team and developers you have met in your life. And please note, it's not me who is calling you pussy, it was you who started this thread and called yourself a weak man who is afraid of moving forward. ;-)

    Have a nice day.


  3. That was easy, here is a patch:

    --- ./startup.lua	Mon Oct 20 23:34:49 2014
    +++ ./startup.lua	Mon Oct 20 23:34:27 2014
    @@ -1221,7 +1221,7 @@
     
     function adch.DataArrival( hub, msg )
     	if msg == "" then
    -		return nil
    +		return 1
     	end
     	local h = dcpp:getHub( hub )
     	if not h then
    

    Issue closed, this patch should be included in default startup.lua file.


  4. Hi.

     

    I've always had problems connecting to ADC(S) hubs with ApexDC++, right now I'm on version 1.6.0.2165 x64, and again when I try to connect to below hub, nothing is happening:

    [15:32:16] *** Connecting to adcs://hub.dcbase.org:16591...
    [15:32:16] *** Connected
    
    [15:35:59] *** Connecting to adc://hub.dcbase.org:16591...
    [15:35:59] *** Connected
    

    System log shows me following:

    [15:35:59] ADC hub added (id = userdata: 000000000959F458)
    

    I'm running 64-bit version of Windows 7 with all installed updates, no viruses.

     

    When I try connecting with DC++ or FlylinkDC++, it works like a charm.

     

    What is the problem here, my settings or bug in the client?


  5. What kind of issue did it open up? Do you mean the HeXHub issue where following sutuation appears:

     

    // client sends a nick that is more than 40 characters long (42 in this example)
    $ValidateNick ABABABABABABABABABABABABABABABABABABABCCDD
    
    // hub accepts client but cuts the nick to 40 characters
    $Hello ABABABABABABABABABABABABABABABABABABABCC
    
    // client compares its own nick with the nick resulted by hub
    ABABABABABABABABABABABABABABABABABABABCC != ABABABABABABABABABABABABABABABABABABABCCDD
    
    // nicks dont match so the client hangs there waiting for correct response until the hub times out and disconnects the client
    ...
    

     

    If this is the case then I have already requested a HeXHub fix where hub disconnects the client and tells it that nick is too long. This is how all other hub softwares work, this is how NMDC works, either $Hello with same nick or $ValidateDenide.

     

    I'm using these NMDC specifications: http://nmdc.sourceforge.net/NMDC.html

     

    You could make nick fields limited to 255 characters, seems a reasonable buffer size to me.


  6. Good morning.

     

    I've never needed this until today, and I'm sorry for my language, but why the hell are nick fields limited to 35 and 28 characters?

     

    Settings > General > Personal information > Nick < The field is limited to 35 characters.

    Favorites > Hub > Properties > Identification > Nick > The field is limited to 28 characters.

     

    Did anyone announce the official maximum allowed nick length for NMDC and ADC protocols? I didn't get that information.  :)

     

    I'm running Windows 7 x86.

     

    Regards.


  7. Hi.

    I've been trying to understand why this XML>BZ2 hublist works in ApexDC++:

    http://www.te-home.net/?do=hublist&get=hublist.xml.bz2 (HTTP redirect)

    While this one, same XML but uncompressed, does not work:

    http://www.te-home.net/?do=hublist&get=hublist.xml (HTTP redirect)

    The only difference between those two is BZ2 compression. Both are being given to the client same way, no MIME-type is being sent from web server.

    Please help me to understand.

    Regards.


  8. MC & PM logs are no longer written, my settings haven't been changed for over a year.

    
    Directory: C:\Program Files\ApexDC++\Logs\
    
    
    MC:
    
    
    Format: [%Y-%m-%d %H:%M:%S%[extra]] %[message]
    
    Filename: %m %Y\%[hubURL]\mainchat.log
    
    
    PM:
    
    
    Format: [%Y-%m-%d %H:%M:%S%[extra]] %[message]
    
    Filename: %m %Y\%[hubURL]\%[userNI].log
    
    

    Windows XP, SP3, writing permission.


  9. 2159 came out a discussion between flipflop and poy as a alternative for connection against web servers so yes it has something to do with ctm ddos since it makes less efficient since it wont reconnect as fast as older clients

    Right, web servers, but I think BM:s feature in StrongDC++ which completely blocks connections to ports 80 and 2501 is more useful in that case, there are only 1 out of 1000 users who manage to put port 80 in connection settings. :) I assume that StrongDC++ doesn't allow to set port 80 in settings.

    now the other was a fix to the inital reconnection reduction that is dealing with the problem

    Good to hear, but still that's not a solution by my opinion.

    I would do a very simple flood detection, to count amount of similar incoming CTM requests under specified interval. Most CTM flooders out there send requests every second, but ofcourse, the amount of requests and interval should be customizable in client settings. And some kind of customizable blocklist, where requests are filtered by connection address + port. Maybe some kind of expiration for blocklist, per hub session for example, or in minutes.

    That would atleast give us the opportunity to protect ourselves from any kind of CTM exploitation.

    Thank you.


  10. no but we are taking preventive steps towards ctm ddosing but u seem to focus more on me then what i write so i will not waste my time replying more..

    Alright, sorry, I did indeed try to make joke out of your reply. Lets be more specific to the topic. :)

    Could you please tell me what steps you and other dcdevs has taken to improve CTM flood detection?


  11. As Big Muscle said PtokaX is easy to crash, so it should be easy to crash these hubs. But really if they use PtokaX for this in hard way (external bots ? why when there is many easier ways). Worse is that if they want to do that you can't do anything. If hub software don't have option to disable ip check then they hexedit it's binary to remove that (PtokaX have many hexedited versions :stuart: ). And if they don't hexedit it then they will simply compile their own version from source (closed source is not option for multi-platform software).

    I don't complain about hub softwares, but about NMDC clients individual users run on their computers.


  12. Good day.

    I don't understand you people trying to proof something completely irrelevant to eachother. What I'm trying to say is that all of you are more or less great developers and contributors. Just think what you could approach by working together instead of working against eachother. Think about changing your tactics to something better like solution to my ever question: Why after several years of foundation of CTM exploitation does every single DC client still miss1) CTM antiflood to prevent innocent users from being exploited either ways2)? CTM exploitation is way far from growing old. So pick your thoughts together and start building better clients. :stuart: :angry:

    Thank you.

    1) I don't mean blocking all CTM requests to port 80 and 2501, but limiting and blocking amount of incoming CTM requests, flood detection, on any port.

    2) A. Old exploitable hub softwares. B. I see more and more hub owners learning to turn off IP check in CTM requests for example in PtokaX 0.4.1.1, redirecting all possible users to that hub and running external bots for sending CTM requests from localhost.


  13. This priority is there since the version where these colors was introduced.

    Are you trying to say that this feature hasn't changed since it was introduced? Don't seem so to me, I can clearly see a difference between StrongDC++ 2.4x and 2.2x with same settings file. Running 2.2x with settings screenshot attached in my previous post and everything works absolutely fine, then overwriting the executable with 2.4x and running it with overridden Operator color. It's clear that userlist colors are affected by user connection status flag. :)


  14. I further investigated the problem today, and have found the reason for my problem. User with fireball and User with server colors are set to yellow, that's the color operators with fireball or server in the hub get instead of Operator color. In older version of StrongDC++ the Operator color always did override all other colors, and it seems not to do that anymore.

    I really like this colorful feature the way it was previously, so I could separate operators from all other regular users. What would you suggest me to do?

    post-4587-127514618592_thumb.png


  15. Good evening.

    I've noticed this some time ago in StrongDC++ 2.41, an issue that seems have been inherited from there. Operator lists in my hubs, all 31 hubs, are not colored properly for some reason. Some operators have desired color which is red, other have yellow, which is color for normal users.

    See attached screenshot below, and please ask if more information is required.

    Thank you.

    post-4587-127507880921_thumb.png