07.27.18

update on compiling sall calcs with gcc for SCD6000

It's been a while since I last worked on this, and today I made my first (unsuccessful) attempt to load a gcc compiled elf onto a SCD6000. In the previous post, I outlined how a sall file can be turned into an elf outside of the RTU Station environment.  The progress made in this post is the small step of using the gcc toolchain from within the RTU Station environment.  This is required, because any points used by the calc need to be parsed and included for the rest of the RTU configuration (these points are stored in the defs.h file, which gets renamed to <calcname>.h).  The details are in on github.

Unfortunately, the first attempt to load an actual file didn't work (the calc shows up in the error state in the RTU).  This is not at all unexpected, and now begins the tedious process of trying to understand why.  This may prove to be quite a challenge, given that we can't really observe the internals of the RTU, but I'll keep chipping away at it.

 

06.16.18

Reverse engineering the innards of System Platform #1 - Packages, Templates, Objects, Primitives and Attributes

In order to try and understand various aspects of System Platform a little better, I have been poking around the inner workings of the software and discovering many interesting things, which I intend to share in a series of posts on the subject.  So here goes with the first one about Packages, Templates, Primitives and Attributes - settle in because it's a long one.

Firstly, we must must realise that the templates, primitives and attributes that we are going to talk about here are not the same as the templates and attributes that we are used to dealing with in the IDE which I will call IDE templates and IDE attributes from now on.

Templates are a base object type, such as $UserDefined, $Symbol, $DiscreteDevice and so on.  This list of templates is in the database in table template_definition, and for example mine looks like this:
Read the rest of this entry »

05.16.18

Reverse Engineering A Mimomax Radio

Sometimes I like mimomax radios, and sometimes I hate mimomax radios.  They are without doubt one of the best radios around for getting the most value out of a 25kHz radio channel.  However they have bugs.  Lots of bugs, sometimes big, sometimes little.  I have spent more time working out why these radios don't work or behave like I would expect than any other radio.  So I decided to break one.  Purely for academic purposes of course.

Mimomax radios have an open ssh port on port 22, and I happened across the root password for one radio in particular.  Unfortunately I can't say how I happened upon this password, but happen upon it I did.  It would seem from observation that the root password for every radio is different, the passwords are 8 characters long and only have lower case letters and digits.

Armed with the root password, one can download the entire file system and inspect the scripts that control the radio and so on.  From this the following information is discovered:

  • A file called passfile is used as an symmetric key for encrypting and decrypting custom scripts, firmware images, and SFE licence files.  We can assume that this file is the same on all radios, because firmware images are not issued per radio like license files are.
  • SFE files are compressed and encrypted sqlite databases (the one called dbsfe.sqlite3), and as such it would be trivial to generate new licenses for a radio.
  • Custom scripts are just a collection of files tarballed and encrypted using the passfile.  Therefore it is trivial for us to create our own custom script files.

In theory then, we could write a custom script to extract the password hashes for the radio which we could crack by brute force.  Using an Amazon EC2 16 GPU  VM with hashcat, we can achieve a md5crypt hash rate of 197.5 MH/s.  To hash the entire keyspace (36^8) of would take about 4 hours, so on average it should take 2 hours per hash, at a cost of roughly $50 USD.

The security of the radio could be increased greatly by encrypting custom scripts and license files using an asymmetric key instead of symmetric key.  This way even though we could decrypt existing scripts and license files we would not be able to generate new ones without further tampering with the radio.  Of course, once you have the root password all bets are off as we can change the keys to whatever we like.  To make cracking the password hashes more difficult, they could also increase the keyspace of the passwords by using upper case characters and making them at least 10 characters long.

 

10.20.17

compiling SALL calcs for SCD6000 without WindRiver

Schneider released the SCD6000 RTU a while ago now, and while it has come with some good improvements, it has also come with a couple of shitty regressions. One of these shitty regressions is the use of the propriety Wind River C compiler for the compilation of SALL files. I'm guessing that this decision was made because Wind River makes VxWorks, which I believe is the operating system that runs on the SCD RTUs.  However because Wind River is based on GCC, and I don't want to pay many thousands of dollars for a compiler I only use a handful of times a year, I wondered if it was possible to use instead the very free GNU ARM embedded toolchain?

Now I don't actually have any SCD6000 hardware to test on, so this is just what I have come up with so far, and hopefully one day I'll get a chance to test it. On the other hand, if anyone out there wants to test this for me then please do so and let me know the results!

First, lets examine the process of how a SALL file is transformed into an elf binary.

  1. SALL file is converted into a C file.
    For SCD5200 RTUs this is done using the sall.exe file, located in C:\Program Files (x86)\Foxboro\RTU Station\utils\CalcsRTU_SALL\<firmware version>\buildsal\. You can run the program from the command line by using the following syntax: sall.exe infile.sal outfile.c errorfile.
    For SCD6000 RTUs this functionality is built into a dll file that is called directly from RTU Station.
  2. Compile and link the files into an elf file.
    For SCD5200 RTUs this is done with the Watcom compiler, and for SCD6000 RTUs this is done with the Wind River compiler. In both cases a make file is used to invoke the compiler and linker.

Read the rest of this entry »

06.30.17

Repairing 'corrupt' ASE 1.x capture files

Recently I captured a whole bunch of data using an ASE V1 RTU test set to trouble shoot a comms issue, with the intention of analyzing the data once I got back to the office. Well when I did get back to the office and tried to open my files, ASE just sat there, blank, looking at me as if I were stupid. I only had one capture file out of a dozen that actually opened and it happened to be the smallest one. I figured that ASE had an issue opening large capture files, so I fired off an email to support asking for haaaaalp.

I was told that there was no issues viewing large files, but that I had likely following the incorrect procedure for capturing files which must be closed properly.  There was no hope of recovering my data.


Read the rest of this entry »

| Posted in Reversing | No Comments »
08.21.14

Everyday useful reverse engineering

I recently purchased a product that required a password to configure it (the product shall remain nameless), and I couldn't find the default password anywhere in the documentation that came with it. Of course, I could have rang support and asked for it, but where is the fun in that?

re password4

So, how to find the password? Our configuration program is called config.exe - so lets see what kind of program it is:
Read the rest of this entry »

| Posted in Reversing | No Comments »