kpc

Hi, nice to see the vendor participating in the HN discussion (and hopefully gathering feedback from users) :-)

One of the main factors driving me back to the DK board was the fact that many NCS samples take advantage of the 4 switches + 4 LEDs on the DK board. Even the light_switch sample uses all 4 buttons to trigger different functionality.

The smaller boards don't have room for these switches and LEDs, so you'd have to tweak the program to work around the hardware differences. And that's a big investment if you just wanted to play around with the stock sample code for a few minutes.

A more general critique of the NCS samples is that many of them require a great deal of "polishing" before you can use them in a real project. It would actually be helpful if NCS shipped ready-made overlays that allowed them to run on smaller boards like the MDK and Dongle, in a configuration that's closer to what a shippable product would look like. As it stands, a company that wants to ship a Zigbee bulb or switch has to do a lot of work to convert the samples into something usable.

Maybe this is worth filing some PRs on the sdk-nrf github.

For my use case, Zigbee was vastly preferable to WiFi (or BLE). IP stacks are complex, buggy, and require a lot of configuration -- even moreso if you add encryption into the mix. Zigbee was the simplest tool for the job.

Some of the newer ESP32 boards do support Zigbee but I don't think they were available yet when I started my project. Might be worth looking into ESP32-C6 now.

As others have mentioned, power consumption is also a consideration. My battery powered devices consume about 25uA and should theoretically last 5+ years on two lithium AAA cells.

I have about 20 nRF52840 boards deployed around my house for various automations.

Personally I've found that for casual experimenting and software development, the official nRF52840 DK board is your best bet. Here in the US it only costs around $50, and all of the samples in the nRF Connect SDK support it natively. It's also pre-wired for power measurement.

My first board was the nRF52840 MDK from makerdiary. I ordered it from Amazon because it was cheap and it had one-day delivery. Most of the NCS samples do not support the makerdiary boards as-is. You can usually add a dts .overlay file to the sample to get it working, but it will take a bit of extra effort. Having to tweak device trees right off the bat adds another step to the learning curve and makes it harder to try out random sample apps.

Over time I migrated to using the DK for development (the integrated debugger + serial interfaces are super handy) and then using the USD $10 nRF52840 Dongle boards for deployment. I program the dongle boards using a knockoff J-Link probe from Aliexpress and run them off battery power. I eventually stopped using the makerdiary MDK since it didn't really fill a niche for me. But YMMV.

One nice thing about the board in this article is that it has an external SPI flash, which could be useful if the nRF52840's 1MB onchip flash isn't large enough for your application. I use A/B partitions to support OTA updates and it's pretty easy to run over 512kB per image if your use case is moderately complex.

Once I push a new ocproxy release, vpnns will percolate into the Debian package: https://packages.debian.org/sid/ocproxy

See also: Trolling the Web of Trust[1]

The slides from Micah's original OHM2013 presentation are in trollwot.pdf

0xdeadbeef keys[2] have been around for quite a while, too. Generating a custom 32-bit key ID using a simple unoptimized brute force program takes under an hour on a midrange PC.

[1] https://github.com/micahflee/trollwot

[2] http://pgp.mit.edu/pks/lookup?search=0xdeadbeef&op=index

Another option:

Most/all modern distributions can run programs built with lsbcc[1] from the Linux Standard Base workgroup. The lsbdev environment links your program against "stub" .so files that advertise appropriate symbol versions, and prevent referencing library symbols that are not defined in the standard.

It can be somewhat of a hassle to get programs to build in this environment, but it greatly reduces the chances of finding an incompatibility when the program is later run under an unexpected Linux distribution. LSB includes an app checker[2] which can generate reports[3] showing compatibility with various distributions.

[1] https://wiki.linuxfoundation.org/en/Book/HowToDevel

[2] http://ispras.linuxbase.org/index.php/About_Linux_Applicatio...

[3] http://ispras.linuxbase.org/index.php/File:LAC_TestReportDis...

My use case is the equivalent of adding printf's to various obfuscated methods, for purposes like:

- Determining if/when/how the method is called, i.e. understanding how specific operator actions affect the program flow

- Dumping out arguments or intermediate values, to see if I recognize the data or have properly identified the purpose of the obfuscated method

- Extracting secrets buried in the program, without having to reverse engineer the storage format

- Printing out strings or byte arrays after the de-obfuscator code has run (FWIW I have also used ASM for this when I had a bunch of similarly-obfuscated .class files to process)

This tends to be a manual, iterative process - not necessarily something well-suited to applying the same "formula" to every method. So I'll find an interesting method (often identified using strings or magic numbers), instrument it, and rerun the program. That result will determine what gets instrumented next. Being able to run "make ; java -jar new.jar", and only reassemble the files that have changed, is a huge time saver.

I'd actually prefer to use a debugger, but the best solution I found was Dr. Garbage[1] and it doesn't allow inspection of objects on the operand stack, or breakpoints on specific opcodes. Also, attaching a debugger to a more complex multithreaded system, such as a J2EE application server, may be tricky.

[1] http://www.drgarbage.com/bytecode-visualizer/

jarsurgeon is a simple wrapper script that builds upon several pre-existing tools:

- Krakatau (Python)

- GNU make (C)

- git (C)

- javac, jar (ELF binaries that invoke Java)

- javap (alternative to Krakatau's disassemble.py; another ELF binary that invokes Java)

After repeating this workflow by hand for numerous JAR files, I figured it was worth automating.

Arguably the "disassemble" step could have been integrated a little better using e.g. jython or "import Krakatau", but I didn't feel that it was worth the trouble. Also, structuring it this way makes it easy to substitute jasper/jasmin or another bytecode (dis)assembler if desired.

The "reassemble" (make) step would have to be completely redesigned to use pure Java tools. Changing to Ant/Maven/Gradle/... might be helpful if the instrumentation has more complicated dependencies. For my purposes, GNU make was the most expedient solution.

Shelling out to run the binaries has the added advantage of making it easy to switch between different JDK versions.