pcmhacking.net

RADustin wrote: The problem is, one a bad file is uploaded- the module goes into a 'soft brick' mode and if another bad file is tried it will brick.

I have never ever seen that occur. Calibrations will never brick a module.

If you are writing over the operating system also, then thats a different story.

Tazzi wrote:

RADustin wrote: The problem is, one a bad file is uploaded- the module goes into a 'soft brick' mode and if another bad file is tried it will brick.

I have never ever seen that occur. Calibrations will never brick a module.

If you are writing over the operating system also, then thats a different story.

My friend made me the hardware I’m flashing with... it basically emulates the MDI from what I understand and therefore flashes with the OS.

Currently I don’t have a way to cal only flash. Is your thought that if I could cal only flash, then it may work even with a bad checksum?

RADustin wrote:

Tazzi wrote:

RADustin wrote: The problem is, one a bad file is uploaded- the module goes into a 'soft brick' mode and if another bad file is tried it will brick.

I have never ever seen that occur. Calibrations will never brick a module.

If you are writing over the operating system also, then thats a different story.

My friend made me the hardware I’m flashing with... it basically emulates the MDI from what I understand and therefore flashes with the OS.

Currently I don’t have a way to cal only flash. Is your thought that if I could cal only flash, then it may work even with a bad checksum?

It will never work with a bad checksum. But doing a calibration only flash is MUCH faster.
Update the programming to do calibration only, and also to keep retrying to flash when its incorrect.
When it detects its incorrect, you can automated the software to simply increase the checksum byte by 1 and reflash. Eventually you will find the value.

Tazzi wrote:
It will never work with a bad checksum. But doing a calibration only flash is MUCH faster.
Update the programming to do calibration only, and also to keep retrying to flash when its incorrect.
When it detects its incorrect, you can automated the software to simply increase the checksum byte by 1 and reflash. Eventually you will find the value.

I'll work on implementing this. It's going to take me some time just to see how to set it up, I'll have to quiz my friend on the bootloader.

any idea of a non brute-force way to figure it? Seems like assembly(IDA) had promise, but I don't know much about it. Is there anything I can do to make an assembly strategy more effective?

Tazzi wrote:
It will never work with a bad checksum. But doing a calibration only flash is MUCH faster.
Update the programming to do calibration only, and also to keep retrying to flash when its incorrect.
When it detects its incorrect, you can automated the software to simply increase the checksum byte by 1 and reflash. Eventually you will find the value.

OK been working on this.

Cal only reflash is about 12-15 seconds. so at this rate, it'll take only a max of 2043 years to solve.(4 byte problems)

I'm waiting on another EBCM to come in from ebay that I can setup on the bench for the purposes of wearing out its flash brute forcing.

In the meantime, I'm trying to determine ways to reduce the amount of trys. My plan right now is to increment the address that I think I need to modify by 1. Then brute force the CS. Hopefully this won't be a super huge jump in value, and when it solves I can try it in the truck with my scan tool I wrote to see if the right variable has changed. So it'll tell me if I'm correct on the location...and hopefully tell me more about the CS by being so close to the original flash.

I'm still not sure if everything is 16-bit or 32-bit. I doubt it's 8-bit by the amount of data crunching that needs to happen. I wrote a python script to sum all the binaries I have so I can compare the binary sum(without the CS(s) added in) and the checksums, in both 16-bit and 32-bit big endian. A few different clues have me fairly sure it's big endian. I was hoping to find a trend or something, but I didn't. Attached a pic of the OS's and their sums/checksums. The peach color is two OSs that are VERY similar; their sums are close but checksums very different. OS 2324 and 2327 have very close hex sums in 16 bit, and again their checksums are very far apart(about 726 years@15 seconds). The yellow OS is the one I need.

Also I tried to write infineon to get a data sheet on the Orion D2 chip but to no avail. It is not available without signing an NDA and having a company.

any ideas? Thanks

Two questions about this.

Which specific TMS470 is it? I'm guessing it's an R1B512, but I'd like to know for sure.

Do you have the utility file SPS uses to program this thing? It'll be in your SPS cache with the calibration files.

Gatecrasher wrote:Two questions about this.

Which specific TMS470 is it? I'm guessing it's an R1B512, but I'd like to know for sure.

Do you have the utility file SPS uses to program this thing? It'll be in your SPS cache with the calibration files.

Yes I have the utility. That's what I modified to cut out the OS flash and rebuild the instructions. Attached. 25869283

Also attached is a pic of the board with the chips.

And this.

Gatecrasher wrote:Two questions about this.

Which specific TMS470 is it? I'm guessing it's an R1B512, but I'd like to know for sure.

Do you have the utility file SPS uses to program this thing? It'll be in your SPS cache with the calibration files.

R1VF67

I disassembled the consolidated ROM that kur4o posted and found some subroutines that reference the checksum locations, but nothing that called that code to begin with. That's why I asked for the utility file. I pulled out the reflash kernel and I've got a clean disassembly of that. I'm looking for a standalone checksum routine. But I'm running into the same problem I did with the main operational code. Both of them make a bunch of references to memory locations in the bootloader area. 0x0-0x3FFF. I'm worried the checksum routine is in the bootloader because the reflash kernel has the same type of 4 byte checksum in the same location as the OS and cal files. I'm hoping there's maybe a redundant copy of it in the reflash kernel though.

I'm trying to make some educated guesses on some of the memory references. It's tedious, but I've got the buzz now.