..out of the dark

But what exactly happened? We got to see as well as touch the executables and resource files shipped with the phones' firmwares. And it's also possible now to change virtually any reference and resource on the phone, if you have enough time and will (mostly to find out what sort of curious solutions are used) to do it.

What didn't happen was that we would see anything new about prepackaged sis- files from other developers. Anyone could extract the files already, as well as run through any references to files in use and change them. Still - anyone using the private directories to drop some lock- file or other, trusting that noone would ever see it or have access to it, would probably be pretty eager to change their coding practices after this. I don't honestly think that's bad either.

Maybe some are going to start encrypting their files now, and double and triple the resources used with the programs - but I'm sure most will simply just avoid storing sensitive information in clear text, and use external files that would not be useful on other devices, and that won't expose the program logic.

So, possible abuses emerging along with this hack: 1. Tear SE's bundled software off the phones and install them on other UIQ phones. 2. Expose bad programming practices. 3. Change that goddamned annoying translation- attempt into something that makes sense.

---

Anyway - so what is the hack?

In symbian- based phones, the file- access to system- directories are limited by certificate- levels. These are checked in run- time whenever some api is accessed. And for example, a developer- certificate and the relatively cheap certificates can give you access to all the common apis, and the necessary tools to do most things. Except of course to access system- directories directly, and change or see any files used by other programs. If you try using these, the program will fail - i.e., you list the files on the disk, and some return no values, and others allow you to read. And that makes perfect sense - there's no need for most to have access to more (if SE was a bit better with creating the apis for globally accessing things like volume- control and the wlan interface - or write public apis for changing background images, etc., at least - but for the moment, let's leave that alone). It also ensures that you're not dependent on the courtesy and skill of other programmers when it comes to the stability of your device.

For that reason, it makes complete sense to restrict 3rd party development to this model also after the hack was done. And no users should under any circumstance be encouraged to buy or distribute software dependent on this hack. (Except if you really have to ). Nor to avoid the signing process for testing certain software. Disaster will ensue, and we'll end up like WM very quickly, where any non- licensed developer is more like a hacker than a programmer.

Because the development model on Symbian allows securely deploying third- party applications, even for developers without a large company or a license - and we should respect that, for all of Symbian Signed's weaknesses. And for all the unavailable apis SE refuses to write for us.

Back to the hack: the on- device debugger has a strong certificate, and allows read and write permissions above the developer- certificate. And some really clever guy figured out the exact pair of bytes to change in memory on the phone that concerns the check for the certificate permissions. Which is easy to explain - but probably a bit worse to figure out on your own. I'm not even sure how it can be done - trying to run a command that require higher privileges, and then read the memory- content logs..? Sounds almost incredible to me.

---

Not too long after the hack, there were some bad news from the ones we thought would probably be the first to use the hack for something constructive. It turned out that simply getting the files (in this case the walkman player) off the phone wasn't enough. Because in the executables and resource- files, there were several absolute references. Apparently, it turns out that this is not just from the final makesis layer to the user- areas either - there are several in the middle of the files to specific resources. Which comes as no suprise, since we've come to recognise SE as being pretty far gone when it comes to modular programming in general.

Or - I may be wrong, and the makesis program doesn't just, as I'm assuming, put an extra layer at the beginning of the exe- file. But goes through the entire file, replacing the resource references one by one into absolute paths... actually - no. That'd be stupid. Incredibly stupid.

The first attempt at a solution, then, would be to copy the absolute reference targets to the new phone along with the exe. It didn't work - because the operation to read files used in the program was based on a lower certificate- level - the usual file- permissions that require you to only read in a private directory corresponding the registered UID. In other words, when the program tried to access the resources it would need, the file would exist, but would return access denied - that function simply will not succeed when trying to access files outside the program's own private area. With or without hacked permissions. Because the command that would work wasn't used. Of course - why have to change the directory for the install- files? Because the media- player on the p1 shared UID with the player on the w960, and just overwriting the files would not really be a very good idea. Because a lot of things are loaded at startup, and I don't doubt that someone bricked their phone before finding out that this wasn't possible.

The second attempt (figuratively speaking) was by moherovy (or dark skeleton... the lamest hacker alias I've ever seen..) over at ipmart forums. Apparently he had not ran into that first problem, since the UID on the w950 player and the m600 media player were not the same. So by mirroring the files, changing some of the resource references from z: to c:, as well as placing the loc_rsc files in the right application import- directory - it worked. Good news, after all - it was possible to run the program as a stand- alone app.

Soon after that, the references for the UID on the w960 player were changed, along with the necessary absolute references - and presto - walman player 3.0 on the p1, happily running as a separate program. And any other future UIQ3 device with enough ram, and the required in- built libraries. (Luckily the p1 had those. In the future, I've no doubt that programs specially built for UIQ3.3 and svg tiny 1.2 won't run on the p1, for example - but still - it's possible it will work anyway as long as the changes are in low- level implementations, and not on the program interface level.)

The next step now will be to package these files in a sis- file, and write an intallation script. It's not too complex - and I suppose it'll be done soon enough. As it probably will be with any future goodies Sony Ericsson sees fit to sell only together with a specific phone- model, that is physically about identical. Anyway - instead, SE could spend time developing the underlying program interfaces, and develop the ones that are still missing - and then perhaps just sell these pretty cool and functional apps (they have obviously spent more time on making than fixing bugs on the phones) on the content- portals instead. And so /increase/ the market potential of their devices..

---

Is this sort of thing really ethical? Personally, I've never been fond of crackers - it had nothing to do with skill, or knowledge about systems - it had all to do with using preconfigured tools to generate bypasses - in order to get free games and programs. The most genuinely lazy cracks I've seen turned out to be someone releasing a full game with the execute that came with the demo. Because that launched the game, and didn't hang it until you came past the first level. And that wasn't just a one- time occurrence, believe me.. Script- kiddies go! Batteries to full speed!

Still - when we're trying to get a product we bought, thinking it'd work out of the box, then you'll forgive some misfires like that. Simply because that crack made it possible to play the game without intrusive cd- check utilities running in the background - that would, among other things, reduce the speed of the entire system.

But are we really talking about that sort of excuse here? Not really. But what irks me the most when we're talking about smartphones and Symbian is the mystery shrouded over the entire thing. To be perfectly honest, talking to some programmers gives you the same feeling you would have when talking to a monk in a monastery, who presumes to know everything about everything. But isn't actually erudite enough to remove the suspicion that the elliptic and haughty language he's using is simply there to cover over that he does, in fact, not know anything about women - even though he insists the opposite is true.

In the same way, the user- base tends to be impressed with new tech and sales- packages, and just can't be expected to know how the entire thing fits together. And, the first thing I heard when wondering when SE should release the walkman player for all UIQ units (perhaps as an add- on) was that it was physically impossible. Probably hardware- differences, people said. The same when wondering about upgrades to certain extra- programs bundled with UIQ - they had to be added with firmware, it was said. It was impossible to upgrade it through external means, outside SE's lackdaisical schedules for firmware- updates.

All of which is of course complete nonsense. As for example the hack shows, it's perfectly possible to extract Symbian and UIQ compiled programs off the device - in just the same way that any other computer cannot - by design - hide pre- installed programs stuck on it very easily. And as usual - any attempt at this, is motivated by bad programming practices, and simply an attempt to hide them. Indeed, the biggest obstacle to deploying the walkman player on all UIQ phones is the amount of absolute addresses, that also obviously makes the development process device- specific - and not merely UIQ specific.

And that is because of policy set in the first place - a carryover from the feature- phone market, where it was necessary from the very beginning to do things like these to exploit the newest software- chip, the slightly bigger memory on the new version, or the changed heap- sizes. I.e., it wasn't going to be possible to use the identical programs on other phones anyway.

With so- called object- oriented and modular programming, however *cough*, that kind of thing is now not necessary any more. Instead, it's perfectly possible to use common code - for example UIQ or any other documented library collection - and then port this to symbian- libraries. And then - observe - do the hardware- specific changes only on the low- level interfaces - on the code that actually is device specific - instead of MAKING a program device- specific on principle.

Because this incurs a tremendous cost on the development process - it makes the debugging process impossible to improve on between different branches, and it takes effort from other activities that are - once the low- level interfaces exist - infinitely more important. Not in the least because all of that rewriting of the source- code could be dropped completely.

But policy and the sales- package was already set, and so we continue to be tempted with trinkets when buying a new device. This one has red buttons, and that one has green! I must choose one! Really..

And the same problem makes users not see the actual potential of the platforms. For example - there's nothing technical that stops anyone from writing a new set of phone- tools for Symbian- based phones to replace Sony Ericsson's attempt at it. For example one that moves seamlessly between gsm, gprs and 3g dependent on coverage. But the enforcement mechanisms are there, since these tools are impossible to deploy successfully on the devices within the "approved" licenses - the phone- manufacturers make sure of that. And so they keep the monopoly on making these programs. No matter what sort of level of quality they offer.

The same issues arise with the flash- lite player: it's not physically impossible to do, far from it. Neither is it impossible to implement a software- based wrapper for executing the code purely from software. But licenses and non- interest early on made SE drop the vector- graphics libraries needed for hardware- accelerated flash on their phones long ago, and they have had no intention of ever improving this. Meanwhile, aquiring the license for flash lite is a less than tempting prospect for any smaller developer.

And this process then enables phone- manufactures to indiscriminately sell their products based incremental and tiny improvements in software - instead of offering a good platform for everyone - including the phone- companies - to develop on. And why? Simple - so they can sit on the technology and make sure we do not use any of this to the extent of it's potential. Because doing so would be obscene and ineconomical - when we've only had the technology for about fifteen years now, and computers with open developer- opportunities have existed for much longer than that.

Apparently, if the current mobile phone business made cars, they would still need to have a guy walking in front of it with a warning sign, whenever you'd meet anyone. Because it's not about selling phones and making your platform more appealing, is it. It's about controlling the development process. It's the same insanity that made phone- companies initially take $2 bucks for sending 20kb of data through their networks - also called MMS. Just imagine that - if someone made a program for a PC that sent pictures to someone else - and then took $2 for each message, because that format was so incredibly advanced, and impossible to replicate with just using /an ordinary datastream/. I mean - you'd laugh yourself silly. But not if it's on a mobile - because that's completely different..

But of course it is not - and until we recognize that as users, and are unwilling to pay for these very, very bad sales- packages - then we'll continue to get more of them. In the same way that if we continue to buy these phones in spite of their weaknesses, then eventually they'll come in cardboard with painted on buttons and a hand- drawn screen.

I'd rather that we'd actually create a demand for improved devices on the market instead. Where technology actually evolves, instead of stranding itself and declining. Like we've shown how SE does with their newest symbian phones - instead of producing something new and exploiting the tools they've actually bought, they insist on simply leveraging as much control as possible over the development of the phone- market. Without vision, without real interest or ability to advance mobile tech - even though they have the tools in their hands, and they're being challenged by increasingly smaller computers turning up on the market.

----

Tutorial for the hack:
You need:
One symbian UIQ phone. One computer (with windows). A data- cable.

1. Install the following software on your computer, in this order:
-The Sony Ericsson PC suite (see www.sonyericsson.com)
-Python.
-Python Windows extensions.
-Python Serial port extension.
-The python script for simulating the debugger- interface (just copy it to some directory).

2. Install the on- device debugger on the phone.
AppTRK.sis[/quote]. If the PC suite installed fine, you could use the wizard, and just double- click the sis- file when the phone is connected in "phone- mode". 3. Edit the python script, or prepare the connection on the computer. - Find the ports your phone is connected to. Look under system->device- manager->lpt/com. There are two ports. One should say application port, and have a number. - Open 1.py in your favourite editor, and search for the line that contains this text: "ser = serial.Serial(4) # I have COM5" - Change (4) into your port minus one (i.e., port one is (0), and so on), and save. 4. Prepare the connection on the phone. - Run AppTrk from the tools- menu. If it says "connected", all is well. If not, change the serial port on the device to 1. 5. Open a command shell (run "cmd" in the "run- menu" for example). - Find the 1.py script. And run it. If it says something like ....replynoerror >close>end+exit towards the end, things should be fine. Now the hack is completed, and you can access the files on c: and the private directories. 6. Install CapsSwitch. So you can switch on and off the permissions as you'd like. It's not a good idea to have the permissions running all the time, or run programs that depend on the permissions being open - as explained at length above. - Install CapsSwitch. The sis- file in the zip, I mean. And with the new permissions, copy the ldd- file to c:/sys/bin like it says in the readme. Don't worry about the hash. There! Now you should be able to switch the permission- byte pair on and off as you'd like. ---- Allright, but what can I do with it, except stare blankly at endless lists of incomprehensible characters and files with numbers?

Installing Walkman Player 3.0 on the SE p1i:
1. Download Swmail's Walkman 3.0 mod.
2. Extract the archive over the c: drive. If you have x-plore (excellent multipurpose filebrowser from Lonelycatgames), just copy the zip to the phone, open it, select the directories in the zip, and then extract them to c:/.

Or, if that makes no sense to you, extract the files to a place on the mem- stick, and then copy the directories over to c:. You'll be asked if you want to overwrite some files - click yes. In this case, you're not actually overwriting anything, but that message turns up if you have a directory with the same names on the target, and it would overwrite all the files with the same name. So be careful with that.

If you for some reason want to uninstall this again, it should be enough to remove the files (the specific files in the archive, not the folders) one by one, and then rebooting the phone.

----

...Other than that, take a look here, for example, for the latest updates. Also, ares at www.uiqblog.com seems to be pretty quick at finding out news on the hacking progress

----

Here's a link to swmail's "install" mod. Basically, install any package with any permissions without needing to sign it. Great when testing programs you've written (because you need to pay for a SS id to get a developer cert), updating programs with protected IDs, etc.