What a coincidence, I just got an email announcing that Breville intend to orphan my Joule sous vide stick: the existing app will stop working, the new app is only available the US and Canada and in parts of Europe.
Live in another country? You're s.o.l., it wasn't officially sold there. You need a new account as well, hope you like the TOS.
All of this for a device whose core functionality -- setting a target temperature, getting the current temperature and checking for error states -- is both trivial and has no inherent need for internet connectivity.
I suppose I should be grateful they're still supporting a device that's like 10 years old. Caveat emptor (I got it as a gift).
From get go I considered the whole design with no interface on device a bad idea... Apps can and will often go. Better to have also the local controls.
I have an Anova sous vide cooker that is also about 10 years old and has an app, but is fully functional without it.
When I bought it the app was free, but then later became a subscription addon. However they grandfathered all original owners into a free lifetime subscription. Pretty classy.
>a device whose core functionality [...] is both trivial and has no inherent need for internet connectivity.
For a while I've given a hard pass to anything which requires an app for such functionality, knowing full well that eventually I'll be locked out of it (not to mention the privacy implications of such designs).
Why would you say "semi-legally"? Nothing "semi" here. What is "semi-legal" is making hardware e-waste by deciding it is "no longer supported". It is "semi" legal because it is legal under the corrupt political systems in most of the world but is criminal against humanity and the planet we all call home. In that sense if you can prevent e-waste trough any means you are a hero.
.docx and .xlsx are also just zip files with XML and attachments. The bad thing is that the XML is Word's internal document structure serialized and behavior for some values is only defined in Microsoft's code.
I've worked on docx and xlsx import/export and the public documentation for the formats was sufficient for normal documents (maybe excluding some very exotic features). That was ca 2010.
Sometimes you also find hidden things lurking accidentally left behind in IPAs and APKs that are nice and juicy and realize they've been shipped on Google Play/App Store for years.
I've found everything from entire copies of internal company manuals to working test credentials for a physical place with a membership barcode in debug logs left inside the app from developers.
Also sometimes changelogs left inside by accident which include things like "It hasn't been sanitized for outside consumption and thus should remain internal
to <company>. Deliver it externally at your own risk of embarassment."
I've found that Claude Code works well at reversing java applications. Even if it is fully obfuscated claude can restore sensible names for everything and understand how it all works and answer questions about what it is doing.
Interesting, I'd have assumed the guardrails would disallow them from doing anything like that, regardless of legality. Do you need to "convince" it to do it or no questions asked?
It is no questions asked. Even if you are reversing things like anticheats (I wanted to know the privacy implications of running the anticheat modules).
+1. While vibe-coding (natural language to code) is not such a great idea, we can always check the source, so vibe-reverse-engineering (code to natural language) may actually be quite useful.
Naming is an area where LLMs are useful; but I'd still use a regular Java decompiler (there are quite a few of these around) for the actual decompilation part.
It required a lot of manual work and for large apps like Minecraft it took teams of people to figure out what the symbol names should be slowly contributing a little bit every day.
What a coincidence, I just got an email announcing that Breville intend to orphan my Joule sous vide stick: the existing app will stop working, the new app is only available the US and Canada and in parts of Europe.
Live in another country? You're s.o.l., it wasn't officially sold there. You need a new account as well, hope you like the TOS.
All of this for a device whose core functionality -- setting a target temperature, getting the current temperature and checking for error states -- is both trivial and has no inherent need for internet connectivity.
I suppose I should be grateful they're still supporting a device that's like 10 years old. Caveat emptor (I got it as a gift).
https://community.chefsteps.com/discussion/78615/joule-sous-...
"With Breville+ Cooking, you’ll get: ... The ability to cook with or without WiFi anywhere, anytime."
What has gone wrong with humanity, that we need to advertise that as a feature if you download a new app?
From get go I considered the whole design with no interface on device a bad idea... Apps can and will often go. Better to have also the local controls.
I have an Anova sous vide cooker that is also about 10 years old and has an app, but is fully functional without it.
When I bought it the app was free, but then later became a subscription addon. However they grandfathered all original owners into a free lifetime subscription. Pretty classy.
This reads like satire:
The ability to cook with or without WiFi anywhere, anytime.
I'd pay to cook with WiFi. Just imagine the signal strength!
Isn't that just a microwave oven, more or less?
And in a bold face font:
> You've always needed an account to operate your Joule Sous Vide with the Joule app. This is not a new requirement.
Absolute comedy.
If you're not cooking with WiFi, you need more key-down transmit power.
I'm currently full QRO on the 13cm band with something around 1600W EIRP CW, and will be for several minutes until the curry base defrosts.
>WiFi
>1600W EIRP
Your local regulatory authority would like a word with you.
A sous vide stick! Bahahahaha! Do you use an app for crapping too?
>a device whose core functionality [...] is both trivial and has no inherent need for internet connectivity.
For a while I've given a hard pass to anything which requires an app for such functionality, knowing full well that eventually I'll be locked out of it (not to mention the privacy implications of such designs).
I encourage others to follow suit.
Has anyone does this for VIZIO app that controls among other things their soundbars (circa 2019)
I moved to a different country and the app is not on google play store in the new geography.
Even when it is installed somehow it is absolutely unreliable in pairing or controlling the device.
Wish I had time to go on a quest and reverse engineer and build my own better controller.
Why would you say "semi-legally"? Nothing "semi" here. What is "semi-legal" is making hardware e-waste by deciding it is "no longer supported". It is "semi" legal because it is legal under the corrupt political systems in most of the world but is criminal against humanity and the planet we all call home. In that sense if you can prevent e-waste trough any means you are a hero.
Warning: Very rambly and somewhat incoherent video; tried to pay attention due to the topic being of interest, but very quickly gave up.
EULAs be damned, even the DMCA has exceptions for RE in the name of interoperability and repair.
You're going to the bathroom at an airport? You pee in a urinal you can't even take home.
YOU
OWN
NOTHING
Before 1984 "take a taxi" meant you could actually take the taxi.
You wouldn’t download a car
You're not taking all your shits in other people's bathrooms but soil your own instead? What a chump, lmao.
The same is true for iPhone apps (.ipa files). You can just unzip them.
Wait till people discover file(1)!
.docx and .xlsx are also just zip files with XML and attachments. The bad thing is that the XML is Word's internal document structure serialized and behavior for some values is only defined in Microsoft's code.
I've worked on docx and xlsx import/export and the public documentation for the formats was sufficient for normal documents (maybe excluding some very exotic features). That was ca 2010.
Even pk3 files from the id Tech engine are just zip files.
For many things. Change .epub to .zip for example, you get html text and jpg images
Sometimes you also find hidden things lurking accidentally left behind in IPAs and APKs that are nice and juicy and realize they've been shipped on Google Play/App Store for years.
I've found everything from entire copies of internal company manuals to working test credentials for a physical place with a membership barcode in debug logs left inside the app from developers.
Also sometimes changelogs left inside by accident which include things like "It hasn't been sanitized for outside consumption and thus should remain internal to <company>. Deliver it externally at your own risk of embarassment."
They are typically encrypted, though.
I've found that Claude Code works well at reversing java applications. Even if it is fully obfuscated claude can restore sensible names for everything and understand how it all works and answer questions about what it is doing.
Interesting, I'd have assumed the guardrails would disallow them from doing anything like that, regardless of legality. Do you need to "convince" it to do it or no questions asked?
I use AWS Kiro, with the Claude models, and its only to happy to help. I give it the headerless ghidra, and decompilers etc... and away it goes.
Claude doesn't care as long as you aren't straight up asking it to write exploits. It's my go-to for reverse engineering tasks.
ChatGPT is full of refusals and has to be jailbroken out of it.
It is no questions asked. Even if you are reversing things like anticheats (I wanted to know the privacy implications of running the anticheat modules).
+1. While vibe-coding (natural language to code) is not such a great idea, we can always check the source, so vibe-reverse-engineering (code to natural language) may actually be quite useful.
Naming is an area where LLMs are useful; but I'd still use a regular Java decompiler (there are quite a few of these around) for the actual decompilation part.
Claude will opt to use a regular Java decompiler too.
huh, iirc this already exists long before LLM
Claude is quite skilled at using Ghidra, for example.
It required a lot of manual work and for large apps like Minecraft it took teams of people to figure out what the symbol names should be slowly contributing a little bit every day.
I experimented with disassembling 6502 from the c64 California Games. Claude was very prone to bullshit.
While somewhat counterintuitive, I have found that Claude is better at decompilation than disassembly.