NetBurner Community Forum

I would like to somehow impose some control over what firmware images (S19) files can be uploaded to Netburner flash via the Monitor utility. I have existing firmware images in the field that I would like the user to NOT be able to roll back to once they've rolled to my latest firmware release. If I had owned this application from the beginning, and foreseen this need, I could have built something into the application to enforce this. I've run across a few things that work with AutoUpdate, but haven't figured out yet how to selectively "break" the ability to upload via the monitor. Are there any alternate versions of the monitor utility that can be loaded into flash? Versions that will only load the app from flash to DRAM based on some security criteria? Can I do some trick where I change the platform name or some retained field on the board such that older S19 files no longer work?

This is a pretty tough one.... What NetBurner product are you using?

Why not have an array called VersionSignatures stored as a user parameter with some reasonable number of entries to more than allow for future revisions. At the start of your product life each table entry is set to a value signifiying "unsigned." Code version "n" is loaded via the monitor. As part of the application, when the code boots, it checks the VersionsSignatures table. Version "n" of your code checks table entry "n". If the location is empty, it writes a signature to location "n" indicating that version "n" has been loaded and booted. Version "n" has just signed itself. Thereafter, on successive boots, the application first checks to see if the entry at location "n" (corrsponding to version "n") is signed, and if so, whether the locations at n+1, n+2, n+3 (until the end of the table) are all unsigned. If any location higher than "n" is signed, it means that at one point, a higher version of code has been loaded and run. If so, the app should refuse to boot, and should output a message to some appropriate location(s) (web page, log file on ftp site, serial port, tcp or udp post, etc indicating that that "the application has been rolled back from a previously installed higher version 'xyz': reload version 'xyz' to recover functionality." Of course, to make things more difficult to beat, the table does not have to be a simple linear array, but can use all sorts of schemes to have either an irregular order or signature.

This scheme could be beat by erasing all user memory prior to loading a rolled-back application. To protect against this, you could also require user memory to include a series of unique keys at specific locations. Then, if someone erased all user memory, goodbye keys.

I am using MOD5234


RidgeGlider.... your solution might work if I didn't already have multiple versions of firmware already distributed in the field. I can solve the problem moving forward from where I am today, but not sure what I can do to stop some previous, already released version, from being loaded via the monitor.

How many units do you have in the field?

If it is not too many, you could use RG's idea, but manually manage the customers who are running older stuff.

If this is a major issue and you have a lot of field units you may want to inquire about costs and availability of NetBurner designing a custom monitor for you. This would be the most secure and easiest route.

Another solution would be to not allow monitor use at all. Do you want your customer to be able to use any of the monitor settings via serial port? If not you can set the boot delay to 0 in the monitor config record. Look at the programmers manual to see the config record structure and how to modify it. You must make sure you do not load any broken (trapping) applications when the boot time is 0 because your module will be unrecoverable, it will need to be RMAed to NetBurner. You will also need to modify udp.cpp so that the ipsetup functionality will not have the ability to change the boot time. If you do not want customers to use IPSetup at all then you can just portect this with the ipsetup_authenticate_func. There is an eample of this in the AutoUpdate Features Example in the NNDK.

For a very unrecommended method, you could change the location of the correct MAC in the config record and replace it with an invalid one. Changing MAC addresses is not a listed option from the monitor menu so they could not easily change it via serial port. Only your newer application will have system files you modified that point to the correct MAC. I do not want to go into details about this one on the group as MAC spoofing can bring down an entire network or possibly worse if used maliciously or blindly. Bringing down a network can result in civil and/or criminal penalties... this is also a very bad way to tell a customer not to use your old stuff.

-Larry