> We could brute force the 4 Bytes. Without any further assumption, this would be 255**4 possibilities, which is way to many.
The author comes up with a much simpler attack in the end, but a 2^32 bruteforce would also have been perfectly doable, taking ~seconds with optimized code on modern hardware.
Agreed :) the problem is though, that you have to decrypt the whole file everytime and not just a few bytes, which makes this still a little bit longer.
You get files, which identify as mp3, but are garbage, and have to check multiple frames.
But agreed bruteforcing 2*32 key is possible. The "way to many" was: "Way to many " for my taste.
Jap...Checking for ID3 is not good enough in checking for correctly decrypted MP3. Brute Forcing with only small letters, you get approx 43k possibilities with "ID3" as the first 3 letters, that makes ~10% of all 26*4 possibilities.
Jap, you only have to decrypt those 43k possibilities, but you have to look at the whole file.
Even if you have garbage in the file, it is not the correct file, as the codec will ignore it, and the output is garbage.
I haven't tried how many of these 43k actually work, or give you at least partialy good result.
On those 10%, look for another magic number, or entropy in general: correctly decrypted data must* have (usually) significantly lower entropy/randomness than encrypted data.
A highly optimized (for this _exact_ context) hash/bloom function may yield comparable results, in general.
Or you can compute an efficient delineation algorithm using the docs:
> correctly decrypted data must* have (usually) significantly lower entropy/randomness than encrypted data
I'd expect the average difference in entropy of random data vs. a compressed format to be so small as to be a useless filter. After all if it wasn't so, it would be bad compression. Now I don't know about mp3 specifically...
You are correct, the format would have to be lossless for this to be maximally effective. Since MP3 was explicitly designed to encode voice-range audio efficiently, this would not be the *ideal* metric.
However, since the format is also resilient and flexible, it should have a structure - even if that complexity is hidden in the codec - with a magnitude less entropy than the mis-decrypted possible plaintexts.
But yes, you compress, than encrypt. If your encrypted data is compressible or otherwise distinguishable from random noise, than you have (exploitable, correlatable) bias in your encryption functions, or you have inefficiency/redundancy in your compression.
I would think a very limited set of magic numbers/possible hex ranges would yield the highest performance per error.
It looks like this is a German product but the name in English is a meme. Making these play Shadilay would be top kek!
After the connection, the files were gone and I was kinda puzzled, until I found the following code in the application [...] They seem to set the hidden Attribute on the first connect, so the files are not easily discovered.
I'm surprised that people still leave that setting at the horrible default. Unhiding hidden files and file extensions is one of the first things I do to any installation of Windows since Windows 95.
On the other hand, I'm not surprised at all that they attempt to track your location; my default ever since ~2010 has been to assume that any software will contain embedded spyware and phone home whenever given the opportunity.
If you're looking for headphones with built-in audio players, a search of the usual Chinese sites for "headphones TF card" will yield plenty of results --- for products that are unlikely to contain spyware nor require an invasive app, but have more useful features like BT. In fact, I suspect they're also using JieLi SoCs, and the company that was contracted to do the firmware on this one may also produce those.
Awesome article. Just wondering, how can a hardware company voluntarily submit their device for reverse engineering and dismantling as a show of good faith? Given the right circumstances this is basically a free security audit and marketing for the company.
They could just provided schematics, blueprints, parts explosion graphics, etc.
I have been a fan of the Sony MDR-7502 headphones since Moses was in a basket. They provide an explosion of each of the parts and their numbers so that you can order replacements. Granted, these are "old skool" dumb wired headphones, so no software is needed, nor are chips necessary to look up and what not.
Yes it would. I also think they are playing with their target audience. The headphones mentioned were meant for professional use, PlayStation ones are meant for consumers.
This doesn't mean they shouldn't have done it. They should. But they get away with it more easily.
If a company wants somebody to do a hardware audit for marketing purposes, they should pay money for that. Please fairly value people's labor, especially when you seek to profit from it.
Well, influencers are able to work out alternative means of compensation because the content is more valuable than the work performed. For example a blogger that is renowned for teardowns might do the work in exchange for access to early release models so that their content is highly relevant. That is worth more than the hourly cost to perform the teardown work. Compensation negotiation is part of the art of that deal.
If an influencer is indeed able to monetize the content sufficient to match market price for the labor, then sure, that is also fairly valuing people's labor. But that's definitely not what's happening here.
If someone wants to do the hardware audit for free, or in exchange for some kind of promotional exchange, is that a bad thing? I’d breakdown a lot of devices if I could get a duplicate one intact, for free
Any company with sufficiently interesting hardware is welcome to send me a copy. Most hardware isn't very interesting though, so they'd likely have to pay me too.
First, I just came back from Germany where I've seen that thing in a shop. Didn't have much time to investigate due to the kids, but guessed that it's just NFC chips with data on the headphores.
Second, I've been thinking about building a simple MP3-player for my kids for quite a while now, and (minus the obfuscation there) that's not far from what I've been thinking about doing.
I was thinking of a steampunk music player using floppy disks: store a 32-bit (4 billion songs should be enough right?) ID onto a floppy, and have a player (it can be a Raspberry Pi with a USB floppy drive) read the ID, lookup the MP3 the ID corresponds to and play the MP3 from an attached storage device.
Because floppies get bad sectors, the ID should be stored repeatedly on it, 4 bytes repeated to fill 1.38 MB should be redundant enough!
I suppose without ID's, one can also store the artist name and song title, and do some text search to find the MP3. Or a YouTube video.
I was thinking child friendly, so using NFC tags isn't such a bad idea - plus I have a few hundred spare ones in nice plastic casings. I'd also just store IDs on them, and either have the media files preloaded (as seems to be the case here), or have it download it from my media server on first use.
Other thing I want (which they don't do) is the ability of resuming playback at the same position, even when putting it into a different player - that's one reason I still have some audio cassettes for the kids. No other medium I'm aware of does that kind of easy state saving. My idea there is to have the tags locked in the player in a way that gives me enough time to write the position if the user tries to remove it.
I did this for my child and it worked well. Arduino compatible RFID module, ESP32 with and SD card and I2S. I ended up renaming the MP3s to match the card serial numbers, rather than program each one.
There have been multiple devices. I have been looking into the jooki box as well, which is quite hackable, tonibox is nice hardware (with already good firmware replacement), yoto is weird.
... the application tries not only uploading the ID3 Tags, but also geolocation data,
which is most likely gathered from Wi-Fi triangulation from windows itself.
That's likely breaking some EU GDPR rules, at the very least.
The beginning of the article says the device "work without any internet connection and all of the content already on the headphones itself", then the device needs a Windows application downloads content from the Internet.
I am a bit frustrated as isn't this just an MP3 player playing from SD card but put inside a headphone? Doesn't sound like an invention at all.
basically yes. it is a prefilled mp3 player with content, which get's activated with nfc chips. You can add custom content for 3 nfc chips with this windows application (or update the pre fillment).
all of this little children audio devices are glorified mp3 players, with encryption inside.
The point is, that most of them don't allow to really "own" the content, like vinyl/tape/cd. they are encrypted, and you only get the encryption key, which is only playable on the device...you buy a license key and not the content.
What a wonderful article. I love step by step reverse engineering break downs.
I did not expect to read about tracking in such a seemingly self-contained product. Paranoia level successfully raised. Never trust their silly "terms" and "policies" documents, they can change without your knowledge and the company will gaslight you about it. Never trust their proprietary software, reverse engineer it and implement a free software replacement.
The author comes up with a much simpler attack in the end, but a 2^32 bruteforce would also have been perfectly doable, taking ~seconds with optimized code on modern hardware.
But agreed bruteforcing 2*32 key is possible. The "way to many" was: "Way to many " for my taste.
You could also put garbage data in nearly every frame and most modern codecs will fit it the best they can - for mp3 anyway.
Even if you have garbage in the file, it is not the correct file, as the codec will ignore it, and the output is garbage.
I haven't tried how many of these 43k actually work, or give you at least partialy good result.
A highly optimized (for this _exact_ context) hash/bloom function may yield comparable results, in general.
Or you can compute an efficient delineation algorithm using the docs:
https://www.loc.gov/preservation/digital/formats/fdd/fdd0001...
If the so many bytes of the rolling context don't match any numbers, keep brut'in the key til you have magic numbers and non-random garbage.
I'd expect the average difference in entropy of random data vs. a compressed format to be so small as to be a useless filter. After all if it wasn't so, it would be bad compression. Now I don't know about mp3 specifically...
However, since the format is also resilient and flexible, it should have a structure - even if that complexity is hidden in the codec - with a magnitude less entropy than the mis-decrypted possible plaintexts.
But yes, you compress, than encrypt. If your encrypted data is compressible or otherwise distinguishable from random noise, than you have (exploitable, correlatable) bias in your encryption functions, or you have inefficiency/redundancy in your compression.
I would think a very limited set of magic numbers/possible hex ranges would yield the highest performance per error.
After the connection, the files were gone and I was kinda puzzled, until I found the following code in the application [...] They seem to set the hidden Attribute on the first connect, so the files are not easily discovered.
I'm surprised that people still leave that setting at the horrible default. Unhiding hidden files and file extensions is one of the first things I do to any installation of Windows since Windows 95.
On the other hand, I'm not surprised at all that they attempt to track your location; my default ever since ~2010 has been to assume that any software will contain embedded spyware and phone home whenever given the opportunity.
If you're looking for headphones with built-in audio players, a search of the usual Chinese sites for "headphones TF card" will yield plenty of results --- for products that are unlikely to contain spyware nor require an invasive app, but have more useful features like BT. In fact, I suspect they're also using JieLi SoCs, and the company that was contracted to do the firmware on this one may also produce those.
I have been a fan of the Sony MDR-7502 headphones since Moses was in a basket. They provide an explosion of each of the parts and their numbers so that you can order replacements. Granted, these are "old skool" dumb wired headphones, so no software is needed, nor are chips necessary to look up and what not.
If you can go open at all, I'd recommend Sennheiser HD600. It doesn't get more solid than this.
HD560S are new, and use the same type of body HD598/99/579 do. They aren't anywhere as durable.
Ultimately they're bought for the sound; HD600 is the tried and true all-rounder neutral reference, and that's why it remains relevant.
HD560S is good relative to its peers at its price, but isn't tuned the same way, nor has it passed the test of time.
Speaking of wireless, their battery problems over time have already bit me, will continue buying "dumb" ones in the future.
This doesn't mean they shouldn't have done it. They should. But they get away with it more easily.
There are plenty of other consultants that do that too, but they don't have the same reach and brand recognition.
First, I just came back from Germany where I've seen that thing in a shop. Didn't have much time to investigate due to the kids, but guessed that it's just NFC chips with data on the headphores.
Second, I've been thinking about building a simple MP3-player for my kids for quite a while now, and (minus the obfuscation there) that's not far from what I've been thinking about doing.
Because floppies get bad sectors, the ID should be stored repeatedly on it, 4 bytes repeated to fill 1.38 MB should be redundant enough!
I suppose without ID's, one can also store the artist name and song title, and do some text search to find the MP3. Or a YouTube video.
Other thing I want (which they don't do) is the ability of resuming playback at the same position, even when putting it into a different player - that's one reason I still have some audio cassettes for the kids. No other medium I'm aware of does that kind of easy state saving. My idea there is to have the tags locked in the player in a way that gives me enough time to write the position if the user tries to remove it.
https://us.yotoplay.com
Doesn't seem like that'd be an accidental thing?
So they're clearly aware it's happening.
I am a bit frustrated as isn't this just an MP3 player playing from SD card but put inside a headphone? Doesn't sound like an invention at all.
all of this little children audio devices are glorified mp3 players, with encryption inside.
The point is, that most of them don't allow to really "own" the content, like vinyl/tape/cd. they are encrypted, and you only get the encryption key, which is only playable on the device...you buy a license key and not the content.
Would be cooler if the hardware was more OS before but I take what I can get…
I did not expect to read about tracking in such a seemingly self-contained product. Paranoia level successfully raised. Never trust their silly "terms" and "policies" documents, they can change without your knowledge and the company will gaslight you about it. Never trust their proprietary software, reverse engineer it and implement a free software replacement.