Saturday, November 19, 2005
Sony's Rootkit CD Buyback
I don't know if this warrants a new blog, but the other Sony blog is dated for the 16th. This piece of news has occurred on the 18th.
Sony is moving fast (as they should be) in their CD buyback program. They have partnered with Amazon and UPS (apparently) to buy back your CD's. Amazon purchasers have been getting an email from Amanzon with this incredible offer to buy back their CD.
I'm really not impressed at the overall tone of the exchange program page. The title says it all: "Welcome to the Sony BMG XCP Exchange program" it says, in big blue bold letters. "Why thank you," I'd probably say in a cheerful voice.
But they're not apologetic. Nothing on that page says they are. They're probably saying, "shit, I've got to slap on a fake smile while I spend millions to shut you whiners up." Hell, they're a big company; they have the clout to throw their weight around.
This page has an interesting statement, "you will have the option of selecting whether you would like to receive MP3 files of the title(s) in addition to your replacement CD(s)."
Huh? .... *REALLY* Well then Mr. Sony, load 'em up, pleaze. DRM-protected MP3's? I know of no such types. Maybe 64kbit versions (for faster internet downloads, they might say) of lower audio quality? Hmmmmm. We'll have to see how this plays out.
Sony is moving fast (as they should be) in their CD buyback program. They have partnered with Amazon and UPS (apparently) to buy back your CD's. Amazon purchasers have been getting an email from Amanzon with this incredible offer to buy back their CD.
I'm really not impressed at the overall tone of the exchange program page. The title says it all: "Welcome to the Sony BMG XCP Exchange program" it says, in big blue bold letters. "Why thank you," I'd probably say in a cheerful voice.
But they're not apologetic. Nothing on that page says they are. They're probably saying, "shit, I've got to slap on a fake smile while I spend millions to shut you whiners up." Hell, they're a big company; they have the clout to throw their weight around.
This page has an interesting statement, "you will have the option of selecting whether you would like to receive MP3 files of the title(s) in addition to your replacement CD(s)."
Huh? .... *REALLY* Well then Mr. Sony, load 'em up, pleaze. DRM-protected MP3's? I know of no such types. Maybe 64kbit versions (for faster internet downloads, they might say) of lower audio quality? Hmmmmm. We'll have to see how this plays out.
Wednesday, November 16, 2005
Sony - How Low Can You Go?
Rootkits, Spyware Tactics, Copyright Infringements and LPGL Violations.
I grew up with Sony, in the land where Sony originates. The CEO of Sony lived in the same condo as I did--I used to watch his majestic limousine show up every morning, pert and obedient, awaiting to take his master to his domain. I was a commoner (a foreigner at that), who walked 17 minutes to the trainstation to begin my 1.5 hour commute to school. Back then, there was no concept of Sony Japan. It was just..., "It's a SONY!"
My precious microphones were Sony, my first Walkman (circa 1979) was a Sony. Oooh, the anodized blue and silver body with two headphone outputs, a mic and the orange Hot Talk button so you could talk to each other while listening to the Bee Gees (yea, yea). My $600.00 turntable was a Sony (magentically levitated linear tracking arm with a PLL controlled brushless DC motor. The whole platen was the motor! The body was well heavy, concrete I think, with vibration dampening feet. I still have it.
Japan has two government channels (NHK) which provides very professional, unbiased news, educational content and drama series, including award winning TV-series Silkroad. NHK primarily uses Sony equipment--everywhere.
Sony was ingrained into my young psyche. It was a symbol of Japanese staunchiness. It ranked up there with Toyota, Mazda and Honda as an international power to be reckoned with. Sony was it--if you didn't have Sony then, you were nothing.
But it seems that Sony has just gone a little too far for its own good, and for the good of the public. Recently Sony has been distributing CD media bundled with a controversial piece of DRM software. DRM (or this link), in of itself, is not a bad thing. It serves to help protect the interests of the recording industry and the music artists to which it caters.
But Sony has taken this a step further, and in my opinion, several steps too far. Sony's DRM code burned onto a number of undisclosed CD's will attempt to install itself to the user's PC, when it's played on that machine.
Using advanced techniques to circumvent security, the installed code obtains higher security permissions than the user has and installs itself into the very core of the Windows user's operating system. It replaces core files with its own and employing stealth techniques known only to the savviest viruses, it hides itself in such a manner that even the system administrator cannot find it, nor remove it even if he did. What's worse, all of this occurs without the knowledge of the user, apart from the horrible EULA that mentions none of this.
This has led the public to label this piece of software as a "rootkit." It is a coveted prize amongst hackers, virus programmers and the denizens of the ether-netherworld. It's a bane of the good citizens of the computing world, however.
Once embedded into the OS it lies there, quietly monitoring every keystroke, event, password, music that's been played. Occasionally, it wakes up to enforce the DRM policies. But more disturbing, it surreptitiously reports back to the "mothership" of the user's activities.
Several firms have pointed out this also poses a security risk. Of course, Sony denies all of this, stating that this program does nothing bad nor does anything to get in the way, and heaven forbid--violate the user's privacy by sending usage data back to a tracking site, nor does it pose a security threat in any way. Assistant Secretary of Homeland Security, Stewart Baker, made a comment directed at software makers but primarily directed at Sony. "It's very important to remember that it's your intellectual property -- it's not your computer." I agree.
Sony remains unapologetic, and even devalued consumers by making a derogatory statement about them. However bowing to pressure, it made available a means to "bypass" this DRM on November 2, then a service pack2a on November 8, to remove the Cloaking Technology employed by its DRM code. It was only going to decloak the software--not remove the DRM entirely. Critics blew their stack! Here's a nice write up on the "patched" XCP code.
Then around November 10, the first Trojan Horse using Sony's rootkit to infiltrate then cloak itself, appeared. A real slap in Sony's face. Bad news for Sony continued as a second variant of a Trojan Horse that exploits Sony's DRM code was discovered later that day.
This software comes without an uninstaller. Any attempt to remove this software damages your operating system, and employs tactics that makes it difficult to do so in the first place. To remove the software at all, you must contact Sony through various emails, website registrations, click throughs, agreement with other policies, etc. If you're lucky, it might have been removed.
Public outcry has reached cacophonic proportions. Microsoft has reponded with a patch to disable Sony's rootkit. Anti-spyware software companies have capitalized on this and labeled Sony's XCP code as spyware and offer to detect (and disable) it. Links (1, 2, 3, ...)
Crippled Sony has posted this statement on November 16, and is pulling the controversial code from the shelves world wide. It has disclosed a list of 52 song titles which contain the XCP technology, and has provided a FAQ about this rootkit. Interesting though, they still maintain that their XCP only contacts a website for ad-banner rotation despite proof that this thing dials out to connected.sonymusic.com (See a write up on how Dan Kaminsky estimated nearly 500,000 networks were "infected" with XCP Rootkit using this URL).
Whew! That's a handful, isn't it? To top it off, it has come to the public's attention that Sony's Rootkit code (XCP) incorporates LGPL protected code, which necessitates Sony to publish the code and the derivative code (the XCP code itself). Sony has published a number of open-source code for a its more obscure products. But none can be found for this rootkit.
Isn't that just icing on the cake? Companies like SonyBMG are no different than the smaller companies like SimpleDevices and OmnifiMedia when it comes to GPL violations and Software Copyright Infringements. I recently mentioned this on an earlier blog (GPL Violations Irk Me) as well...
Chances are, we might not ever see the source code for SimpleDevices nor Sony's controversial DRM. These companies are utilizing sleazy tactics against us, hiding behind beaurcratic mire.
I used to like Sony. In a way I still do. I'm trying to justify that I like Sony, and by saying I dislike Sony BMG which is a different company. But in the end, Sony Americas, Sony UK, Sony BMG, Sony Japan are all..., well Sony. The damage is done.
~Lum
I grew up with Sony, in the land where Sony originates. The CEO of Sony lived in the same condo as I did--I used to watch his majestic limousine show up every morning, pert and obedient, awaiting to take his master to his domain. I was a commoner (a foreigner at that), who walked 17 minutes to the trainstation to begin my 1.5 hour commute to school. Back then, there was no concept of Sony Japan. It was just..., "It's a SONY!"
My precious microphones were Sony, my first Walkman (circa 1979) was a Sony. Oooh, the anodized blue and silver body with two headphone outputs, a mic and the orange Hot Talk button so you could talk to each other while listening to the Bee Gees (yea, yea). My $600.00 turntable was a Sony (magentically levitated linear tracking arm with a PLL controlled brushless DC motor. The whole platen was the motor! The body was well heavy, concrete I think, with vibration dampening feet. I still have it.
Japan has two government channels (NHK) which provides very professional, unbiased news, educational content and drama series, including award winning TV-series Silkroad. NHK primarily uses Sony equipment--everywhere.
Sony was ingrained into my young psyche. It was a symbol of Japanese staunchiness. It ranked up there with Toyota, Mazda and Honda as an international power to be reckoned with. Sony was it--if you didn't have Sony then, you were nothing.
But it seems that Sony has just gone a little too far for its own good, and for the good of the public. Recently Sony has been distributing CD media bundled with a controversial piece of DRM software. DRM (or this link), in of itself, is not a bad thing. It serves to help protect the interests of the recording industry and the music artists to which it caters.
But Sony has taken this a step further, and in my opinion, several steps too far. Sony's DRM code burned onto a number of undisclosed CD's will attempt to install itself to the user's PC, when it's played on that machine.
Using advanced techniques to circumvent security, the installed code obtains higher security permissions than the user has and installs itself into the very core of the Windows user's operating system. It replaces core files with its own and employing stealth techniques known only to the savviest viruses, it hides itself in such a manner that even the system administrator cannot find it, nor remove it even if he did. What's worse, all of this occurs without the knowledge of the user, apart from the horrible EULA that mentions none of this.
This has led the public to label this piece of software as a "rootkit." It is a coveted prize amongst hackers, virus programmers and the denizens of the ether-netherworld. It's a bane of the good citizens of the computing world, however.
Once embedded into the OS it lies there, quietly monitoring every keystroke, event, password, music that's been played. Occasionally, it wakes up to enforce the DRM policies. But more disturbing, it surreptitiously reports back to the "mothership" of the user's activities.
Several firms have pointed out this also poses a security risk. Of course, Sony denies all of this, stating that this program does nothing bad nor does anything to get in the way, and heaven forbid--violate the user's privacy by sending usage data back to a tracking site, nor does it pose a security threat in any way. Assistant Secretary of Homeland Security, Stewart Baker, made a comment directed at software makers but primarily directed at Sony. "It's very important to remember that it's your intellectual property -- it's not your computer." I agree.
Sony remains unapologetic, and even devalued consumers by making a derogatory statement about them. However bowing to pressure, it made available a means to "bypass" this DRM on November 2, then a service pack2a on November 8, to remove the Cloaking Technology employed by its DRM code. It was only going to decloak the software--not remove the DRM entirely. Critics blew their stack! Here's a nice write up on the "patched" XCP code.
Then around November 10, the first Trojan Horse using Sony's rootkit to infiltrate then cloak itself, appeared. A real slap in Sony's face. Bad news for Sony continued as a second variant of a Trojan Horse that exploits Sony's DRM code was discovered later that day.
This software comes without an uninstaller. Any attempt to remove this software damages your operating system, and employs tactics that makes it difficult to do so in the first place. To remove the software at all, you must contact Sony through various emails, website registrations, click throughs, agreement with other policies, etc. If you're lucky, it might have been removed.
Public outcry has reached cacophonic proportions. Microsoft has reponded with a patch to disable Sony's rootkit. Anti-spyware software companies have capitalized on this and labeled Sony's XCP code as spyware and offer to detect (and disable) it. Links (1, 2, 3, ...)
Crippled Sony has posted this statement on November 16, and is pulling the controversial code from the shelves world wide. It has disclosed a list of 52 song titles which contain the XCP technology, and has provided a FAQ about this rootkit. Interesting though, they still maintain that their XCP only contacts a website for ad-banner rotation despite proof that this thing dials out to connected.sonymusic.com (See a write up on how Dan Kaminsky estimated nearly 500,000 networks were "infected" with XCP Rootkit using this URL).
Whew! That's a handful, isn't it? To top it off, it has come to the public's attention that Sony's Rootkit code (XCP) incorporates LGPL protected code, which necessitates Sony to publish the code and the derivative code (the XCP code itself). Sony has published a number of open-source code for a its more obscure products. But none can be found for this rootkit.
Isn't that just icing on the cake? Companies like SonyBMG are no different than the smaller companies like SimpleDevices and OmnifiMedia when it comes to GPL violations and Software Copyright Infringements. I recently mentioned this on an earlier blog (GPL Violations Irk Me) as well...
Chances are, we might not ever see the source code for SimpleDevices nor Sony's controversial DRM. These companies are utilizing sleazy tactics against us, hiding behind beaurcratic mire.
I used to like Sony. In a way I still do. I'm trying to justify that I like Sony, and by saying I dislike Sony BMG which is a different company. But in the end, Sony Americas, Sony UK, Sony BMG, Sony Japan are all..., well Sony. The damage is done.
~Lum
Tuesday, November 01, 2005
"Compile In Place," - a Java Technique
"Compile In Place" is a concept that I've been working for the better part of a year and a half. I do believe other Java programmers are aware of it and many of them probably utilize it. I have searched and searched but never found a name or a reference to this kind of programming.
Simply put, Compile In Place allows a person to compile a single Java file without having the entire source code library. This is particularly powerful when trying to maintain Java programs ehose authors have long since left the company and did not disclose the location of the source.
Normal Programmers
Normally, a programmer would have access to Java Project and begins to compile and build starting with the main file. As the main file is compiled, source files for the referenced objects are checked by the Java compiler and if they are newer (by timestamp) than the associated class files, or if the class file is not present at all, then those referenced classes are compiled as well. Those referenced classes may reference other classes and objects until the entire project is built top down.
Alternately a Java programmer might use an AntScript or an IDE (such as Sun One, JPad Pro) to build his files, compiling each source file independently, from the bottom up.
In any case, the Java compiler likes to have the source file present when compiling, as do compilers of other languages. But maintenance programmers who must reverse engineer their predecessor's code may not have this luxury.
But Me?
A Java application is a collection of class files (and supporting properties files, etc.). Compile in place allows a single Java file to be compiled without having any other source file present AS LONG AS the compiled binary file is present in the proper package structure.
If I have decompiled a single file in myCompany.jar, made modifications to it, I can still recompile my single java file PROVIDED I either reference the original jar file in my CLASSPATH along with all of the library files referenced by myCompany.jar itself, and I maintain the package structure.
Alternately, I can extract the contents of the myCompany.jar file completely, and I place my .java I wish to compile in the appropriate directory (according to the package information), then I can simply invoke the command
C:\java> javac com\myPackage\myUtil\MyMain.java
C:\java> _
And it will compile only the one file: MyMain.java to produce one new file MyMain.class. In this case, the entire application is NOT recompiled even though Main.class might be the main class of the entire project.
Why is This So?
Well, for one, there are no source codes to check for -- what's there is what's there. Additionally Java and Javac use reflection extensively which inspects contents of the class files to check for valid public method signatures and public variables. It does not need the source if the binary class files referenced by my .java program checks out.
Lucky, because my job relies heavily on Compile In Place to effect changes to a piece of software who was written by a disgruntled ex-employee. Without it, I just would not be able to repair the bugs in our company's software, sometimes.
I guess this is like C or Assembly where I can compile a simple .c file or .asm file and let the linker link everything provided the libraries and objects are all present. The difference is that in .c and assembly, the output of a linking process is usually a single executable, which cannot be used to help in compiling another single .c or .asm file. (You know, if I have a bunch of object files, it implies I had a bunch of source files to begin with).
But a pitfall...?
There is a pitfall! It might happen if you've been trying to repair a bug in this code elsewhere and you leave your source code in and you recompile another java file in your project. That new java file might have dependencies on your first piece of code and you might encounter hundreds of compiler errors (actually the compiler would give up after a hundred, usually). It may not go away until you move your first source code out to where the compiler cannot find it.
You'll just have to look very carefully at the error output and determine that it might not be coming from the class you're currently compiling, but instead from another class you were tinkering with.
For more info check out Omnifi Wiki Pages.
~lumkichi
Simply put, Compile In Place allows a person to compile a single Java file without having the entire source code library. This is particularly powerful when trying to maintain Java programs ehose authors have long since left the company and did not disclose the location of the source.
Normal Programmers
Normally, a programmer would have access to Java Project and begins to compile and build starting with the main file. As the main file is compiled, source files for the referenced objects are checked by the Java compiler and if they are newer (by timestamp) than the associated class files, or if the class file is not present at all, then those referenced classes are compiled as well. Those referenced classes may reference other classes and objects until the entire project is built top down.
Alternately a Java programmer might use an AntScript or an IDE (such as Sun One, JPad Pro) to build his files, compiling each source file independently, from the bottom up.
In any case, the Java compiler likes to have the source file present when compiling, as do compilers of other languages. But maintenance programmers who must reverse engineer their predecessor's code may not have this luxury.
But Me?
A Java application is a collection of class files (and supporting properties files, etc.). Compile in place allows a single Java file to be compiled without having any other source file present AS LONG AS the compiled binary file is present in the proper package structure.
If I have decompiled a single file in myCompany.jar, made modifications to it, I can still recompile my single java file PROVIDED I either reference the original jar file in my CLASSPATH along with all of the library files referenced by myCompany.jar itself, and I maintain the package structure.
Alternately, I can extract the contents of the myCompany.jar file completely, and I place my .java I wish to compile in the appropriate directory (according to the package information), then I can simply invoke the command
C:\java> javac com\myPackage\myUtil\MyMain.java
C:\java> _
And it will compile only the one file: MyMain.java to produce one new file MyMain.class. In this case, the entire application is NOT recompiled even though Main.class might be the main class of the entire project.
Why is This So?
Well, for one, there are no source codes to check for -- what's there is what's there. Additionally Java and Javac use reflection extensively which inspects contents of the class files to check for valid public method signatures and public variables. It does not need the source if the binary class files referenced by my .java program checks out.
Lucky, because my job relies heavily on Compile In Place to effect changes to a piece of software who was written by a disgruntled ex-employee. Without it, I just would not be able to repair the bugs in our company's software, sometimes.
I guess this is like C or Assembly where I can compile a simple .c file or .asm file and let the linker link everything provided the libraries and objects are all present. The difference is that in .c and assembly, the output of a linking process is usually a single executable, which cannot be used to help in compiling another single .c or .asm file. (You know, if I have a bunch of object files, it implies I had a bunch of source files to begin with).
But a pitfall...?
There is a pitfall! It might happen if you've been trying to repair a bug in this code elsewhere and you leave your source code in and you recompile another java file in your project. That new java file might have dependencies on your first piece of code and you might encounter hundreds of compiler errors (actually the compiler would give up after a hundred, usually). It may not go away until you move your first source code out to where the compiler cannot find it.
You'll just have to look very carefully at the error output and determine that it might not be coming from the class you're currently compiling, but instead from another class you were tinkering with.
For more info check out Omnifi Wiki Pages.
~lumkichi
