[Frogman]

Originally Posted by MyFastM3

Just a random thought ...... would this tool not work for other FSC codes? Like the collision warning system ?

I don't think so.

The tool generates the "short" FSC code that can be entered via the iDrive for maps. It's only for maps.

Other FSC's are full, signed code files have to be imported into the car thought the Enet connection and some software.

[pikcachu]

Originally Posted by Aritaurus

You need to encode it to Base64 right after or else it won't work with the generator.

http://www.motobit.com/util/base64-decoder-encoder.asp

Use this website, load the .fsc file in there then convert and open a new text fiew and copy everything into one line and copy the new file over the old .fsc file.

weird... for some reason now one of the generators says:

"version after create() = 0xD1"

and the other generator says "fields!" in the code box

[steve@codemybimmer]

Originally Posted by pikcachu

weird... for some reason now one of the generators says:

"version after create() = 0xD1"

and the other generator says "fields!" in the code box

When you copy and paste the output back into the .fsc file, make sure it's all in one line.

[pikcachu]

Originally Posted by Aritaurus

When you copy and paste the output back into the .fsc file, make sure it's all in one line.

Ya it's in 1 line also :-s

[steve@codemybimmer]

Originally Posted by pikcachu

Ya it's in 1 line also :-s

You need to save it as a .fsc file

[steve@codemybimmer]

Hmm weird, are you sure that it's the DE file you extracted? I tried generating the code as well even changing the file extension to .fsc and it still doesn't work.

I don't think you grabbed the correct file from your car.

[Frogman]

Originally Posted by pikcachu

Ya it's in 1 line also :-s

This does look like a DE file, but when I try to generate an FSC code for it, it fails with a message saying it does not contain enough fields.

Comparing it to another DE FSC file I have, I see that your FSC code has spaces (0x20) where the good FSC has NUL's (0x00). So, I edited your "bad" FSC file and it's now acceptable to the genreator.

Something strange seems to happen when you read the DE FSC code via E-Sys that does not agree with the generator.

Your signature does not indicate your geography or what map version you want, so I can't generate your FSC code. If you post which map you want, an FSC can be generated, just no guarantee that it will work because of the edits.

Here is the diff:

fc /b bad.hex good.hex
Comparing files bad.hex and good.hex
00000002: 20 00
00000004: 20 00
00000017: 20 00
00000022: 20 00
00000023: 20 00
00000024: 20 00
00000025: 20 00
00000026: 20 00
00000027: 20 00
00000028: 20 00
00000029: 20 00
0000002A: 20 00
0000003A: 20 00
000000BE: 20 00

[pikcachu]

ah... you guys are awesome.... ya for some reason it doesn't work in the UI but it works if you call nbt.exe with the params....i generated the code that way... but was wondering why the UI wasn't doing it

wonder why esys does that thing with the spaces....

[Frogman]

Originally Posted by pikcachu

ah... you guys are awesome.... ya for some reason it doesn't work in the UI but it works if you call nbt.exe with the params....i generated the code that way... but was wondering why the UI wasn't doing it

wonder why esys does that thing with the spaces....

So, you're good now, right?

Humm, questions:

1. When you read the FSC via E-Sys, it appears it's already in binary form (not base64 encoded), correct?

2. You are able to manually generate the correct short code with the original FSC extracted from the car via E-Sys, right?

If both are yes, then E-Sys is extracting the correct FSC file.

It looks like Aritaurus had you base64 encode the FSC to make the GUI happy and that encoded FSC is what is bad.

If so, I wonder if the issue is that somewhere along the way, the base64 encoding step somehow messed the file up and that E-Sys is working correctly.

The SWID reader technique reads the FSC and base64 encodes it automatically, so that step is skipped when generating the short code.

[pikcachu]

Originally Posted by Frogman

So, you're good now, right?

Humm, questions:

1. When you read the FSC via E-Sys, it appears it's already in binary form (not base64 encoded), correct?

2. You are able to manually generate the correct short code with the original FSC extracted from the car via E-Sys, right?

If both are yes, then E-Sys is extracting the correct FSC file.

It looks like Aritaurus had you base64 encode the FSC to make the GUI happy and that encoded FSC is what is bad.

If so, I wonder if the issue is that somewhere along the way, the base64 encoding step somehow messed the file up and that E-Sys is working correctly.

The SWID reader technique reads the FSC and base64 encodes it automatically, so that step is skipped when generating the short code.

1) Yes the FSC from esys is already binary
2) Yes I can get the code if i run nbt.exe directly with the .fsc

well the Phonix129 generator won't work with the binary fsc... for that to work i had to use the base64 encoded one and in that case it shows the "fields!!" message...

but the nbt.exe takes the fsc from esys directly and works....

The other generator with the i8 pic didn't work either neither with the binary nor the base64.... but in both cases i was using the file that had the 0x20 instead of the 0x00

so maybe both generators work with the file sanitized with 0x00

[Frogman]

Originally Posted by pikcachu

1) Yes the FSC from esys is already binary
2) Yes I can get the code if i run nbt.exe directly with the .fsc

well the Phonix129 generator won't work with the binary fsc... for that to work i had to use the base64 encoded one and in that case it shows the "fields!!" message...

but the nbt.exe takes the fsc from esys directly and works....

The other generator with the i8 pic didn't work either neither with the binary nor the base64.... but in both cases i was using the file that had the 0x20 instead of the 0x00

so maybe both generators work with the file sanitized with 0x00

It sounds like the base64 encoder you are using doesn't encode using the same method as the one used by the SWID reader.

It sounds like the extract via E-Sys technique Aritaurus provided is working correctly, so that's good news!

[pikcachu]

could you post your good.hex so i can try running the gens against it ?

Originally Posted by Frogman

This does look like a DE file, but when I try to generate an FSC code for it, it fails with a message saying it does not contain enough fields.

Comparing it to another DE FSC file I have, I see that your FSC code has spaces (0x20) where the good FSC has NUL's (0x00). So, I edited your "bad" FSC file and it's now acceptable to the genreator.

Something strange seems to happen when you read the DE FSC code via E-Sys that does not agree with the generator.

Your signature does not indicate your geography or what map version you want, so I can't generate your FSC code. If you post which map you want, an FSC can be generated, just no guarantee that it will work because of the edits.

Here is the diff:

fc /b bad.hex good.hex
Comparing files bad.hex and good.hex
00000002: 20 00
00000004: 20 00
00000017: 20 00
00000022: 20 00
00000023: 20 00
00000024: 20 00
00000025: 20 00
00000026: 20 00
00000027: 20 00
00000028: 20 00
00000029: 20 00
0000002A: 20 00
0000003A: 20 00
000000BE: 20 00

[Frogman]

Originally Posted by pikcachu

could you post your good.hex so i can try running the gens against it ?

Here you go. This is marked as a .pdf file, just remove the .pdf extension and feed it to the NBT fsc.exe

It *should* match the FSC you read of from E-Sys!

[xxxm3]

is there a known issue like this for others:

Starting...E-serie...
Ediabas version: 7.3.0
Ignition: = OKAY
------------------------------------
Trying...
Reading CAS...
CAS: VIN - A875364
Setting addresse: = OKAY
Reading CIC...
CIC: VIN - A875364
------------------------------------
System.Exception: IFH-0009: NO RESPONSE FROM CONTROLUNIT

Total bytes: 0

my interface work correct for diag with inpa and ncsexpert also without issues

[Frogman]

Originally Posted by xxxm3

is there a known issue like this for others:

Starting...E-serie...
Ediabas version: 7.3.0
Ignition: = OKAY
------------------------------------
Trying...
Reading CAS...
CAS: VIN - A875364
Setting addresse: = OKAY
Reading CIC...
CIC: VIN - A875364
------------------------------------
System.Exception: IFH-0009: NO RESPONSE FROM CONTROLUNIT

Total bytes: 0

my interface work correct for diag with inpa and ncsexpert also without issues

You have an E91 not an F30. The procedure is different for your car.

[xxxm3]

Ah, thanks for the information - was everywhere looking but couldn't find.
is here a good contact for calc the code for update the cic?

[Frogman]

Originally Posted by xxxm3

Ah, thanks for the information - was everywhere looking but couldn't find.
is here a good contact for calc the code for update the cic?

PM Sent.

[pikcachu]

Originally Posted by Frogman

Here you go. This is marked as a .pdf file, just remove the .pdf extension and feed it to the NBT fsc.exe

It *should* match the FSC you read of from E-Sys!

that one looks like the binary version... do you have the actual .hex one?

[Frogman]

Originally Posted by pikcachu

that one looks like the binary version... do you have the actual .hex one?

For what we are talking about, hex = binary. This is what you get when you decode a base64 encoded file. The binary file is what the FSC.exe generator requires as input.

The SWID_reader writes a base64 encoded file, so that's why the FSC generator program needs to decode that file into binary before it can be used.

I created the good binary file from your bad base64 file by converting it from base64 to binary, and then patching it by changing the embedded spaces to NUL bytes.

When I compare my base64 encoded file to the base64 encoded file you supplied above, the files are different (as expected).

So, I think when you originally encoded your binary FSC code extracted from E-Sys into base64, something went wrong and it produced an incorrect base64 file. Then, when you decoded the base64 file back into binary, the decode did not produce the correct binary file and the FSC generator failed.

If you are not familiar with base64 encoding/decoding, I suggest you look here: https://en.wikipedia.org/wiki/Base64


I created a base64 (printable) version of my good binary FSC file by encoding it with the same site that Aritaurus used: http://www.motobit.com/util/base64-decoder-encoder.asp

It's enclosed below. You should be able to feed it to the GUI and have it generate an FSC code for you.

[Silver F30]

I keep getting a api32.dll not found error. Anyone else getting this?

Thanks for any help.

[pikcachu]

Ya really weird....

Your base64 file works on the GUI... but the code i get is different from the one I get if I use the binary fsc from e-sys against the NBT.exe generator directly.... wonder if more than one code is valid or if only 1 code works for each VIN

I got my base 64 by taking the binary and using the site http://www.motobit.com/util/base64-decoder-encoder.asp also but that creates the base64 with those spaces instead of the nulls which then makes the GUI show "fields!!" and not generate the code

The way I got it to work was using the NBT directly like "nbt KS91992_00DE0001.fsc 0xAF 0x02 KS91992"

[Frogman]

Originally Posted by pikcachu

Ya really weird....

Your base64 file works on the GUI... but the code i get is different from the one I get if I use the binary fsc from e-sys against the NBT.exe generator directly.... wonder if more than one code is valid or if only 1 code works for each VIN

I got my base 64 by taking the binary and using the site http://www.motobit.com/util/base64-decoder-encoder.asp also but that creates the base64 with those spaces instead of the nulls which then makes the GUI show "fields!!" and not generate the code

The way I got it to work was using the NBT directly like "nbt KS91992_00DE0001.fsc 0xAF 0x02 KS91992"

I would expect only one code to work, but I don't know for sure.

Can you compare your original binary file to my binary file and see if they are exactly the same?

Remember, I just brute-force changed every space to NUL; I have no idea if that would generate a correct short FSC or not. It was done just to prove that something did happen in the encoding/decoding process.

If the binary files are different, that could explain the different short FSC code being generated.