RISC OS is best known for its stability and performing with very little resource. Things rarely break and unless there’s an application-specific error the operating system will just run until hardware components die. Naturally this makes RISC OS a prime candidate for running a file server that needs to be up 24/7, collecting back-ups and storing important files.
The only limitation with using RISC OS as a file server is it’ll be next to useless in acting as a media server for offering video streaming services to client machines. This is because Unix-like systems that are commonly used for media servers utilise ‘binary blobs’ that can interact at a low level with the Graphics Processing Unit (GPU) making high-quality video decoding easy as pie.
Like a VGA card of old, RISC OS only really considers the GPU to be a framebuffer which means video decoding must be done in software. In theory, serving media files from RISC OS running on a very powerful processor may give positive-ish results, but I wouldn’t want to put it to the test.
When looking around for various file transfer solutions that I could use on RISC OS, my first port of call was SFTP as it’s a protocol I widely use for accessing files on other non-RISC OS systems I use.
A year or so ago on this very blog I also took a look at SSH on RISC OS, which took a look what offerings are available to us to communicate securely with remote systems.
While there are a number of good SSH and SFTP options available for RISC OS, none of them including the port of OpenSSH offer the ability to run an SSH server, so you’re limited to accessing other SSH systems from your RISC OS desktop rather than vice versa.
From what I can also find, all FTP server applications for RISC OS are pretty ancient and are no longer compatible with 32-bit RISC OS.
That leaves me with Samba – it’s widely used amongst RISC OS users and it’s highly compatible with other non-RISC OS systems.
What is Samba?
Samba is a free software re-implementation of Microsoft’s SMB/CIFS networking protocol. It provides file and printer sharing services and is especially widely used on the Windows operating systems. Samba runs on the majority of major operating systems, Linux, Solaris, the BSDs, MacOS, Windows and more. Samba/SMB is usually pre-installed on most Windows, Mac and Linux systems – and can usually be configured to act as a file server with very little effort.
Samba on RISC OS
The latest version for RISC OS is a port of Samba 2.0.2-19990209 for Unix/Linux – versions of Samba 3.6.3 and lower suffer serious security issues but given that RISC OS is an entirely different beast I find it unlikely that Samba on RISC OS will be exploitable. Saying that, I still wouldn’t expose the Samba port (445) past your firewall and to the wider Internet, that’s always a bad idea regardless of if you’re running it on a RISC OS machine.
Samba for RISC OS is also 32-bit and 26-bit compatible, so it will run on the latest RISC OS compatible systems, including the Raspberry Pi.
Advantages of Samba:
- Communicate with Windows and Apple systems on your local network with almost no-configuration (providing file-sharing is enabled on those systems)
- Ability to browse your RISC OS systems’ hard drive(s) on remote Windows, Mac and Linux machines
- Free and open-source software
- Very fast and responsive on a local network
Disadvantages of Samba:
- RISC OS port is of an out-dated version of Samba
- Not a good solution if you want your server to be accessible from outside your home network
- Samba doesn’t utilise encryption, data is passed between systems in plain text
Setting up the Samba server on RISC OS
Samba requires at least 8MB of memory in order to run. Once !smbserver has been downloaded and unzipped into a location on your hard drive, run it and a Samba icon should appear on the left side of the iconbar.
Please note that the latest version of !smbserver (v0.08) relies on you already having version 0.07a installed on your machine. So to install from scratch, download 0.07a and place it into somewhere on your drive, then download 0.08 and drag the !smbserver icon over the existing 0.07a to overwrite it.
Something else to keep in mind when downloading the Samba server application from here, the downloaded files are not pre-configured to show up as Zip files, RISC OS will just show it as a data file. To fix this just middle click on the !smbserver icon and go down to Type, set the type to Zip.
Once run, you can then configure !smbserver so that a remote computer can connect to it remotely and pull or drop files from it. Middle click on the Samba iconbar icon then click ‘Configure’ to bring up the main configuration options, fill in the relevant entries with the details for your specific setup:
Server string – This field allows you to set a name for what your RISC OS Samba share will look like to other machines – e.g. Sion’s RISC OS NAS
- Interfaces – Enter the IP address of your the machine you’re setting up the server on. Running the ‘ifconfig -a‘ command on the RISC OS command line will show you the IP address assigned to your machine – on most home network it will be something like 192.168.0.2. The subnet mask is in /xx notation, with the most common setting being /24 which is equivalent to 255.255.255.0 (ie. 24 bits being masked).
- Workgroup – This is where you can definie what local workgroup you want your Samba server to be available on. In most cases it’s safe to leave it as WORKGROUP.
The other settings can be left as default unless you have a specific need to change them. That’s it for setting up the Samba server itself.
Next we’ll need to configure what drives are available for other machines to access. If you click on the Samba iconbar icon it will bring up your Samba shares, by default yours will be called ‘MyRiscPC’ but if you middle click on it, go to ‘Share MyRiscPC’ hover over to ‘Rename’ then you can change it to something else. This name will be visible as a folder you can browse to when you’re accessing your Samba server from other computers.
Configure a folder to share
The final step is to configure a folder on your computer that will be accessible to other machines who’re connecting to it via Samba.
Unless you configure the folder to be ‘read only’ this folder will allow anyone who’s connected to it to be able to drop files into it, delete files, edit them etc.
In my instance I created a folder on my hard drive called ‘Public’. I then clicked on the Samba icon then the name of my Share to bring up the configuration page for what folder I’d like shared via Samba.
In my example I’m using RPCEmu so the path to my Public folder is HostFS::HostFS.$.Public – if you’re running RISC OS natively then your path will be ADFS::HardDisc4.$.Public unless you’ve configured your hard drive under another name.
Once that’s done, enable or disable any options as you see fit then click OK.
Setup a password
To set a password for your share, middle click on the Samba icon again, go to ‘Share MyRiscPC’ then hover over to ‘Set Password’.
Unless you’ve specifically configured your router’s firewall to allow port 445 to be accessible past your local network, then this Samba server will only be accessible to other computers on your network.
In most cases it’s safe to leave your share open with no password, as it’ll only be users on your home network that can look and edit files in your shared Samba folder.
Configure Samba to run on boot
As a last step, you’ll most likely want to ensure that !smbserver automatically runs whenever the machine boots into RISC OS just in case of any unexpected reboots.
Editing the ‘PreDesk’ configuration file located here will provide this functionality – !Boot.Choices.Boot.PreDesk
Local network configuration
If you want to access your RISC OS machine via Samba from an external network (your work’s network for example) then you’ll need to enable the firewall your Samba server is passing through to allow connections over port 445 TCP . With most setups this can be achieved by adding a port forwarding rule in your router’s firewall to allow TCP connections over port 445.
Should you decide you don’t require access to your Samba server from an external network – for example, you only need to connect to it from devices in your home, or you use a VPN connection to remotely access your network remotely – then you don’t need to do anything, traffic should pass over port 445 without a problem unless you have device-specific firewalls blocking this port (you’ll probably know about it if this is the case).
Accessing your Samba server from other computers
Accessing your RISC OS Samba server from other computers is pretty easy. All major operating systems will allow you to access a Samba server on your network directly from your file manager.
Windows – On Windows, it’s just a case of clicking onto ‘File Explorer’ then clicking the ‘Network’ option on the left side of the window.
If you click onto your RISC OS computer’s name, in my screenshot it’s 192, you’ll then see the folder you’ve told !smbserver to share there, in my case it’s called ‘RISCOSBlog’.
If you’ve set a password on your Samba share then you’ll be prompted to enter it when you attempt to click into the folder.
Mac OS – On a Mac it’s just a case of bringing up ‘Finder’ and navigating down to ‘Shared’ on the left side of the window. There you’ll find your Samba server that you can click into and access just like you would a part of your hard drive.
Linux and other Unix-like systems – Methods of accessing Samba shares on Linux and other Unix-like operating systems vary but in the majority of cases it’s just a case of going to your file manager application and navigating to the section that allows you to look at other computers on your network.
Automation – Automating file uploads to your Samba server is also possible. Say for example you want all your computers to send backups of themselves every night to your RISC OS file server. Ways of doing this vary between operating systems, it’s possible to do this with a basic scripts on Linux/Unix systems.
Modern versions of Windows allows you to do this by going to the ‘Backup settings’ utility and configuring your system or certain folders to back up to your Samba server at specific times.
There we have it!
You now have your RISC OS system configured to act as a file server for other computers and devices on your network. Desktops, laptops, tablets and phones will be able to use your Samba server as a central hub for dropping in files, documents, backups etc.
If you’ve been keeping an eye on technology matters in the last few years you’ve more than likely heard the term ‘Internet of Things (IoT)’. It’s widely used to describe embedded ‘smart’ systems, usually running some form of Linux, that are connected to the Internet.
In this article I’ll be talking about systems that are accessible to the Internet or web-facing, what I mean by this is computer systems that are running services (e.g. a web server) that are not sitting behind a firewall (just on some ports, or all ports) – and thus anyone on the wider Internet can visit it.
Also, it goes without saying that everything discussed in this article is for educational purposes only, this is all publicly available information that is good for researching into what people are putting on the Internet and what risks they’re exposing themselves to.
These days everything is moving towards being Internet-connected, CCTV cameras, light bulbs, fridge freezers and even kettles. They’re hooked up to the web to allow for convenient features such as being able to control what lights are on in your home or to stick the kettle on while you’re on the way back to your house.
Problems arise however when these features are implemented poorly, and in a lot of cases the security of that smart device is nothing but an afterthought. A lot of these come with already outdated versions of Linux or BSD as well as out-dated versions of services such as OpenSSH, Samba etc. This exposes these systems to known security vulnerabilities that are fixed in later versions, but in a lot of cases, the device manufacturers won’t issue any updates because afterall, they’ve got your money already.
There are a number of responsible manufacturers out there, mainly large brandnames, but the sheer volume of cheap IOT devices being churned out from places like China is staggering.
Now that’s just for consumer equipment. There’s also a huge amount of enterprise and industrial systems accessible on the Internet. CCTV systems, SCADA systems, power plants, hydro-electric powerplants – you name it, someone’s most likely stuck it on the Internet. Similar to the consumer-grade kit I discussed above, a scary amount of these systems are running outdated versions of Linux and Windows – and the same goes for the services they’re running on them.
What seems to be a more common trend with enterprise and industrial systems however is poor firewall management. Consumer kit is generally plugged into a router, which then routes the device through a firewall and blocks anything you don’t need exposed to the Internet. This isn’t usually the case with industrial and enterprise stuff, I’ve seen a lot of instances where a system has been introduced to the Internet and presumably either routed through a poorly configured firewall or it’s not going through one. The result is you have services that are designed only to be used on a local network exposed to the wider-Internet. Bad news.
Samba/SMB is a good example of this, there’s a horde of systems out there that have no authentication required to access the contents of its drives – and through sheer stupidity the port used by that service, in SMB’s case port 445, is exposed to the Internet and not hidden behind a firewall. That results in anyone who goes looking for it to be able to map that drive to their system, and access anything on it, or even put anything on it.
What is Shodan?
This is where Shodan ties in. Historically finding web-facing systems other than web servers was a time-consuming thing to do, there are tools such as Mass-scan out there that allow you to scan IP ranges or the entire Internet across all ports or just some ports. This takes a long time to do with standard systems and Internet connections. There are some researchers out there that can scan the entire Internet for an entire port in a few minutes, but that’s using tailored systems connected to mammoth Internet connections.
Shodan is a search engine for finding specific devices, and device types, that exist online. It works by scanning the entire Internet and parsing the banners that are returned by various devices. Using that information, Shodan can tell you things like what web server (and version) is most popular, or how many TFTP servers exist in a particular location, and what make and model the device may be.
Although there are APIs and smartphone apps available, Shodan is primarily a website that you can just visit and search for particular devices. It’s not quite as simple as googling for the term ‘webcams’ or something similar, you have to know what you’re looking for.
Shodan does work through Netsurf on RISC OS, asthetically it does look a little off when compared to a browser on another OS – but from a technical perspective, it works just fine.
Know what you’re searching for
You can use Shodan to search for what particular ports are open on a specific IP address. In the screenshot above I’ve taken the IP address of the RISCOSBlog’s web server and entered it into Shodan’s search bar. It’s then given me information on where the server is located, who hosts the server and what widely used ports are open. Shodan doesn’t scan the entire Internet for every port, as that would a herculean task, instead it focuses on the most widely used ports used by web-facing servers.
The interesting searches on Shodan come from looking for interesting things you can find rather than just searching for open ports on an IP address. As Shodan works on the header output a system will chuck out when you query it, you’ll need to have an idea of what the headers for the systems you want to find contain.
An example being, if I use the ‘netcat’ tool on a FreeBSD box I use, I can query my file-server on port 22 (the SSH port) to see what version SSH I’m running, it’ll also tell me what operating system I have to. In the below example my file-server is running on local IP address 192.168.0.2
nc 192.168.0.2 22
The SSH service on that box has been kind enough to tell me that it’s running version 7.2 of the OpenSSH server software and it’s running on the FreeBSD operating system.
I can then take that output and query Shodan for ‘OpenSSH_7.2’. It then gives me a long list of IP addresses that have that version of OpenSSH public to the Internet as well as statistics on what it’s found.
In in this instance, it’s found 88,560 public-facing systems with that version of OpenSSH. The majority are in the United States, and the most popular OS running that version is FreeBSD.
This is all very interesting if you’re curious, but this is where keeping all your systems up to date really comes in, because if I can identify a version of a particular service, say SSH, which has an exploitable-vulnerability in it, then I can search for that vulnerable version of SSH on Shodan and it’ll output a list of potential victims should I want to do something nasty.
As with any search engine, Shodan works well with basic, single-term searches, but the real power comes with customised queries.
Here are the basic search filters you can use:
- city: find devices in a particular city
- country: find devices in a particular country
- geo: you can pass it coordinates
- hostname: find values that match the hostname
- net: search based on an IP or /x CIDR
- os: search based on operating system
- port: find particular ports that are open
- org: specify a particular ISP or organisation name
- before/after: find results within a timeframe
An example of filtering search queries to find what you want is: I know that the HTTP headers for systems that are running the Emby media server software will come back with ’emby’ in the name of it. So by using the below search term I can query for all Emby servers in the UK that have BT as their Internet Service Provider (ISP).
emby country: “GB” org: “BT”
Again, from a research perspective this is all pretty interesting, you can see there’s 12 systems running on BT Internet connections that have Emby running a port that Shodan scans (most likely 80 or 443). Emby defaults to port 8096 which isn’t scanned by Shodan so the vast majority won’t be visible.
If you were a bad guy however, then by researching the server software you’re querying for in Shodan, you’ll be able to pick up vulnerabilities you can exploit quite easily.
Emby for example, comes with authentication disabled by default. So there’s a good chance that at least some of the IP addresses in the list are probably running Emby instances that you can just log into without being asked for a password. A lot of users will set up a service and once it’s seen to be working, they’ll leave it rather than think about if it can be accessed by anyone else.
That’s reasonably harmless when you’re talking about a media server like Emby, but if you apply this logic to Telnet servers, MongoDB servers etc. then you’re starting to look at systems that have serious vulnerabilities in them. It would be trivial to search for MongoDB databases (again another service that defaults to no authentication) and then do whatever you want with the data it stores.
Other useful aspects of Shodan
You can use the “Explore” button on the main Shodan site to look at common searches and results, which are interesting and also pretty scary at times. You’ll find things like:
- SCADA systems
- Traffic lights
- Power plants
- Point of sale systems
- Industrial control systems
- Systems with default passwords
Here are a few other cool things you can do:
- Data Export: You can export your results in various formats using the top menu after you’ve performed a search.
- Browser Search: You can configure your browser to search Shodan when you search from the URL bar. Not compatible with any RISC OS browser.
- Shodan Free Account: You should create and log in to your free account when you search, as the interface is pretty nerfed if you don’t, e.g. not being able to see host information, etc. Search results are limited to a few pages for free accounts.
- Premium Accounts: A premium account is a one-time payment and it gives you increased access to the API and allows you to pull much more information than the free account will allow.
What have people found on Shodan?
If you start targetting specific services like known webcam makes or the VNC port 5900, you will start coming across systems that people have unknowingly left publicly accessible due to poor firewall management or by forgetting to setup authentication.
It’s worth noting that although these systems are, just like a HTTP website, openly accessible, it means that viewing only does not constitute unauthorised access – but intentionally messing with systems to cause damage or anything like that could end you up in legal hot water.
A number of security researchers are constantly finding interesting things on the Internet, a lot of them are things that definitely should not be exposed to the public, and some even allow you to mess with them.
Well-known security researcher Dan Tentler, who talks about the things he’s found on Shodan in this video, has found systems from hydro-electric plants to Internet-connect crematorium panels that allows you to control the furnesess.
It’s presented in 16 millions colours and is written using Amcog’s very own AMCOG Development Kit – which is also available for purchase.
The game itself involves you, a Cyborg treasure hunter, attempting to penetrate Castle CyberDroid on your quest to thieve ancient treasures from under the noses of hordes of security robots that are teleported into nearby rooms with a view to spoiling your fun.
To make things worse, if you spend longer than 30 seconds in any given room then a holgrammatic energy field aptly named ‘Buzz’ will activate and give you a nasty shock.
The overall aim of the game is to collect all of the treasures on each level before heading to the teleport – and then presumably selling your ill-gotten gains on eBay.
Cyborg comes with 7 level maps consisting of 112 screens and 5 especially made music tracks to go with it. As with all of Amcog’s games, the game’s audio has received a lot work – all sound effects are provided by the RDSP virtual sound chip that generates synthesised sounds in real time.
Since it’s release, a free update has been issued to all Cyborg users with improved graphics and animation, as well as improvements to the sound effects and a few additional levels to play. For more details on what the v2.20 brings to the table, have a read of Amcog’s press release.
As you’d expect from a game influenced on the original Cybertron, the game has a definite retro feel to it – and the music definitely ties in with this. At times I found myself being reminded of a cross between the Botkiller series from Artex Software and Moonquake.
Cyborg incorporates multiple types of enemy robots that come along throughout the various levels to spoil your fun, there’s also several power ups that you stumble across from time to time, these include smart bombs, freeze, local transporters and bonus lives.
The game’s controlled through the standard WSAD keys on the keyboard for moving up, down, left, right etc. The arrow keys can also be used as well as an alternate configuration of z & x for left and right, with @ & ? for up and down. The game’s response to your keyboard input is sharp and responsive, which turns out is pretty key for a game of this nature considering that I spent a good chunk of time dancing out of the way of charging enemies and other nasties.
Playability-wise, the game’s levels are not particularly long in length, but the game’s difficulty definitely makes up for that. There’s a definitive learning curve to begin with, but once you’ve become used to the mechanics of the game and when to time your runs past enemies then the game begins to flow nicely.
The game is a digital purchase via the Pling Store. The process is quite easy, if you haven’t used the Pling Store before, you just need to download the application itself, unzip it and place it wherever you want on your computer. Once run, you’ll need to register or login to the Pling Store, the registration process took me a few minutes when I signed up a few months back and as far as I’m aware all information including card information is kept locally on your computer rather than in a data center somewhere.
The game should play fine on a vast majority of RISC OS machines, be it legacy 26-bit computers or 32-bit machines. It was designed for use on Raspberry Pi and similar modern machines but it should work fine with older systems.
Overall, Cyborg is a solid and well-authored game. It successfully delivers that retro platformer feel Anthony at Amcog has worked to achieve. If you’ve got a tenner ear-marked for procrastionation material then spending it on a copy of Cyborg isn’t a bad shout.