Part 1: The system.
Introduction:
There can be a number of reasons why a company finds itself owning software and hardware systems that are no longer supported by the original vendor. Reasons may include the original vendor going out of business, or existing contracts may have been terminated due to poor quality or unacceptable project costs. In these situations companies will understandably be keen to protect their investment by ensuring they are still able to maintain and improve expensive systems.
As part of our professional services offering at Welcm Software, we are able to assess your unsupported systems to ascertain the steps required for you to regain control of your investments. This article briefly goes through the steps we typically take with such projects.
Welcm Software’s Process:
One of the more complicated scenarios where we have been asked to help with unsupported software and hardware is for unattended systems, which typically run on dedicated hardware. In these situations we require physical access to the system, which usually requires a site visit including collection of hardware for assessment in our office. For desktop applications and web applications this may not be necessary, and simply a copy of the application or web server login details will suffice.
In the case of custom software and hardware solutions, we carry out the following process (with purely software based solutions after some initial enquiries we usually start at step 7):
1. Assess hardware and peripherals
Typically unattended systems are simply traditional PCs with hardware devices such as webcams or printers, inside some custom housing to integrate the peripherals.
We take note of the makes and models of the hardware and advise on its suitability for its current or potential future use.
2. Determine the operating system (OS) the hardware is running
Usually this will be a version of Windows, either a traditional desktop version or an embedded version. In some cases it may be a linux-based system such as Debian or Ubuntu, or even Chromium/Chrome OS, although this is less common.
3. Gain access to the OS
Unattended systems are usually designed to boot directly into the bespoke software, preventing access to the usual OS features. There will often be a password required to exit the software and use the operating system. If our client has not been provided with any of these logins and passwords from the previous vendor, we can use a number of methods to reset the system passwords to ones specified by our client. In the event there is no OS password set, we recommend setting one and disabling non-essential administrator rights to prevent potential unauthorised access.
4. Assessment and audit of the OS
We check and document the OS version and check for applicable system updates. We make sure the system is secured with the correct administrator and user accounts with appropriate passwords. We document the network configuration and ensure all drivers are up-to-date. We also check the system for remote access tools (such as TeamViewer or VNC) from previous vendors and remove or reconfigure if required.
5. Check network access
We check there are no unexpected processes accessing the network to ensure the system is secure.
6. Check startup applications
We determine which applications are running on boot, this will typically be the end-user facing application and any related processes. This enables us to determine the location of the application, whether it is stored locally on the device or on a server for a web-based application.
7. Obtain application files
If the application is stored locally, i.e. a set of executable files on a device (this could be a desktop/laptop PC, or unattended bespoke hardware), or a web application running on a local web server, we will make our own copy for further analysis. See part two of this article for further information on our process for recovering the application source code from compiled files.
If the application is hosted remotely on a server we will carry out further enquiries into who owns and manages the server. Once we obtain access, we can recover the code from the server.
In both cases, once the application files have been obtained, they are checked in to a dedicated code repository for the client.
8. Document findings
We will create a report for the client on the steps taken, status of the software or system, and recommended actions, as well as documenting all software and hardware model numbers, serial numbers and driver versions.
At this stage, our clients will have a clear picture of the status of their system, and the options available to them to support and improve it.
In the next article we will look at the process when a client wishes to make changes to their software and how Welcm Software can help, whether or not the original source code is available.
