Today, Broken Fractal Ventures -- my new company -- is announcing El Tunes, a way for Linux users to play their Fairplay DRM-encumbered media from the iTunes Store. El Tunes comes in the form of a GStreamer plugin that will decode M4P files and allow you to use any GStreamer-enabled media player -- Songbird, Rhythmbox, Totem, Amarok, or others -- to listen to the music you own. Today's release is a free preview that enables music playback but video playback and AirTunes support are coming soon.
I hope you enjoy this free preview, and I suggest you keep an eye on this blog -- the best is yet to come :)
- Cody
More Info: El Tunes
Thursday, July 24, 2008
Wednesday, May 31, 2006
My Vision
My vision for computing and my goal for the next 5 years is simple: Any piece of software, any platform you choose.
Right now, I'm working on a project called Alky that will allow you to convert a Windows executable to a Mac OS X or Linux binary. We are focused on high-end gaming at the moment, though we will support normal applications in the future.
Our binary translation layer is already working fully for OS X and Linux support is in progress. Of course, Windows applications use a very different set of libraries from Linux or OS X applications so we are also working on a library called LibAlky that will provide those Windows libraries to the application.
Now, this may seem similar to Wine/libwine in many ways, but Alky differs on a few major points including that:
1) Alky requires no wineserver-like software, reducing overhead greatly.
2) Alky converts binaries rather than running them through it at runtime, so a vendor can use it to port an application and ship with it without requiring any additional dependencies on the user's machine.
3) Since Alky runs at the binary level, applications can be ported using it without any access to the source.
4) Since Alky doesn't depend on access to the source to port applications (as noted in #3) we can greatly clean up the APIs, so long as we keep them binary-compatible. This gives us a lot of freedom.
When an application is converted, the imports are checked to see what's supported and what isn't. For functions that aren't supported, it will report them as such (at conversion-time, mind you) and will optionally pull up a function prototype from MSDN and auto-generate a stub for you. In this way, we can very easily extend LibAlky without playing a guessing game as to what needs to be implemented.
Although it's a very new project, it will already convert (nearly) any Windows executable into a Mac OS X executable and attempt to run it, with some success and a fair amount more debug data.
As an example, you can see Oblivion throwing an error here. We get further, now, but not near the actual game. It's going to take time.
My vision is not limited to applications or games, either. I believe that it is entirely possible to take drivers from various OS's and convert between them as well.
This is truly the start of something beautiful, and it's been a long time in coming. This is my goal for the next 5 years, and I will not fail in attaining it.
Happy Hacking,
- Cody Brocious
Right now, I'm working on a project called Alky that will allow you to convert a Windows executable to a Mac OS X or Linux binary. We are focused on high-end gaming at the moment, though we will support normal applications in the future.
Our binary translation layer is already working fully for OS X and Linux support is in progress. Of course, Windows applications use a very different set of libraries from Linux or OS X applications so we are also working on a library called LibAlky that will provide those Windows libraries to the application.
Now, this may seem similar to Wine/libwine in many ways, but Alky differs on a few major points including that:
1) Alky requires no wineserver-like software, reducing overhead greatly.
2) Alky converts binaries rather than running them through it at runtime, so a vendor can use it to port an application and ship with it without requiring any additional dependencies on the user's machine.
3) Since Alky runs at the binary level, applications can be ported using it without any access to the source.
4) Since Alky doesn't depend on access to the source to port applications (as noted in #3) we can greatly clean up the APIs, so long as we keep them binary-compatible. This gives us a lot of freedom.
When an application is converted, the imports are checked to see what's supported and what isn't. For functions that aren't supported, it will report them as such (at conversion-time, mind you) and will optionally pull up a function prototype from MSDN and auto-generate a stub for you. In this way, we can very easily extend LibAlky without playing a guessing game as to what needs to be implemented.
Although it's a very new project, it will already convert (nearly) any Windows executable into a Mac OS X executable and attempt to run it, with some success and a fair amount more debug data.
As an example, you can see Oblivion throwing an error here. We get further, now, but not near the actual game. It's going to take time.
My vision is not limited to applications or games, either. I believe that it is entirely possible to take drivers from various OS's and convert between them as well.
This is truly the start of something beautiful, and it's been a long time in coming. This is my goal for the next 5 years, and I will not fail in attaining it.
Happy Hacking,
- Cody Brocious
Sunday, August 28, 2005
ArchShadow Status and History
Well, I'm now in the process of rewriting a large bit of the core of my decompiler (ArchShadow), now nearing its 3rd year of development (though not on the same codebase)
ArchShadow originally started as a proof of concept decompiler that was fully standalone. It was written in PHP (please don't martyr me for that) and used its own, very poorly written, disassembler. It actually could decompile a number of large test binaries, but it was gcc-specific and very specific to certain ways of using constructs. It was a hack, by any definition of the word.
From there it grew into a pure C project, still implementing its own disassembler. This implementation didn't last long, as it simply wasn't worth the hastle for the limited return. It did make the disassembler core a decent bit cleaner, though.
After that, I worked on an implementation in Python, still using my own disassembler. This lasted for a while and let me get a lot of the SSA theory down. Eventually it was eliminated when the analysis work on the disassembler side (especially function detection) got to be too big to handle.
All of this taught me a big, very important issue. If the option to use an existing disassembler is there, USE IT.
ArchShadow is now in Python, sitting on top of IDA. It reads in a good bit of information from the DB and caches it allowing you to run it away from IDA as long as you don't change the code to the point that the information read from the DB is different. I'll eventually make it pull the entire IDA DB so that that's not such a big deal, but that's going to be a while in coming. The current version works good enough for now.
The problem with the current revision is that my SSA support for variables (used for detecting the modifications to different things over the course of a given function) is simply poor. It works, but to change names from the SSA name (var_#) I have to do a string replace which simply feels like a hack. I'm going to address this in my partial rewrite.
Anyway, enough history.
I'm considering building a system that can export data from an IDA database and then be used in an external interface. The main reason being that the interface for IDA on Linux is very poor, and there's absolutely no way for me to run any sort of IDA interface natively on OS X as it stands. One other option is writing a network layer where tvision would currently stand in the linux version and building a GUI that works with that, but I'm not sure of what is exposed ot tvision.
Anyway, enough wasted time for now...
Take care.
Cody Brocious
ArchShadow originally started as a proof of concept decompiler that was fully standalone. It was written in PHP (please don't martyr me for that) and used its own, very poorly written, disassembler. It actually could decompile a number of large test binaries, but it was gcc-specific and very specific to certain ways of using constructs. It was a hack, by any definition of the word.
From there it grew into a pure C project, still implementing its own disassembler. This implementation didn't last long, as it simply wasn't worth the hastle for the limited return. It did make the disassembler core a decent bit cleaner, though.
After that, I worked on an implementation in Python, still using my own disassembler. This lasted for a while and let me get a lot of the SSA theory down. Eventually it was eliminated when the analysis work on the disassembler side (especially function detection) got to be too big to handle.
All of this taught me a big, very important issue. If the option to use an existing disassembler is there, USE IT.
ArchShadow is now in Python, sitting on top of IDA. It reads in a good bit of information from the DB and caches it allowing you to run it away from IDA as long as you don't change the code to the point that the information read from the DB is different. I'll eventually make it pull the entire IDA DB so that that's not such a big deal, but that's going to be a while in coming. The current version works good enough for now.
The problem with the current revision is that my SSA support for variables (used for detecting the modifications to different things over the course of a given function) is simply poor. It works, but to change names from the SSA name (var_#) I have to do a string replace which simply feels like a hack. I'm going to address this in my partial rewrite.
Anyway, enough history.
I'm considering building a system that can export data from an IDA database and then be used in an external interface. The main reason being that the interface for IDA on Linux is very poor, and there's absolutely no way for me to run any sort of IDA interface natively on OS X as it stands. One other option is writing a network layer where tvision would currently stand in the linux version and building a GUI that works with that, but I'm not sure of what is exposed ot tvision.
Anyway, enough wasted time for now...
Take care.
Cody Brocious
Thursday, July 28, 2005
Content Delivery
Every developer has, at one time or another, considered what the next methods for content delivery will be. In the early days, we had BBS's. With the coming of the internet, we had Gopher, then HTML. HTML was great when we needed simple text and static images, but we've moved on from there. We now desire interactive graphics and streaming content. VRML was one early way this was accomplished, but it never took off. I'll cover VRML later, but right now let's focus on HTML and other more common web technologies. These things we desire are where JavaScript, Flash, and a half-dozen other technologies come in. They work to fill the gaps HTML leaves. This isn't to say HTML doesn't serve its purpose, but we're pushing it to do things it's simply not meant to do.
We need a change. We need to stop beating the dead horse that is HTML. The problem is that we keep ending up with proprietary replacements that perform poorly and are designed even more poorly. Flash and XAML are two fantastic examples of this. They both share the same basic concept: applications should be simple to design, run in any setting you want them to, and do what you want them to do. Flash does this fairly well: its design tools are simple to use, it runs on many systems, and most of the time they Just Work (TM). However, its design tools are commercial and few (if any) good replacements exist, it is a primarily proprietary system in that it is not completely open for producing and rendering, and one organization controls (almost) every Flash player implementation. XAML suffers from many of these same issues, though it's unsure whether it's going to be available beyond Windows.
So what can we do? Well, for starters, we need to design a system that provides every bit of functionality current systems provide. This means everything from basic elements of web sites (2d text, forms, etc) to animated graphics and dynamic content. This is a big undertaking, but not impossible by any means. That is the first goal.
The second goal is simple: complete interoperability. HTML was great at this; you could browse an HTML-only website in the most 3d-rich environment or from a simple text-based console. Sure, you could make it easier to use, but HTML could never truly scale. You could never take advantage of the environment HTML was running in because of its simple design, and if you attempted to use Flash and the like, you ran a good chance at blocking out potential users. So what's the solution? Build in layers, separating content from display. You shouldn't have to build your site in 3 or more ways (Flash-only, HTML with frames, HTML with no frames, etc) just to make it usable to everyone, it should be part of the design.
Before I get to the next goal, I'd like to go back to VRML for a moment. VRML stands for Virtual Reality Markup Language, and it was just that. With VRML you could build complex (for the time) 3d worlds, and with extensions from companies like Blaxxun you could have multiple people cooperating in an online world. (Cybertown is a good example of this) The problem was that because of the limitations of systems (both clients and servers) and limitations of bandwidth, no one could truly take advantage of this technology. Later, X3D was designed by the Web3D Consortium to replace VRML, but it only took off in a very limited space. VRML and its kin are essentially dead in the water, despite being fantastic concepts.
The third goal is a bit more complex: unlimited 3d content that scales. If you're on a powerful system, you don't want to look at graphics from 1995, just like when you're on a portable concept you don't want to have such high quality graphics that you can't move. By designing the 3d system to allow for scaling content, and designing tools (and retrofitting existing tools) to do so, it's well within reach.
Now, everything I've said seems fairly straight-forward really. Non-trivial, but straight-forward. There are a few dilemmas I am faced with while thinking this through, the biggest of which is this: How will the actual logic be done? It's very simple to throw content at various devices and have them render it, but it's far more difficult to design the system in a way that you can do actual logic in it. Being a Python fanboy, it is my first choice, but this is really where something like .NET reigns supreme, because you're not tied down to one language. Parrot would be an obvious choice if it were more mature, but as it stands, it's not even an option.
So that said, I'm very interested to hear what everyone thinks, and maybe one day we can move forward with this.
Later.
Cody Brocious
Edit: Alex Goodwin commented about .NET not being a good idea to him, and I agree. I forgot to add that I think .NET is a poor implementation of a great concept, and that I have no intention of using it.
We need a change. We need to stop beating the dead horse that is HTML. The problem is that we keep ending up with proprietary replacements that perform poorly and are designed even more poorly. Flash and XAML are two fantastic examples of this. They both share the same basic concept: applications should be simple to design, run in any setting you want them to, and do what you want them to do. Flash does this fairly well: its design tools are simple to use, it runs on many systems, and most of the time they Just Work (TM). However, its design tools are commercial and few (if any) good replacements exist, it is a primarily proprietary system in that it is not completely open for producing and rendering, and one organization controls (almost) every Flash player implementation. XAML suffers from many of these same issues, though it's unsure whether it's going to be available beyond Windows.
So what can we do? Well, for starters, we need to design a system that provides every bit of functionality current systems provide. This means everything from basic elements of web sites (2d text, forms, etc) to animated graphics and dynamic content. This is a big undertaking, but not impossible by any means. That is the first goal.
The second goal is simple: complete interoperability. HTML was great at this; you could browse an HTML-only website in the most 3d-rich environment or from a simple text-based console. Sure, you could make it easier to use, but HTML could never truly scale. You could never take advantage of the environment HTML was running in because of its simple design, and if you attempted to use Flash and the like, you ran a good chance at blocking out potential users. So what's the solution? Build in layers, separating content from display. You shouldn't have to build your site in 3 or more ways (Flash-only, HTML with frames, HTML with no frames, etc) just to make it usable to everyone, it should be part of the design.
Before I get to the next goal, I'd like to go back to VRML for a moment. VRML stands for Virtual Reality Markup Language, and it was just that. With VRML you could build complex (for the time) 3d worlds, and with extensions from companies like Blaxxun you could have multiple people cooperating in an online world. (Cybertown is a good example of this) The problem was that because of the limitations of systems (both clients and servers) and limitations of bandwidth, no one could truly take advantage of this technology. Later, X3D was designed by the Web3D Consortium to replace VRML, but it only took off in a very limited space. VRML and its kin are essentially dead in the water, despite being fantastic concepts.
The third goal is a bit more complex: unlimited 3d content that scales. If you're on a powerful system, you don't want to look at graphics from 1995, just like when you're on a portable concept you don't want to have such high quality graphics that you can't move. By designing the 3d system to allow for scaling content, and designing tools (and retrofitting existing tools) to do so, it's well within reach.
Now, everything I've said seems fairly straight-forward really. Non-trivial, but straight-forward. There are a few dilemmas I am faced with while thinking this through, the biggest of which is this: How will the actual logic be done? It's very simple to throw content at various devices and have them render it, but it's far more difficult to design the system in a way that you can do actual logic in it. Being a Python fanboy, it is my first choice, but this is really where something like .NET reigns supreme, because you're not tied down to one language. Parrot would be an obvious choice if it were more mature, but as it stands, it's not even an option.
So that said, I'm very interested to hear what everyone thinks, and maybe one day we can move forward with this.
Later.
Cody Brocious
Edit: Alex Goodwin commented about .NET not being a good idea to him, and I agree. I forgot to add that I think .NET is a poor implementation of a great concept, and that I have no intention of using it.
Friday, July 15, 2005
What's New
Since I haven't been able to blog for a while, I guess I'll throw an update out on what's going on right now.
I'm in the process of moving to San Diego, CA for work. I fell in love with the area after spending two weeks there earlier in the summer.
When I'm not working, I'm coding on my ArchShadow decompiler. Nearly 3 years after its inception, it's starting to take form. It is in its (hopefully) final incarnation, as an IDAPython script. It's finally getting to the point that it can handle complex code. The following are my test cases for ArchShadow:
Finishing reverse-engineering MSDRM (non-Janus)
Reverse-engineering the unknown parts of the Skype protocol
Some random cases (SC Info for iTunes in particular)
ArchShadow is my first piece of commercial software in a long while, and I can only hope it goes well. I'd love to at least see something come out of all the time I've spent on it haha.
Well, if anyone is in the San Diego (specifically La Jolla) area and wants to hang out, let me know... looking for people to talk geek with out there ;)
Later.
Lord Daeken M. BlackBlade
(Cody Brocious)
I'm in the process of moving to San Diego, CA for work. I fell in love with the area after spending two weeks there earlier in the summer.
When I'm not working, I'm coding on my ArchShadow decompiler. Nearly 3 years after its inception, it's starting to take form. It is in its (hopefully) final incarnation, as an IDAPython script. It's finally getting to the point that it can handle complex code. The following are my test cases for ArchShadow:
Finishing reverse-engineering MSDRM (non-Janus)
Reverse-engineering the unknown parts of the Skype protocol
Some random cases (SC Info for iTunes in particular)
ArchShadow is my first piece of commercial software in a long while, and I can only hope it goes well. I'd love to at least see something come out of all the time I've spent on it haha.
Well, if anyone is in the San Diego (specifically La Jolla) area and wants to hang out, let me know... looking for people to talk geek with out there ;)
Later.
Lord Daeken M. BlackBlade
(Cody Brocious)
New Blog
So, I finally have a blog again. You may have noticed that daeken.com has been down for some time due to a server crash. Well, the server itself was up again within a day or two, but I simply haven't gotten off my ass to put the blog back up. I decided to simply move to Blogger to save myself a lot of time. I'm going to look into moving my old blog postings over, but I doubt I'm going to put the effort forth to do so.
If someone has a cache of the Project Statement for PyMusique, I'd appreciate it if you'd post it here or email it to me.
Thanks.
Lord Daeken M. BlackBlade
(Cody Brocious)
If someone has a cache of the Project Statement for PyMusique, I'd appreciate it if you'd post it here or email it to me.
Thanks.
Lord Daeken M. BlackBlade
(Cody Brocious)
Subscribe to:
Posts (Atom)