search

Jeija / bluefluff

Reverse Engineering Furby Connect's Bluetooth Protocol and Update Format
MIT License
478 stars 82 forks source link

Question about audio offset values #31

Open PsychoFox11 opened 6 years ago

PsychoFox11 commented 6 years ago

Hi, I've been enjoying this project and gotten everything I've tried to work so far, including uploading and activating DLC. However, I'm a little confused about the audio offset values shown in the dlc injector script. How would I determine what to use for a given DLC file and ensure that it doesn't overlap? I don't exactly understand where the numbers come from, and why the offsets are shown broken out into x * y + z. I feel like I'm probably missing something a little more straightforward. I think I could use the examples shown for the DLC file shown, but how do you arrive at those values to begin with, and what do each of those 3 numbers mean? Injecting audio is the last thing I'd really like to get working. Thanks for all your work on this, it has been really fun!

bulkyacronym commented 6 years ago

i'm having the same issue as @PsychoFox11 and am also very curious to know more about how the python scripts work exactly!

Jeija commented 6 years ago

I have to admit that the information in the documentation on that topic is somewhat outdated now that the amazing people at Context Information Security have reverse-engineered the structure of DLC files. Here is their more up-to-date work:

When I tried reverse engineering the DLC files myself, I didn't know about all that stuff that you can read on the Context Information Security blog right now. So I didn't know anything about the PAL / SPR / CEL / AMF / APL … sections you can read about in the blog post. Since I still wanted to be able to insert my own audio files, I just tried to replace existing audio content with my custom audio. I was able to guess that Furby uses the GeneralPlus A1800 codec and I was also able to find out that this codec uses chunks of 40 byte length that are independent of each other. This means that every chunk contains 20ms of audio and modifying one chunk doesn't change the next one.

Now I had an A1800 audio file I created myself and I had the DLC file that I wanted to inject my audio into. By looking at grayscale representations of the DLC file (visualize_audio.py) I was able to figure out which parts of the file contained audio and which one's didn't (after staring long enough at A1800 file visualizations you will notice that there is always a vertical line). However, the question remains where exactly to inject the audio content.

Since I knew that every section is 40 bytes long, one way would be to just try out every address a, a+1, a+2, …, a+39. As you can guess, trying that out would take a lot of time. So instead, the only solution I found at the time was to stare at the grayscale images of the modified DLC file and make sure the audio was injected in a way so that the typical pattern of the A1800 codec (the horizontal line) persists. If that was the case, I knew that I had found a good offset value.

If this seems complicated and unneccesary to you: It is, but I didn't know a better method at that time. If you just want to insert your own audio into DLC files, I recommend you to use Context Information Security's python tool (use replace_audio) instead: https://github.com/ctxis/Furby