Collaborating on opening up JuiceBox IP for ongoing software support?

[natematias]

Hi folks,

Thanks for all your work on this open source project. Greetings from the Ithaca Ecovillage, where Juiceboxes have charged our many EVs for years, and where we rely on the app to handle billing. I have been following the story of Enel X's declining support and just saw the news that they are ending North American US operations.

Given how many folks are likely to be affected, I wonder if people are interested in a collaborative effort to seek access to the relevant IP and contribute to an open source solution. I would have to ask, but I think we would be likely to donate to a shared effort, and I personally know a lot of lawyers in the open source world, and one might be persuaded to negotiate and advise on the IP issues.

I imagine we could also collaborate with some of the Enel X's commercial clients, who are also in a pickle.

I had been planning to send a note about this idea sometime this fall anyway, but then the news forced my hand.

All the best,

--J. Nathan Matias https://natematias.com

[quicklywilliam]

Would love to see this, happy to support if I can.

[FalconFour]

I'm on board as much as I can be. Really, they just need to implement some way to command the Zentri software to send traffic somewhere else (override the directory server's commands). That would make the local control setup SO much easier. Zentri's management and control is cloud-based, so the only way to develop for it is to "own" the devices, and the Enel company's Zentri DMS "owns" all the devices, for firmware/developement purposes. To clarify: it's "owned" for the purposes of being able to deploy firmware and manage OTA processes - once a device is "owned" by an org, it can't be re-assigned to program your own firmware as a different org, for example. Zentri was bought by SiLabs long ago, so that's another layer of complexity.

Commercial clients and all? They have use-cases way beyond what Home Assistant could offer. That's where the complex yarnball of the Enel servers comes in... app (yuck), dashboard (actually decent), directory server, messaging gateway, database, all that stuff. Implementing an OCPP adapter may be the best approach to attach to a different charger management platform. The boxes are all still just "dumb terminals", responding to simple server commands in real-time (they have no knowledge of car, energy pricing, users, and only a rudimentary fail-safe understanding of schedules) - no difference (AFAIK) between commercial and home stations except where they're routed in the directory server (to the commercial server, or the home server). That makes it reasonably plausible to write an adapter for the protocol based on the work we're already doing with JuicePassProxy on single stations. So there is a chance...

[natematias]

That's super useful information. Do you have any hunches on what unit within Silicon Labs it is? I would be willing to collaborate on a letter to them. We took a tally, and my neighborhood uses ~41 Juiceboxes, so we have a vested interest in finding a way to make this work!

[FalconFour]

Hard to tell, but the acquisition happened a long time ago: https://news.silabs.com/2017-01-23-Silicon-Labs-Acquires-Wi-Fi-Innovator-Zentri

Some clues may be found in their forum, with which I've interacted just a couple times over the years - such as: https://community.silabs.com/s/question/0D7Vm000000JRxNKAW/detail - maybe a post in there might be insightful?

(Oh, and those smart bulbs by Sengled, referenced at the end of that original post, are also still working too ;) )

[natematias]

Another clue in this story is this exploit report by Sector7, who were able to compromise the Juicebox 40 DMS. And when they notified the company, they were told by SILabs "Gecko OS is in end of life (EOL) status so no fix will be offered."

It's possible that one reason Enel X is exiting the market rapidly is to avoid liability for a system with unpatched exploits.

[FalconFour]

Whoa, that's new! I had been wondering if there was a report on their efforts with the JuiceBox, and the results are not surprising at all. A huge benefit to not running Linux on everything is that it's got a much, much smaller attack surface. They had to dig really deep. haha.

Out of all the exploits which we had prepared before going to the event, this was by far the most complex and had the highest number of moving parts. So we spent a good amount of time making sure that it was as reliable as possible prior to our flight to Tokyo.

May be enough info there to use the exploit for good rather than evil (e.g. soft-modding a console) and there may be a path to a fully software-based solution through that. I never thought there'd be a path through the Zentri chip, given how locked-down it is.

Still, that's a complex project. If we can just get in there and change the UDP target stored in memory, that'd eliminate any need for a MitM device to send data to juicepassproxy. What's better - developing a MitM device, or pulling on that exploit chain?

[jcsalem]

Hi Nate, Falcon, and friends,

I'm writing from New View CoHousing where we have 6 or 7 Juiceboxes including 5 commercial ones that are less than a year old. Sigh...

We really want to keep the commercial ones from turning into bricks. Ideally, I'd like to capture data from them like juicepassproxy offers. But would be happy with a hardware hack that turns them into dumb, but working, charges. I'll try to open one up sometime and see what I find.

I'm pretty handy around electronics and software but I have limited time. Happy to beta test what others figure out.

I suggest everyone grab all the public doc before it disappears: https://support-emobility.enelx.com/content/dam/support-hub/canada-en/JuiceBox-Manual-JuiceBox-32A-40A-48A.pdf https://emotorwerks.zendesk.com/hc/en-us/

Jim

PS: I bought the very first post-Kickstarter Juicebox back in ~2105. Loved the company at that time. Everything went to heck once EnelX bought them.

[FalconFour]

@jcsalem - don't worry too much! The boxes should function as dumb stations by default! The problem in your particular case, I think, is that the Enel servers set an offline amperage limit of 0A - so when disconnected, they stop charging.

There is hope, no hardware hack needed. And I hope this doesn't drive interest away from JuicePassProxy and, maybe, another OCPP adapter system, because getting that across the finish line is really needed. These boxes have the ability to be so much more useful in this new second life.

You might want to experiment with a factory reset. First, ensure your box IS NOT running the oldest WiFi code - that is, that it's running a ZAP-enabled software (Zentri APplication). If it's a JuiceBox 2.x (grey plastic case, Enel branding), then it is 100% already a ZAP box for sure. If it's a metal case (silver or black), it can go either way, so you need to verify.

1. Get to WiFi setup mode by power-cycling the box, wait for the Setup network to appear (may take up to 30 seconds, keep scanning your WiFi networks), and connect to that "JuiceNet-###" network. In fact, that's already a good indicator - if the network says "JuiceNet" then you almost certainly have a ZAP system (you can do a factory reset). If it says "JuiceBox-###", you almost certainly have a non-ZAP system (do not proceed with factory reset, it will brick the WiFi!).
2. Once connected, load the URL http://10.10.10.1/command/ver in a web browser. You should see some JSON spew. Among the spew, you should see the version string. If the version string includes "JB814" and "ZentriOS-W" in it, that's non-ZAP. If it says some other version string (I can't remember the exact details, but I know it says "ZentriOS-WZ"), you have a ZAP firmware.
3. Worth reiterating here: If you have non-ZAP ("JB814" and "ZentriOS-W"), do not proceed with factory reset despite the temptations. It will reset the baud rate and the console will become inaccessible without a TTL Serial dongle going into the box to change settings! Bad, bad, no going back. In fact, the factory reset does make the console temporarily inaccessible, but the ZAP software (the JuiceBox specific code) repairs the settings on the immediate next boot, thus why it can be done with the ZAP, but not the non-ZAP.
4. To obtain the MAC address to issue a factory reset (on ZAP), first issue http://10.10.10.1/command/get%20wlan.mac (the command "get wlan.mac") and observe the MAC address in the output (xx:xx:xx:xx:xx:xx - 6 groups of 2 digits). Copy that to the clipboard.
5. To perform the factory reset, issue 10.10.10.1/command/fac%20(PASTE) - you'll have to put the MAC into the paste, no space between the "%20" and the MAC. If successful, I can't recall if it returns a blank page, an "OK", or what - but as long as you don't get an error, it was successful.

With the factory reset, it might just wipe-out the offline current limit, and return to unit defaults. This isn't a sure thing, because that value isn't actually stored in the Zentri (WiFi) module! It's stored in the main processor (the ATMega) on the board, and we're relying on the ZAP reset to communicate default settings, overwriting what the ATMega has in its memory. There's a bit more protocol / inter-processor communication to dive into there, but there's a fair chance this mechanism should send the right data. If not, there's still one more edge-case we might be able to exploit (falling-back on its JuiceNet protocol emulation as it's booting, by timing a power-cycle just after it gets the factory reset command).

From then on, without being connected to WiFi, it should default to being a dumb charger forever until it hears otherwise (which it never will, without a server connection).

Give that a try on a sample station, maybe - see if it just plugs in and starts charging!

[jcsalem]

Thank you for these details, Falcon. Just wanted to confirm that you expect this to work for the Commercial JuiceBoxes. I think both residential and commercial use the same JuiceBox Pro hardware. However, I'm wondering if the commercial firmware would prevent this. In any case, we'll give it a try.

Anyway, if it doesn't work, I suppose the next step is to see if we can modify the ATMega firmware. Have you looked into that? Do you know if we can download it via JTAG or somesuch? Or is it protected.

It would be so great if we could turn these into OpenSource devices. I'd be happy to run a server to collect data from JuiceBox for billing purposes.

Thanks again!

PS: The ones I'm concerned about are the 2.x versions used by my neighbors. My personal one is a black case but it is using the Zentri code.

[FalconFour]

I don't think there actually is any difference in firmware between home and commercial :) I haven't observed any difference in all my tinkering, at least - and no reason to believe it is different. Pretty sure it's all server-side. So, you should be good to go there.

ATMega firmware isn't protected, should be able to slurp it down all you like. There are two components inside each ATmega328p: the Flash space (32KB) and the EEPROM space (2KB). Settings are stored in the EEPROM along with a checksum of the Flash. Settings aren't checksummed. Not sure the exact layout of EEPROM on the JB2.x devices. I'm pretty sure it's all in Zentri EEPROM.

As for Zentri EEPROM, the identity (serial/ID number) and meter calibration is stored in there on JB2.x - that data is stored in Atmel EEPROM on JB1.x. So, I'd be pretty sure that "factory reset" would NOT clobber those details (would be pretty bad if it did). Tread carefully there, though. Having access through Telnet port 2000 is pretty useful for poking around. Check "email.name_address" for the ID number - it was a hack done long ago that the app started relying on, so I think they carried it over into the new versions too. Could use that to ensure the ID number is valid.

[natematias]

Hi folks,

Following the line of the opening thread, I have sent notes out to Consumer Reports and to the Cyberlaw Clinic at Harvard to ask for advice on opening up the IP, and also advice on what kind of legal or advocacy avenues Juicebox owners might have with the company.

I'll keep folks posted.

--Nathan

[1fish2]

From this Reddit thread:

Happy to offer our free charger software to manage juicebox chargers - head over to Pulseenergy.io and sign up ... All juicebox chargers can connect to an OCPP complaint cloud server. We have already ported two customers based in SF over since the notice went out.

Since most of the impacted users after the Enel decision are home charger users we are doing our bit to help these users by offering to host their chargers for free on our cloud.

Our primary business is in commercial large scale charging for fleets.

[URLs and bold added]

Reprogramming an Enel X Juicebox 40 Charger to Pulse Energy

[natematias]

Hi everyone,

Thanks for a great conversation! We met yesterday, and we now have a Discord, needs/volunteer intake form, and a Github project dedicated to Juice Rescue. You can find links and details here: https://juice-rescue.org/