Another massive DDoS attack coming out of Russia. One of my favorite talks at Defcon last summer was by Gadi Evron an can be seen below. It is very interesting what wars of the future may hold. My Linux servers throughout the past have constantly been logging attempts by Chinese hackers to break into them. Nearly 90% of the banned IP's I have in my hosts.deny file are from China, and I have heard rumors of the Chinese government actually subsidizing hackers to try to break into U.S. computers and sending students to college specifically for the purpose of learning how to hack so that the Chinese government may use their skills. Here is the video. Gadi is an Israeli I believe and throughout the video you will hear him cussing out some drunk Russians in the front row until they are escorted out by security to everyone's applause.
Tuesday, May 6, 2008
Sunday, May 4, 2008
Finishing Up a Semester - Cox Communications == Assholes
I have nearly finished up the Spring 2008 semester. I have taken my AI final, my Formal Languages final, and our group has presented a power-point style overview of our senior-design project. I think that out final project has gone over well both with the professors of the class, and with our fellow students.
Our project is a mobile device application that will be able to use optical character recognition on images and then translate the text that is extracted from the image, if needed. A simple use case situation would be someone traveling in foreign country and needs to read a sign in that language, but they are not fluent. They would be able to pull out their phone, take a picture of the sign and our app would translate it. The mobile device would need internet connectivity because it actually sends the image file to my home Linux server through XML-RPC (eXtensible markup language - remote procedure call) which runs GNU ocrad (an open source optical character recognition tool) on the image, It then sends the resulting text through Google's translate URL and pulls the little piece of translated text out from the resulting HTML document that the call the Google's URL returns. It then sends the resulting translated text back to the mobile device application that called it. We implemented the mobile device portion of the software in Java and built the GUI using only AWT (abstract windowing toolkit) instead of the more feature rich swing library, because even the higher end mobile devices will only run AWT and not swing. The server side remote procedure is all written in Perl using the Frontier::Responder XML-RPC module.
This is one of the oldest XML-RPC implementations in Perl, and it is very easy to use. Although I have developed Web Services using SOAP on a very high level through Microsoft's Visual Studio that hides all the details from you, this is really my first experience developing XML-RPC's, and I have to say that I am a fan. It allows you to connect programs written in different languages running on different operating systems that could be very far apart geographically, because everything is "encoded" and "decoded" using XML and the XML documents are sent over HTTP. One book that helped me out tremendously is Programming Web Services with XML-RPC written by Simon St. Laurent, Joe Johnston, and Edd Dumbill and published by my personal favorite publisher of technology books: O'Reilly.
That brings me to another point (guess I have a lot of things to say after such a long dry spell). I have over the last semester purchased 5 O'Reilly books from Amazon.com for very cheap prices. I have always gotten used books, and they have always been in excellent condition. I'll put it this way, the shipping is always the most expensive part. I get books that would cost anywhere from $45-$80 dollars new, for about $1.50-$8.50 on Amazon, and I have seen books for less than $1.00. I have also bought 4 Fiction Sci-Fi books for a couple of bucks or so each. I will never buy another book from Barnes and Noble.
But I digress. The reason for the Second part of the title for this post is because I was troubleshooting why our senior design application would not connect to my home Linux server from campus. This troubleshooting was not made easier by the fact that campus did not allow outgoing pings, but that isn't the real problem. After trying everything I could think of (putting holes in my router to let HTTP traffic route to my Linux server, etc) and still having no luck, I became very frustrated. I was almost to the point of re-flashing my router's ROM with a newer version of the firmware, because I was sure that it had top be malfunctioning; I mean, I had it configured correctly! Suddenly, however, I decided to try changing the port number that my Apache server was listening on, and having the mobile application call this new port instead of just letting it use the default port 80.
The app then connected and ran as it was supposed to, no problem. So what was the problem? Cox fucking communications blocks all incoming traffic to port 80 unless you pay the fee for a business account. For any who don't know, networked applications communicate over ports. These are "virtual" animals but can be likened to actual physical shipping ports. They are entry and exit points for information like shipping ports are entry and exit points for goods or people. The Web (i.e. any site you can get to through your browser) runs on port 80, except when you are logging into a secure site (such as your bank, or any other kind of account that accepts a username and password) as this uses port 8080 and you will see a little pad-lock on the bottom right of your browser; additionally the url will have https instead of just http. This is usually transparent to most users as their browser just automatically uses port 80. If you wanted to use your browser to connect on a non-standard port, you would type the url with the port included after the domain name but before the path portion, like so:
www.mywebserver.com:90/docs/index.html
The above URL would connect to port 90 instead of trying the default port 80. SO anyway, Cox doesn't want anyone at home hosting a web page that will be easy for others to get to unless they pay for the premium service. So I would like to send a big "Fuck You!" out to Cox Communications for causing me extra grief.
Our project is a mobile device application that will be able to use optical character recognition on images and then translate the text that is extracted from the image, if needed. A simple use case situation would be someone traveling in foreign country and needs to read a sign in that language, but they are not fluent. They would be able to pull out their phone, take a picture of the sign and our app would translate it. The mobile device would need internet connectivity because it actually sends the image file to my home Linux server through XML-RPC (eXtensible markup language - remote procedure call) which runs GNU ocrad (an open source optical character recognition tool) on the image, It then sends the resulting text through Google's translate URL and pulls the little piece of translated text out from the resulting HTML document that the call the Google's URL returns. It then sends the resulting translated text back to the mobile device application that called it. We implemented the mobile device portion of the software in Java and built the GUI using only AWT (abstract windowing toolkit) instead of the more feature rich swing library, because even the higher end mobile devices will only run AWT and not swing. The server side remote procedure is all written in Perl using the Frontier::Responder XML-RPC module.
This is one of the oldest XML-RPC implementations in Perl, and it is very easy to use. Although I have developed Web Services using SOAP on a very high level through Microsoft's Visual Studio that hides all the details from you, this is really my first experience developing XML-RPC's, and I have to say that I am a fan. It allows you to connect programs written in different languages running on different operating systems that could be very far apart geographically, because everything is "encoded" and "decoded" using XML and the XML documents are sent over HTTP. One book that helped me out tremendously is Programming Web Services with XML-RPC written by Simon St. Laurent, Joe Johnston, and Edd Dumbill and published by my personal favorite publisher of technology books: O'Reilly.
That brings me to another point (guess I have a lot of things to say after such a long dry spell). I have over the last semester purchased 5 O'Reilly books from Amazon.com for very cheap prices. I have always gotten used books, and they have always been in excellent condition. I'll put it this way, the shipping is always the most expensive part. I get books that would cost anywhere from $45-$80 dollars new, for about $1.50-$8.50 on Amazon, and I have seen books for less than $1.00. I have also bought 4 Fiction Sci-Fi books for a couple of bucks or so each. I will never buy another book from Barnes and Noble.
But I digress. The reason for the Second part of the title for this post is because I was troubleshooting why our senior design application would not connect to my home Linux server from campus. This troubleshooting was not made easier by the fact that campus did not allow outgoing pings, but that isn't the real problem. After trying everything I could think of (putting holes in my router to let HTTP traffic route to my Linux server, etc) and still having no luck, I became very frustrated. I was almost to the point of re-flashing my router's ROM with a newer version of the firmware, because I was sure that it had top be malfunctioning; I mean, I had it configured correctly! Suddenly, however, I decided to try changing the port number that my Apache server was listening on, and having the mobile application call this new port instead of just letting it use the default port 80.
The app then connected and ran as it was supposed to, no problem. So what was the problem? Cox fucking communications blocks all incoming traffic to port 80 unless you pay the fee for a business account. For any who don't know, networked applications communicate over ports. These are "virtual" animals but can be likened to actual physical shipping ports. They are entry and exit points for information like shipping ports are entry and exit points for goods or people. The Web (i.e. any site you can get to through your browser) runs on port 80, except when you are logging into a secure site (such as your bank, or any other kind of account that accepts a username and password) as this uses port 8080 and you will see a little pad-lock on the bottom right of your browser; additionally the url will have https instead of just http. This is usually transparent to most users as their browser just automatically uses port 80. If you wanted to use your browser to connect on a non-standard port, you would type the url with the port included after the domain name but before the path portion, like so:
www.mywebserver.com:90/docs/index.html
The above URL would connect to port 90 instead of trying the default port 80. SO anyway, Cox doesn't want anyone at home hosting a web page that will be easy for others to get to unless they pay for the premium service. So I would like to send a big "Fuck You!" out to Cox Communications for causing me extra grief.
Subscribe to:
Posts (Atom)
