Hacking lz7 Format (Lets Tap)

[Pyrii]

I've been poking around the Lets Tap files and have come to an impasse at the .arc.lz7 files, I can't seem to find anything to expand/extract the lz7 format, and RARC doesn't work, my guess is lz7 is a wrapper for an encased RARC file.

WiiBrew offers source code for LZ7 but I'm no programmer, I wondered if there are tools already available.

 

[ether2802]

mmmmm.... you may want to PM to those guys messing with animated banners or directly at the wiibrew.org forums...!!!

 

[stayingarmed]

are you saying you downloaded a file and the extension is lz7? If so, you need 7zip to extract the file.....if not then sorry and disregard my answer.

 

[Noitora]

are you saying you downloaded a file and the extension is lz7? If so, you need 7zip to extract the file.....if not then sorry and disregard my answer.

Umm, no in fact that would work, I'm not sure if LZ77 compressors can decompress this file (I guess they can)
Google for these tools:
GBADECMP
Nintenlord's lz77 decompressor

they should be able to uncompress the files

 

[stayingarmed]

again, sorry but I thought he may have been talking about a file compressed inside of a lz7 file (which is a compression extension of that program)

Just goes to show how much I know. haha

 

[stev418]

You will probably need to edit the header on the file to use Nintenlord's lz77 decompressor. Also nintendo use a few variations of the LZ77 so Nintenlord's lz77 decompressor may not work.

Best bet, grab the tools in wwpacker (here on gbatemp) and use the tool wwcxtool.exe with command line -> wwcxtool /u xxxxxxxx.arc.lz7 NEWFILE.arc

Then you will no doubt need to unpack the ARC file, just grab U8tool from Howardc tools thread.

you should then get to see the little goodies inside

 

[Pyrii]

S:\LetsTap>wwcxtool /u Bubble.arc.lz7 Bubble.arc

Error: Cannot write file!


S:\LetsTap>dir /w
Volume in drive S is Scratch
Volume Serial Number is E20E-CC3A

Directory of S:\LetsTap

[.]ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ[..]ÂÂÂÂÂÂÂÂÂÂÂÂÂÂ [BGM]ÂÂÂÂÂÂÂÂÂÂÂÂÂÂBlock.arc.lz7
[Boot]ÂÂÂÂÂÂÂÂÂÂÂÂ Bubble.arcÂÂÂÂÂÂÂÂ Bubble.arc.lz7ÂÂÂÂ Common.arc.lz7
Drum.arc.lz7ÂÂÂÂÂÂ GBACrusherCL.exeÂÂ [hbm]ÂÂÂÂÂÂÂÂÂÂÂÂÂÂHurdle.arc.lz7
opening.bnrÂÂÂÂÂÂÂÂRhythm.arc.lz7ÂÂÂÂ [tanpin]ÂÂÂÂÂÂÂÂÂÂ wwcxtool.exe
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂ10 File(s)ÂÂÂÂ 45,594,107 bytes
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂ 6 Dir(s)ÂÂ197,370,589,184 bytes free

S:\LetsTap>

Not exactly the most helpful error to be honest.

And GBADecmp just blows up. Looking at the file directly shows no obvious header information (But there is a garbled file list) so I'm stuck again.

 

[stev418]

S:\ drive is an internal hdd or something else?

 

[Pyrii]

I like partitioning. S is leftover space on my single hard drive in my lappy. For basically either working with large amounts of stuff or dumping stuff to sort out later. SHould see the scratch on my server... ugh.

 

[stev418]

yeah, get the same thing here :\ how many lz7 variants are there ????

 

[Pyrii]

Knowing SEGA, it may not even be LZ7

EDIT: Can't believe I forgot to say this, but thanks to people who've offered solutions so far. Even if it didn't work, the help is appreciated.

 

[stev418]

lol, well i 'partly' extracted the file. I still used wwcxtool but edited the header of the file, i got a few files extracted correctly. but a lot of 0kb files, hey its a start

i replace everything before Uª8 in the header with the hex from another lz7 from nintendo --> 11 C2 33 0E 00

then unpacked the file with U8tool

there seems to be heaps of .brres and .arc files inside, 68 files in total, you can then use U8Tool on the .arc files

I suppose if you can work out the proper header hex, youd be set

EDIT: from what i can tell the header contains the Hexidecimal size value of the file uncompressed, just not sure what offsets it uses

11 C2 33 0E 00 (11 would = the LZ77 compression variant used)

 

[Pyrii]

i replace everything before Uª8 in the header with the hex from another lz7 from nintendo --> 11 C2 33 0E 00

11 C2 33 0E 00 (11 would = the LZ77 compression variant used)

Hmm, I left the first 4 bytes alone (data length) and edited the next few bytes before 55 AA 38 to make 11 C2 33 0E 00 55 AA 38 but wwcxtool still says it can't write file... Vista problem?

EDIT: My bad, I got the offset wrong, your hex comes in at 0x0

 

[Pyrii]

I've tried playing with the LZ7 header (without really knowing what I'm doing either lol) and can't seem to get anything but a 909kb file out of it. Without the correct header size I'm guess we'll only get a partial extraction.

EXTRA: I just found that Common.arc.lz7 has it's header intact, so I implanted it's header into Bubble and got a matching filesize outputted. It seems everything except common has it's header stripped. Maybe the headers are in common...

• Common.arc.lz7: 11 A0 EF F6 00 (6,506KB)
• Drum.arc.lz7: 11 00 00 00 20 44 5B 01 00 (10,675KB)
• Hurdle.arc.lz7: 11 E0 C5 E5 00 (6,268KB)
• Bubble.arc.lz7: 11 00 00 00 20 32 32 01 00 (8,261KB)
• Rhythm.arc.lz7: 11 00 00 00 20 B6 18 01 00 (8,395KB)
• Block.arc.lz7: 11 40 E1 6D 00 (3,770KB)

Okay, maybe not every file...

EDIT: It occurred to me that the headers of the 00000020 files are padded, remove the 00000020 and you get an lz7 header that matches other files, but still seems wrong as extraction produces undersized files. List is changed to show the extra bits before the U8 header. Maybe the 20 is significant.

I've also asked for some help with the new brsar file format: http://hcs64.com/mboard/forum.php?showthread=13236

EDIT2: underlined byte controls filesize/chunk size.
EDIT3: Added filesize because I just noticed something... important.
EDIT4: Uploaded a selection of .arc.lz7 files, which are Rhythm, Bubble and Common. 1 working, 2 not,

 

[Pyrii]

Bumping for justice. From what I can determine, the new headers are actually significant, what I can see is that because the files are too large for a normal header to indicate the size of the file (Maximum of F7 in hex) they've changed the header to indicate a dynamic file. And of course wwcxtool is limited to normal headers. So I asked the author to take a look: http://gbatemp.net/index.php?s=&showto...t&p=1717271

So as indicated above, Common.arc.lz7 is pretty much at the limit of the old method, which is why it works, the files that are too large have padded bytes which I guess help indicate the new filetype and the old header is pushed along with it's filesize byte pretty much set to nothing(01). Most of the detail is above. Including links to files.

As this pretty much requires a new tool to read these new type of LZ7 files, I'm pretty much reaching the end of my usefulness here. Thanks to hcs, there's a new ripping_mama and vgmstream to rip rwavs from the brsars I'm trying to get at, and plays them perfectly. But these brsars are at the end of the files, so partial extraction isn't working XD oh well. Thanks for stev418 and hcs for getting me this far.

 

[Pyrii]

Sorry for the quadruple post/bump, I just wanted to update that after pointing this at alpha0000, there's a new copy of wwcxtool that reads these new lz7 files. So thanks to him/her for a fix to this.

Head over here for wwcxtool: http://gbatemp.net/index.php?act=ST&f=108&t=95479

So issue solved for anyone wanting an answer.