Fundamentally, you are trying to hide a secret in a client application. There is a long history of trying to do this in applications. It forms the basis for pretty much all forms of application protection – and it is fundamentally impossible. If there is everything you need to run an application on a system, it just requires a certain amount of effort to determine the secret. The amount of effort varies, but in general it is a continual fight between the developer and the person trying to determine the secret.

Mechanisms have been developed to try and make the secret ‘something you have’. One of the earlier disk-based methods was to have ‘malformed’ sectors on a floppy drive that needed to be read. These sectors were only ‘malformed’ in that they were laid on the disk in a method that made them difficult to read normally. The sectors that were read became part of the code that was used to execute the application.

The fix to this form of protection was to read the protected content from an original and then putting this data into a new copy of the program, replacing the invalid content with this good data, and then skip/remove the code that performed the read of the drive data into that location.

An extension to this protection was to actually encrypt the code that is loaded from disk, and then decrypting it at execution time – the encryption varied from simple byte-level xor-based to more fancy xor with rotate. Typically this decryption code butted up to the decrypted code (sometimes even overlaying it), preventing you from setting a breakpoint at the first instruction following the decryption code). Solving this problem involved manually decrypting a few bytes (which at the time was a pen-and-paper operation), and then starting the decryption from the subsequent instructions. Sometimes easy, sometimes more difficult. This would typically be used in conjunction with the ‘special’ media to give a dual layer of protection.

Another mechanism was the hardware dongle. An oft-loved feature of expensive software, it typically embedded some data on the dongle that was necessary for the use of the application. Without the dongle, the application was useless. Some even went so far as to corrupt the data created from the application if the dongle was not present – e.g. straight lines would no longer be quite straight following a save-load cycle, making the files deteriorate following the transition (I think Autocad used this method).

The issue with hardware-based mechanisms is that they have a high cost associated with them on a per-unit basis. A quick search revealed a per-unit cost of €25 for low order quantities, which would need to be added into the cost of the application. In other words, this can quite often not be an appropriate for software which has a low price goal.

For any of these mechanisms, if someone obtained only one part of the solution (application without special disk/dongle) then a well written protection would mean that the application was unusable without the second part. Poorly written protections would use perform a simple test against the special item, and not actually make use of any of the underlying data from it. In general, once you have all the items that are needed for the running of the application all that mattered after that was skill and time.

Special media, encryption, dongles, packers, obfuscation, anti-debugging tricks are many of the tools that have been used to secure applications.

What has this got to do with the opening paragraph? Well quite a bit, actually. The developer needs to store some kind of secret in the application. This secret can be anything, but in general it is some form of key to gain access to some form of resource. Nowadays, the application is not going to be shipped with any physical media – after all, this is the 21st century, and the use of physical media is archaic. This tends to rule out special media and dongles from the mix.

This leaves encryption, packers, obfuscation and other anti-debugging tricks. There are some very good solutions out there for the packer/encryption/anti-debugging. A quick Google for ‘executable packer anti-debugging’ yielded some interesting results. It’s a fun and interesting area, where the developer is trying to outwit the villainous cracker. Some of the solutions are commercial – adding to the cost of application development, and reducing the ability to debug the application when deployed in the field. These generally are decisions that need to be made by the developer when deciding how to proceed to protect their application.

You have to do the math on it. If the cost of developing and implementing the protection exceeds the overall value that you have placed on the application then you simply cannot afford to spend time, effort and money on a solution that will cost you more than you will ever make.

The big take from this is that if you have a secret that you want to keep safe, don’t put it in the application – all that will accomplish is to keep it temporarily out of view. The truly wily hacker will be able to get it; and if the secret is a password to one of your important on-line accounts; then you should think of some other way to mediate access to the resource.

I went and bought the Wi-Fi model. This was because I really did not want to get another mobile data contract device while I have phones and other devices that are capable of taking up the slack. That saved me a few quid on the purchase price, but that saving was nearly doubled as it was a ‘returned item’, the previous purchaser had actually wanted one with 3G, but had made the wrong purchase. I did not think that it was going to be an Internet device on the go, but more of the traditional gaming handheld.

One of the first things you have to do is purchase a memory card – these systems cannot be used without an add-on card if you want to do anything complicated like, say, save a game. Rather than splashing out for a luxuriant 8gb card, I went for a 4gb model – enough for a few movies, a few downloaded games, and space for storing all that necessary data. These cards are not the traditional Sony memory stick model, so you can’t go about plugging them into a PC to see what’s bee transferred to them to make a quick copy – all transfers take place using the content management software, which can be downloaded from the web, or installed from the device itself (which almost immediately needs to be updated to make it work).

Additionally I bought a copy of Uncharted in the store – I’m a sucker for those Nathan Drake adventures, although I really should get to finish Uncharted 3 sooner rather than later – I just got caught at one of those interminable shooting scenes where you need to have the memory of a Demon’s Souls player to make sure you can maneuver your way through the scene. But enough of the complaining about that.

Configuration of the device was quite simple. Starting it up caused it to ask a few questions, then prompt you to connect to the PlayStation Network (soon to be Sony Entertainment Network). This triggered a connection to a local wireless network (using WPA2, so it wins against the original PSP), which supported the standard ‘type in the key’ mechanism or to use WPS or AOSS, which makes connection trivial. Once I had connected to the PlayStation Network, it allowed me to activate my Vita against the account, allowing me to download and play games on the system.

I downloaded a demo copy of ‘Lumines’, which I decided I would try out in transit – some people had been giving great recommendations about it and I could to with a little puzzle game.

I wanted to put a couple of albums and a few movies on the device, which entailed installing the ‘Connection Manager’ software on my PC – I could have transferred media from my PS3, but I didn’t actually have any to make that a goer (I use DNLA for all my media in the apartment, it saves copying things around, and for the most part just works). Installing the software on the PC required downloading it from the internet, as the ‘install from Vita’ option just didn’t seem to work for me. Installation took a little time, and then end product was another icon on the notification area (guys, isn’t there a better way to accomplish this any more????). The software seems to not take advantage of the Library feature of Windows 7, so I had to copy files into a fixed location to make them work with the transfer agent.

Once the agent is running, and you tap on the connection manager icon on the Vita, you can transfer movies and music from your PC – I installed 3 albums a couple of TV episodes. Transfer time seemed to be about on-par with an iPod, but there is some form of ‘database rebuild’ thing that takes place which I can see being very slow if you have a large collection of media on your PC; I don’t expect anyone’s library to get too large when using the Vita – after all the cards do not hold that much once you’ve added in a couple of GB for games, and the system doesn’t have any built-in storage for anything more than a small amount of data. I understand that the devices’ price point is intended to keep the amount of internal storage low, but not putting at least a few GB of internal storage on the system is a little bit silly; plus every time you want to change the card, the system requires a reboot. Hopefully this model can be improved in the future, as in this day and age, having to do something like that with a card that looks like it should be ‘poppable’ at any time is quite jarring.

On to using the device. I played about 30 minutes of Uncharted, which was fun, mind you some of the touch items such as the charcoal rubbings were slightly difficult to accomplish if you were stroking the front of the screen while trying to hold the device in your hands. Stereo output from the device itself is quite good, the position of the speakers facing the user allows for better direction of the audio. I didn’t check to see what the level of audio leakage was like to the environs, but in a crowded area, I could easily see the sound becoming an irritation.

Screen quality is excellent, lovely bright colors that could easily be seen in these cloudy climes. Pretty much everything on the device is managed from touch access to the front screen – when an application has something to say, it’s icon pulses and wobbles to grab your attention. An interesting approach to catching your attention, but I’m sure if they were all vying for your attention you would quickly become overwhelmed. Barring the PS button, none of the buttons on the device have any use on the home screen. This is an interesting design, as it allows for a system that doesn’t have an explicit focus-cursor. Unfortunately, it is a little bit tricky at times to determine what is clicky, and what is not – help icons look like little bubbles with question marks, and menus generally have a disclosure icon (a > mark), or a check box to select them. Selection of check-boxes requires clicking only on the checkbox, while selection of disclosure items allows clicking anywhere on the line – this is a little bit of a user interface inconsistency that one hopes will be addressed in the future. I presume this is because the text and the check-box are actually separate user interface elements, and that you can have multiple items dangling off the end of the line, but in the case that there is a single item present on the line, it would make more sense that the entire line become the action for that item, rather than requiring the hitting of the smaller target-area.

When using the Vita on the train, I plugged in a set of head-phones which connected to the bottom of the device. It seems to be the only practical location for them so that cabling does not cause an issue for the screen (dangling from the top), the rear-touch pad (dangling off the back), or your hands (dangling from either side). This was fine while playing games, as the device was held in-hand for all the time.

Then I went to watch a TV show on it, and the position of the headphones made it difficult to place the device flat on any surface to watch it so I ended up holding it in-hand for the duration of the show. This is not an ideal position, as holding it stationary like that for an extended period without other interactions was quite fatiguing. With Bluetooth, though, you could use the device without having a connected headphone cable, and thus you could place the device on a flat surface for viewing. Now if only I could obtain a set of Bluetooth headphones that are a reasonable fit (gone through several pairs, and they’ve been inconsistent at best). The show viewing experience was fine; the colors were bright and vivid, but overall I would expect to enjoy more interactive experiences – the screen is just that little bit too small to enjoy at more than hand-held distance.

Charging the device means carrying around another power-brick, which really does not interest me, so I attempted to use either the iPhone or iPad power bricks. The Vita refused to charge from these devices. I don’t know if it is a Sony Vs. Apple thing, but guys please stop doing this!! Nobody is interested in carrying around another proprietary power brick when you have several others that you carry round by default. I bring my iPad charger as it supplies sufficient juice for all my devices, but if I have to carry around another charger for the Vita then I just get annoyed.

There is an option in the system menu that allows you to charge the device from USB, but this means that it will charge from the USB port on a PC when the device is powered-off, not when it is simply in standby mode. I presume this is to prevent system interaction while connected to USB in order to charge, but over-all the experience is less-than-ideal.

Once I got the device charged again, I used it on the return journey, and decided to devote as much time as possible to the Vita on the return journey. One 45 minute TV show, and gaming for the remainder of the journey. I got about 3h15m of use out of it before it prompted me that there was a ‘low battery level’. It looked like about 15% battery life by that point – I’m sure I could have probably got another 45 minutes out of it before it died completely, but I played on until my next checkpoint and then just put it to sleep. There seems to be a big margin for the battery once the warning appears; enough to finish up what you’re doing with some time to spare. The only complaint I had at the end of the gaming session was that the joints on my fingers hurt, which is something that happened with the PSP as well. I think that shorter gaming sessions on the device would be warranted to prevent this fro turning into something more serious.

There seem to be some minor hiccups on the WiFi connections, though. I’ve had a few times when it has just not connected to the wireless network, even though everything else in the area is able to connect without issue. This is generally transient as it seems to pick up the connection the second time round. I was trying to use the WiFi on the train, which uses an open access point, with a log-on screen. This works well on laptops and most modern phones, but for the Vita it simply didn’t work – I was told that the connection had failed and that was the end of it. This is something that needs addressing in the future.

Game prices on the PlayStation store are about €5 cheaper than buying them in the store – I presume the added mark-up is for the box and the media that it comes with; I don’t know if you can trade the media-based games once they have been played on your registered Vita. The versions bought in the on-line shop are most definitely tied to your account. Game prices are about 2/3 that of console games, which can add up to quite a chunk of change if you’re buying a lot of them. It is quite annoying that I can’t use any of my old PSP games on the new Vita, nor can I use any of my original PSone games that I downloaded on my PS3 – even though there is an option to transfer them to my Vita, there seems to be no actual way to get them onto it.

For a hand-held device, it’s price is a little on the high-side (€250). It features a proprietary memory-card device that is, relatively to other memory devices, quite pricy (€20, €35 and 50 for the 4, 8 and 16GB models), then the games are between €35 and €50 depending on where you purchase them. Before walking out the store with your new device, you would end forking out at least €305 for the bare essentials – device, minimum sized card, and one low-price game. That’s not a small chunk of change.

Overall, if you’ve got the spare change to put down on another expensive Sony device that could easily prove a White Elephant, then go ahead; otherwise I’d wait for the re-sale market where you should be able to pick one up for cheap once the initial lustre has worn off.

I require a digitally signed .so. Being a decent sort of chap, I’ve decided to allow it to exist in a foo.so.signature file, alongside the library foo.so. it means that I don’t need to add it to the binary in another section of the .so. This generally complicates signature checking – you need to check the signature of the binary, while excluding the section containing the signature, which could itself be a mechanism for getting code into the system. This can be ameliorated by enforcing a size restriction on the signature section, but have you seen some of the code these days? it’s really fricking small.

the standard mechanism for loading foo.so, is to use the dlopen() call. Once you have completed this call any .init section of the library has been executed. you are pwned.

You need to open() the file, open() the signature. Compare the signature to the content of the file (you can use mmap(MAP_PRIVATE) to ensure that changes to the underlying file do not affect the contents of your memory. Then you re implement dlopen(), alowing it to take either a file descriptor or a raw handle to memory and a size… it’s your call

Feckers, not making linux secure by default… oh, wait, this has existed since before linux…

Security is an ever developing process. the APIs need to evolve with the threats.

Except it’s not a bug. It’s by design, and it’s existed since NT.

Microsoft is being smacked in the head by a required feature of Windows due to the initial weakness of the LoadLibrary call. If you don’t specify a path to the file to load, it uses the standard library search path.

Dear god, you would think that this was news. It is not news, nor has it been since the goddamned operating system shipped. Granted, the issue is severe, but the fact of the matter is if an application is executed using a working directory that isn’t under your control, then what can you do? if there are libraries in the same directory that launched the program that happen to share the name of system libraries then you’re hosed.

Hey, guess what asshole, if you link a linux binary with a search path containing ‘.’, then you get the same problem. It’s just as well that nobody links their binaries with -R. …. eh?

The documentation is blatant in this regard. I’ve known it was a security issue since I first learned of the LoadLibrary call, as any even half decent developer should have known when they started using the damned function.

The rule is simple. Resolve the full path to a library before you load it. Validate that it ‘looks right’ at that point. Then load it.

BTW .init section in .so files – so totally a security hole. You can’t dlopen a file to determine if it’s good without executing the .init code. Game over man, game f**king over!

My .init code does a setenv(“LD_LIBRARY_PATH”, “.” + getenv(“LD_LIBRARY_PATH”)) … now piss off and write secure code for once…