How can I hide my codes?

When I download my main.py to openmv3,anyothers get it and connect it to PC can see my main.py.
It is dangerous if I put openmv3 into my product.
Any suggestions?

Hi, we plan to roll out the ability for you to use frozen MicroPython code soon. This will let you compile the code into a byte image that we’ll be able to read.

Note that anyone can easily reverse engineer the byte image to get some ugly source code… But, in general folks won’t.

What’s the ETA on you needing this feature?

I used to use STM32 MCU and download my codes with .bin or .hex file.
So I think my team will not work hard on it if they know the sourse code will be so easy to be copied.

If you feel like editing the STMCUs C code you can disable the flash file system and hard code your script to be main.py by editing our main.c method. After which you can set disable debug access and your code can’t be copied then.

Do you need instructions on how to do this?

I need your instruction,thanks!

Okay, let’s do this one step at a time:

1st - Get the firmware build system running: Home · openmv/openmv Wiki · GitHub. Let me know once you’ve got the M7 firmware compiling.

2nd - Replace main.py with your script here: https://github.com/openmv/openmv/blob/master/src/omv/main.c#L77. The script will now be created on the uPy flash drive on startup and run then.

Once you can get past these two parts when when you program a new firmware image your script runs then we’ll just need to disable the USB flash drive code such that it returns all zeros: micropython/storage.c at 5f79f0f9311d09a2d4f8ab31ce34681586f81761 · openmv/micropython · GitHub. I.e. make sure these memcpys all write zeros.

The above fixes will prevent the user from seeing the clear text code. But, it can still be seen by dumping the flash. The disable that you should write to the STM32 registers than disable flash reading access from debuggers/DFU etc. When you do this then I user must mass erase the chip to read the code off of it. See the programming guide here:

http://www.st.com/resource/en/reference_manual/dm00224583.pdf

See chapter 3.5. You can write to any memory address in your script via the STM32 module or just do it in C.

I was able to build my own main.py but I can’t disable the USB file system, here’s my code:

bool flash_bdev_readblock(uint8_t *dest, uint32_t block) {
    uint8_t buf[FLASH_BLOCK_SIZE];
    // non-MBR block, get data from flash memory, possibly via cache
    uint32_t flash_addr = convert_block_to_flash_addr(block);
    if (flash_addr == -1) {
        // bad block number
        return false;
    }
    uint8_t *src = flash_cache_get_addr_for_read(flash_addr);

    memset(buf,0x00,FLASH_BLOCK_SIZE);
    //clobber the src
    memcpy(src, buf, FLASH_BLOCK_SIZE);

    memcpy(dest, src, FLASH_BLOCK_SIZE);
    return true;
}

When I download the firmware.bin, upon restart I get message on the PC saying the USB file system needs to be formatted, attempting to format it result in failures and my main.py does not run.
Any ideas what I’m doing wrong? I’m making sure the src is ALL ZEROS “memcpy(src, buf, FLASH_BLOCK_SIZE);”

Hi, this is a 3 year old topic.

Please provide context on what you changed.

Don’t edit storage.c, if you want to disable USB storage just comment this line main.c:

https://github.com/openmv/openmv/blob/master/src/omv/main.c#L646

pyb_usb_dev_init(pyb_usb_dev_detect(), USBD_VID, USBD_PID_CDC_MSC, USBD_MODE_CDC_MSC, 0, NULL, NULL);

That should be enough to disable USB storage.

Hi Nyamekye,
Thanks to you and Ibrahim for your help on this matter…
We have compiled a firmware.bin that contains a custom main.py, our goal is to integrate your openMV into our product and prevent access to or expose the main.py in the openMV internal file system.
If I understand correctly 3 steps are needed to accomplish:

  1. compile a firmware.bin that contains a custom main.py
  2. disable the USB flash drive code
  3. write to ST registers to force flash erase
    Step 1 is working well, step 2 did not work( using the method you provided 3 years ago ), I’m going to try Ibrahim’s suggestion ( disable USB storage in main.c instead of storage.c ) hopefully this will allow openMV to run our custom script without exposing it ( keep it secret ), for step 3 where is the best place to stick the code to write to the ST registers?
    If this works out we’re planning to integrate your openMV with our product, the combined product launch is 1st January 2021 so I got some time to make this work…
    So far the H7 openMV is working great for us, is very reliable/stable product, keep up the good job!!
    Regards…

I would just edit main.c with whatever custom fixes to registers you need. There’s a HAL API you can just call to prevent the readout of the flash image.

Or, better yet, edit our boot loader with the changes.

Hello, I have the same request (OPENMV H7 R2), I want to protect the python code. I successfully compiled the firmware with the default configuration (using docker on WSL). In addition I would like to be able to continue to use the TTL serial port. The source files have since changed.

  1. Is the main.c file to be modified that of the bootloader (\openmv\src\bootloader\src\main.c)? There is no “pyb_usb_dev_init” which modification is recommended to block access to the code?
  2. I must modify the line " (void)SDMMC_Init(hsd->Instance, Init);" stm32f7xx_hal_sd.c to prevent initialization?
  3. To avoid ROM dumps which part should be modified please?
  4. It is in the file stm32f4xx_hal_flash_ex.c line 561 I must add OPTIONBYTE_RDP=0xCC to be in level 2 (source https://www.st.com/resource/en/reference_manual/dm00224583-stm32f76xxx-and-stm32f77xxx- advanced-arm-based-32-bit-mcus-stmicroelectronics.pdf)?
  5. Can I always reload a firmware via the IDE?
    Thank you

Hi, you have a bunch of questions at the same time:

  1. The bootloader just jumps to the main file. Give the bootloader only writes and erases it’s safe to not touch.
  2. Just disable the code in the application main file.
  3. I don’t know. You need to make sure your application can’t be stopped/dumped and then you have to enable the option bytes to protect the flash.
  4. I suppose. I’ve never done it though.
  5. Yes, if the bootloader is not changed.

You may find this interesting:

You could also ask the author to share some tips about how they protect their IP.