Support new firmware version

marian-m12l commented 4 years ago

Add support for the new firmware, which comes with great improvements:

Packs are stored in a filesystem, which should be easier to manage than a custom usb driver
Assets are now compressed on the device, which should free up plenty of storage! (my 4GB device went from 73% used to 9% !!)

Major update needed, though.

marian-m12l commented 3 years ago

Did your old hardware get the new firmware too?

marian-m12l commented 3 years ago

@marian-m12l Maybe this guy can help :D https://www.lehibou.com/freelance/developpeur-embarque/17941

Ah ah, indeed, the guy must know a thing or two about this firmware :-D

arabine commented 3 years ago

@marian-m12l Unfortunately not as it died before. I will try to repair it.

marian-m12l commented 3 years ago

@arabine If you manage to fix it and get the firmware upgrade, there's something else you could try. If you're comfortable with the java remote debugger, you could place a breakpoint on com.lunii.device.wrapper.raw.firmware.RawFirmwareUpgradeService#upgradeToFirmware2Part1 to try and get the value of cryptedUUID. This is a byte array (apparently specific to a device) that gets written to the "SPI memory". Could be involved in the obfuscation, somehow, and I don't see how to read it after the upgrade.

arabine commented 3 years ago

Ok my image decoder is working (BMP images are rotated), only in back and white for the moment ; I think that the color palette is a kind of a shade of grey, it may be simple to guess. https://hostpic.xyz/images/2020/10/02/Screenshot_20201002_100731.png

marian-m12l commented 3 years ago

@arabine Nice work! I think most BMP files start on the bottom-left corner, so the rows go upwards :) not sure if there's a header field to change that.

arabine commented 3 years ago

@marian-m12l I changed the battery, my old box works again but the usb connector has a problem, I need to replace it. Then I will try your java debug thing.

marian-m12l commented 3 years ago

@arabine Great. Let me know if you want any guidance regarding the debugging. Could also be interesting to save the firmware files, both for the AVR version and the Sonix one.

bourgouinadrien commented 3 years ago

I'm completely overwhelmed by your technical level @arabine and @marian-m12l but I salute your performance

cnopix commented 3 years ago

i like your work @marian-m12l :-)

how could I help to move the project forward?

marian-m12l commented 3 years ago

Thanks :-)

@cnopix How you can help depends on you skills and what you're comfortable with, as the issue at hand is pretty technical. I think most of the issue is described in this thread, or in the FsStoryPackWriter on branch feature/firmware2dot4. A fresh look at the issue could help ! Getting new inputs may also shine a new light. I'm thinking of firmware files for instance, either for the Sonix DSP or (maybe even better) the one for the new hardware version (probably for some STMicroelectronics microcontroller). Also, if your device is not yet upgraded, you could try what I described in this comment.

appenzellois commented 3 years ago

Hi folks,

First, I'm somehow techie, but not a dev. I was ready to try the 2dot4 conversion thing, but I get stuck with this (you can guess I use Windows (10) and run java from cmd).

After doing a "mvn clean install", I copy-pasted the main class to a Main.java and compiled with javac which gave my a nice Main.class. At first run I got an error regarding java version. I use to have that with the other studio instances also, so I knew what I had to do :

SET PATH="C:\Program Files\Java\jdk-14.0.1\bin"
set STUDIO_PATH=%~dp0

But I still get more errors :

C:\tmp\studio-2dot4\core\target\classes>java Main
Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/commons/io/IOUtils
        at studio.core.v1.reader.archive.ArchiveStoryPackReader.read(ArchiveStoryPackReader.java:201)
        at Main.main(Main.java:12)
Caused by: java.lang.ClassNotFoundException: org.apache.commons.io.IOUtils
        at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:602)
        at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
        at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
        ... 2 more

I don't understand this. In pom.xml the "common-io" seems correctly declared to be retrieved by maven (I tried other alternatives, like adding the version number, 2.6, but it was worse).

        <dependency>
            <groupId>commons-io</groupId>
            <artifactId>commons-io</artifactId>
        </dependency>

On another topic : I tried the "My Lunii Studio" app on Android and it's very limited, as you can't edit your audios. Nevertheless, I was thinking I could find the recorded files on my (not rooted) device and try to fiddle with them (save on PC, modify, put back to device, tada!), BUT I could locate the app folder at all. Did anyone try to follow this route?

marian-m12l commented 3 years ago

@appenzellois It looks like your maven build runs correctly. However if you run your Main class from the command-line you need to provide a classpath which contains all your dependencies. If you have an IDE, it's easier to run your Main from there as the IDE will handle this for you (based on the maven dependencies).

marian-m12l commented 3 years ago

@appenzellois I did not follow the Android app route, as I do not want to either rely on nor burden the Lunii infrastructure. This would also probably violate the usage conditions of the app. And AFAIK you cannot access an app's storage on a non-rooted device.

appenzellois commented 3 years ago

@marian-m12l Ok, I installed IntelliJ (last time I used it was in 2001 ^^) and managed to compile something.

After reducing my RLE BMP image to 200x200pixels I could get past the "file is too big..." error (see below)

Ignoring EOL: 273132
Exception in thread "main" java.lang.RuntimeException: Image file is too big to fit into base image: 272490 > 9462
    at studio.core.v1.writer.fs.FsStoryPackWriter.preprocessImageFile(FsStoryPackWriter.java:485)
    at studio.core.v1.writer.fs.FsStoryPackWriter.writeImageAsset(FsStoryPackWriter.java:552)
    at studio.core.v1.writer.fs.FsStoryPackWriter.write(FsStoryPackWriter.java:206)
    at Main.main(Main.java:17)

Process finished with exit code 1

In the end, the converted folder was generated:

Ignoring EOL: 8426
Image file is too small: expanding compressed chunks to add the missing 1746 bytes

Process finished with exit code 0

But that's when my luck ended.

My first test story had just one Cover node and one Story node, with one single mp3 (mono, 44khz), 10mb total in the folder. I did a second test with a 3 part setup (Cover node, Menu node, Story Node) and for which I only used the few seconds long same "question" mp3 from the previous story (yes, 44khz, mono).

I added their UUID in the HEX .pi file (with 00 in front), and yes they were indeed listed on the Lunii, but whenever I was about to navigate to one of my test stories, the Lunii screen showed some strange things (image from Suzanne et Gaston and at the bottom something weird, which wasn't a part of my story's image), then just froze and rebooted. Adding the UUID in the fisrt line of the .pi made my Lunii reboot in a loop.

I doubt those documented failures can get you any further, but sadly it's all I can do to support the project.

appenzellois commented 3 years ago

@marian-m12l

I did not follow the Android app route, as I do not want to either rely on nor burden the Lunii infrastructure. This would also probably violate the usage conditions of the app. And AFAIK you cannot access an app's storage on a non-rooted device.

When I find some time to root my device etc, I'll maybe give it a try. The provided app is so dramatically useless... I can't believe people are satisfied with that. I think they are too lazy to actually record their stuff or they don't care about the recordings quality.

I never bought any story from the Lunii store (my eldest son is only 3 and I had no need for more stories till now ; in fact I wanted to record some of his books from Pat Patrouille and add some more music the same way I did with STUdio in the past). Meaning I'm still kind of "free" from the Lunii (no bought stories = not tied). As a matter of fact Christmas is approaching and I'm seriously considering other options at the moment. Because IMO the Lunii wihout STUdio is a very disapointing green plastic box... Thanks for having saved it for some time.

marian-m12l commented 3 years ago

@appenzellois Reducing the image dimensions will probably cause reading errors on the device. To reduce the file size, you can try making the image "simpler" (big regions of the image with a single color). Regarding "at the bottom something weird, which wasn't a part of my story's image", that's actually expected because we a reusing the first lines of an existing image. Regarding the audio files, did you hear anything playing ? It seems that some work, and some don't (which causes "autoplay" to fail).

marian-m12l commented 3 years ago

@marian-m12l

I did not follow the Android app route, as I do not want to either rely on nor burden the Lunii infrastructure. This would also probably violate the usage conditions of the app. And AFAIK you cannot access an app's storage on a non-rooted device.

When I find some time to root my device etc, I'll maybe give it a try. The provided app is so dramatically useless... I can't believe people are satisfied with that. I think they are too lazy to actually record their stuff or they don't care about the recordings quality.

I never bought any story from the Lunii store (my eldest son is only 3 and I had no need for more stories till now ; in fact I wanted to record some of his books from Pat Patrouille and add some more music the same way I did with STUdio in the past). Meaning I'm still kind of "free" from the Lunii (no bought stories = not tied). As a matter of fact Christmas is approaching and I'm seriously considering other options at the moment. Because IMO the Lunii wihout STUdio is a very disapointing green plastic box... Thanks for having saved it for some time.

I get your frustration regarding the official application, but I think this is still a good step forward, and that's certainly enough for most people tbh. Yet they seem to be working on improving the app in the future, so we'll see. Even though I created STUdio to extend the possibilities of the device, that doesn't mean I think ill of the official story packs. Actually I think they are doing a tremendous work at offering high quality stories, and that's a good part of why I like this device. Just my 2cts.

alexandreblazy commented 3 years ago

Hi,

I was thrilled by the studio but I just bought a lunii and it does not work.

I also noticed that the quality of the own recording by the app is very low. that is why i wanted to do my own.

is there a solution just to have the luni box recognized by the studio? Is there a solution to import mp3 on the luni ? even with no character or special festure?

yours

alex

jisse44 commented 3 years ago

Hi,

Procedure to put a real story.

With the Android App and a rooted device, you can:

record a fake story (just 2 seconds of 'bla bla' ) and a title (the real one)
navigate to /data/data/fr.lunii.studio/app_flutter/record/ , copy the files to phone sorage, to identify wich one is the story ('bla bla')
rename the real story mp3 file with the 'test_XXXXX.mp3' name, and copy the file to /data/data/fr.lunii.studio/app_flutter/record/ to overwrite the fake story file
export the story to your Luniistore, and import the story to the Lunni

That's it

marian-m12l commented 3 years ago

A little update: I dumped the EEPROM chip (the SPI memory) in hope of finding interesting (or at least new) data, but I came back empty-handed., apart from the various firmware binaries I already had. I guess we'll have to find another angle to see some progress.

mat75011 commented 3 years ago

@jisse44 i tried to find the folders on my xiaomi with android file transfer. There's a data under Android and there's a fr.lunii.studio but only a files folder after that no app_flutter... I already recorded a story and i tried again but nothing changes here. Can you help please to locate the good folder... thanks! And @marian-m12l merci pour ce travail j'espère pouvoir l'utiliser une fois que le problème de nouveau firmware sera réglé!

cvandeplas commented 3 years ago

@jisse44 i tried to find the folders on my xiaomi with android file transfer. There's a data under Android and there's a fr.lunii.studio but only a files folder after that no app_flutter... I already recorded a story and i tried again but nothing changes here. Can you help please to locate the good folder...

You need to have a rooted device to access this folder. A workaround is to export the android lunii data as backup, edit backup locally, and restore the backup to phone.

adb backup -noapk fr.lunii.studio
Use android-backup-extractor to extract the backup file: java -jar abe-all.jar unpack backup.ab backup.tar
Extract the archive: tar xf backup.tar
Replace the .mp3 as explained by @jisse44 . You could also edit the studio.db sqlite database to update the duration of the audio. Although it is not really needed and only causes a cosmetic issue and no technical problem. recreate the tar using the specific method: tar tf backup.tar | grep -F "fr.lunii.studio" > package.list and
edit the file and remove the entries with folder names
recreate the archive based on the filelist: tar cf modified.tar -T package.list
create the modified backup: java -jar abe-all.jar pack modified.tar modified.ab
adb restore modified.ab
start lunii and test the audio,
sync to the lunii store, and then use the official application to sync to the lunii box.

cvandeplas commented 3 years ago

Good news, I confirm that editing the studio.db database manually, adding entries yourself and repackaging everything works. All stories work within the Android application. I was able to upload two stories to their servers, but for the third the program reports the error: "This story has not been sent. Check that your device is properly connected, then try and export your story again". (edit: the error was due to my mistake) I'll try uploading again in a few minutes.

necropoulet commented 3 years ago

Good news, I confirm that editing the studio.db database manually, adding entries yourself and repackaging everything works. All stories work within the Android application. I was able to upload two stories to their servers, but for the third the program reports the error: "This story has not been sent. Check that your device is properly connected, then try and export your story again". I'll try uploading again in a few minutes.

I also tried this method, and I managed to upload one story on their servers. Next try, Lunii App keep crashing, can't even play uploaded stories inside Lunii Android App. I use a rooted android device with X-plore File Manager. Reinstalling app doesn't seem to work either.

cvandeplas commented 3 years ago

Good news, my problem existed between keyboard and chair. I made a mistake in the filename of the story title audio mp3 file. After correcting the filenames, all works as expected and I can upload all to the online store.

necropoulet commented 3 years ago

Good news, my problem existed between keyboard and chair. I made a mistake in the filename of the story title audio mp3 file. After correcting the filenames, all works as expected and I can upload all to the online store.

Can you explain your process in few steps? Thanks!

cvandeplas commented 3 years ago

There might be a 10 minute limit for stories. They work in the app, upload starts, but fails after some seconds.

cvandeplas commented 3 years ago

Hi, I've added detailed instructions in a new wiki page: Adding own stories through the Android application

necropoulet commented 3 years ago

Hi, I've added detailed instructions in a new wiki page: Adding own stories through the Android application

Working great! Thank you so much!

marian-m12l commented 3 years ago

So, I just downgraded my device and put my custom stories back. For the time being, I think I'll let it that way and let my kids enjoy it, while I try to make sense of what I've gathered...

ateliermeteorite commented 3 years ago

So, I just downgraded my device and put my custom stories back. For the time being, I think I'll let it that way and let my kids enjoy it, while I try to make sense of what I've gathered...

How did you go about downgrading your lunii? I would also like to do it ...

marian-m12l commented 3 years ago

@ateliermeteorite Unfortunately, this requires having a dump of the previous firmware and flashing it on the EEPROM chip.

EddyOops commented 3 years ago

@ateliermeteorite Unfortunately, this requires having a dump of the previous firmware and flashing it on the EEPROM chip.

Excellent work ! Did you use a hardware or software flash method? With or without soldering?

noctanvol commented 3 years ago

So, I just downgraded my device and put my custom stories back. For the time being, I think I'll let it that way and let my kids enjoy it, while I try to make sense of what I've gathered...

Yeah thats a great news ! Can't wait for your update on how you did it !!!!

I guess you used an EEPROM clip with a usb writter to do it. Where did you find the old firmware ?

regards

marian-m12l commented 3 years ago

@EddyOops @noctanvol Indeed, I flashed the EEPROM chip directly (raspberry pi + test clips). And I restored the SD card, just in case the Luniistore couldn't repair it (which it should, from what I understand). I had dumped the "SPI" memory blocks earlier, without knowing exactly where it was stored at the time (I actually had never opened the device until I decided to look for this internal storage). Pretty fortunate. However I cannot share this dump because a) it's proprietary software, and b) it seems to contain some data specific to a given device.

EddyOops commented 3 years ago

Yes, the firmware contains at least the serial number of the device and then it is automatically added to the lunii account upon association. We should be able to compare the dumps of 2 devices.

T1nd4 commented 3 years ago

We at least need to know how to dump our self lunii, with our raspy. Is there a specific chip clip ?

De : EddyOops notifications@github.com Envoyé : Monday, November 16, 2020 9:24:55 PM À : marian-m12l/studio studio@noreply.github.com Cc : Subscribed subscribed@noreply.github.com Objet : Re: [marian-m12l/studio] Support new firmware version (#122)

Yes, the firmware contains at least the serial number of the device and then it is automatically added to the lunii account upon association. We should be able to compare the dumps of 2 devices.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/marian-m12l/studio/issues/122#issuecomment-728303930, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AOYM463HPVQT7T7O3TRHRC3SQGDBPANCNFSM4OPJBQAA.

noctanvol commented 3 years ago

@EddyOops @noctanvol Indeed, I flashed the EEPROM chip directly (raspberry pi + test clips). And I restored the SD card, just in case the Luniistore couldn't repair it (which it should, from what I understand). I had dumped the "SPI" memory blocks earlier, without knowing exactly where it was stored at the time (I actually had never opened the device until I decided to look for this internal storage). Pretty fortunate. However I cannot share this dump because a) it's proprietary software, and b) it seems to contain some data specific to a given device.

Still thats a great news. I'll dump the lunii of a friend as soon as i receive the clip and usb writer. ( i dont care If I can no longer access the store) at least i will be able restore all the others customs story i created. My daughter is asking for their return everyday, she is driving me nuts....

Could you please show us a picture of the chip where you plugged the clip ? was it near the battery or near the volume button ? Or on the other side of the motherboard ? If you didnt take any picture of the operation maybe you remember the model of the chip ?

thx again

marian-m12l commented 3 years ago

@EddyOops What I know for sure is that the serial number and UUID are stored on the EEPROM (at address 0x7f000), but there may be more.

@T1nd4 @noctanvol No specific clip required, I used a bunch of test clips to wire the raspberry to the chip, but a SOIC clip is probably more comfortable. On my model, the EEPROM is on the backside of the PCB (the side facing the buttons and screen), and is a GD25Q80C, but there seems to be quite a few revisions of the board out there. In any case, I'd expect a SPI driven EEPROM. I used flashrom with the linux_spi programmer module. For dumping only, make sure to drive the WP# pin low. If you want to try a downgrade, be aware that it's still a blind bet...

EddyOops commented 3 years ago

@EddyOops What I know for sure is that the serial number and UUID are stored on the EEPROM (at address 0x7f000), but there may be more.

Comparing 2 dumps from 2 different devices could give us the information. Some people here have plenty to do it. It's only a matter of time.

noctanvol commented 3 years ago

@EddyOops What I know for sure is that the serial number and UUID are stored on the EEPROM (at address 0x7f000), but there may be more.

@T1nd4 @noctanvol No specific clip required, I used a bunch of test clips to wire the raspberry to the chip, but a SOIC clip is probably more comfortable. On my model, the EEPROM is on the backside of the PCB (the side facing the buttons and screen), and is a GD25Q80C, but there seems to be quite a few revisions of the board out there. In any case, I'd expect a SPI driven EEPROM. I used flashrom with the linux_spi programmer module. For dumping only, make sure to drive the WP# pin low. If you want to try a downgrade, be aware that it's still a blind bet...

@marian-m12l Thx a lot for the infos.

T1nd4 commented 3 years ago

@marian, did you use a 4 wired connections ? If yes which ones plz ?

De : noctanvol notifications@github.com Envoyé : Tuesday, November 17, 2020 8:24:27 PM À : marian-m12l/studio studio@noreply.github.com Cc : T1nd4 lebeneur@hotmail.com; Mention mention@noreply.github.com Objet : Re: [marian-m12l/studio] Support new firmware version (#122)

@EddyOopshttps://github.com/EddyOops What I know for sure is that the serial number and UUID are stored on the EEPROM (at address 0x7f000), but there may be more.

@T1nd4https://github.com/T1nd4 @noctanvolhttps://github.com/noctanvol No specific clip required, I used a bunch of test clips to wire the raspberry to the chip, but a SOIC clip is probably more comfortable. On my model, the EEPROM is on the backside of the PCB (the side facing the buttons and screen), and is a GD25Q80Chttps://www.gigadevice.com/flash-memory/gd25q80c/, but there seems to be quite a few revisions of the board out there. In any case, I'd expect a SPI driven EEPROM. I used flashrom with the linux_spi programmer module. For dumping only, make sure to drive the WP# pin low. If you want to try a downgrade, be aware that it's still a blind bet...

@marian-m12lhttps://github.com/marian-m12l Thx a lot for the infos.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/marian-m12l/studio/issues/122#issuecomment-729148680, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AOYM465A5763QSEDHZMWJQ3SQLEWXANCNFSM4OPJBQAA.

marian-m12l commented 3 years ago

@T1nd4 What do you mean by "4 wired connection"? The EEPROM uses SPI, but all eight pins must be wired.

marian-m12l commented 3 years ago

A few observations I made regarding the pack files, in case anyone can make sense of all this.

As mentioned earlier, for a given story pack the "scrambling" is the same for all devices. Only the bt file changes.
The scrambling seems to be the same for different (all?) packs: when you generate a story pack with the official mobile application, you end up with the same li file. That's because the plaintext is the same (only two entries, or 8 bytes)
The bt file seems to be related to a device's UUID. I tried changing various bytes of the UUID, and it always ended up removing the bt files. Removing the bt file seems to be the device's way of reacting to a mismatch.
The bt seems to be exclusively related to the ri file.
- Changing the pack's UUID in .pi (and renaming the pack folder accordingly) does not break the story pack.
- Changing cleartext or scrambled bytes from the other files (ni, li, si) never seem to trigger the bt file removal (which I attribute to a bt file mismatch), it just makes to pack fail and the device reset.
- However changing bytes from the ri file before 0x40 triggers the bt file removal. Interestingly, the maximum size of bt files seems to be... 64 bytes (0x40). And when the ri is smaller than 64 bytes, the bt file length matches!

A few more thoughts:

I tried to replace some scrambled bytes for which the plaintext is known to see if it can be a XOR-based algorithm (using B ⊕ K = (A ⊕ K) ⊕ (B ⊕ A)), but this always failed. That was prior to the above observations, so maybe someone can give it another try?
The bt and ri files matching lengths also makes me think of a XOR. Maybe applied on the ri plaintext? Maybe a checksum or a hash could also be involved?

Please feel free to share your opinions on this, does that ring a bell for you?

vpoulailleau commented 3 years ago

I've looked for XOR-based algorithm. But especially in bitmap headers there are a lot of 0. So I think they should not use a XOR-based algorithm to scramble the data, or at least the key is not constant (like in the old https://en.wikipedia.org/wiki/Vigen%C3%A8re_cipher), because otherwise that would be easy to detect.

noctanvol commented 3 years ago

@marian-m12l
Hi I eventually received the clip. I was able to dump the firmware of my lunii ( new version) but everything in it seems to be scrambled, at least nothing is readle using "strings" or any txt editor. I dont have any experience with the lunii but with other chips like on GPU card, usually you can read some plain text from the dump, like the model and the manufacturer, etc things like that

My question is : Is it normal ?? i tried several time reading the chip with the same result I assume you performed a dump of your lunii ( nex fw version) before trying to revert it to the old firmware ? Did you get also i file completly unreadable ? thx

marian-m12l commented 3 years ago

@noctanvol Well, I guess it depends on what you call "unreadable" :-) The ROM essentially contains firmware binaries, which seem to use a (sadly) undocumented instructions set (from what I can tell, at least). So, yeah, mostly unreadable indeed. However, the dump should not look completely random:

You should be able to read a few strings, for instance around 0xb21d0. The reason there are very few strings, I believe, is because the production firmware probably does not keep any logs or print anything to serial. Thus, the only strings I could find are those required to operate: folder and file paths, mostly.
The dump should be structured, with data chunks in-between erased blocks. SYS.BIN from 0x0 to 0x3fff, FU.BIN from 0x6000 to 0x7d039, FA.BIN from 0x80000 to 0xf7039, and your serial number and UUID at 0xff000

If you are getting the same dump every time, this sounds pretty reassuring. Did you compare checksums to make sure your dumps are identical?

marian-m12l commented 3 years ago

@vpoulailleau Yes, XOR can be a weakness, but not necessarily. There are ways to use XOR in a secure way; after all it's a big part of state-of-the-art cipher algorithms. The security lies in the bitstream itself. I cannot make sense of this (yet?), but some patterns seem match a word-wise modular addition. Could be used instead of XOR as the "combination function", maybe..

noctanvol commented 3 years ago

@noctanvol Well, I guess it depends on what you call "unreadable" :-) The ROM essentially contains firmware binaries, which seem to use a (sadly) undocumented instructions set (from what I can tell, at least). So, yeah, mostly unreadable indeed. However, the dump should not look completely random:

You should be able to read a few strings, for instance around 0xb21d0. The reason there are very few strings, I believe, is because the production firmware probably does not keep any logs or print anything to serial. Thus, the only strings I could find are those required to operate: folder and file paths, mostly.

The dump should be structured, with data chunks in-between erased blocks. SYS.BIN from 0x0 to 0x3fff, FU.BIN from 0x6000 to 0x7d039, FA.BIN from 0x80000 to 0xf7039, and your serial number and UUID at 0xff000

If you are getting the same dump every time, this sounds pretty reassuring. Did you compare checksums to make sure your dumps are identical?

@marian-m12l Thx for your answer and infos but so far I didnt find anything "readable" in the dump even at the address you provided I did 3 dump and checked checksum they are all identicall.

I'm using HxD to open the file created during dump thx

marian-m12l / studio

Support new firmware version #122