Friday, August 21st 2015

MBE ECU DIM Sport Key Decryption
posted @ 4:07 pm in [ Cars -Decryption -Fixing Things -PHP -Technology ]

I’ve recently started investigating into the working of the MBE ECU (Engine Control Unit) that runs the engine and fuel mixture on my TVR Cerbera and as part of the process took my own ECU out of the car to see how it was setup, and what version of the software it was using

On inspection my own ECU seemed rather different than the test unit I had bought from eBay, as the EPROM that contains the program code was piggy-backed off of a daughter board rather than being directly connected to the ECU motherboard

As you can see from the picture below the daughterboard plugs in in-between the ECU and the code EPROM



and if we actually take the EPROM and daughterboard out of the ECU you can see that the daughterboard has an ATMEL F16V8BQL electronically programmable logic device in circuit



So the ATMEL F16V8BQL basically can be programmed like a small computer to do something with data that comes through it’s inputs, and then send this data back out of it’s outputs

Therefore the next logical question would why would you want to do that when normally the data from the EPROM is sent directly to the ECU for reading?

We’ll it turns out that basically it is a decryption device for taking encoded data stored on the EPROM, decoding it in real time, and then sending this to the ECU as unencoded data to run with

Taking the EPROM out of it’s daughterboard you can see it’s made by “DIM Sport, Electronic per motori” and is labelled as Key 1010A


On investigation DIM Sport are an Italian engine calibration specialist company who make rolling road tuning systems for cars and other vehicles and Key 1010A is sold as part of their rolling road kit

So let’s try and work out how this works by reading the EPROM on it’s own (encrypted) and with it’s daughterboard installed (unencrypted)

As you can see from the Hex dumps below, the daughterboard is doing some data decryption in between


If you compare the first 16 bytes of the encrypted versus the unencrypted you can see that there is a pattern between the two


04219402 C4C10FC4 9501C4C1 0FC49501


01249102 C1C40FC1 9504C1C4 0FC19504

Every second value is being changed between the two, but the first value is always exactly the same

Originally I thought this was a pattern based cypher, so basically something like

0, -3, 0, +3, 0, -3, 0

but if you look at it visually you can see it is actually a substitution based cypher as every time on the ASCII display you see an ‘!’ symbol on the encryption version, or the unencrypted version it is a ‘$’, the same for the letter ‘t’ being a q

So that leans to being a substitution cypher, so we basically just need to work out the mapping of which letter to which, and then we can begin to reverse engineer the encryption

Here’s my map I made as I was doing it for reference (and you can see the original pattern test sequence there too) πŸ™‚


Now lets test our theory and translate the first 8 numbers (the numbers mapped are in brackets, every even number)

04219402 = 0(1)2(4)9(1)0(2)

Perfect! So now we have the sequence let’s write a decryption program to read the original encrypted binary EPROM dump, decode it, and then write out an UNENCODED EPROM dump for us to use in our ECU and no longer require the key

I’ve written it in PHP as that’s currently where I am spending most of my programming time at the moment, and uploaded it to my GIT HUB account here

So if you find one of these in your ECU, or you want to backup your own ECU software feel free to use the above, which because I didn’t reverse engineer any hardware, doesn’t normally break any software licensing rules πŸ™‚

Wednesday, October 24th 2012

Decoding $_F=__FILE__;$_X= Encoded PHP Files
posted @ 7:27 am in [ Decryption -Fixing Things -Magento -PHP -Technology -Web Design ]

Some PHP files we get from Extension developers for Magento have Bytecode encoding on them, which means if we want to change the functionality or layout of certain parts of the code, even if we’ve paid for it, we can’t.

Obviously this is rather frustrating, however it is possible to reverse engineer the files as follows to make the changes you need.

1. The three component parts

Each file has 3 main parts to it:




These parts are as follows:

$_F - a holder to do the ereg_replace of the obfuscater code with the unencryption keys

$_X - the encrypted PHP code

eval(base64_decode() - the decryption code for $_X

2. Getting the decryption code

To get the decryption code, we need to change the eval(base64_decode()); code to be an echo instead.

In our case above this would be:


and this gives us the decryption code for the main $_X values;


If we break this apart into it’s core lines we have:

//decode our main string with base64_decode

//replace obfuscater characters in the result with the correct ones

//replace the contents of $_R with our unencrypted file/PHP code

//run the contents of the unencrypted file/PHP code

//clear the contents of $_R so you can't access it

//clear the contents of $_X so you can't access it

3. Decrypting the encoded code

So now we just need to run the decryption code as far as it replacing the contents of $_R with the un-encrypted result, and echo that out to the screen.

Here’s the code:

//decode our main string with base64_decode

//replace obfuscater characters in the result with the correct ones

//replace the contents of $_R with our unencrypted file/PHP code

//print the contents of the unencrypted file/PHP code

4. Final code

So we end up with:

And we can now make the changes we need

Wednesday, May 2nd 2012

Extending core events in concrete5
posted @ 7:09 am in [ concrete5 -PHP -Technology -Web Design ]

We’re building all of our content based sites on concrete5 as it fits in with our LAMP architecture and Zend Framework architecture which we implement a lot with our Magento eCommerce websites.

The platform is ready to go out of the box, but it’s a bit hard to find how to do what you want sometimes so here’s how to extend the core events (add user, login etc.) with your own code

1. Extending the core events

Events are extended using the /config/site_events.php file and contain the event you want to extend, along with the class and method you want to call when this happens, and finally the model that contains that information

Here’s my example extending the user add event, and calling my own class ‘ApplicationUser’ and the method (function) ‘setupUserJoinInfo’

Obviously you only need the PHP tags the first time you create the file and you can overwrite many events in the same file.

2. Create your class

New file outside of the core, so we’re going to create /models/application_user.php and add in our basic class definition

3. Create our method

So in my case I'm going to hook into my method 'setupUserJoinInfo' pass it the new user object (as we know this is being triggered by the 'on_user_add' event)

class ApplicationUser extends Object {

* @param User $uI
public static function setupUserJoinInfo($ui) {
/* Your own code goes here */

4. Make it do something

In my case I wanted to email the user a one time hash password when their account was registered so I used the User object and the Mail object with a template in the '/mail/' folder called 'account_creation.php' (you can borrow the hash generation code from the core user.php file/class)

It's not that scary once you get your files installed and the Helpers for Mail and Users make it pretty flexible. Good luck!



1. System events

2. Helpers -> Mail

3. Permissions -> Users

Monday, November 7th 2011

NGinx not compressing CSS and Javascript
posted @ 8:11 am in [ Fixing Things -Javascript -Magento -PHP -Web Design ]

Another challenge to catch-out the unwary, is that the latest CentOS/RedHat YUM repository version of NGinx, the fantastically fast web server we use for Magento, has some case scenarios where even though it should be compressing CSS and Javascript, it simply doesn’t!

The reason why seems to be that most definitions for what types of files NGinx should compress posted across the forums of the web, include the “text/html” type, such as:

gzip_types text/plain text/html text/css application/json application/x-javascript text/xml application/javascript text/x-js;

Now the problem with this seems to be that NGinx throws a simple warning that it has already got “text/html” defined as it does this by default, however what it then doesn’t tell you is that it IGNORES all the other definitions that come after it in the same line.

So what that means is that if you have the line above in your config file, even though you are defining for example “text/css” as being a file type to compress, NGinx will ignore this as it stops reading the line as soon as it hits the “text/html” double definition.

To fix, remove “text/html” from your line (*and while you are there you might as well just define the types we are using) and it will all work again.

Here’s my line for reference:

gzip_types text/css application/x-javascript;

Friday, September 23rd 2011

Upgrading Magento 1.5 to 1.6 – the gotchas
posted @ 3:46 am in [ Magento -PHP -Web Design ]

Magento upgrade time again, and as normal it should be really easy, but there are as expected a number of snags that come across the way so here’s the (pretty much) definitive way of how to do it and how to fix the problems/errors/snags that happen as you do!

1. Start with the official Magento upgrade guide at the link below

2. If when running your ./mage mage-setup you receive the following error message:

PHP Fatal error: Uncaught exception ‘Exception’ with message ‘Invalid login credentials’ in /path-to-your-website/downloader/lib/Mage/Connect/Ftp.php

then you have the incorrect ftp details for your site configured.

To fix this edit /path-to-your-website/downloader/connnect.cfg and change magento_root to your webserver/downloader directory and remote_config to you username/password and webserver root directory

3. If you initial page load after upgrade fails with the following error:

SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry during upgrade

Then you need to remove constraints from your database as per the advice here which for reference involves changing your app/etc/config.xml file so that the existing initstatements change from:

<initstatements>SET NAMES utf8</initstatements>


<initstatements>SET NAMES utf8; SET FOREIGN_KEY_CHECKS=0; SET UNIQUE_CHECKS=0;</initstatements>

Another alternative is to remove the problematic line from the SQL upgrade script which is probably much neater [and we did both just in case]. Details of how to do that here and for reference you have to:

edit “app/code/core/Mage/Sales/sql/sales_setup/mysql4-upgrade-” and comment out the command starting on line 753.

4. Final ‘gotcha’ is that your JS and CSS files can refuse to load, and instead start trying to use your path-to-your-website as their root path, rather than the / path that they should do.

This seems to be due to permissions on the /path-to-your-website/media/ directory which Magento wants to write to, so make sure that the web server has write access here (normally a recursive permission change to allow group writes should do the thing and for reference that is:)

chmod -R g+w media

5. Clear your cache (safe way to do this is to change directory into your var directory and remove *, else if you include a /var in your statement you’ve wiped half your operating system if your dangerously logged in as root or su’d up!!)

cd var
rm -rf cache/* session/*

6. Good to go

Now the final thing is to fix any bugs in your themes – we found some new fatals in the Navigation skin due to not checking for parent/children objects being null – so you may get a few of those too. You can fix those with a

if($_categories != NULL) {

and matching closing } for the if statement

7. More references

A good support thread for this is on the Magento boards here

Wednesday, June 15th 2011

Fixing TimThumb for PHP 5.3
posted @ 8:01 am in [ Fixing Things -PHP -WordPress ]

The latest version of PHP 5.3 deprecates the ‘ereg’ function, which generates errors that break programs such as TimThumb, the automatic image thumbnail generator.

To fix this, replace the existing ‘ereg’ expressions with alternative functions as per below:


if (ereg(‘http://’, $src) == true) {


if (strpos (strtolower ($src), ‘http://’) !== false || strpos (strtolower ($src), ‘https://’) !== false) {


if (ereg($site, $url_info[‘host’]) == true) {


if (strpos (strtolower ($url_info[‘host’]), $site) !== false) {

and you are all good to go :->


Friday, August 20th 2010

Magento Site Performance
posted @ 8:57 am in [ Apache -Fixing Things -Hosting -Magento -Media Temple -PHP -Technology -Web Design ]

Magento the nice Community Version available e-commerce platform that we are using at Skywire for a number of our client builds is incredibly feature rich, but with all of these features comes the trade-off that to get any kind of speed out of the system you either need SERIOUS server hardware, or an awful lot of performance tuning.

To be honest it can run like a real dog if you don’t really work at it!

Well we like to make things work hard at Skywire so went on a journey of discovery on how to make Magento fly, and here’s our understandings to share with everyone else.

1. Server software selection and tuning

Lots of articles out there about this around the web, but you can sum it up in a few points really.

– What webserver (Apache vs. Lighttpd vs. Nginx) and how many threads for that webserver you need. Interestingly, against every article out there, Apache 2 was faster for us that Lighttpd and NginX but I think this was to do with the PHP CGI access the other two were using being slower on our Media Temple server

– Fine tune your mySQL database – we found that the two great scripts mysqlreport and mysqltuner are your friends here

– Get rid of any other processes you don’t need that get in the way (xinetd, spam assassin etc.)

2. Turn on lots of Caching

Magento has caching so turn that on for starts, and then get a minify type plugin (there’s lots of them out there but ) to complement that and join all of your CSS and JS into a single compressed file.

Install a PHP Byte Code caching system to cache any code generated by PHP – we used XCache as it was available via yum but eAccellerator gets good reviews too [although it just hung in our environment].

3. Turn on the Page Compilation feature in Magento!

Yes, I know it’s labelled as Beta, and yes I know it falls over most of the time you run it, but if you run it from the command line, as the same user that owns your web files then it works just great creating a new single directory in /includes/src containing flattened files of all your Magento files with the naming format directory_directory_etc_filename.php

This shaved at least 1 second off of every page load for us (amazing but true) however was a job to install as it ignores any modules installed in /app/code/community.

No worries though, you can work around this by just copying the whole module directory to the /app/code/local directory and rerunning the compiler and then it works great.

4. Load you Magento cache directories into a memory filesystem

Sounds a strange thing to do but you can load your /var/cache/ directory into a memory based ‘tmpfs’ which makes it much faster. Also you can move your sessions to your database instead however this slowed things down for us so we left them as files.


So once you’ve done this on a mid-spec Media Temple DV server you can reduce page times from about 10 seconds down to just over a second, which believe me seems fast compared to how clunky Magento can be when running. Have fun!


Magento performance and optimization

How do I use the inbuilt magento profiler to see bottlenecks?

Magento Compiler – Improve your performance

9 Methods to Speed Up Magento – A Guide to Making Magento Faster

Magento performance hosting

Magento Site Performance Optimization

Performance is Key! – Notes on Magento’s Performance

Friday, June 18th 2010

The dangers of $REQUEST_URI ….
posted @ 3:09 am in [ osCommerce -PHP -Technology -Web Design ]

One of the recent reasons we were failing PCI compliance with some of our sites is because our forms that submit to themselves, namely those with code in the top and html in the bottom, use the PHP $REQUEST_URI to use their own URL as the action for the form to POST back to.

Now… the reason this is dangerous is because it includes all the query string parameters too so if you add code after the query string it includes it in the page = BAD

So…. how do we fix it?

The trick is to use the parse_url() function in PHP to ONLY grab the main path of the page itself rather than all the query strings.

So if we use

action="<?php echo parse_url($REQUEST_URI, PHP_URL_PATH);?>"

then we fix the security loop hole above and happy days πŸ™‚

Additional: If we want to get the complete URL just without the query string we can tokenize the string using strtok as follows:

action="<php echo strtok($_SERVER['REQUEST_URI'],'?');?>"

Wednesday, March 10th 2010

More Plesk 9.2.3 PCI Compliance fixes on CentOS 5
posted @ 8:38 am in [ Fixing Things -PCI Compliance -PHP -Technology ]

Plesk is a right pain when it comes to having your site successfully audited as being PCI compliant, as it has it’s own versions of everything that it uses that you need to patch/fix/SSL upgrade or disable.

Luckily most of these are started with the xinetd daemon, so for SMTPS certificate problems (port 465 if my memory servers me correctly) simply create a folder to move the ones you don’t want into (in my case I used /etc/xinetd.disabled) and move the following files out of /etc/xinet.d

mkdir /etc/xinetd.disabled
mv /etc/xinetd.d/smtps_psa /etc/xinetd.disabled/.
mv /etc/xinetd.d/submission_psa /etc/xinetd.disabled/.

and restart your xinetd

/etc/init.d/xinetd restart

Then the last tasks should be to create valid SSL certificates for the Qmail and disable weak SSL ciphers in Plesk.

To disable weak SSL ciphers in Plesk edit the Plesk config file and add the following line


ssl.cipher-list = “TLSv1+HIGH !SSLv2 RC4+MEDIUM !aNULL !eNULL !3DES @STRENGTH”

so the file will now look like this

include_shell "/usr/local/psa/admin/conf/"
ssl.cipher-list = "TLSv1+HIGH !SSLv2 RC4+MEDIUM !aNULL !eNULL !3DES @STRENGTH"
index-file.names = ("index.php")

Creating Qmail self signed SSL Certificates is best illustrated at the following guide

How to create a self-signed SSL Certificate
How to find out which process is listening on which port
port 8443 medium strength SSL ciphers in Plesk
Generating QMail SSL Certificates

Monday, January 18th 2010

Confusing SSL with mixed IP addresses
posted @ 8:21 am in [ Apache -Fixing Things -Hosting -PHP -Technology ]

SSL throws a weird error in that if you have http (port 80) bound to one IP address [say an internal one] and you bind https (port 443) to a different IP address [say an external one] then SSL throws the following very undescriptive error:

SSL received a record that exceeded the maximum permissible length.

(Error code: ssl_error_rx_record_too_long)

To fix, edit your Apace configuration file in /etc/httpd/conf/httpd.conf (or similar) and make sure that both virtual hosts have the same IP address – job done πŸ™‚

references: here and here