Forum Replies Created
-
AuthorPosts
-
September 30, 2006 at 1:59 am in reply to: YTK Pro Now Available! *pre-release to release info tracking* #155818Torseq Tech.Member
Yes, the activity logger’s contents can be saved to a text file for later viewing. The ability is already there. About your error reporting question, if an error occurs it can be logged locally and submitted if the user chooses to do so or submitted to the server automatically. I don’t like the idea of it being done automatically so for the time being this can and will be done locally to a file.
Regarding your suggestions. The skinning can be made available as well as adding tattoos to chat room messages and PMs quite easily. Scripting support will also be possible down the road (when the details are sorted out). The chat icons could be added but there were polls in the past on various IM forums and believe it or not chat icons were voted against lots of other features as being the least desirable. This doesn’t mean they’ll never appear it just means that they weren’t at the top of the list for the first version’s release. Your other suggestion regarding the menu editor is doable but I’ll need to give it some more thought. A bit more detail regarding that and I’ll see what I can do. Granting that ability definitely would be easy to do without the need to modify/edit any library of Yahoo!’s (YTK doesn’t modify any of Yahoo! Messenger’s library dependencies or even use them).
September 30, 2006 at 1:00 am in reply to: YTK Pro Now Available! *pre-release to release info tracking* #155816Torseq Tech.MemberEnigma, that’s exactly our intention to update it for compatibility immediately with Yahoo!’s new versions. The WLM/MSN support we added and the plug-ins support for 8.0 (with the new support for the newer packet types) we finished within about 2 solid days. Tested and had it fully working with no issues (this also includes supporting all the new status messages, add buddy system, offline/online notifications, buddy list key/value pair delimiter changes etc). While it took some work we tackle new updates extremely fast. When something new hits we’re on it just as fast as it comes out. While our policy so far has been to not officially support beta builds we might be able to make exceptions based on demand.
As for Chet Simpson, we are in good relations (I’ve been a good friend of his for a few years now) so I can’t comment on whether he should be more timely with his releases or not. He is programming Y!TunnelPro in C++ while we’re using a language that’s known to be more productive. He’s also only one person while our team consists of two.
September 29, 2006 at 11:50 pm in reply to: YTK Pro Now Available! *pre-release to release info tracking* #155817Torseq Tech.MemberWill do, kingofchaos. As it stands YTK Pro is currently along the lines of ~60,000 lines of code not counting header includes. It’s definitely been a long haul and a lot of work and time spent developing it. It’s going to be aggressively updated (since there’s myself and another developer involved with it) and will support anything new and exciting that Yahoo! Inc. decides to throw into their new Messenger versions as they’re released. Feature suggestions of course are always welcome too.
I’m glad you liked the screens. The road ahead is definitely going to be interesting in this uncrowded market for this type of application. 😉
September 29, 2006 at 8:20 am in reply to: YTK Pro Now Available! *pre-release to release info tracking* #155815Torseq Tech.MemberHere is a collection of numerous screen shots of the program in it’s beta form (26 shots split into 2 separate zips). Feedback is appreciated. The GUI and some of the option’s placement isn’t completely finalized yet in these screens.
Torseq Tech.MemberAs dermot said:
Quote:I concur to this fact as i have found YMSG/HTTP connection to be very unstable and has a habit of just disconnecting for no apparent reason, and having to hide behind a unstable situation to just be able to have a decent chat is unacceptable and people shouldnt have to do it.Which is exactly why I won’t be using this anti-boot option anytime soon (if at all) for my application. While there are a couple ways to stop the frequent disconnects, as I’ve said about this before, you should never have to have two sessions going on simultaneously just to combat being flooded. While it works great it’s just too inefficient for a serious “solution”. This could be implemented cleanly and I could think of some ways to make it work out extremely well but it’d require some extra work that I’m not willing to put in for such a small percentage of chatters that would actually need it *dial-up users, mainly*.
Torseq Tech.MemberThis can be applied to any and all versions and builds of Yahoo! Messenger, not just version 8.0. The difference, however, is in finding that information in the logfile from Messenger version to version. Since the protocol version # is always higher with newer versions the contents that are logged can sometimes change *requiring different parsing routines*. With YMSG 14 and below the lists were usually comma-delimited already for you when they’re sent but in YMSG 15 *8.0* that’s not the case, instead the new key/value pairs are used to separate each item/name in the packets.
Using this logfile isn’t something I’d ever advise anybody do unless they knew exactly what it is and how it works. Last year I published a security advisory that explains it which can be found here: Bugtraq: Yahoo! Messenger may be storing all session data ‘Unencoded’ on the local machine
A lot of information is logged and can be used positively or negatively depending on what the purpose is. Since this could be used to achieve carriemeaway’s goal I figured it was worth mentioning.
Torseq Tech.MemberCarriemeawayplz, I know of a couple ways to save your permanent ignore list (not sure why you would want to do it though).
First way that comes to mind:
Get a hold of a third party client that “imports” and saves the perm ignores to a text file (or other) on your hard disk. Once you locate the file pluck out the users you need or all of them if you need all of them. I can’t specifically tell you any because I don’t use third party clients much so I’m not sure which ones have this capability and which ones don’t.
Second way (my way):
You could enable the local “logfile” in Yahoo! Messenger and get a copy of your perm ignore list this way (as well as any list you’d ever need). I will note however that keeping this enabled could jeopardize your privacy in YM and allow others to keep tabs on you (if your computer is “shared” with others). If this is used safely that wouldn’t be a problem for you.
To obtain a comma-delimited complete list of your permanent ignores you will need to follow these exact steps in order (assuming you’re using Yahoo! Messenger 8.0):
1) Go to “Run…” from your windows start button, type this command in and execute it: “ymsgr:enablelog?1”. When you do this Yahoo! Messenger ‘should’ open itself and you will need to sign into your Yahoo! account that has the permanent ignores you need to save (fetch a copy of). After you’ve signed in you’ll see a dialog box about logging, click “ok”. Messenger will then close out and you will need to restart it, logging into the same account you were signed into before. Once you’ve signed in *the logging is taking place at this point* you will then need to go to your Program FilesYahoo!Messengerlogs directory. Once you get there you will see a text file with a .log extension named along the lines of “network_.log”. Looking for network is enough as it’s the only log file in that folder that starts with that name. When you find this file it should already contain your logged information from when you just signed in. Open this file with a text editor such as notepad. Place your cursor at the first line in the file (at the very top where the data starts) and hold control and type “h”. When the dialog opens where it says “Find what:” paste this in exactly: 3013203003207
Where it says “Replace with:” type a comma and then choose the “Replace All” command button on the right. Once this is done it’ll auto-parse your permanent ignore list and will comma-delimit the names for you so it’s readable. After this is done go to the start of the file again, hold control type “f” for find and paste this string in: 3207
This will find the very first permanently ignored user for you. Copy from this user’s id to the end of your comma-delimited ignore list and have it end at the last comma-delimited entry just before 301320303320
Paste your comma-delimited list into notepad or wordpad and save it. After you’re done go back to “Run…” from the start menu in windows and type in: “ymsgr:enablelog?” and click “Ok” to disable further logging. Do NOT leave this on.
Torseq Tech.MemberQuote:I wanna know how I can remove users from the Yahoo Chatrooms without the Use of Y tunnel Pro is this possible ?It’s possible to pluck specific (or all) users out of Messenger’s listview (room list) but that’s not to say that it would prevent their messages from being displayed (joins/leaves) on the chat screen. Y!TunnelPro, like my program, removes users by sending their leave packets to Messenger (since it acts as a client & a server). The reason you don’t see them leave is because some scripting is being done to not show you it (inside the chat window). There’s another way to accomplish that too so you won’t see them being taken out.
Unsakred mentioned the ability to listen as a socks server and have Messenger connect to you then in turn you can control the connection’s data because you’d be relaying it. The other approach as he also mentioned would be to API hook (my program uses this approach w/ dll injection). No hooking would be required if you used the LSP approach (Layered Service Provider) but you’d have some extra overhead (less performance) from it. Lastly you could go with writing a KMD/driver to intercept the data and modify it to your liking. The easiest of these would be the socks option since Messenger already has built-in support *client socks support*. Even if it didn’t have support for proxying via SOCKs you could always force it to connect to your proxy server (check out Permeo’s SocksCap or the SDK).
A good start would be to learn C++, C or Delphi (all would be best =) as you can go far with any of those 3 HLLs for this type of work and practically everything else.
Torseq Tech.MemberQuote:If you have Firefox browser and IE you can get a WML extension for firefox and login to wap at Yahoo! mobile which uses YMSGHTTP and open a Chat2 session in IE and you’re making yourself very resistant to booters.I’ve used this before for experimentation purposes (nothing more). While it’s capable of sending and receiving IMs, Add buddy requests and friends status messages it isn’t a substitute for YMSG/HTTP because WAP (WML/HTTP) is HTTP without the use of YMSG as far as both the authentication negotiation and the session data goes. With YMSG/HTTP (firewall with no proxies) it not only supports everything that YMSG does *the packet types which increase per version* but both the authentication and the whole session’s packets are all YMSG packets just carried over HTTP (specifically designed by Yahoo! for getting around firewalls). It attempts to “fool” corporate firewalls, ones that might be used at a college campus or in a business environment, into thinking that all the traffic is standard “web” traffic. Some of the smarter firewalls with a technology called ‘protocol anomaly detection’ would instantly recognize that the traffic as not conforming to typical web traffic patterns (and data encapsulation) and it wouldn’t be allowed to leave the network.
I haven’t used this “CGuard” program and I don’t plan to so I can’t comment on whether or not it actually does do what has been suggested in terms of malintent.
When I talk about YMSG/HTTP I only mean the firewall with no proxies option in Messenger since it’s used there. I’m not a big fan of HTTP in general especially when used for IM but when coupled with Chat 2 they coexist nicely in the Yahoo! IM environment. If you were to PM flood a user that’s logged into both of these protocols (with the same ID) the PMs would go through the YMSG/HTTP session as would the chat invites which was discussed before. There’s a way to reverse that traffic flow and have it all go down the Chat 2 connection and you could receive all of your PMs and chat invites instead of through YMSG/HTTP *default*. If this Soda guy can’t figure it out I’ll post the answer for anyone that would like to know how to do it and you can instantly see how going from “unbootable” to “bootable” can be changed so easily by simply knowing where to direct the packet types that are sent to you during your “dual” session.
I can say, however, that I don’t find this anti-boot solution to be a very efficient one. You shouldn’t have to have two simultaneous sessions taking place just to avoid being flooded eventually (or instantly depending on your connection & the boot method) leading to disconnection.
Torseq Tech.MemberA bit confused here, Soda. You’re one angry soft drink (must be too much carbonation?). What exactly have I used of “yours” again? You do realize that YMSG/HTTP has been known to be “unbootable” for years now, right? It doesn’t take any knowledge of Yahoo! to know this either. Look at how HTTP works, how data is POSTed and GET requests are made and you’ll see very quickly that HTTP connections are not single entity dedicated connections. Avoiding the flooding effects by using such a protocol that encapsulates your YMSG chat data would make sense to avoid being booted, wouldn’t it? I figured this out on my own and I could elaborate on how it works and even alternate methods to prove that I didn’t “steal” this idea from you or anybody else. I’m sure many others have at least had the thought of logging into YMSG/HTTP and then using Chat 2 at the same time (they were doing this with YCHT and YMSG – dual logins for YEARS). It’s more or less common sense, Soda.
I have never heard of this “Cguard” application but if it uses exactly what I’m talking about here then this should prove to you that you’re not the only one with such “knowledge” of this concept. I’ve also never heard of you nor have I ever spoken to you or downloaded any of your applications, I write my own. But, since you are claiming you are the original sole “founder” of such a marvelous discovery, elaborating on what I mentioned previously should be no problem for you:
Quote:This works because YMSG protocol (including YMSG/HTTP) has priority/precedence over Chat 2 protocol and it overrides all of the packet types that you can receive such as chat invites and PMs. There’s a way to toggle this back and forth from the YMSG connection not getting priority and the chat 2 connection receiving the PMs and chat invites but then this will make your chat 2 connection “bootable” by means of flooding (back to square one). What could be done is to toggle it on when you’re not under attack *so you can receive your PMs and chat invites on the Chat 2 connection normally* and when you are under attack shift the priority back to YMSG/HTTP receiving that traffic so your Chat 2 (room) connection is unaffected.Shifting the traffic flow of PMs and chat invites, how would that be accomplished with “your” method or doesn’t this Cguard have that ability ‘yet’?
Soda wrote:
Quote:OKay here i’ll explain in wannabe tearms okay you take your bandwith and take someone else bandwith if they have a higher bandwith then the user there trying to send.it’s using yahoo protocol to boot that person witch this means BUFFER OVER FLOW okay good you with me now?For one overflow is a single word and secondly you’re using “buffer overflow/overrun” in the wrong context. Maybe before I post from here on out I’ll check with you on whether or not I’m allowed to mention certain material as you may have *by chance* already privately discovered it, okay? I know the one thing I wouldn’t check with you on is spelling.
Torseq Tech.MemberWhat Tim said, ned, is correct. It’s called YMSG/HTTP because it’s actually YMSG protocol over HTTP protocol (YMSG packets encapsulated inside of HTTP). I probably should have specified by naming the actual option in Messenger to use. In this case if you open Messenger and then go to preferences, then Connection and choose the radio/option button called “Firewall with no proxies” apply then ok you’ll sign into the network with YMSG/HTTP. It’s also important to mention that you should go to Messenger’s preferences and then to the “Ignore List” section and apply the “Ignore anyone who is not on my Messenger List” so if you are being PM bombed or other the packets will be ignored locally. The only thing that can bother you in this case would be add buddy requests but those won’t be all over your screen if you’re attacked but instead isolated (overlapping one another) since the “Ignore anyone who is not on my Messenger List” option doesn’t stop you from seeing those.
After you do this do not enter chat just leave it in “pager mode” signed into Messenger. After this is done the same ID you used to sign into YMSG/HTTP with use that ID to sign into Chat 2 protocol on either the browser DHTML chat (which uses Chat 2) or a separate 3rd party client. You could leave the YMSG/HTTP messenger session minimized but still active and just focus on your Chat 2 session inside the 3rd party client or DHTML browser page (whichever means you go about when using Chat 2).
This works because YMSG protocol (including YMSG/HTTP) has priority/precedence over Chat 2 protocol and it overrides all of the packet types that you can receive such as chat invites and PMs. There’s a way to toggle this back and forth from the YMSG connection not getting priority and the chat 2 connection receiving the PMs and chat invites but then this will make your chat 2 connection “bootable” by means of flooding (back to square one). What could be done is to toggle it on when you’re not under attack *so you can receive your PMs and chat invites on the Chat 2 connection normally* and when you are under attack shift the priority back to YMSG/HTTP receiving that traffic so your Chat 2 (room) connection is unaffected. Let me know if you’re wanting to know how to change that up and I can share that information.
Torseq Tech.MemberFor the server-side “boots” craig is describing what’s called an amplification attack. It works by amplifying the traffic load while only having to send a small amount of traffic to make it happen. It’s also called the snowball effect. These server-side d/c packets are basically a Yahoo!-specific SMURF attack using Yahoo!’s own protocol to abuse their server’s traffic routing rules. I know of a couple ways to stop them from working but there’s only a couple tricks you can use to stop one of these attacks if it uses chat invitations or PMs *deliverable in all scenarios regardless of whether you’re using Chat 2 or YMSG, cloaked on YMSG or not*. If the packets can be delivered to you it’s a potential avenue for flooding to boot you.
Cloaking in YMSG aids in preventing most of these attacks but can’t cover all of them. To combat against strong PM bombing even if the PM bomb is using an amplified packet structure to force lots of traffic on you (booters call these “looped” packets) something can be done about it. What you can do is log your ID into YMSG/HTTP and then use a chat client to log that same ID into Chat 2 to join a room. You’ll be able to chat regularly on the Chat 2 connection, use voice etc. while all of the chat invites that you receive as well as all of the PMs you’ll receive will all be sent to your YMSG/HTTP connection. It’s impossible to flood off a user that’s signed into YMSG/HTTP even if they’re on dial-up due to the nature of how HTTP operates and how the servers deal with the excess traffic that’s buffered or built up. The excess is simply discarded while using this protocol. There are other “tricks” you can use but this is the cleanest and would truly make anyone regardless of their connection “unbootable” as far as the flooding goes unless that flood is generated inside the chat room (on the Chat 2 connection). Cookie exploits and other disconnect exploitation methods that don’t involve flooding you would still be susceptible to.
Torseq Tech.MemberQuote:The fact still remains that you have stated that your method does not remove the main messenger window ad from the messenger.Yes, it doesn’t remove this small ad and it will be seen with Messenger versions 7.5 and 8.0 but this ad is not present in 6.0, the 7.0 builds and the 7.02 build. Killing that ad isn’t hard to do through the HOSTS file either it simply doesn’t get killed with the chat.yahoo.com line. That ad too can be killed if you add a separate line “0.0.0.0 messenger.yahoo.com” and it won’t be loaded but the side effect is that messenger.yahoo.com becomes unavailable and it can effect the plug-ins manager (if anybody uses it in 8.0). This is why I said that the chat.yahoo.com line is safe because it kills the most annoying ads while at the same time it doesn’t prevent certain functionality from working properly.
The point of my post was not to argue which way was better but the fact that you don’t need a program at all to kill ads in Messenger or even in most applications as long as they fetch the content dynamically through DNS lookup requests. Programmatically this can be done easily, yes. I’ve removed every ad in Messenger in a Y!Tunnel-like application we’ve created that will have a free version available to the public within weeks. A pay-for commercial version will also be available with lots of features. It’s currently in private beta testing.
Torseq Tech.MemberQuote:I wouldn’t suggest using HOSTS file tricks.Actually, it’s perfectly safe to use and is actually recommended by LOTS of different resources on the net. In fact it’s safer than using a “hacked/modified” executable or program to accomplish the ad-killing for you. Wikipedia, for example, documents it’s effective use for ad-blocking since it’s commonly used for this purpose:
Quote:Ad filteringOne use of the hosts file is ad filtering. This is accomplished by adding a line to the file that maps an ad server’s hostname to an address that will not satisfy the browser’s request for the ad. Since no additional programs are necessary to do this, hosts file based ad-blocking has a near-zero memory and CPU footprint, as well as requiring no loading time. The hostname for an advertiser may be obtained by right-clicking on the banner or advertisement, then clicking properties from the context menu. This will indicate the full URL, of which the part between the double slash and first single slash represent the hostname.
The two most common addresses used for this purpose are the ‘null’ address Default PLESK Page (which may simply be written as a single ‘0’) and the ‘loopback’ address Default PLESK Page. The distinction between the two is that 0.0.0.0 is an invalid destination address[1], so no connection can be established. If a name is mapped to the loopback address 127.0.0.1, any connections to the “blocked” domain will be mapped to the originating machine. If it is running a Web server, that Web server may attempt to handle the request. The ad-blocking technique may include a local web server that provides substitute images rather than 404 error messages [2], which would require the use of 127.0.0.1.
Torseq Tech.Memberkingofchaos6669 wrote:
Quote:Now, all we have to do now is find a way to block the chat transition ad, or, find a way to surpass it completely. Which I’ll be researching all day tomorrow.Killing Messenger’s ads is actually incredibly easy to do (including the chat transition ad). To kill most of them (or all depending on your messenger version) you don’t even need a program to do it for you, registry edits or any programming experience at all. If you’ve ever sniffed traffic (network packets) you’ll notice that these ads have DNS lookup requests sent out before the actual TCP (HTTP) connections are even made to download and display their content (flash, html etc). The “key” here is to tell your operating system that when a DNS lookup is to be performed to first look inside your HOSTS file (a text file for DNS name to IP address static mappings).
On XP and Windows 2K3 your HOSTS file is located under WINDOWSsystem32driversetc. For 2K and 95/98/ME the location is different. For 2K it’s under WINNTsystem32driversetc and for the 9x OSs it’s in your Windows directory.
Once you’ve located your HOSTS file you need to open it for editing (notepad will do or wordpad). Once it’s open you will want to add a new line to it that would look like this: “0.0.0.0 chat.yahoo.com” from left to right. This tells Windows that before a DNS lookup is made for “chat.yahoo.com” to first check and see if there’s a static mapping of it’s name to an ip address (it wouldn’t need to be resolved if the ip is already supplied). Once Windows finds the ip address it’ll return it to the requesting application (in this case Messenger) and Messenger will see that the ip address is no good (not routable). Messenger then can’t make the appropriate HTTP connections to download the ad content and you will be able to get by without seeing the major ones.
This method will kill off the chat transition ad, the chat room ad at the bottom of the chat screen and when you open your Join Chat room window it’ll kill off the content to the left from being downloaded and displaying. Depending on whether you’re using this method in version 6.0, 7-7.5 or 8.0 you’ll get different results (now that 8.0 carries an ad in the buddy list window which this doesn’t affect). Using registry edits in combination with this method would be sure to get the smaller ads (webcam viewer ad and/or the 8.0 buddy list window ad) that are still present after.
*Side effects of editing your HOSTS file to do this:
– Each time you sign into Messenger the first attempt or 2 to join a room will fail (nothing will happen). After you’ve attempted a couple times (may only take one time) you should be able to get into the room and any rooms thereafter first try.
– http://chat.yahoo.com in your browser will become unavailable while that line is in your HOSTS file. This won’t negatively affect third party chat clients like YahElite for using Chat 2 or YMSG. If you absolutely need to use chat.yahoo.com’s DHTML Chat 2 for chatting instead of completely removing that line from your HOSTS file simply comment it out (by using the pound sign # before the line starts) and that website will be available for you to visit again. When you’re done uncomment the line and save the file again so you won’t see the ads again in Messenger afterwards.
– I’ve tested this on Messenger version 5.6 and it’s had negative effects, do not use it on versions below 6.0.
-
AuthorPosts