Announcement

Collapse
No announcement yet.

General circuit reverse engineering section

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • General circuit reverse engineering section

    I thought I would tap the Mp3Car communities circuitry knowledge on a semi related topic.

    My question is, the processor is soldered onto the circuit board, if I solder some extra wires on to the correct processor pins, and then I apply ground to these pins, how likely is it that I will fry something else on the circuit board? Is there anything I can do to put ground on these processor pins in a safer way?

  • #2
    Depending on the package, I have seen clamps that fit onto some surface mount or dip packages that provide a breadboard-like interface for each pin. Soldering on should be fine though, if you're confident of your skills. Just make sure you use the correct ground, something on board, not chassis or a power-supply ground. You can also check for other processor pins that may be hard-wired low, see how they're connected.
    MII-12000 / Ampie / Lilliput 7" / BU-355 / PicoPSU / uSDC
    Currently: Enjoying the setup, but always contemplating my next move...

    Comment


    • #3
      Thats what I was planning. I'm just worried that there are other chips on the circuit board driving these pins high, and if I wire my connections to drive the pins low that I am going to fry something.

      I was also thinking I could desolder these individual pins from the circuit board to remove them from any existing connections.

      Should I maybe put a resistor in-line with the ground connection I hook up?

      Comment


      • #4
        Desoldering would be the best way. There is a chance that grounding may burn out a pin, but if the driving chips are using pull-ups it shouldnt cause harm. Guess you cant assume anything though.

        Connecting a resistor to ground would just cause the pin to float, you'd have a weird divider between the output resistance of the driving circuit, input resistance of the processor, and the ground resistor. You are very correct though, best bet would be to desolder or somehow isolate the pins.

        Do you know what kind of processor it is? Im very curious now. Also, what do you plan to do? Just cute hacks, or are you going to do some real tuning?
        MII-12000 / Ampie / Lilliput 7" / BU-355 / PicoPSU / uSDC
        Currently: Enjoying the setup, but always contemplating my next move...

        Comment


        • #5
          Originally posted by archimense
          I think I am going to desolder the pins I need to pull low.

          It is a Siemens/Infineon C167CR processor. I have already read out 512KB of external EPROM, but some of that code calls into the internal 128KB ROM on the processor. So I need to get that code off of the processor to get a better picture of how everything works. The only way to do that is by putting the processor into bootstrap mode.

          I'm sick of people "Tuning" cars with diagnostic adaptation and trims values, and being told they are gods. :P So I decided that if companies like GIAC, and APR can do this stuff for European cars, then I should be able to figure it out.

          I've traced a lot of the inputs and ouputs from the engine computer to the individual chip pins, and I have dissambled a lot of the code using IDA Pro Dissambler.

          Right now the plan is to do some simple tuning, and if I don't blow something up I will start some real hardcore tuning. One step at a time though. :P
          Have you looked into J2534 (Pass thru programming)?

          I don't know about other manufacturers, but for my car (Chrysler), they released the flashes all the way back to 2000.

          If it's available for your car, you could probably get the data you need out of the file.
          GE Cache Builder | [email protected] |Coolstuff :autospeed.com | bit-tech.net | Nitemax Ultra Pinouts

          Comment


          • #6
            Originally posted by shotgunefx
            Have you looked into J2534 (Pass thru programming)?

            I don't know about other manufacturers, but for my car (Chrysler), they released the flashes all the way back to 2000.

            If it's available for your car, you could probably get the data you need out of the file.
            Just use a decent tool and your life will be easy. My company's CarDAQ-Plus is the J2534 reflash tool recommended by most automakers. Why reverse engineer anything from the files? Just sniff the reflash procedure, or better yet use the CarDAQ-Plus debug DLL and log every API function call to a file. No sense messing around if you can cut your time in half by using the right tool.

            Also there's the lower-priced Mongoose but the Ford and Chrysler versions won't be available until Summer 2006.

            Comment


            • #7
              J2534 is only required post 2004. I'm working on a 2001 which I am almost positive does not support this protocol.

              Also just because CarDAQ-Plus can speak KWP2000 which my ECU speaks does not mean that it can automatically reflash my ECU unless I am missing something. The reflash procedures are not published by VW/Audi. Hence why I am reverse engineering.

              Plus I don't just want to reflash, I want to read the contents of ROM and figure out how the ECU works. Cause if I don't figure out how it works, how am I going to know what I actually want to modify inside the ECU? Unless CarDAQ-Plus can tell me the location of every memory map in the ECU, also calculate the four different types of memory checksums, and tell me how all of the different sensor readings are combined together to actually make use of the memory maps... which I highly doubt...

              Comment


              • #8
                Originally posted by joeyoravec
                Just use a decent tool and your life will be easy. My company's CarDAQ-Plus is the J2534 reflash tool recommended by most automakers. Why reverse engineer anything from the files? Just sniff the reflash procedure, or better yet use the CarDAQ-Plus debug DLL and log every API function call to a file. No sense messing around if you can cut your time in half by using the right tool.

                Also there's the lower-priced Mongoose but the Ford and Chrysler versions won't be available until Summer 2006.
                Why? To change things that aren't normally changable. For instance, my car is a Chrysler Sebring Coupe (basically a big eclipse with chrsyler sheet metal).

                There are almost no parameters to change. The ECU fights hard to cancel out any mods you add. This has meant lots of shennanigans for anyone thinking about forced induction. At least $1000 in additional electronics alone and the results are spotty even years later. Some people have no problems, some still have issues years later.

                Maybe I'm missing some point in your comment about sniffing the flash? My knowledge of J2534 reprogramming is very basic to say the least. I thought the tools were primarly for just uploading a flash file. Is there some functional aspect I'm missing?
                GE Cache Builder | [email protected] |Coolstuff :autospeed.com | bit-tech.net | Nitemax Ultra Pinouts

                Comment


                • #9
                  Originally posted by archimense
                  J2534 is only required post 2004. I'm working on a 2001 which I am almost positive does not support this protocol.

                  Also just because CarDAQ-Plus can speak KWP2000 which my ECU speaks does not mean that it can automatically reflash my ECU unless I am missing something. The reflash procedures are not published by VW/Audi. Hence why I am reverse engineering.

                  Plus I don't just want to reflash, I want to read the contents of ROM and figure out how the ECU works. Cause if I don't figure out how it works, how am I going to know what I actually want to modify inside the ECU? Unless CarDAQ-Plus can tell me the location of every memory map in the ECU, also calculate the four different types of memory checksums, and tell me how all of the different sensor readings are combined together to actually make use of the memory maps... which I highly doubt...
                  My car is an 02 and it supports it. So does the 01 model so you might get lucky.

                  I was getting at that you could just disassemble the contents of the flash file to reverse engineer it rather than potentially killing your ECU to retrieve the same data.
                  GE Cache Builder | [email protected] |Coolstuff :autospeed.com | bit-tech.net | Nitemax Ultra Pinouts

                  Comment


                  • #10
                    Originally posted by shotgunefx
                    My car is an 02 and it supports it. So does the 01 model so you might get lucky.

                    I was getting at that you could just disassemble the contents of the flash file to reverse engineer it rather than potentially killing your ECU to retrieve the same data.
                    That would be nice, but I have yet to find any flash files. Audi/VW have setup the Erwin website to sell dealer equipment and documentation. I have been through all of it and there is nothing on flashing ECUs. Also I need to take the ECU apart to determine how the processor pins are connected to the ECU connectors, otherwise how do I know that Port 7 pin 0 is connected to fuel injector 1, etc. If I don't know the internal connections then it is just assembly code reading from and writing to ports which connect to who knows what.

                    I bought a spare ECU just for this purpose.

                    There is also the possiblity that the flash file is a different format from the memory layout of the ECU, which would mean I would have to reverse engineer the flash file layout, and then from that reverse engineer the code from the flash file.

                    I appreciate all of the suggestions; I just get defensive when people try to oversimplfy something that is very complex.

                    Comment


                    • #11
                      Originally posted by archimense
                      Also just because CarDAQ-Plus can speak KWP2000 which my ECU speaks does not mean that it can automatically reflash my ECU unless I am missing something. The reflash procedures are not published by VW/Audi. Hence why I am reverse engineering.
                      I believe KWP2000 was only used on late 2002+ VW's in NA but maybe used on your Audi. And you are right the flashing procedures are not published and very hard to get a hold of but it seems companies like Giac, Revo, Upsolute etc can do it so it is known.

                      Comment


                      • #12
                        Originally posted by Stonewall78
                        I believe KWP2000 was only used on late 2002+ VW's in NA but maybe used on your Audi. And you are right the flashing procedures are not published and very hard to get a hold of but it seems companies like Giac, Revo, Upsolute etc can do it so it is known.
                        True, companies like Giac, APR, Revo, etc can flash Audi/VW ECU's and that is the reason they can charge in the $500 - $900 range per ECU flash. No one else can do it, or they don't have anything worth flashing onto the ECU.

                        Comment


                        • #13
                          Man you guys must be on this forum day and night! Lots of posts since I checked last time. Let me adddress some of the previous postings.

                          J2534 is not a protocol, it's a standard device driver for vehicle interfaces. It uses the same underlying protocols (ISO, KWP, VPW, PWM, CAN) to communicate but provides standard driver functions to connect, read, write, send periodic messages, assert programming voltages, etc. This way you can write software that will work with any standard vehicle interface.

                          Although USA automakers are required by law to provide reflash software for 2004 and newer vehicles that contain flash memory, most of them support the older vehicles too. Ford and GM go back back to 1996, but Honda didn't support flashing until 2001. Your mileage will vary based on the OEM.

                          For VW/Audi, the erWin software was replaced by eBahn in April but both packages support PassThru ECU flashing.

                          My point was that most vehicles can be reflashed in this fashion and it's much safer and easier to sniff this datastream than to desolder chips. Obviously you must still reverse engineer and learn what to put inside the PCM, but you can save a lot of time by learning how to upload and download with a working example. Save your time for reverse engineering the memory maps.

                          Comment


                          • #14
                            Originally posted by joeyoravec
                            My point was that most vehicles can be reflashed in this fashion and it's much safer and easier to sniff this datastream than to desolder chips. Obviously you must still reverse engineer and learn what to put inside the PCM, but you can save a lot of time by learning how to upload and download with a working example. Save your time for reverse engineering the memory maps.


                            It is most likely that the internal FLASH is read protected as the C167CR processor do support "read protection", this wont surpise me at all.

                            As for reading the external ROM, it may contains the code as well as the MAP. Wont surpise me if the MAP is encrypted and the encryption key/algo is stored in the internal FLASH where you couldnt read it at the first place.

                            You are basically left with HEXs that are almost unworkable.

                            But this is just assuming the manufacturer took the precautions. You may be lucky who knows, if you have lots of time then go ahead, it be fun getting some results. But expect alot of headaches

                            Comment


                            • #15
                              No idea because I've neither reverse engineered nor driven a VW/Audi before.

                              But I'm not surprised by what you said about the external ROM. Many of the OEMs upload binary code via the OBD connector, jump to that instruction in RAM, and execute this small routine to perform the reflash. Or maybe it's part of the internal ROM. I guess you'll see soon.

                              Good luck!

                              Comment

                              Working...
                              X