Unauthorized firmware (read: not mine) randomly loaded on one of my Photons

Troubleshooting
1

It appears one of my Photons has had unauthorized firmware loaded on it from the Cloud, while I still own the “claim” on the device. Read below for more.

I have two Photons, one outside running as a weather station, another inside as an indoor temp/humidity sensor. This morning at 7:22 AM (MST), I received notification that the outdoor weather station did the following:

  • stopped reporting to Weather Underground
  • unregistered all variables that my firmware publishes.

I thought it might have just hung, so I went outside to check it and it’s still connected, breathing cyan. Fine, I thought, maybe my WiFi is broken. Checked that too… it was fine.

Then I went into Particle Dev, selected the device, and checked to see what it listed for cloud variables and functions.

It now had no variables listed, showed as online, and what’s more – it had three totally unrecognized cloud functions, that I did not add to my firmware: pubnub, clear, and cal.

I have come to the conclusion that my device has had firmware loaded on it over the cloud that I did not authorize.

How is this possible?

Is there anything I can do with the device right now that would help in solving this issue? I will provide my device ID if needed.

2 Likes
2

That’s very interesting.

Can you overwrite it again? or have you also lost control of flashing it over wifi?

3

I have not attempted to overwrite it at this point, as I was holding off to see if there is any data I can gather for the good of those who may need to address this problem.

I appear to have the ability to begin the flashing process through both Build and Dev, though, so it looks like it would work.

4

Yea I think that is a good way to go for now.

They should have server side logs that show when this happened so there should be a trail as to who loaded your device with their code.

We should ping @Dave

1 Like
5

I have successfully reflashed without any issue, my code is now running on the device again.

I am genuinely concerned that this happened. I thought the whole claim system was meant to prevent this.

6

It should prevent this. This is the first case I’ve encountered in the 2.5 years I’m on here. There isn’t any possibility that you’ve accidentally flashed it to the wrong device? I suspect not, but it wouldn’t be the first time that happened to me, hence the question.
You also have got any access tokens exposed to the public that could be abused?

7

As for your first question: totally good point and an easy mistake to make; but I haven’t even loaded Build or Dev for over a month, much less at 7:22 this morning. I was enjoying a nice Saturday sleep-in :wink:

On your second question:
I have no publicly exposed access tokens, or even Device IDs for that matter; all of them are stored in private files that are never exposed to web clients or committed to source code repositories (and all of my repos are on a private gitlab instance, anyway).

8

What is a lot more likely is that your current code was not running on the device for some reason, but previous code or system code was running and just not calling your code.

If this was a Core, it could be the backup firmware which would generally be the app “Tinker” unless you worked hard to replace it. I have had this happen to me several times in the early days of the core.

If this was Photon, the multitasking mode makes a huge difference and I don’t think we can say more without seeing how you have you code setup.

9

I considered this possibility when I first discovered the issue, but there are some holes in the theory that make it impossible.

Firstly, I looked at the Tinker source code, and it does not publish any of the Particle cloud functions that I discovered that my device had after this occurred: pubnub, clear, or cal.

Secondly, if it somehow recalled an older piece of code that I replaced Tinker with (which I never did), then I have never created code myself that publishes these cloud functions.

What about my code would you like to see to verify that this is not the scenario we are looking at? I have this at the beginning of my code, to enable the system thread.

void startup_functions() {
  System.enableFeature(FEATURE_RETAINED_MEMORY);
  WiFi.selectAntenna(ANT_EXTERNAL);
}
STARTUP(startup_functions());

SYSTEM_THREAD(ENABLED);
SYSTEM_MODE(SEMI_AUTOMATIC);
10

Hi @legoguy,

I doubt someone else flashed code to your device, I’m guessing it’s more likely your app became corrupted somehow due to environmental effects. Please feel free to send me your device id and I can track if / when something was flashed to your device. If you want you can email it to me or PM it to me on the forums (david at particle io)

Thanks!
David

2 Likes
11

I looked into this, it looks like the product_id on his photon is changing frequently for some reason and collided with an organization. His device was loaded with the correct firmware for that product after a reboot. I’m guessing something about his firmware is corrupting his DCT region.

It’s worth noting that we’ve accounted for this from an organizational security standpoint. The org doesn’t encounter any risk as a result, mostly it’s just confusing if someone hits it by accident.

Thanks,
David

5 Likes
12

Hey @Dave, this seems like a good time to ask a question we’ve been having.

The documentation is unclear, but we were under the assumption that two conditions had to be met for the dashboard to upload firmware to a photon

  1. the product_id in the photon’s firmware needs to match the org’s product_id
  2. the photon ID needed to be registered to that org’s dashboard and be assigned to a product and assigned to a ‘firmware version’

How could @legoguy’s photon get firmware from an org’s dashboard if only condition 1 is met? Is it the case that as long as a photon has the proper product_id, it can pull firmware from an org?

13

I have also seen one of my devices that was not assigned to a product get flashed with the latest product code if the firmware it was running had the product_id in it.

14

I think we’re still building quarantine features to support that workflow, but the current behavior is to deliver the auto-update to anything with that product_id.

This is so that the default “worst-cast” is still, your device is your device, instead of it thinking it’s a photon, for example. We’re still adding features and building functionality, so if this is a strong concern of yours, I’d love to get the right people involved internally so we can react quickly.

To start lets ping @bryce and @jeiden who helped develop the product auto-update behavior and dashboard.

Thanks,
David

2 Likes