swoope

iTrader: (5)

actually by speed and rpm....

beers

seikx8

Well, there are actual map that has indication of gear based. Take this one for example:
X-Axis: [0x70a70 6x4]
1250 1500 4990 5000 5990 6000
Y-Axis: [0x70a88 6x4]
1 2 3 4 5 6
Cells: [0x70aa0 6x6x1]
075 056 056 015 015 000
075 056 056 015 015 000
056 056 056 015 015 000
056 056 056 015 015 000
056 056 056 015 015 000
056 056 056 015 015 000

Does this look like timming?
X-Axis: [0x70c34 16x4]
-40 -30 -20 -10 0 10 20 30 40 50 60 70 80 90 100 110
Y-Axis: [0x70c74 6x4]
1 2 3 4 5 6
Cells: [0x70c8c 16x6x1]
005 005 005 005 005 005 005 005 005 005 005 030 030 030 030 030
005 005 005 005 005 005 005 005 005 005 005 010 010 010 010 010
005 005 005 005 005 005 005 005 005 005 005 010 010 010 010 010
005 005 005 005 005 005 005 005 005 005 005 005 005 005 005 005
005 005 005 005 005 005 005 005 005 005 005 005 005 005 005 005
005 005 005 005 005 005 005 005 005 005 005 005 005 005 005 005

seikx8

Got some update,

Bad news is I still haven't figure out the internal checksum algorithm use. However, by analysing SW-N3Z2ER000 & SW-N3ZXE0000, there was only minor change between these two file; the MOP map and two location of 4 bytes each that look like check sum value.

Axis-X (RPM): 700 720 1000 1500 2000 2500 3000 3500 4000 4500 5000 5500 6000 6500 7000 7500 8000 8500 9000
Axis-Y: 0.0625 0.125 0.1875 0.25 0.3125 0.375 0.4375 0.5 0.5625 0.625 0.6875 0.75 0.8125 0.875 0.9375 1 1.0625

SW-N3Z2ER000:

3 3 3 3 3 3 3 3 3 5 7 7 7 11 12 15 19 19 21
3 3 3 3 3 3 3 3 3 5 7 7 7 11 15 18 20 21 22
3 3 3 3 3 3 3 3 3 5 7 7 7 11 17 19 21 22 45
3 3 3 3 3 3 3 3 3 5 7 7 7 11 18 21 22 23 45
3 3 3 3 3 3 3 4 5 6 8 7 9 12 18 22 23 45 45
3 3 3 6 3 3 3 5 6 9 10 11 12 15 21 23 45 45 45
3 6 6 9 6 5 8 8 8 11 13 14 16 19 23 45 45 45 45
3 19 19 16 16 16 19 16 14 13 15 17 17 20 45 45 45 45 45
3 19 19 16 16 16 19 16 14 15 18 19 19 20 45 45 45 45 47
3 19 19 16 16 16 19 17 16 17 20 20 20 21 45 45 45 48 50
3 19 19 18 17 16 19 18 19 20 20 21 21 21 45 45 47 49 51
3 21 21 21 19 18 19 20 21 21 21 21 21 21 45 45 48 51 54
3 21 21 22 21 21 21 21 25 25 25 25 25 45 45 45 50 54 56
3 21 21 22 21 21 21 21 26 26 26 26 26 45 45 48 52 56 59
3 21 21 22 22 22 21 21 26 26 27 26 45 45 47 52 55 58 60
3 21 21 22 22 22 22 22 26 27 27 45 45 45 48 53 55 60 60
3 21 21 22 22 22 22 22 26 27 27 45 45 45 60 60 60 60 60



SW-N3ZXE0000:

3 3 3 3 28 3 3 3 3 5 7 7 7 11 12 15 19 19 21
3 3 3 3 27 3 3 3 3 5 7 7 7 11 15 18 20 21 22
3 7 7 7 7 7 7 7 7 7 7 7 7 11 17 19 21 22 45
3 9 9 9 9 9 9 9 9 9 9 9 9 11 18 21 22 23 45
3 12 12 12 12 12 12 12 12 12 12 12 12 12 18 22 23 45 45
3 15 15 15 15 15 15 15 15 15 15 15 15 15 21 23 45 45 45
3 17 17 17 17 17 17 17 17 17 17 17 17 19 23 45 45 45 45
3 19 19 17 17 17 19 17 17 13 15 17 17 20 45 45 45 45 45
3 19 19 17 17 17 19 17 17 15 18 19 19 20 45 45 45 45 47
3 19 19 18 17 17 19 18 18 17 20 20 20 21 45 45 45 48 50
3 19 19 18 17 18 19 18 19 20 20 21 21 21 45 45 47 49 51
3 21 21 21 19 18 19 20 21 21 21 21 21 21 45 45 48 51 54
3 21 21 22 21 21 21 21 25 25 25 25 25 45 45 45 50 54 56
3 21 21 22 21 21 21 21 26 26 26 26 26 45 45 48 52 56 59
3 21 21 22 22 22 21 21 26 26 27 26 45 45 47 52 55 58 60
3 21 21 22 22 22 22 22 26 27 27 45 45 45 48 53 55 60 60
3 21 21 22 22 22 22 22 26 27 27 45 45 45 60 60 60 60 60

If this is the MOP map, then the X version, seemed like there are some drammatic changes to the value around 2k rpm; cold start = high fuels = need more oil to keep the chamber lubes.

In order to figure the checksum and identify all other things easily, you will need a good disassembler like the IDA pro that support the SH processor. However that software cost around $800, too expensive for a hobbiest that have no cash to spare

Anyone has any progress that care to contribute? checksum algorithm use? Any hint would be help, Mazda? Anyone?

Xantium

I would assume that you know of the other ways to get software? Or is indivudual hobbiest "temporary software demo-ing" unethical...


btw ida pro is like $30

seikx8

Where can I get a copy of IDA Pro that support the SH* processor for $30? Even a temporary demo version for a few days will be enough whether it's ethical or not. There wasn't much info regarding buying individual plugins.

The IDA Pro Advance Edition cost $875 to be exact. http://www.ccso.com/files/idaord.txt

List of processors it support can be view here: http://datarescue.com./idabase/idaproc.htm

Japan8

Damn... too bad this only supports 80x86 and ARM...
http://www.datarescue.be/downloaddemo.htm

Hmm...
http://www.thefreecountry.com/progra...semblers.shtml

Will this work?
http://www.trzy.org/
http://www.rockbox.org/tools.html
http://www.brouhaha.com/~eric/software/shdis/
http://www.osflash.org/swf9tools

Aseras

I have a copy of IDA Pro 4.8 advanced...

seikx8

PM sent

seikx8

I have tried some of the free disassembler, they are some what help but very hard to follow in identifying the entry point. There seem to be some kind of boot loader that send each subroutine to each tasks, etc. Identify those with little help on register and stack tracking is like finding a needle in a haze stack for me at the moment. But if there is other way, I would prefer to use the alternative

I've also try other ECU editor software, but some do not support the IEEE floating point data type that used by the SH2/3 family. Some of them crashed everytime I try to define a map definition on the binary. So I figure, if we was able to grab a hold of the checksum algorithm or checksum routine, we can remove the checksum and by pass it. The only thing I would be afraid is the checksum might be outside of the flashable region which we have no access to from the flash file. That what I would do if I want to protect my code from non-authorize reflash.

~)(

Hi,

I’ve used several disassemblers myself and I can’t stress how much better IDA Pro is over everything else – especially for non-x86/x64 instruction sets. It’s been a while since I’ve used IDA and no, I do not have a copy.

I haven’t looked at the ECU myself, but if there is a ROM chip in there, then we need to dump its contents and reverse engineer that first. I don’t know how competent or security-focused the engineers that designed the software are, so I’m assuming that all of the code (we care about) is probably in the flash. Someone that’s dealt with the actual board itself should be able to tell if there is a ROM there.

Anyhow, I’m willing to bet that the checksum algorithm is embedded within in the image itself. However, this doesn’t mean that we can hook or jump the checksum algorithm on the new image since the checksum calculation is being executed off the old image; otherwise, then what’s the point of checksumming? Therefore, if you intend to bypass the checksum check, then you need to be able to flash the image in the first place.

I don’t know if you guys can already do this, but there are a couple of ways of rewriting a flash. You can de-solder the flash, reprogram it, and then solder it back on. Alternatively, you can reprogram the chip in-place – this can be a pain in the ***, but so is de-soldering anything.

I recommend you guys read “Hacking the Xbox: An Introduction to Reverse Engineering” by Andrew “bunnie” Huang. I highly recommend it to anyone interested in reverse engineering hardware. I’ve met the guy on a few occasions and he’s an awesome dude (http://bunniestudios.com/).

-jc

seikx8

The promising disassembler I found thus far is this one "SH disassembler v19991206" from
http://www.eidolons-inn.net/tiki-lis...downloads_desc

I have some hunt on where the entry point might look like, but cannot confirm until I gain access to the Mongoose cable to read some data of the PCM from address location outside of the ROM image in the flash file; is it possible? is another question I have not have a chance to look into.

Aseras

I gave it a whirl in IDA. IDA only does sh3 and sh4. it basically pukes and does nothing. I found this dissassembler for sh2 that seems to work well http://www.trzy.org/files/sh2d020.zip

Seikx8 you can probably grab that and give it a whirl yourself or I can send you the output. it seems to work, starting at

0x00004000: 0x9D6F mov.w @(0x0E2, pc), r13 ; 0x000040E2

we start getting code

seikx8

I've tried that one and it's lack the Data marking ability. For IDA, you would want to try SH4 or even SH3. The only different are some FPU instructions. Looking closely of the OS segment, it seemed like it was compiled to target SH3 instruction set. The address at 0x4000 is the starting of the rom address, however the entry point are some where else. The hint I got from reading the hardware manual was, the OS must make a call to HW initialization before anything can start during the power on event, which then trigger the entry point to the main application or by calling the start OS instructions. The clues are to find instruction that make call with register pushed to stack (R1-R6) at least, then restore them when it's done.

During hardware initialization, there will be code that allocate memory or at least initialize the RAM to all zero (perhaps some type of stack or heap), without IDA pro, it's going to be a slow process verifying those.

In IDA pro, you will need to study the code by try an error and look for entry point. Most likely it doesn't recognize the signature of the OS, so you will have to give its some hint by defining some entry points and let it analyze. If you hit the correct location, the whole thing will be reveal itself; that's what a good analyzer would do; especially if you have the SDK version, you can write your own extension and plugin which will speedup the recovery process.

rotarygod

Man you guys are going to a lot of trouble to figure this all out. What will you do if we see an aftermarket company offering reflashes in the next few weeks? Will you keep trying? It seems like a pretty good undertaking to get it all figured out.

seikx8

If there is, it's great. Are you trying to give us some hint? Maybe we will try to study their software and reveal their secret too

Still it's a good learning curve for me to know more about the EOM software and its ability and what type of routines are put in place to harness or hold back the Renesis power from its original developer. And it's also a great way to prevent the aftermarket company to over charge us when there are open competition, especially when there are free info to be harness. I'm sure the aftermarket will try to hold back some secret to make it's more profitable.

And there are a very good source of information out there, such as the PC & SP register are look up at address 0x0 and 0x4 during power up exception. So if we just be able to access that address area of the ROM, we are in good shape no? As for removing the chip to read the data, I'm not that crazy yet, but it will be the quickest solution out there. So I would not surprise if the aftermarket company are pursuing of cracking the code by using that route if there will be profits to be make.

For me it's just a hobby and knowledge to learn just like I did with the eMange blue version protocols research that I have started and write software for the auto tunning feature, but halt that project and to pursue this instead. To answer your question, if there are enought knowledge gained and the aftermarket offer a reason price for the ability to tune the map ourselves, this project will be pretty much drop in a lower priority list.

It's eManage vs ECU reflash, so I need to make a choice in pursuing FI for the RX8.

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.