@utc_pyro: Nice try but ...
First you need to understand (standard) SSM/SSM2 addresses are sort of fake or virtual as they don't represent real hardware addresses the processor uses. Think of them like defined IDs. The ROM includes SSM subroutines that handle incoming SSM requests and generate a response packet.
Example: on most ECUs requesting byte at 0x00001C yields battery voltage (value/12.5 = volts).
Address/ID 0x00001C tells it what you want. So far I've seen the ROM code uses either redirection table or function table lookup to generate the corresponding answer byte.
The virtual SSM address space is limited as this thing needs extra space and there's a limited number of measuring blocks than it supports anyway. Rather new ECUs limit addresses to being smaller than 0x350. Older ECUs have smaller address spaces like 0x200 or 0x150 bytes etc. If you request addresses above the limit, you just get constant fake byte 'FF' for these. SSM2 over CAN would tell you an error, SSM over serial line doesn't tell errors, reporting fake content instead or ignoring the entire request.
Another thing: Block read command A0 may not work for standard range e.g. 0x000000..0x00034F like on my ECU. I only get FFs by doing this. I've also heard some people get inconsistent data. In that case you'll have to use (slow) A8 messages. Again, that's a deliberate limitation compiled into the ROM software.
RAM case exception: Specific to firmware/model some RAM ranges are allowed which map almost directly to hardware addresses.
Example for 32bit control units: an SSM2 address like 0xFF1234 is a RAM address, highest address byte is FF, far beyond normal address range. It will be translated internally to 0xFFFF1234 which now is a real 32bit hardware address the CPU works with. One can dump real RAM by A8 or better A0 commands with this but only from the ranges that the firmware code allows. Outside valid range(es) you probably get fake FFs again.
SSM message length in general is limited, too. Modern ECUs take up to 255 bytes limiting the number of data bytes one can request/get per single message. Older units may use smaller buffers.
I think with your fubar TCU responses there must be something wrong with your tool. If there's not even a valid response header you should not even touch the msg with a stick.
IMHO there is NO way you can dump ROM using standard SSM2 commands like 'A8' or 'A0'.
If you want to know inner workings of SSM2 protocol you can disassemble available ROMs and see for yourself.
Flashing/dumping ROM is a different story. Sniffing a flash is a good idea but Subaru dealer tools transfer all data in encrypted form.
Makes sense? Haven't played with a TCU yet but it seems same SSM principles apply.
