search

marian-m12l / studio

STUdio - Story Teller Unleashed
https://marian-m12l.github.io/studio-website/
Mozilla Public License 2.0
671 stars 131 forks source link

Support new firmware version #122

Closed marian-m12l closed 3 years ago

marian-m12l commented 4 years ago

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

Major update needed, though.

chrobiche commented 3 years ago

Can you clarify if the new firmware can work with version 0.2.0 or we need to wait to update?

bourgouinadrien commented 3 years ago

I've just upgraded the Lunii of one of my daughter and Lunii isn't detected anymore but Studio. Also, story pack where like .pack files and they are now .pk files. It's still just some archived, I was able to find 2 audio file in sf\000\

marian-m12l commented 3 years ago

Indeed, the newest firmware is not supported by STUdio. When upgraded, the Lunii become a completely different device (even the usb productId changed), using a filesystem partition instead of usb bulk operations, compressed assets and a new binary format to describe nodes.

I did some "manual" testing since opening this issue to try and make it work on my device, but as of today the packs only work partially. And I am unsure whether I can make it work in the future. I'm working (from time to time...) on integrating this work into STUdio (on a branch) to automate the generation of pack files and detect the new device / partition, but this will take some time...

GossBust commented 3 years ago

Hi,

I updated the firmware of my Lunii and lost all my custom stories, what a shame and a waste of time! Is there a way to downgrade the firmware and come back to the latest firmware working with Studio?

By the way, mhank you Marian for Studio: incredible work!

kaelhem commented 3 years ago

@marian-m12l Do you need any help to support the new firmware? It would be a pleasure to lend a hand (even if I'm not a java guy). Did you manage to do reverse-engineering with the new binary format? Does the file transfer work? I've almost finished my converter Moiki -> STUdio, so I'm really motivated :)

GossBust commented 3 years ago

Hi,

I updated the firmware of my Lunii and lost all my custom stories, what a shame and a waste of time! Is there a way to downgrade the firmware and come back to the latest firmware working with Studio?

By the way, mhank you Marian for Studio: incredible work!

Does anybody think it is possible to copy the old firmware from the SD card of another Lunii? Did anybody tried this manipulation? Has someone a SD card image of the previous firmware please?

ateliermeteorite commented 3 years ago

great idea !!

bourgouinadrien commented 3 years ago

Hi, I updated the firmware of my Lunii and lost all my custom stories, what a shame and a waste of time! Is there a way to downgrade the firmware and come back to the latest firmware working with Studio? By the way, mhank you Marian for Studio: incredible work!

Does anybody think it is possible to copy the old firmware from the SD card of another Lunii? Did anybody tried this manipulation? Has someone a SD card image of the previous firmware please?

I have 2 Lunii, one with old firmware and one with the new. If it can help I can dd both sd card

ateliermeteorite commented 3 years ago

Hi, I updated the firmware of my Lunii and lost all my custom stories, what a shame and a waste of time! Is there a way to downgrade the firmware and come back to the latest firmware working with Studio? By the way, mhank you Marian for Studio: incredible work!

Does anybody think it is possible to copy the old firmware from the SD card of another Lunii? Did anybody tried this manipulation? Has someone a SD card image of the previous firmware please?

I have 2 Lunii, one with old firmware and one with the new. If it can help I can dd both sd card

yes, if you manage to make a dd of the old version

kaelhem commented 3 years ago

Unfortunately, I think the firmware is flashed on the board, not on the sd...

marian-m12l commented 3 years ago

I've still some work to do to "clean up" the new pack writer. Once it's done, i'll push it on a branch if you guys want to have a look at it. Most of the pack generation is done (the new format is pretty straightforward) but there are issues with the assets. Help and contributions are welcome :-)

marian-m12l commented 3 years ago

I just pushed the WIP pack writer on branch feature/firmware2dot4, if y'all want to have a look.

A few words of caution:

import java.io.FileInputStream; import java.nio.file.Path;

public class Main { public static void main(String[] args) throws Exception { ArchiveStoryPackReader reader = new ArchiveStoryPackReader(); StoryPack pack = reader.read(new FileInputStream("/path/to/pack.zip")); // Prepare assets (RLE-encoded BMP, audio must already be MP3) StoryPack packWithPreparedAssets = PackAssetsCompression.withPreparedAssetsFirmware2dot4(pack); // Write FS pack FsStoryPackWriter writer = new FsStoryPackWriter(); writer.write(packWithPreparedAssets, Path.of("/tmp")); } }

GossBust commented 3 years ago

Hi,

Can you explain this step please? "then edit the binary "pack index" file .pi to add your pack's 16-bytes UUID to the list (e.g. 00000000000000000000000012345678)" Where is the .pi file please?

Thanks for the work

marian-m12l commented 3 years ago

@GossBust Should have made this clearer: .pi is a file at the root of the device partition that acts as a "pack index", listing the (ordered) uuids of all the "installed" packs. Apparently, only the last 8 hex characters are used by the device to find the pack folder within .content.

GossBust commented 3 years ago

@marian-m12l Thanks for the explanation. That is why my converted packs where not recognized by the Lunii. Mounting the Lunii on Windows 7, I can not see this 'pack index' file at the root of the device partition using Windows Explorer. Should I use a specific tool to see it ? "Cmd" ? A binary viewer?

noctanvol commented 3 years ago

@marian-m12l thx for your hardwork on fixing Studio to work with the latest firmware. Can I buy you a coffee or smt ? regards

marian-m12l commented 3 years ago

@GossBust Didn't try on Windows. The file is probably hidden, though. You can use an hex editor to add your pack.

marian-m12l commented 3 years ago

@noctanvol Thanks for your kind words. There's still some way to go before it is correctly supported, though (if ever).

GossBust commented 3 years ago

Hi there,

Launching the pack conversion for most of my custom packs, I have an error "Image file is too big to fit into base image: 10876 > 9462". The 'rf' files and 'sf' files are not created in the 'new format' pack. I guess there is some work on this new firmware version, I keep faith :p.

Waiting for that, do you think there is a way to come back to the previous firmware version?

See you

marian-m12l commented 3 years ago

@GossBust Indeed, support for the new firmware is still far from being done and reliable, it's pretty "hackish" and the assets processing is constrained by the existing story pack. Smaller images can be expanded, but bigger images that cannot fit cause errors. You can tweak your images by converting yourself to BMP format (4-bit depth, RLE encoding/compression) and making sure the files are small enough. I've not looked into downgrading firmware, but I think it's written to the flash/SPI memory on the device, which (to my knowledge) is not writable via USB anymore.

GossBust commented 3 years ago

@marian-m12l Thanks again for your work and the explanations.

Grumby commented 3 years ago

Hello,

Thank you and well done for your work and the pleasure it can bring to our children and grandchildren.

I fetched https://github.com/marian-m12l/studio/tree/feature/firmware2dot4 via git and created the app with maven. This created a ~/studio folder and the application is in ~ /studio/web-ui/target. It is from this folder that I run the command sh studio-linux.sh (or sh studio-macos.sh depending on the computer I'm using, although the two scripts are the same).

I have two concerns about your explanation for transferring my Stories Pack to the Lunii device.

1) in the .content/ directory of the Lunii, I don't have a 4CDF38C6 file but six files with 8 alphanumeric characters. Which one should I copy to ~/.studio/fs/ ? Or should I copy all 6 ?

2) when I write a Main.java script by taking your example and replacing (of course) the "/path/to/pack.zip" by my path to my pack and that I place it in the ~/studio/core/target/classes folder I run in a terminal the command: javac Main.java An error appears:

Main.java:1: error: cannot access StoryPack import studio.core.v1.model.StoryPack; bad class file: ./studio/core/v1/model/StoryPack.class class file has wrong version 55.0, should be 52.0 Please remove or make sure it appears in the correct subdirectory of the classpath.

Am I in the correct folder to run the java script (knowing that in other folders I have the error that the packages cannot be imported because they do not exist) ? How to neutralize the error concerning the wrong version, knowing that I am under jdk 11.0.8 and that version 52 depends on jdk 8.x.x if I believe what I have read on the internet ?

Thanks for your help.

baldator commented 3 years ago

Hi, I was able to build and push to my Lunii a custom story pack. However, when I select the cover node, nothing happens, meaning that the menu node is not working. Is someone experiencing the same behavior? @marian-m12l: in which file is the link between the cover and the menu node? Thank you

marian-m12l commented 3 years ago

@Grumby 4CDF38C6 folder is supposed to hold the default story pack (Susanne et Gaston). Did you remove it from the device? It's also possible that there are several versions using different uuids. To create an application of your own, the easiest way is probably to add it within the maven project, so you can benefit from the dependencies management. The error you mention, though, means you're probably compiling with JDK 8. Did you check which javac command is in your path?

marian-m12l commented 3 years ago

@baldator What do you mean "nothing happens"? You turn the wheel onto your pack and you get nothing? empty screen and no sound? no error either? As mentioned, the support is very shaky at this point, and I do not expect a complete story pack to work. The node navigation is basically a done deal (as long as the story pack is consistent), but assets cause issues.

baldator commented 3 years ago

@marian-m12l my apologies: it wasn't so clear. I select the story pack, I click ok and then no sounds nor errors. At this point buttons aren't working, meaning I can't event go back to the main menu. I understand it's very shaky, but let me know if I can help to troubleshoot the problem :)

gilles6 commented 3 years ago

After trying unsuccessfully to use STUdio, I realised I was also on the new firmware.

So, I tried feature/firmware2dot4 and did the following (successfully):

git clone https://github.com/marian-m12l/studio.git
git checkout feature/firmware2dot4
git pull
mvn clean install
chmod +x ./studio-macos.sh

Then, I plugged my Lunii device and did this:

mkdir  ~/.studio/fs
cp -r /Volumes/LUNII/.content/F3C18541 ~/.studio/fs/

But, I didn't understand... what are the other steps before running studio-macos.sh ? Any terminal command to help me understand ?

Where is supposed to be my /path/to/pack.zip ? Maybe this .pk file: ~/Library/Application\ Support/Luniitheque/packs/d489f67b0e514669b1e11555f3c18541.pk? Which is a zip file according to the command file.

I noticed with VSCode Hex Editor that .pi contains the default story pack folder's name /Volumes/LUNII/.content/F3C18541 and is actually the name of the only pack installed on my device ("Douce Nuit") ~/Library/Application Support/Luniitheque/packs/d489f67b0e514669b1e11555f3c18541.pk.

image But I don't understand what I should do with it.

Also, how to deal with the pack conversion program (naming, path, execution).

Thanks a lot for your work and help and sorry for all these newbie questions :-p

marian-m12l commented 3 years ago

@baldator That's interesting. Are you using a pack that worked previously (with the older firmware)? What's in your first node? On nodes with images, all I get is either a correct(-ish) display or an error. Sounds may just not play. It could make sense if your first node is sound-only with autoplay: if the sound does not play, then the device is never notified to autoplay the next node, and is just stuck there.

marian-m12l commented 3 years ago

@gilles6 Be aware that this branch is heavily work-in-progress, and you should not expect a working story pack. The pack conversion is not "wired" yet on the UI, so you'd have to make your own application/main to perform conversion. The "source" pack should be in the STUdio archive format (what you get from the editor), and there are restrictions on assets (mono/44100Hz MP3 files). .pi is the "pack index" which lists all the packs installed on the device; each "row" of 16 bytes is a story pack UUID.

arabine commented 3 years ago

Hello! Regarding the new pack format, the sound is native mp3, that's ok we can play them directly with VLC for instance, but what is the format of the images in the rf folder? (previous firmware was BMP).

marian-m12l commented 3 years ago

@arabine The images are still BMP, but using Run-Length Encoding (RLE) and 4-bits color depth (16 colors palette). However all asset files have their first 512 bytes somehow obfuscated or ciphered, so the header is not readable, which is why the images cannot be opened "as-is".

arabine commented 3 years ago

Ok thank you, this may prevent the software to generate a valid pack file. We have a kind of a challenge here.

marian-m12l commented 3 years ago

@arabine You're right, that's the challenging part :-)

cvandeplas commented 3 years ago

@arabine The images are still BMP, but using Run-Length Encoding (RLE) and 4-bits color depth (16 colors palette). However all asset files have their first 512 bytes somehow obfuscated or ciphered, so the header is not readable, which is why the images cannot be opened "as-is".

Would you be able to share some of these with me? I can have a look myself and ask some friends who like crypto capture-the-flags.

chrisn51 commented 3 years ago

Hi guys, @marian-m12l , I come back on the initial idea of downgrading the firmware (which would be much easier & faster than other options). Stupid question but how can we say "the firmware written to the flash/SPI memory on the device... is not writable via USB" whereas each upgrade to a newer version of the firmware is done via USB (or we don´t have the same box... )? Thanks.

marian-m12l commented 3 years ago

@cvandeplas I cannot share any file as they are protected content. However if you have a Lunii you can take a look at your own story packs. The .content folder contains a folder for each story pack. Each pack consists of:

That's what I know, but I cannot wrap my head around those scrambled blocks...

If you or your friends have good knowledge wrt crypto then your opinion(s) would be very welcome :- ) Anything that could point in the right direction :-) (I myself have some experience and understanding of ciphers, but I'm certainly not an expert in that domain).

marian-m12l commented 3 years ago

@chrisn51 Feel free to look into downgrading :-) As I say, I did not look into it. What I know is that the upgrade to the newer (FS-based) firmware involved writing to the "SPI" memory, and that USB bulk commands that could be used to read/write this memory no longer work (at least not "out-of-the-box"). Upgrades from a 2.x to a 2.x+1 are now performed by the device itself, which reads firmware files (FA.bin and FU.bin) from its FS partition.

marian-m12l commented 3 years ago

@arabine To make the bitmaps somewhat readable (at least open-able), you can overwrite the beginning of the files with BMP v4 header :

BITMAPFILEHEADER

(https://docs.microsoft.com/en-us/windows/win32/api/wingdi/ns-wingdi-bitmapfileheader)

0x00 (2 bytes): Magic bytes (0x424d) 0x02 (4 bytes, little-endian): Size of file in bytes 0x06 (4 bytes): Reserved 0x0a (4 bytes, little-endian): Offset / Starting address of pixel data (0xba)

BITMAPV4HEADER

(https://docs.microsoft.com/en-us/windows/win32/api/wingdi/ns-wingdi-bitmapv4header)

0x0e (4 bytes, little-endian): Size of header in bytes (0x6c) 0x12 (4 bytes, little-endian): Width in pixels (0x140) 0x16 (4 bytes, little-endian): Height in pixels (0xf0) 0x1a (2 bytes, little-endian): Number of color planes (0x01) 0x1c (2 bytes, little-endian): Color depth / Bits per pixel (0x04) 0x1e (4 bytes, little-endian): Compression method (0x02 for BI_RLE4 - RLE 4-bit/pixel) 0x22 (4 bytes, little-endian): Size of the raw pixel data (total size minus headers size) 0x26 (4 bytes, little-endian): Horizontal resolution (e.g. 0xb12 for 72DPI) 0x2a (4 bytes, little-endian): Vertical resolution (e.g. 0xb12 for 72DPI) 0x2e (4 bytes, little-endian): Number of colors in palette (0x10 or 0x00 to default to 2^n) 0x32 (4 bytes, little-endian): Number of "important" colors (0x00 to ignore) 0x36 (4 bytes): Color mask for red component (ignored as this is incompatible with BI_RLE4 compression) 0x3a (4 bytes): Color mask for green component (ignored as this is incompatible with BI_RLE4 compression) 0x3e (4 bytes): Color mask for blue component (ignored as this is incompatible with BI_RLE4 compression) 0x42 (4 bytes): Color mask for alpha component (ignored as this is incompatible with BI_RLE4 compression) 0x46 (4 bytes, little-endian): Color space (LCS_sRGB = 0x73524742) 0x4a (36 bytes): Color space endpoints (ignored as this is incompatible with LCS_sRGB) 0x6e (4 bytes): Gamme for red component (ignored as this is incompatible with LCS_sRGB) 0x72 (4 bytes): Gamme for red component (ignored as this is incompatible with LCS_sRGB) 0x76 (4 bytes): Gamme for red component (ignored as this is incompatible with LCS_sRGB)

Color palette

0x7a (4 bytes): Color # 1 in the form: blue, green, red, 0x00 0x7e (4 bytes): Color # 2 0x82 (4 bytes): Color # 3 0x86 (4 bytes): Color # 4 0x8a (4 bytes): Color # 5 0x8e (4 bytes): Color # 6 0x92 (4 bytes): Color # 7 0x96 (4 bytes): Color # 8 0x9a (4 bytes): Color # 9 0x9e (4 bytes): Color # 10 0xa2 (4 bytes): Color # 11 0xa6 (4 bytes): Color # 12 0xaa (4 bytes): Color # 13 0xae (4 bytes): Color # 14 0xb2 (4 bytes): Color # 15 0xb6 (4 bytes): Color # 16

Pixel data

(https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-wmf/73b57f24-6d78-4eeb-9c06-8f892d88f1ab)

Starting at 0xba

Example header for a 9998 bytes image (XX... being the color palette):

42 4D 0E 27  00 00 00 00  00 00 BA 00  00 00 6C 00
00 00 40 01  00 00 F0 00  00 00 01 00  04 00 02 00
00 00 A6 26  00 00 12 0B  00 00 12 0B  00 00 00 00
00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00
00 00 00 00  00 00 42 47  52 73 00 00  00 00 00 00
00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00
00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00
00 00 00 00  00 00 00 00  00 00 XX XX  XX XX XX XX
XX XX XX XX  XX XX XX XX  XX XX XX XX  XX XX XX XX
XX XX XX XX  XX XX XX XX  XX XX XX XX  XX XX XX XX
XX XX XX XX  XX XX XX XX  XX XX XX XX  XX XX XX XX
XX XX XX XX  XX XX XX XX  XX XX
arabine commented 3 years ago

Thanks, I'm currently working on an image converter / viewer. Since the Sonix MCU does not seems to have a lot of RAM nor encryption engine, the scrambling may be a simple obfuscator algorithm (performing aes in pure software is also possible).

marian-m12l commented 3 years ago

@arabine Documentation of the MCU is pretty scarce, unfortunately. There does not seem to be hardware crypto support, indeed, but given the small quantity of "scrambled" data, the controller may be up to it? I was not able to find the SDK either, except behind a password wall. And couldn't find any hint as to which instruction set is used by this DSP.. Which brings me to your blog post (looking forward to the followup btw!) you mention older hardware having an AVR microcontroller? If it still receives firmware upgrades, that could be easier to reverse? Going back to the obfuscated data, I'm actually not leaning towards block cipher such as AES, because the ciphertext length seems to perfectly match the plaintext length... Hence the use of "scrambled" or "obfuscated" terms by lack of better words... Anyway, I'm all ears for a fresh view on the topic :-) Out of curiosity, what is your converter / viewer for?

Aptustech commented 3 years ago

Il y a une nouvelle version de Lunii qui est en route, elle est fabriquée en France et à priori sera basée sur un STM32. Le sonix va peut être bien disparaître.

On Thu, Oct 1, 2020 at 8:44 PM marian-m12l notifications@github.com wrote:

@arabine https://github.com/arabine Documentation of the MCU is pretty scarce, unfortunately. There does not seem to be hardware crypto support, indeed, but given the small quantity of "scrambled" data, the controller may be up to it? I was not able to find the SDK either, except behind a password wall. And couldn't find any hint as to which instruction set is used by this DSP.. Which brings me to your blog post (looking forward to the followup btw!) you mention older hardware having an AVR microcontroller? If it still receives firmware upgrades, that could be easier to reverse? Going back to the obfuscated data, I'm actually not leaning towards block cipher such as AES, because the ciphertext length seems to perfectly match the plaintext length... Hence the use of "scrambled" or "obfuscated" terms by lack of better words... Anyway, I'm all ears for a fresh view on the topic :-) Out of curiosity, what is your converter / viewer for?

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

-- Frédéric Renet Tel: +33 601 765 096

marian-m12l commented 3 years ago

@Aptustech Effectivement, mais je n'ai pas l'impression que les fonctionnalités (et donc le firmware) soient différentes sur cette nouvelle version. Le luniistore utilise le même "driver" pour le nouveau vendorId/productId. Il me semble donc que les packs seront au même format sur cette V2.

cvandeplas commented 3 years ago

Did you already verify if the files are the same on all the boxes? For the 4CDF38C6 story (Suzanne&Gaston?) here is what I have for md5 checksums:. 

90ecaa46246b385ef11692980136716d  bt
54f5a6818634c753152f2dde280b9ba6  li
ef0f68b06a678a9665e9e15faf2f1ded  ni
b91e0f7d0bd23928f1eb5eee83e3516d  ri
07fc1be3913d47dbce3f477acc8d34bf  si

The rf/000 folder:

02bcd173a08ba5182d4fee59034c7563  07BECADA
2b70a515384f55eda1b381eb6a951973  0A4E3F17
bcd1923f32d1437533eb5f8f3072037a  0EE9C18B
marian-m12l commented 3 years ago

@cvandeplas AFAIK the files are the same except for the "boot file" (bt). I'll compare the checksums.

Edit: yup, same checksums for all files except bt.

cvandeplas commented 3 years ago

The li file might be an opportunity for a known plaintext attack: the end is a sequence of 00 00 00 <counter>. At byte 513 we have:

81 00 00 00 82 00 00 00 83 00 00 00

Some math says that: 512 / 4 = 128 = 0x80. So it makes sense this could be a sequence starting from 01 00 00 00 02 00 00 00 ... to the end. That sequence might therefore be an opportunity/weakness to crack. I'm wildly guessing that the key could be in one of the other files, be the filename of the file or the full uuid of the story.

marian-m12l commented 3 years ago

Actually, those are little-endian 4-byte integers, so a block actually starts with the less significant byte: <counter> 00 00 00. Although, this is not a counter. Each value refers to a node in the ni file, and may not be ordered because they represent the lists/menu options. But actually yes, we can probably assume the 3 most-significant bytes for each int are 0x00 (we can even be sure if there are no more than 256 nodes in ni). Feel free to take a look at FsStoryPackWriter, I tried to comment how the files are built.

arabine commented 3 years ago

I'm currently developing an open source version of the hardware ; my first step is to be able to load and play the last version of the pack archive and run it on a mobile or PC app. For the moment, the BI_RLE4 format is decoding well, now I have to display the result with a custom palette ...).

marian-m12l commented 3 years ago

Some other interesting tidbits:

marian-m12l commented 3 years ago

@arabine That's a nice project. Good to see the fast progress! :+1: IIRC the color palette may not be the same for all files, though :/

arabine commented 3 years ago

@marian-m12l I have an old box that seems to run an Atmel chip, guessed by the USB driver used. Then they switched to Sonix. Maybe this guy can help :D https://www.lehibou.com/freelance/developpeur-embarque/17941