03.03.07
Posted in IDE, tools, PHP, open source, projects, webdev
at 04:34 am
This night, I’ve finally released NOPworklog version 0.1, first public release. What’s it all about?
It’s very simple tool written in PHP (and it stored data in XML file, so installation is easy, too). In the simplest way, you log how you spend time by three clicks – you choose project and task from the list (think of this as categorising the logged time) and then click “start”. It saves the time of starting the task. Then, when you’re done with whatever you were doing, you just click “stop”, and the time is again saved. In this version, it’s only displayed (as a list of all log entries), but since we’ve got the data saved, it won’t be difficult to add some statistics or even invoice generation.
NOPworklog 0.1 is available for download immediately from sourceforge.net. Released under Open Software License 3.0.
Permalink
01.27.07
Posted in CMS, PHP, development, javascript, open source, webdev
at 01:26 am
Without noticing that similar activity is already going on, I’ve modified Quicktags module for Drupal 4.7 and rewrote it… restored back classic text buttons, just like we know them from Wordpress. Of course, it’s all based on quicktags by Alex King.
So, download my first version if you wish. It needs a lot of work to be seaworthy, but it’s enough for me (it’s working).
drupal, drupal 5, module, quicktags, non-wysiwyg, javascript
Permalink
10.03.06
Posted in Flash, PHP, design, development, game, projects, webdev
at 07:46 pm
First of all, I presume that your web server is more secure than your Flash file. Because, as you know, your Flash file isn’t safe place at all.
Although you can create cronjobs (scheduled tasks on server) to regularly change filenames to prevent leeching (or any other technique), there is only little you can do about having your Flash files decompiled. But OK, let’s first have a look on how to spoil leech’s day.
Design your asset storing smartly. The more levels of including external assets and code, the more files they’ll have to decompile. Storing everything in one file is the best thing you can do to help leeches, thieves, hackers and warez guys (I’ll call them just leeches). Apply any techniques for changing file names and locations, no matter how simple they are. The more of them, the more leeches you will scare. Few examples:
- Add somewhere in you filename date or time. For example, if original name would be “monsters.swf”, add day of month to position given by day of week. E.g. Monday = 0, Tuesday = 1, Wednesday = 2… So if today is Monday the 13th, the new filename could be “13monsters.swf”, if it’s Thursday, it would be “mon13sters.swf”.
- Be inconsistent. For example, don’t use 5 for Saturday and 6 for Sunday, but switch them. In January, add to filename day of the month in decimal (01-31), in February in hexadecimal (01-1F). And every other week, switch the digits (‘F1′ instead of ‘1F’, ‘72′ on 27th day). The more rules the better.
- Rotate the filenames. If you have separate files for cars, tracks, trees and power-ups, just change them every (insert time period here), so they’ll get file with power-ups when they’ll look for levels.
- Create fake assets. Just throw in few ballast files to confuse them. The more similar filenames you give them, the more confusing it will get (sadly, both for you and leeches). E.g. “cars.swf”, “car.swf”, “car-new.swf”.
- Throw in few mathematical and string methods to protect suitable data (XOR, rot13, crypting).
- Change the rules once in a while.
- Don’t store all these rules in main Flash file. Have multiple compiled SWF files, each with only a subset of rules. The more things you store on server side, the better (I’ll get to this one later).
Most of you probably now just wander how the heck is this gonna help in protecting from decompiling. It isn’t. This is just a first step – adding a little noise. If something, it will scare away lazy kids who think they can put your Flash application on their site. But let’s not stop there – what are we gonna do next?
A little review. I know most of readers know this, but anyway: there’s no way to save your Flash file from certain decompiling. There are only ways to make it harder. Every method of hiding assets (mentioned above) what you implement on server has to be implemented in Flash file. When I rename files on server depending on the day of the week, the Flash file has to know that they’re named depending on the day of the week. Clear? Clear. Good.
What does it mean? Never, never ever store passwords in your swf. Well, if you put there game-related passwords, you know what you’re risking. But think twice before you insert ftp or email logins. There are other ways to store passwords.
Use database. Or just plain text files or whatever, adding detailed description of these is outside of scope of this article. Example: We want to have content accessible only by registered users. User registers, chooses name and password. Name is stored in the DB using some PHP function or XMLRPC handler. Password is hashed and stored there in the same way. When users returns and logs in, Flash application will compare his name/pwd to data in the DB or even better, let the PHP script do it. But here is our potential security vulnerability- if cracker will decompile our Flash app, he could just remove the password checking method and access desired content. Some more tips:
- Hash entire content with the user password and serve it on demand by PHP. This way you can monitor who has accessed assets and when.
- Implement flood protection. If you know that players will need at least 3 minutes to finish the level, forbid downloading more levels by the same user in shorter period of time.
- Often check the path the script is running from. Use JavaScript to do this.
- Add additional checks using PHP/JavaScript. Create your own session ID in JavaScript (or use PHP session ID), send it both to Flash app and server, store it temporarily in database and require it for communication with server.
I am not a security expert. There are still many places where you can improve security. The question is if your application is really so precious that you gain something by spending a lot of time on implementing these (and other) security features.
Anti-cheat methods coming in next article.
flash, protection, decompile, anti-cheat, leech, asset, games
Permalink
10.27.05
Posted in PHP, web, webdev
at 09:08 am
It’s nice to see someone who has made informed step and migrated from ASP.NET to PHP. I’ve found that link at this blog, which I’ve found from PHP design patterns. Nice reading.
Permalink
10.21.05
Posted in PHP, web
at 10:45 am
Now this is what I call useful blog. After only a short reading, I’ve learned quite a few things, gathered some useful links and found a couple of tools. B-E-A-utiful.
Permalink
10.15.05
Posted in FXweb CMS, PHP, design, projects, webdev
at 11:10 am
Ewww, awfully long title. But I don’t know how to express is by fewer words, so… on to the subject.
I’ve been coding new CMS in past few days, which won’t be released under any OSI-approved license, because it won’t be released at all. But I hope that the fragments of code and any gained skillz will make it to FXGAS, my open source project (which is codeless so far) someday.
My CMS can read static XML files and transform them via XSLT. Nothing special actually, that could be done in some 20 lines of code. Of course, that wouldn’t make it Content Management, nor System. It can analyse GPC data, look in the database and determine which XML to choose. This is all done by what I call ‘kernel’, or more specifically, class kernel. This is the only thing that’s instantiated by index.php and handles everything else. And, since I’ve used the name ‘kernel’, it should be able to load modules.
Now that was kinda problem. It wouldn’t be problem if I’d know what data modules need – but I don’t want to restrict them anyhow. I could have handled them all data, but that would unnecessarily increase memory usage. And nothing like calling public properties of instantiated kernel class didn’t work. Passing them by reference didn’t work either. Passing whole kernel by reference like $module->doStuff(&$this); didn’t work. And then…
I know I’m not very good at designing objects and stuff – I lack experience and time to read some of those nice books about design patterns. I didn’t want to use inheritance, because it just wasn’t suitable for my needs – PHP 5 doesn’t support multiple inheritance – and I don’t expect to have just one module. :)
So, when I finally realised that when I call preprocess modules with something like this:
// preprocess arrays stores names of pre-process module .php files
foreach ($this->
;preprocess
as $name) {
//strip .php from end and everything before last slash
$name = substr($name, strrpos($name, "/")+1
, -4
);
//run all modules from the list
$this->
;mod_pre
[] = new $name($this);
}
it gives the pre-process module just what I need – reference to the kernel! Awesome. No extra memory usage, no hassle with determining what data will module need. The only problem I see is that all properties had to be declared as public – and we ruin one of the cornerstones of OOP, encapsulation. But as long as we won’t let any rookie change important kernel properties we have no problem, I think.
So, now my baby CMS can call preprocess modules, which will replace in XSLT stylesheets with all transformations supplied by modules as well as in static XML content files with inclusion of all styles supplied by modules. Isn’t that great?
Permalink
