Hello,
I’m having problem to find a solution to my issue, I make a log and receive 2 bytes as SEED, and 4 bytes are the KEY to send to the ECU in my communication, I’ll be clearer.
I make the communication with the ECU, then I send a command to request the SEED, the ECU sends to me 2 bytes, then I have to send the key, which are 4 bytes are right key. What I need is the algorithm to calculate the KEY to send, since I have the SEED and the Result.

Received SEED ........................................................ KEY Sent
92 90 <<<<<<< if I receive this, how I get this >>>>>>> 02 2A 7C 90
BC BB .................................................................... 31 A0 21 1F
73 90 .................................................................... 17 A7 B7 60
19 CA .................................................................... 0B B9 53 3A
8A 53 .................................................................... 01 4B BE F4
(OS. This SEED’s and KEY’s are valid).

I hope someone could help me to solve this problem; I’m took several days to analyze this and haven’t any result.

This is a total shot in the dark, but this COULD be a "Diffie-Hellman key exchange".

More info is required.

You request the seed from the ECU, how is it transmitted? USB? CAN Bus?
What is the software that generates the key?
Does it run on a PC?
If so, what OS?
Can you inject values? (Change the SEED value to 00 00, and see if you always get the same Key).

A good validation test protocol, worth its salt, is supposed to be resistant to the type of analysis that you are proposing. The blackbox approach:

Know the input
know the output

find out the algorithm?

If you can your get your hands on the program that generates the KEY given a SEED, you could reverse engineer it.

Give that there are only FFFF possible seeds, you could could construct an exhasutive look-up table, by making a one to one relationship between each possible SEED and the resulting KEY

However, keep in mind that the algorithm may have an internal, private SEED that is composed with the received (Public) SEED, to generate the valid KEY.

Finally, a really solid crypt system should be non-reversible: With a KNOWN (public) SEED and a KNOWN (Private) SEED you can generate a valid KEY.

But even if you know a (public) SEED and a valid KEY, you cannot deduce a (Private) SEED, regardless if you know the algo internal workings. . .