Aseras

Hmm entry points...

ok well there's plenty of denso tags in hex.

05800
07320


070670

willing to bet it's near one of them.

honestly i know jack about sh. I'm assuming all the jumps for r1,r2 etc.. are for it.

seikx8

You're getting there, since we do not have access to the PC & SP vector, so the alternative route is to identify and mark the data segment first as we know they are fact and can be identify easiy. This way, we are eliminating possible invalid codes generated by the data segment.

With IDA, you will need to manually go through those and mark the identified text as data; in this case, string. It will nicely auto detect and define the string variable and lock the segment down so that it will not treat it as codes. The other data are the map location which I've identified in some previous posts, mark those as either individual data or define them as array, etc. Once you have all that, you are eliminating invalid codes. This will take time, but it will be fun to play around.

The nice thing about IDA is it will automatic analyze and nicely display the result from your manual analyzing point. Just have to identify one segment at a time... once you found the segment that doesn't make sense (such as code collision with data) you can eliminate that. Its also have a very nice UI where you can navigate your codes and tracing the flow of codes execution.

I have a chance to play around with the Demo version of IDA pro, so I know its potential. Thus figuring the rest of the ROM image will be time consuming and requires lots of patience.

zoom44

could the flash file name- sw-N3Z(1 or 2)E(R or S etc)000 be the code or check sum in some way?

seikx8

It's shouldn't be. One of the checksum is a 32bit value located at 0x837F4 for sure, and the other is at 0x83388. I have a hunt that the checksum only apply to a few segments and not the entire image.

seikx8

To give some update, the following are a few subroutines I found in these range of addresses:

0x25D0C:0x25FD4
0x25FDC:0x26114
0x26114:0x2633c
and so on..

Most of these code have floating point operation and call to address in the 0x2000 - 0x3000 range outside of the flash image range starting from 0x4000.

Some hints to analyze the assembly code is to look for any valid subroutine call. All subroutines call should use a register to load a full 32bit data. eg.

mov.l @(PC,xx), Rn
jsr @Rn
nop

And the follow codes should be mark as invalid:
mov.w (@PC,xx),Rn
jsr @Rn

All subroutine should have a begin and end code signatures with some variant of the follow format:

;begin routine
mov.l r14, @-r15
mov.l r13, @-r15
...
sts.l pr,@-r15
...
...
lds.l @r15+,pr
...
mov.l r15+,@r13
rts
mov.l r15+,@r14 ; code place here for delay return, sometime you may see nop instruction
; some data definition if any
; end subroutine

seikx8

I hit gold in subroutine in range: 0x22060:0x2211A, there are codes referencing data access to the data map I've previous identified.

I'm tired now, got to catch some shut eye.

SomeGuy_sg

Big Up to all the guys working on this
Your work does not go un-appreciated :shakeboobs:

juanjux

Did this *wonderful* thread dies because of RB reflash? Please don't!

zoom44

no seik and aeseras are both still working. seik has some new findings and they both have copies of the newest US and Canadian flash levels to look at

Aseras

i've been swamped for the last month and a half with work. I lost my tech and picked up a new gf so I've not had much time. I'll have the next week and a half or so all to myself so hopefully I'll be able to go through some of the new things I've got ( thanks zoom ) and see what I can do.

juanjux

I'm interested in the Europe Vs USA AFR tables in the ECU, could someone post them there (both)?

seikx8

There is progress, but slow. Currently I'm waiting to purchase the J2534 device as I am tight in budget at the moment. Otherwise, I have learned a lot about how the module is programed and such.

To lets you in some details, the Mazda Module Programming software seem to have a function for you to read the Flash from the PCM and check to see if the PCM is empty by validating if all data is Zero/FF (depending on the EEPROM each PCM use). In the application there are .DLL files which have functions interfacing with the Vehicle and reading/writing Flash images, etc. By default, it will auto check the HW and look in DB then connect to internet to get the latest info, if found you will be prompt whether you want to download & reflash with the new version.

However, there is option that would allow you to manually select a module flash File to upload to the PCM. There are options that set to prevent user from uploading the wrong flash file to the PCM but they can be turn off and bypass. Since I do not have the J2534, I cannot verify how that will work in the UI yet.

Regarding the flash image itself, I still have not figure out the checksum yet because there are missing data and I'm trying to locate and study the SBL (Secondary BootLoader) segment of the codes; these codes are upload/load from a protected region on he ROM to the RAM then run so that the reading/write process may occurs via communication with the a remote application such as the Mazda Module Programming Software.

As for the disassembly, I have about 350+ functions/subroutines identified and some jump/branch to address below 0x4000 which I currently have no access to so I can't verify the codes purpose.

And I was sick today, so I took a day off to rest. Still having a light headache at the moment

theboy

RE is visiting singapore and they say they can by pass the speed-cut. well?

Aseras

zoom talked to drewtech and they are going to offer a mongoose with a powersupply for flashing soon. that's the perfect tool. I'm waiting for it.

seikx8

To continue the saga,

if anyone want to pursue other alternative is to use the SCI port (Serial Communication Interface), there are source in japan that have those board to allow you to flash the ECU and here is the link for example if you understand Japanese (or to babefish translated): http://60.43.208.97/1/CPU-SH.htm

I've also read through many document from Renesas, the board can be reprogram directly via the SCI port (now I have understood how it works). The site also have the Flash Development Kit that you can download. Problem is, I have no spare ECU to play around with; because if you put the ECU into the wrong mode (boot mode) the entire flash will auto erase. This is the cheapest option you will find by making a very simple circuit to interface with the SCI that probably cost in the 2 digit figure.

And the cheapest J2534 device I found is McS1 from EEPod costing $475.