Welcome to the Pycom forum Forum
    • \[\[global:header.categories\]\]
    • \[\[global:header.recent\]\]
    • \[\[global:header.tags\]\]
    • \[\[global:header.popular\]\]
    • Login

    Explore Pybytes | Official Documentation | Report a Firmware Bug/Issue | GitHub

    Security Hardening

    Scheduled Pinned Locked Moved LoPy
    lopy
    4 Posts 2 Posters 1.1k Views 5 Watching
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • W Offline
      wstallwood
      last edited by

      Hi,

      Looking for tips and references in order to collect a set of good practices to secure our LoPy devices and code (our devices will end up being installed in the public domain)

      Whilst we are aware there is only so much we can do to protect them when the attacker has physical access, it seems there isn't much in terms of documented best practices to achieve this.

      Perhaps if we can collect them here we can get it up in a wiki page at docs.pycom.io

      The key areas I am interested in are as follows:

      WiFi, changing the default WPA password, hidden network option ?
      Telnet/FTP passwords (and disabling the services)
      Options to only store/load precompiled python byte code
      Options to block access to the alternate boot modes.

      1 Reply Last reply Reply Quote 3
      • D Offline
        daniel
        last edited by

        Hello Wayne,

        Thanks for this useful post. I think we need a set of extra functions to disable the safeboot option after deploying a firmware in production, that way you can avoid people from getting easy access to the device. Adding another function to permanently change the default AP SSID and PW is also a good idea. We'll work on that.

        Cheers,
        Daniel

        1 Reply Last reply Reply Quote 1
        • W Offline
          wstallwood
          last edited by

          @daniel Thanks for that, I'll watch out for that and document the hardening steps I am taking here.

          1 Reply Last reply Reply Quote 0
          • W Offline
            wstallwood
            last edited by

            I've finally gotten around to doing a bit more, so I have a utility now on the device we run to "harden" them

            aside from setting some parameters in our code to disable debugging does two things.

            pycom.wifi_on_boot(False)

            (our project doesn't need the wifi radio at all and it better than halves the power consumption on the L01 we found)

            Then it writes the following into boot.py

            import os
            os.dupterm(None)

            Which disables the REPL Console, leaving only the initial boot messages generated by the ESP.

            The only easy way back in then is to short the pins on the module to perform a clean boot.

            1 Reply Last reply Reply Quote 0

            Hello! It looks like you're interested in this conversation, but you don't have an account yet.

            Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.

            With your input, this post could be even better 💗

            Register Login
            • 1 / 1
            • First post
              Last post

            Pycom on Twitter

            Pycom