Flash method verification

[uprev]

Hey there MiikaS

I've been playing around with FastECU a little bit recently and have some questions

Firstly, is it possible to have the software ignore the RomRaider definitions and work solely from EcuFlash definitions? I have been generating my own extended EF definitions and have not gotten around to writing them in RR format as of yet.

Second, I see you have read/write methods pertaining to both ecutek and cobb. Does this mean that the software could potentially read out an ecu flashed via those methods and then write back to the ecu using the same method? Therefore if attempted to read out via EF, the ecu reports as locked? And on that same note, could the ecu be "virginized" from cobb or ecutek flashes?

Third, any chance for failed flash recovery?

Thank you for your hard work

uprev

[uprev]

Whoops...

Just saw the denso_can_recovery protocol

[MiikaS]

Hey there MiikaS

I've been playing around with FastECU a little bit recently and have some questions

Firstly, is it possible to have the software ignore the RomRaider definitions and work solely from EcuFlash definitions? I have been generating my own extended EF definitions and have not gotten around to writing them in RR format as of yet.

Second, I see you have read/write methods pertaining to both ecutek and cobb. Does this mean that the software could potentially read out an ecu flashed via those methods and then write back to the ecu using the same method? Therefore if attempted to read out via EF, the ecu reports as locked? And on that same note, could the ecu be "virginized" from cobb or ecutek flashes?

Third, any chance for failed flash recovery?

Thank you for your hard work

uprev

Hi uprev!

For disabling RomRaider def lookup, you can test by removing def files from list on settings. I might add checkbox to disable them without clearing the list...

Those EcuTek and COBB methods are still under testing. EcuTek uses on all 32-bit ECUs quite simple method across all models to prevent access to ECU so it should work but COBB I'm not yet really sure, because I have only two ROMs that I have looked at, 2012 and 2017 STi ROMs. 2012 is also simple but 2017 there is normal access disabled (subarucan method) what we have found so far, and it needs further examination how it access to married ECU. It still can be accessed with 'Denso CAN bootloader' but ECU needs to be removed from car.

Also what I have tested so far, I haven't got SH7058 kernel to work on 1gen diesel ECU that loads it to different address in RAM (so don't know if it's related to that or comms) and I don't have petrol ECU in hand right now to test it until next week. This is for 'subarucan' method, but you are able to use 'Denso CAN bootloader' and so far it has worked on all SH7055/SH7058 based Subaru ECUs I have tested.

Also the 'recovery' method is under testing, it is made to continuously sending connect request to Denso CAN bootloader when powering up but need to 'brick' one of my ECUs in different ways for better testing.

And for clarity, as so far checked, ALL 32-bit ECUs has primary CAN bootloader that I call 'Denso CAN bootloader' and depending on model either K-Line or iso15765 CAN for 'normal' access. And depending on vehicle, if CANbus is wired to OBD, that primary CAN bootloader can be accessed straight via OBD (some models needs to be in test mode for that), otherwise ECU needs to be removed from car. And as long as that bootloader is untouched, ECU can be 'virginized' via that method.

[uprev]

Miika,

Concerning definitions, maps that were previously shown with standard definitions are present and are displayed correctly. But all of the tables that I have added seem to populate under an unnamed category but do not translate the axis or map data. Please advise on what I need to do to get these displayed correctly

I can provide testing on a GR WRX for Cobb and Ecutek recovery/flashing. I have a V2 and V3 Accessport as well as Ecutek that I have previously flashed my own car with many times

[MiikaS]

Can you share some definition with modified/added tables that don't show up so I can pinpoint the problem?

Basicly, on GR series EcuTek option should work atleast to pass security access / upload kernel, kernel itself might not work but that's under investigation. For COBB, there is 2012 STi security access added to software, and if COBB does not use different methods on every ECU, it should also pass security access. But, using Denso CAN bootloader you can download ROM from all of those. If ECU is in car, some needs to be on test mode, like 2012 STi but 2008 STi doesn't.

[uprev]

Yes, I can email you some definitions to see what seems to be going on

I will try and find some time to attempt the denso bootloader, the car currently is flashed with the V2 AP. Just haven't found the time to sit down and change things recently

[uprev]

Miika,

Do you have a flash method developed for Cobb K Line vehicles? I cannot seem to get FastEcu to read through K Line

[MiikaS]

Hi!

Did you get it to read through Denso CAN? I have few COBB K-Line/CAN ROMs and they have all different security keys/modifications, so I think I need ROM from ECU you are trying to access with K-Line to add it to software. You can clear out/remove calibration part and send it so I can have a look if you have one.

[uprev]

Yes, Denso CAN works as it should. I have not been able to successfully read any K-Line Roms other than stock roms. Is there a way to "Brute force" a read on the K-line? Currently attempting on A2ZJ710J which is a 512k rom, so that could be different from 1mb roms too?

[MiikaS]

I think brute force would not work so good as there is simply too much different possibilieties to test... Easiest way is if we can get functional part of code to look seed keys and decompile to make sure there is still stock calcultaion methods and conditional testings in use. For that we need to use Denso CAN.