Author Topic: .  (Read 6223 times)

Jenova's Witness

  • Right Wing Safety Squads
  • *
  • Posts: 471
  • I ♥ SCIENCE
    • View Profile
.
« on: 2014-09-04 00:53:23 »
.
« Last Edit: 2015-11-16 07:36:26 by Jenova's Witness »

Bosola

  • Fire hazard!
  • *
  • Posts: 1752
    • View Profile
    • My YouTube Channel
Searching the disc image won't work; you're assuming the executable is unencoded and uncompressed. No, you're going to have to trace writes to the memory location where the instruction lives, then follow the writes back to a disc access instruction.

It won't be a convenient process but I can't see how else you would do it.

Jenova's Witness

  • Right Wing Safety Squads
  • *
  • Posts: 471
  • I ♥ SCIENCE
    • View Profile
.
« Reply #2 on: 2014-09-06 01:59:27 »
.
« Last Edit: 2015-11-16 07:36:35 by Jenova's Witness »

Jenova's Witness

  • Right Wing Safety Squads
  • *
  • Posts: 471
  • I ♥ SCIENCE
    • View Profile
.
« Reply #3 on: 2014-09-09 04:56:56 »
.
« Last Edit: 2015-11-16 07:36:45 by Jenova's Witness »

Vehek

  • *
  • Posts: 215
    • View Profile
Sorry for missing your report until now.

Those first 4 bytes? Either keep them on or use the "no-header" option. Those bytes are the header (compressed size). Also, the decompressed output should be completely identical to BATTLE.OUT. So, actually, you should be able to skip decompressing the data and go straight to editing and recompressing.
Edit:
Looks like when working with a header, myst6re's unlzs is extremely picky. If there are any extra bytes beyond the specified compressed size, it complains. And the subfile's size as derived from the ARC header does exactly that. Delete the last two bytes (F1 D2).
« Last Edit: 2014-09-23 02:40:46 by Vehek »

Jenova's Witness

  • Right Wing Safety Squads
  • *
  • Posts: 471
  • I ♥ SCIENCE
    • View Profile
.
« Reply #5 on: 2014-10-05 02:30:50 »
.
« Last Edit: 2015-11-16 07:36:54 by Jenova's Witness »

Vehek

  • *
  • Posts: 215
    • View Profile
First four bytes of what?  The *.ARC header?
First 4 bytes of the first subfile, what you called "pointer of the last, missing file on it.", 86 A5 03 00. These bytes are the LZS header.

Quote
I don't specify the compressed size because I understood that I didn't have to if I was just using the whole sub-file.
By specifying the compressed size, I'm talking about the LZS header. When working in validate header mode (the default), myst6re's tool demands that the remaining file length after the header matches the value of the header exactly. Otherwise it'll throw up that "Invalid LZS header" error message.

Quote
Quote
And the subfile's size as derived from the ARC header does exactly that.
What?
According to the LZS header, the compressed data is 0x3A586 (238982) bytes long. Adding the 4 bytes taken up by the header, the LZS file would be 238986 bytes long. But a length of 238988 bytes, the subfile length you got from the ARC header, is 2 bytes more than that. See my point just above.

Quote
The last two bytes of the *.ARC header, the last two bytes of which specific subfile, or the last two bytes of the whole ARC file?
Last two bytes of the first subfile. I don't know why they're there, but they don't seem to be used. I tried setting a breakpoint while entering battle and they didn't get read.

Steps:
1. Extract the subfiles from BATTLE.ARC
2. Using a hex editor, delete the final two bytes, F1 D2, from the first subfile.
3. Run unlzs on the first subfile.
4. If all went well, you should have a decompressed file with a length of 516688 bytes. It should be identical down to the last byte to BATTLE.OUT.
« Last Edit: 2014-10-05 04:30:01 by Vehek »

Jenova's Witness

  • Right Wing Safety Squads
  • *
  • Posts: 471
  • I ♥ SCIENCE
    • View Profile
.
« Reply #7 on: 2014-10-15 22:09:47 »
.
« Last Edit: 2015-11-16 07:37:04 by Jenova's Witness »