Lunii V3 - new reverse engineering efforts and advices

[olup]

Hello, creator of lunii-admin and lunii-admin-web here.

I am poking around the new lunii v3. They advertise network-based-only pack installation, but actually the device is still a USB mass storage and should be workable the same way we do it now.

However, metadata file has changed, and clearly the "encryption" algorithms too (for instance, pack boot file is now 32 bytes - was 64 - and file decryption does not work with the v2 method).

I could make sense of the .md file from the LuniiStore app java class decompilation, but as the encryption and boot file generation seems to come from the cloud, I guess the only route is firmware decompilation itself, obtained from the updater api ?

Is that the way you took initially with the v1/v2 ? OR was it present in the LuniiStore source code ? If so would you point me to a direction ?

Edit: File encryption method is probably similar, as mp3s are still playable - as only the first block is fuzzed around. But I posit the device specific key is built in a slightly different way. The device uuid also changed - used to be 256 bytes, and is now 48 bytes

Edit2: Actually, thinking about it, the fact that I can't decipher the files could also mean that they are still using xxtea but the common keyhas chnaged.

Cheers

[marian-m12l]

Hello @olup, sorry about the slow reaction time...

All I have is an old V1 device, so I probably won't be of any help, here. However you're correct that the previous cipher algorithm was reversed from the firmware (the arm one, because the sonix mcu on older devices is pretty opaque...). However I did not perform the reverse engineering myself, since I don't own a V2 and I'm not very experienced. Have fun reading issue #122 if you want some context :sweat_smile:

Basically the idea would be to dump flash memory from the mcu and spi flash, using a SWD debug probe and/or a flash probe, then analyze it with ghidra to identify the cipher functions and constants. V2 devices did not have any readout protection or firmware encryption iirc.

Side note: being able to read mp3 files is to be expected if the file is only partially ciphered, since the file format is made of frames.

[zydar16]

Hi, i got the new lunii v3, if i can send you some file or whatever please tell me :)

[DantSu]

Hi,

@marian-m12l @Aptustech Your works on this project is very impressive. I have read all the comments issue of the previous reverse engineering and the only word is "WOOOOW".

On the lunii v3, the common key has changed, I have try to decipher a bmp file and it's not working. Do you have a bmp file 0D15C276 from story of Suzan And Gaston (13 kb). If I have the original header that will be more easier. I wan't to try a brut force to find the new key. Thanks you.

@Aptustech How did you find the first common key ? Have you read this in the Lunii RAM ? Or did you do a brut force ? Or an other way ?

[DantSu]

@zydar16 @olup Can you send me 0D15C276 from story of Suzan And Gaston too ? I wan't to confirm that all lunii v3 have the same common key and the specific key has not be used to cipher all the file header.

[Aptustech]

Key is stored in the flash memory. As the chosen processor do not have a secure enclave the key is sitting here for you to find.

My understanding is the new V3 added an esp32 on top of the existing cortex m7. Due to this I think we can bet on the engineering laziness and changes should be minimal. I think they locked the memory read from JTAG which means firmware extraction is a little harder. May be one of their engineers followed a security design 101 course.

I didn't get a V3 and I've very little time to investigate. If you can not find the new key in brute force, I'll have a small Xmas project.

Keep up the good work.

F.

On Thu, Oct 19, 2023, 10:41 Franck Alary @.***> wrote:

@marian-m12l https://github.com/marian-m12l @Aptustech https://github.com/Aptustech Your works on this is very impressive. I have read all the comments issue of the previous reverse engineering and the only word is "WOOOOW".

On the lunii v3, the common key has changed, I have try to decipher a bmp file and it's not working. Do you have a bmp file 0D15C276 from story of Suzan And Gaston (13 kb). If I have the original header that will be more easier. I wan't to try a brut force to find the new key. Thanks you.

@Aptustech https://github.com/Aptustech How did you find the first common key ? Have you read this in the Lunii RAM ? Or did you do a brut force ? Or an other way ?

— Reply to this email directly, view it on GitHub https://github.com/marian-m12l/studio/issues/387#issuecomment-1770338310, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIECZ6IWL2YXLADTY4246V3YADRUFAVCNFSM6AAAAAA4DRI6OWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONZQGMZTQMZRGA . You are receiving this because you were mentioned.Message ID: @.***>

[olup]

@DantSu you mean to compare the same file on different device to check if there is variation in the the key(s) used right ?

Also yeah, they locked the reading from the jtag, a direct dump from the external flash would be needed.

[DantSu]

@Aptustech Thx for your feedback, So the brut force is a way to consider.

@olup Yes, I wan't to be sure that they not change the method to encrypt header, and if all lunii v3 have same key and encryption method.

[DantSu]

@zydar16 @olup There is my file data. Have you the same ?

[DantSu]

If someone have this story on lunii v2 : Les mondes merveilleux de Suzanne et Gaston That will be helpful.

[vpoulailleau]

@DantSu I have the included "free" pack Les histoires de Suzanne et Gaston on a Lunii v2. Can it be helpul? If yes, which file do you want?

[DantSu]

erf I think, this is not the same pack that I have :/ https://lunii.com/fr-fr/luniistore-catalogue/les-mondes-merveilleux-de-suzanne-et-gaston/

[DantSu]

Something change on mp3, the first 16 bytes are always the same : 92 EF 8E F0 F4 39 C2 09 6C 8F 4E D2 07 C6 AC 24 But that should be impossible with btea algorithm. So I think algorithm encryption has changed for audio files header. Pictures seems to be like lunii v2.

EDIT : It's not impossible, if the 16 first and 509 to 512 bytes are identicals.

[olup]

Is that impossible even if the mp3 have the same first frames ? Anyway, there is a french discord where discussion around the V3 hacks are going on and easier to do than in a gh issue, if you are a french speaker this you do better

Le ven. 20 oct. 2023, 15:49, Franck Alary @.***> a écrit :

Something change on mp3, the first 16 bytes are always the same : 92 EF 8E F0 F4 39 C2 09 6C 8F 4E D2 07 C6 AC 24 But that should be impossible with btea algorithm. So I think algorithm encryption has changed for audio files header. Pictures seems to be like lunii v2.

— Reply to this email directly, view it on GitHub https://github.com/marian-m12l/studio/issues/387#issuecomment-1772776671, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADJFT5BLHPAJLKAATKQIFJ3YAJ6QDAVCNFSM6AAAAAA4DRI6OWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONZSG43TMNRXGE . You are receiving this because you were mentioned.Message ID: @.***>

[Benroxxx]

@DantSu , I've got the V2

Les mondes merveilleux de Suzanne et Gaston 

What do you need, how can I provide it to you?

[DantSu]

@DantSu , I've got the V2

Les mondes merveilleux de Suzanne et Gaston 

What do you need, how can I provide it to you?

Thx for your reply. I have found someone with same stories as mine. We works on the v3 hack.

[marian-m12l]

@DantSu I found out on friday about V3 support on your repo, congrats!! Is it stable yet? I started porting the changes in branch feature/v3. Untested of course because I don't have a recent device to test on. I should still make sure I didn't break v2 compatibility, especially since I tweaked the behaviour to keep the packs as cleartext in the library (something I wanted to do already for v2 packs).

I am right about the changes in V3?

• the first 512 bytes of files are ciphered with AES/CBC with a device-specific key (instead of XXTEA with a common key)
• the bt file simply contains part of the device-specific key, which would make it the same for all story packs (did I miss something here?!)
• the device-specific key is derived from the metadata file, in part from the serial number

[olup]

@marian-m12l I also implemented the port in lunii-admin-web (https://github.com/olup/lunii-admin-web), I can answer most of your questions.

the first 512 bytes of files are ciphered with AES/CBC with a device-specific key (instead of XXTEA with a common key)

Yes, spot on. The AES in this case uses a key that is given in the BT file of the story

the bt file simply contains part of the device-specific key, which would make it the same for all story packs (did I miss something here?!)

Stock stories' BT file will contain the encryption key+iv for the specific story, used to encrypt all its files. The BT file itself is then encrypted with the device specific key.

So there is a decorrelation between the story encryption and the device key.

the device-specific key is derived from the metadata file, in part from the serial number

Not exactly. The device specific key is more difficult to obtain than in the v2, and it involves hardware tempering.

So this is where some creative thinking was involved, resulting to what you see in the codebase. I'll mail you the definitive approach, as I remember the group not wanting to put it all out there.

[DantSu]

@DantSu I found out on friday about V3 support on your repo, congrats!! Is it stable yet? I started porting the changes in branch feature/v3. Untested of course because I don't have a recent device to test on. I should still make sure I didn't break v2 compatibility, especially since I tweaked the behaviour to keep the packs as cleartext in the library (something I wanted to do already for v2 packs).

I am right about the changes in V3?

• the first 512 bytes of files are ciphered with AES/CBC with a device-specific key (instead of XXTEA with a common key)
• the bt file simply contains part of the device-specific key, which would make it the same for all story packs (did I miss something here?!)
• the device-specific key is derived from the metadata file, in part from the serial number

Hi, I have use the v0.4.2 of kairoh fork, But this is changes that I made. That will be the same on your version.

Get metadata change : https://github.com/DantSu/studio/blob/7560ca55308c81d7a1e887ab9755daefb2e97b14/driver/src/main/java/studio/driver/fs/FsStoryTellerAsyncDriver.java#L144C1-L144C1

AES Cipher class : https://github.com/DantSu/studio/blob/master/core/src/main/java/studio/core/v1/utils/AESCBCCipher.java

The addboot file is static in Kairoh version but for your version, you can do an abstract class of FsStoryPackWriter and create FsStoryPackWriterV2 and V3 : https://github.com/DantSu/studio/blob/master/core/src/main/java/studio/core/v1/writer/fs/FsStoryPackWriter.java https://github.com/DantSu/studio/blob/master/core/src/main/java/studio/core/v1/writer/fs/FsStoryPackWriterV3.java

Upload file change, wee need deviceInfos for copyPackFolder : https://github.com/DantSu/studio/blob/7560ca55308c81d7a1e887ab9755daefb2e97b14/driver/src/main/java/studio/driver/fs/FsStoryTellerAsyncDriver.java#L430C42-L430C42 Copy pack folder change : https://github.com/DantSu/studio/blob/7560ca55308c81d7a1e887ab9755daefb2e97b14/driver/src/main/java/studio/driver/fs/FsStoryTellerAsyncDriver.java#L502C29-L502C29

https://github.com/DantSu/studio/blob/7560ca55308c81d7a1e887ab9755daefb2e97b14/driver/src/main/java/studio/driver/fs/FsStoryTellerAsyncDriver.java#L446

That it.

[marian-m12l]

@olup @DantSu Thanks for all the info! (and for figuring it out of course!!) I've cleaned up the branch, but I have yet to validate that I didn't break v2 support. Since I don't own a v3 device I won't be able to validate. If anyone feels adventurous (and is comfortable resetting their storyteller) I'll wait for some real-world testing and feedback before merging and making a release.

exit: v2 does not seem to be broken :smile:

[djcaesar9114]

@olup @DantSu Thanks for all the info! (and for figuring it out of course!!) I've cleaned up the branch, but I have yet to validate that I didn't break v2 support. Since I don't own a v3 device I won't be able to validate. If anyone feels adventurous (and is comfortable resetting their storyteller) I'll wait for some real-world testing and feedback before merging and making a release.

exit: v2 does not seem to be broken 😄

Hello/Bonjour, I've a Lunii v3 and will be happy to be a tester. Just tell me what I have to do. You can DM me on Twitter if you don't want to pollute this thread. Merci beaucoup pour ce super travail!

[marian-m12l]

@olup @DantSu Thanks for all the info! (and for figuring it out of course!!) I've cleaned up the branch, but I have yet to validate that I didn't break v2 support. Since I don't own a v3 device I won't be able to validate. If anyone feels adventurous (and is comfortable resetting their storyteller) I'll wait for some real-world testing and feedback before merging and making a release. exit: v2 does not seem to be broken 😄

Hello/Bonjour, I've a Lunii v3 and will be happy to be a tester. Just tell me what I have to do. You can DM me on Twitter if you don't want to pollute this thread. Merci beaucoup pour ce super travail!

You have to be aware that there's a significant chance for failure, and be comfortable resetting your device if needed. I don't own a V3 device and would be of very little assistance.

All you have to do is checkout branch feature/v3 and run the maven build according to instructions in the readme.

[djcaesar9114]

@olup @DantSu Thanks for all the info! (and for figuring it out of course!!) I've cleaned up the branch, but I have yet to validate that I didn't break v2 support. Since I don't own a v3 device I won't be able to validate. If anyone feels adventurous (and is comfortable resetting their storyteller) I'll wait for some real-world testing and feedback before merging and making a release. exit: v2 does not seem to be broken 😄

Hello/Bonjour, I've a Lunii v3 and will be happy to be a tester. Just tell me what I have to do. You can DM me on Twitter if you don't want to pollute this thread. Merci beaucoup pour ce super travail!

You have to be aware that there's a significant chance for failure, and be comfortable resetting your device if needed. I don't own a V3 device and would be of very little assistance.

All you have to do is checkout branch feature/v3 and run the maven build according to instructions in the readme.

I've just tested on Linux: sadly, it doesn't work: the Lunii doesn't appear in the web client. Something should appear on the left, but the screen remains unchanged. Here is the log:

2023-12-27 23:21:35,941 [INFO ] [s.d.LibUsbDetectionHelper]: Hotplug event callback (0483:a341): 2
2023-12-27 23:21:35,941 [INFO ] [s.w.s.StoryTellerService]: Device 2.x unplugged
2023-12-27 23:21:44,443 [INFO ] [s.d.LibUsbDetectionHelper]: Hotplug event callback (0483:a341): 1
2023-12-27 23:21:44,443 [DEBUG] [s.d.f.FsStoryTellerAsyncDriver]: Waiting for device partition...
2023-12-27 23:21:46,602 [INFO ] [s.d.f.FsStoryTellerAsyncDriver]: FS device partition located: /media/cesar/LUNII
2023-12-27 23:21:46,602 [INFO ] [s.w.s.StoryTellerService]: Device 2.x plugged
2023-12-27 23:21:46,603 [DEBUG] [s.d.f.FsStoryTellerAsyncDriver]: Firmware version: 3.1
2023-12-27 23:21:46,604 [INFO ] [s.d.f.FsStoryTellerAsyncDriver]: Serial Number: 23223030013358
2023-12-27 23:21:46,604 [DEBUG] [s.d.f.FsStoryTellerAsyncDriver]: SD card size: 7939817472
2023-12-27 23:21:46,604 [DEBUG] [s.d.f.FsStoryTellerAsyncDriver]: SD card used space: 149422080

When I switch off the Lunii I've got a message "Fabrique à histoires débranchée", but nothing happens when I switch it on again. If I continue switching on and off again I only get the same messages in the log and in the web client.

In the client console I have this message on every switchoff:

Receivedstoryteller.unpluggedevent from vert.x event bus.

Followed by a large JSON object:

[DantSu]

@djcaesar9114 In the meantime, You can use this release that works with your lunii v3 https://github.com/DantSu/studio/releases/tag/0.5.1

[djcaesar9114]

@djcaesar9114 Meanwhile, You can use this release that works with your lunii v3

Oh, which release :) ? The current master of this repo or the latest release of your fork?

[DantSu]

Lol I forgot the link. I edited my previous comment.

[djcaesar9114]

Lol I forgot the link. I edited my previous comment.

OK I've tested it on Linux, it works like a charm. I think I've got a lot of story writing to do, I won't go to bed very soon... Thanks Franck!

[marian-m12l]

@djcaesar9114 Thanks for the feedback!

Did you try refreshing the web interface when the device is plugged? There could be an issue with the message to the web interface.

Looks like the device is detected correctly and the new metadata format is also read correctly. Which is really the only difference at this point.

[marian-m12l]

@djcaesar9114 I fixed an issue with device infos collection, which is probably the error you hit. Is it any better?

[djcaesar9114]

@djcaesar9114 I fixed an issue with device infos collection, which is probably the error you hit. Is it any better?

I can't find your fix, neither in the branches, nor your GitHub activity. Is it in a private clone repo?

[marian-m12l]

@djcaesar9114 I fixed an issue with device infos collection, which is probably the error you hit. Is it any better?

I can't find your fix, neither in the branches, nor your GitHub activity. Is it in a private clone repo?

The fix is in branch feature/v3

[djcaesar9114]

OK my bad I read to fast, I didn't see the recent changes, I was looking for "hours" and I missed the "days"... Everything works fine, I'm still wondering why there is a 0.5.1 from the fork of @DantSu . Don't you want to work on the same repo and make merge requests?

Thanks a lot anyways, it's really a great job!

[marian-m12l]

@djcaesar9114 Thanks for taking the time to test it :+1: were you able to list stories and to transfer stories from/to the storyteller?

Some forks have diverged a lot by now, which means merging would take a lot of efforts. I wish I could dedicate more time and energy to maintaining the repo and handling issues. V3 support seems important, so I'd like to merge that.

[djcaesar9114]

Well, sadly it doesn't allow me to import:

2023-12-30 17:54:18,156 [ERROR] [s.w.s.StoryTellerService]: Failed to add pack to device
java.util.concurrent.CompletionException: studio.driver.StoryTellerException: Failed to copy pack folder
    at java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:314)
    at java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:319)
    at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1702)
    at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.exec(CompletableFuture.java:1692)
    at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
    at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
    at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656)
    at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
    at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:183)
Caused by: studio.driver.StoryTellerException: Failed to copy pack folder
    at studio.driver.fs.FsStoryTellerAsyncDriver.lambda$copyPackFolder$20(FsStoryTellerAsyncDriver.java:583)
    at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
    at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
    at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
    at java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
    at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
    at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
    at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
    at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
    at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
    at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:497)
    at studio.driver.fs.FsStoryTellerAsyncDriver.copyPackFolder(FsStoryTellerAsyncDriver.java:518)
    at studio.driver.fs.FsStoryTellerAsyncDriver.lambda$uploadPack$13(FsStoryTellerAsyncDriver.java:460)
    at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1700)
    ... 6 more
Caused by: java.lang.RuntimeException: javax.crypto.IllegalBlockSizeException: Input length not multiple of 16 bytes
    at studio.driver.fs.AESCBCCipher.cbc(AESCBCCipher.java:47)
    at studio.driver.fs.AESCBCCipher.cipher(AESCBCCipher.java:26)
    at studio.driver.fs.CipherUtils.cipherFirstBlockSpecificKeyV3(CipherUtils.java:118)
    at studio.driver.fs.FsStoryTellerAsyncDriver.lambda$copyPackFolder$20(FsStoryTellerAsyncDriver.java:555)
    ... 19 more
Caused by: javax.crypto.IllegalBlockSizeException: Input length not multiple of 16 bytes
    at java.base/com.sun.crypto.provider.CipherCore.finalNoPadding(CipherCore.java:1115)
    at java.base/com.sun.crypto.provider.CipherCore.fillOutputBuffer(CipherCore.java:1059)
    at java.base/com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:853)
    at java.base/com.sun.crypto.provider.AESCipher.engineDoFinal(AESCipher.java:446)
    at java.base/javax.crypto.Cipher.doFinal(Cipher.java:2202)
    at studio.driver.fs.AESCBCCipher.cbc(AESCBCCipher.java:44)
    ... 22 more

If I try again with @DantSu for the same packs, it works.

[marian-m12l]

@djcaesar9114 Thanks. I messed up with the padding. Should be fixed now.

[djcaesar9114]

Still can't import do to this error:

11:00,079 [TRACE] [s.d.f.FsStoryTellerAsyncDriver]: Copying file /home/cesar/.studio/library/5a7d2931-bf67-428e-9b7d-39b0ffc86b38.converted_1703717167072/si to /media/cesar/LUNII/.content/FFC86B38/si (60 bytes)
2023-12-30 18:11:00,081 [ERROR] [s.w.s.StoryTellerService]: Failed to add pack to device
java.util.concurrent.CompletionException: studio.driver.StoryTellerException: Failed to copy pack folder
    at java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:314)
    at java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:319)
    at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1702)
    at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.exec(CompletableFuture.java:1692)
    at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
    at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
    at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656)
    at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
    at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:183)
Caused by: studio.driver.StoryTellerException: Failed to copy pack folder
    at studio.driver.fs.FsStoryTellerAsyncDriver.lambda$copyPackFolder$20(FsStoryTellerAsyncDriver.java:583)
    at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
    at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
    at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
    at java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
    at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
    at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
    at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
    at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
    at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
    at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:497)
    at studio.driver.fs.FsStoryTellerAsyncDriver.copyPackFolder(FsStoryTellerAsyncDriver.java:518)
    at studio.driver.fs.FsStoryTellerAsyncDriver.lambda$uploadPack$13(FsStoryTellerAsyncDriver.java:460)
    at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1700)
    ... 6 more
Caused by: java.nio.BufferOverflowException
    at java.base/java.nio.HeapByteBuffer.put(HeapByteBuffer.java:221)
    at java.base/java.nio.ByteBuffer.put(ByteBuffer.java:914)
    at studio.driver.fs.CipherUtils.cipherFirstBlockSpecificKeyV3(CipherUtils.java:120)
    at studio.driver.fs.FsStoryTellerAsyncDriver.lambda$copyPackFolder$20(FsStoryTellerAsyncDriver.java:555)
    ... 19 more

[marian-m12l]

ok, I guess I need to take a little more time to test these functions on my side. I'll let you know when I have a fix.

[marian-m12l]

@djcaesar9114 cipher utils class looks ok now

[djcaesar9114]

It more than looks OK, it is. I can import the packs with no error, and the stories work.

[marian-m12l]

Great! Thanks for testing!

[marian-m12l]

Merged in master

[djcaesar9114]

Thanks, I created some issues, some of them are minor but one of them seems major.

Et bonne année!

[DantSu]

OK my bad I read to fast, I didn't see the recent changes, I was looking for "hours" and I missed the "days"... Everything works fine, I'm still wondering why there is a 0.5.1 from the fork of @DantSu . Don't you want to work on the same repo and make merge requests?

Thanks a lot anyways, it's really a great job!

To begin with, many of us believe that the marian-m12l/studio project has been abandoned. Consequently, there have been numerous forks to continue improving it, notably Kairoh's fork, which fix many issues with STUdio, enhances speed, and optimizes various aspects.

The problem is that Kairoh do a complete refactor from v1.0.0 that introduced bugs without providing significant improvements. Therefore, the 0.4.2 version by Kairoh is considered by many as one of the most stable and optimized versions of STUdio.

That's why I didn't create a fork but instead started from Kairoh's version 0.4.2 to develop my version 0.5.1 of STUdio.

[djcaesar9114]

OK my bad I read to fast, I didn't see the recent changes, I was looking for "hours" and I missed the "days"... Everything works fine, I'm still wondering why there is a 0.5.1 from the fork of @DantSu . Don't you want to work on the same repo and make merge requests? Thanks a lot anyways, it's really a great job!

To begin with, many of us believe that the marian-m12l/studio project has been abandoned. Consequently, there have been numerous forks to continue improving it, notably Kairoh's fork, which fix many issues with STUdio, enhances speed, and optimizes various aspects.

The problem is that Kairoh do a complete refactor from v1.0.0 that introduced bugs without providing significant improvements. Therefore, the 0.4.2 version by Kairoh is considered by many as one of the most stable and optimized versions of STUdio.

That's why I didn't create a fork but instead started from Kairoh's version 0.4.2 to develop my version 0.5.1 of STUdio.

OK, I understand. I think this development is a niche and it would be great if people could join their forces. Sadly, that is not a language I'm expert in, so I can't help that much except when it comes to testing.

[apic-jeremy]

File : https://we.tl/t-RNpkiAkxTp

I recently get a Lunii V3 instead my usually V2 (warranty exchange :)) And i try convert story, but it getting me an error :

2024-02-21 22:20:07,260 [ERROR] [s.w.s.LibraryService]: Failed to convert FS format pack to archive format java.nio.file.InvalidPathException: Illegal char <?> at index 45: C:\Users\CZ5387\.studio\library\38260255\rf\,?´┐¢L´┐¢´┐¢▼7´┐¢r´┐¢´┐¢ at java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182) at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153) at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77) at java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92) at java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:232) at java.base/java.io.File.toPath(File.java:2387) at studio.core.v1.reader.fs.FsStoryPackReader.read(FsStoryPackReader.java:151) at studio.webui.service.LibraryService.addConvertedArchivePackFile(LibraryService.java:279) at studio.webui.api.LibraryController$3.run(LibraryController.java:114) at java.base/java.util.TimerThread.mainLoop(Timer.java:566) at java.base/java.util.TimerThread.run(Timer.java:516) Exception in thread "Timer-0" java.lang.RuntimeException: Failed to convert FS format pack to archive format at studio.webui.service.LibraryService.addConvertedArchivePackFile(LibraryService.java:297) at studio.webui.api.LibraryController$3.run(LibraryController.java:114) at java.base/java.util.TimerThread.mainLoop(Timer.java:566) at java.base/java.util.TimerThread.run(Timer.java:516) Caused by: java.nio.file.InvalidPathException: Illegal char <?> at index 45: C:\Users\CZ5387\.studio\library\38260255\rf\,??L??▼7?r?? at java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182) at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153) at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77) at java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92) at java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:232) at java.base/java.io.File.toPath(File.java:2387) at studio.core.v1.reader.fs.FsStoryPackReader.read(FsStoryPackReader.java:151) at studio.webui.service.LibraryService.addConvertedArchivePackFile(LibraryService.java:279) ... 3 more