PD, E15n, RE and AICAs

This document is an outline for a presentation I am working on with a view to presenting at an appropriate forum.

Please contact me via my LinkedIn profile if you represent a group who might be interested in hosting this presentation.

PD = Product Differentiation
E15n = Macquarie Dictionary’s word of the year 2024 (associated with Cory Doctorow)
RE = Reverse engineering
AICAs = we’ll get to that​

Counterpoint to E15n:
When “software eats the world”, what is a poor corporation with a brand/product portfolio in non-digital hardware supposed to do?
Often the answer is a companion app. Often connectivity is WiFi/BLE/USB.
Often the apps are not great or become obsolete while the hardware is still useful.
But should we expect corporations with non-digital DNA to maintain their companion apps forever?

AICA = Alternative Interoperable Companion App

Targets:

  • Fender Mustang modelling guitar amplifiers

  • Akai and Alesis Midi Keyboard Controllers

  • Wifi Cameras?

  • Older Chromecasts?

Data mining:

  • Downloadable installers for companion apps, firmware

  • Downloadable manuals

  • Freely available, but copyright belongs to corporation

  • Installers are often deeply nested zip/tar/… containers with interesting JSON/XML configuration files there for the review

    • UI labelling generally visible using ‘strings’ if not actually in structured config files

    • Experiment with UTF-8 vs ISO-LATIN-1 vs 7-bit-ASCII for string extraction (and don’t send UTF-8 to hardware where vendor only sends ISO-LATIN-1 or ASCII)

    • Decompilation might be possible - but is it ever worth the effort?

  • Wireshark

Techniques:

  • FOSS (you’re never going to make money)

  • Python, Java

    • Library availability more important than syntax

  • AICA hosted on RPi etc (Balena?)

  • Build a web UI app then your client can be anywhere

  • Platform libraries for USB BLE

Limitations:

  • Building a community:

    • Who else owns the target hardware?

    • Are they prepared to risk running your software?

    • Should you even ask them to risk it?

    • If there other FOSS AICA’s for the hardware should you help them rather than start rolling your own?

  • Getting sued

    • You don’t want this

    • Be ‘Caesar’s Wife` in relation to hardware vendor’s copyright, branding and other IP

    • Treat the the hardware vendor with respect and understanding

      • If your software broke it you bought that consequence - don’t claim on the warranty

      • Don’t expect them to be happy if your effort works against their PD

      • Don’t expect them to be happy even if it doesn’t

      • No point in asking for permission - if you want to do something but think you might need permission for legal reasons you probably just shouldn’t ask and shouldn’t do it

      • Don’t assume a hostile action from an employee or agent reflects the considered position of the whole company

      • Don’t assume that because your app is harmless they should permit/support it - your cool FOSS app can be next year’s trojan malware delivery system

  • ???

???

Conclusions

Q&A

Demos?
…