Commander X16

If you're developing I guess you'll mostly be using the emulator, as the debugging experience is going to be better.

That said eventually there are all sorts of possibilities.

RMC's latest video gives some good examples of connectivity via an old (well new) Amstrad CPC. 

 

In modern systems I use an SD card and even thumb drives as more or less permanent storage. But if it was the main way to load programs, I would almost certainly switch it in and out at least weekly or even several times a day if I'm actively developing something.

Still not a deal breaker where ever it ends up.

Quote

However, as far as network security risks go, the risk that somebody will hack WiFi access to a SD board that remains plugged into my CX16 and use it to inject a CX16 virus is somewhere "near" the bottom of my security concerns list.

hihi friend - yes the likelihood of someone p0wning an x16 is very small. the issue is more a broader concern I'm developing around the integrity of my wifi network in general. I've been a back-end generalist/security engineer for a lot of years and I'm presently slogging through an ethical hacker cert so am presently extra paranoid about all things cybersecurity as all the possible nasty that can happen is top of mind. it's one of those nagging back of the mind problems that I don't have enough cycles to deal with and thus have a bit of a knee-jerk emotional pushback response to adding NAS to the mix. I know I should have a firewall appliance installed and need to do some homework to see what routers comcast will support that also have regular firmware updates from the vendor but - job and kids and life and and and keep me under rested, over caffeinated, and always a bit bleary eyed  ? 



That being said - with my black hat on - I wonder if it's not possible to implant something malicious on a wifi-sd card in someones x16 that infects other devices on access (like the internet connected machine one might use to xfer files to the x16). Generally speaking, any machines that are talking to one another are ripe for remote exploit. Might be a fun experiment somewhere down the road ?



*EDIT* 

 

Quote

 sometime before I leave China

I just caught that you're in China. A year of lockdown has me crawling in my own skin to do some traveling. Jealous of your adventure(s) friend! 

 

13 hours ago, snerd said:

That being said - with my black hat on - I wonder if it's not possible to implant something malicious on a wifi-sd card in someones x16 that infects other devices on access (like the internet connected machine one might use to xfer files to the x16). Generally speaking, any machines that are talking to one another are ripe for remote exploit. Might be a fun experiment somewhere down the road ?

...



I just caught that you're in China. A year of lockdown has me crawling in my own skin to do some traveling. Jealous of your adventure(s) friend! 



 

Ah, an ESP32 hack ... IIUC, it would require changing the firmware, since the device itself is just responding to requests coming to it from the LAN. I'd still be more worried about an IOT hack of a wireless security camera than of an IOT hack of an obscure set-up of an ESP32 with firmware to let it serve an file system on SD card onto a LAN.

& yes, I work in China, so the "Emergency" meant I missed last summer vacation back to the US. But over here, the main part of the Emergency was over in the Spring of last year, and while you still have to wear masks to go on buses and subways, and use your health check app to go to some stores and restaurants, the part of the Emergency hanging over is almost no foreign tourists.

The SD location is a non-issue, since those things *shouldn't* be removed continually anyhow.  Wifi SD intrigues me.

If most of the buyers of the X16 are not going to install code more than monthly, then it's a niche problem in a niche product. 

However, it is absolutely easier to develop on the emulator, so that removes a lot of pain.

On the gripping hand, stress and performance testing of your homemade software will have to be done *on* the hardware, probably.

But there's also some random, unsupported possibilities that I think are interesting to think about.

(1) An SD2IEC running on that IEC port.

(2) A custom driver (to *something*) that uses the IEC port.  Probably not practical... but it's interesting since that port is there.  It could completely co-opt the port pins... I suppose the old quick loaders did something like that, didn't they?  In a way, it's easier on the X16, because there's no requirement to handle C64 copy protection schemes. 

(3) A card on the extension bus that does I/O, and a patch that injects a custom driver to make it seem like it's an IEC device of a sort.

(4) Perhaps using the I2C pins for I/O.

 

Quote

Ah, an ESP32 hack ... IIUC, it would require changing the firmware, since the device itself is just responding to requests coming to it from the LAN. I'd still be more worried about an IOT hack of a wireless security camera than of an IOT hack of an obscure set-up of an ESP32 with firmware to let it serve an file system on SD card onto a LAN.

hihi friend -- I get the feeling you're are a person of considerable knowledge. Hope you don't mind my pulling your coat a bit on this as I'm still working on earning my graybeard ?‍♂️ Also - for the benefit of anyone else reading this - none of this is 'in scope' for the x16 team to concern themselves with. The conversation thread took an interesting turn and I'm enjoying the dialogue about cybersecurity with my new, learned, pal ? 



re the attack vector - what I had in mind conceptually was much simpler. Basically the attack I had in mind is a variant of the 'thumb drive in the parking lot' trick. Place something intriguing in the target's path in the hope that their curiosity is piqued enough to access a malicious payload and thus unwittingly get themselves p0wned 

here's what I had in mind: 

* penetrate the target's wifi network

* enumerate the devices connected to the network. this would reveal the SD card but also any computers and (ideally) the OS and build IDs of said computer(s). The attacker needs this in order to craft a payload.

* enumerate the contents of the file system on the SD card and with some googles discover what it's likely being used for.

* whip up a basic reverse shell embedded in something like a self-extracting archive. the nice thing about reverse shells is that 99% of folks out there run with AV only and AV doesn't monitor network traffic in the way something like Glasswire or LittleSnitch will. Moreover, a basic shell-code reverse shell script tends not to get picked up by even up-to-date-AV. If need be I could use something like Shellter to embed a reverse shell inside an executable and get some AV evasion - but for social engineering reasons I suspect a self-extracting archive might be a better way to go. Either way - the goal is to create a file that looks to the target that it's something they placed there, forgot about, and is interesting enough to pique their curiosity to investigate on their win/mac/linux machine.

* place the file onto the target sd wifi card 

* use netcat to listen on a given port (along with a firewall rule that prevents access to that port from anywhere BUT the target IP address to prevent bots and such from mucking up the attack machine) 

* if the filename is sufficiently enticing, the target will see the file and (assuming the x16 can't handle self-extracting archives) will get curious, move the malicious payload back to their internet connected workstation, and extract the contents to see what's there

* voila - reverse shell with at least user-level privilege. 



My question is whether or not a firmware change would be required to execute this attack? My assumption was that it wasn't given that the sd card is being used as the virtual 'parking lot' in which the payload is being left for the target to stumble upon. Very interested as to your thoughts though. 

 

Quote

& yes, I work in China, so the "Emergency" meant I missed last summer vacation back to the US. But over here, the main part of the Emergency was over in the Spring of last year, and while you still have to wear masks to go on buses and subways, and use your health check app to go to some stores and restaurants, the part of the Emergency hanging over is almost no foreign tourists.

The mandated method of testing foreign visitors may have something to do with that ? That being said - glad to hear you and the other folks in your community are healthy and able to get back to some semblance of normal life. China has been on my list of places to spend some time in for a long time. Hopefully things will clear up soon and I can make my first visit ?









 

And here I was, thinking the +WiFi part meant it was acting like a WiFi adapter somehow, but now I get the point - mount the SD card from some other device over WiFi and push files onto it. I'm doing a little reading to find out whether any of these things can actually just join a WLAN and then export a fileshare, or if you must use a client-side app to talk to it.

Yes, sir!  That's the way I hope it works.  

19 hours ago, snerd said:

here's what I had in mind: 

* penetrate the target's wifi network

* enumerate the devices connected to the network. this would reveal the SD card but also any computers and (ideally) the OS and build IDs of said computer(s). The attacker needs this in order to craft a payload.

* enumerate the contents of the file system on the SD card and with some googles discover what it's likely being used for.

* whip up a basic reverse shell embedded in something like a self-extracting archive. the nice thing about reverse shells is that 99% of folks out there run with AV only and AV doesn't monitor network traffic in the way something like Glasswire or LittleSnitch will. Moreover, a basic shell-code reverse shell script tends not to get picked up by even up-to-date-AV. If need be I could use something like Shellter to embed a reverse shell inside an executable and get some AV evasion - but for social engineering reasons I suspect a self-extracting archive might be a better way to go. Either way - the goal is to create a file that looks to the target that it's something they placed there, forgot about, and is interesting enough to pique their curiosity to investigate on their win/mac/linux machine.

* place the file onto the target sd wifi card 

* use netcat to listen on a given port (along with a firewall rule that prevents access to that port from anywhere BUT the target IP address to prevent bots and such from mucking up the attack machine) 

* if the filename is sufficiently enticing, the target will see the file and (assuming the x16 can't handle self-extracting archives) will get curious, move the malicious payload back to their internet connected workstation, and extract the contents to see what's there

* voila - reverse shell with at least user-level privilege.

My reaction to seeing an enticingly named file on the filesystem for the CX16 SD card would be "shoot, I wonder whether someone has put a honey trap in my WiFi SD card, need to increase my network security" and delete it from the CX16 side.

Now, if you smuggled an enticingly titled .PRG on a 28 year old 5.25" disk from back when I was using my C64 regularly, the odds of my copying of my copying and trying to open it in VICE if I would ever be able to read that disk again would be much higher, but then again if you are in a position to find where I have 28 year old disks stored and have the time to set up a 1541 drive and write data into them, you would skip the 28 year old disk and put the malware straight onto my laptop.

Yes, the micro-SD + WiFi access point on the SD board is originally for things like cheap 3D printers that print from a file on an SD card, to give them wireless access without requiring any modification to the printer.

Unlike micro-SD cards, the original SD cards were intended to be swapped on a regular basis, similar to game cartridges in a portable game console, but since that is not as common as it was when SD cards were focused on cameras and such, it is reasonable to be a bit cautious about whether modern SD connectors are as well designed for repeated insertion/removal as the original designs were.