... 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.
Doesn't seem like that'd be an accidental thing?
right circumstancesI 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.
Speaking of wireless, their battery problems over time have already bit me, will continue buying "dumb" ones in the future.
There are plenty of other consultants that do that too, but they don't have the same reach and brand recognition.
Would be cooler if the hardware was more OS before but I take what I can get…
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.
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.