Page 1 of 3 123 LastLast
Results 1 to 10 of 29

Thread: General circuit reverse engineering section

  1. #1
    Variable Bitrate
    Join Date
    Mar 2004
    Location
    Vancouver, BC, Canada
    Posts
    429

    General circuit reverse engineering question

    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. #2
    Variable Bitrate
    Join Date
    Jun 2005
    Location
    Michigan
    Posts
    311
    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...

  3. #3
    Variable Bitrate
    Join Date
    Mar 2004
    Location
    Vancouver, BC, Canada
    Posts
    429
    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?

  4. #4
    Variable Bitrate
    Join Date
    Jun 2005
    Location
    Michigan
    Posts
    311
    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...

  5. #5
    Raw Wave shotgunefx's Avatar
    Join Date
    Apr 2005
    Location
    Boston, MA
    Posts
    1,800
    Quote 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.

  6. #6
    Constant Bitrate joeyoravec's Avatar
    Join Date
    Oct 2005
    Location
    Livonia, MI
    Posts
    205
    Quote 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.

  7. #7
    Variable Bitrate
    Join Date
    Mar 2004
    Location
    Vancouver, BC, Canada
    Posts
    429
    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...

  8. #8
    Raw Wave shotgunefx's Avatar
    Join Date
    Apr 2005
    Location
    Boston, MA
    Posts
    1,800
    Quote 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?

  9. #9
    Raw Wave shotgunefx's Avatar
    Join Date
    Apr 2005
    Location
    Boston, MA
    Posts
    1,800
    Quote 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.

  10. #10
    Variable Bitrate
    Join Date
    Mar 2004
    Location
    Vancouver, BC, Canada
    Posts
    429
    Quote 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.

Page 1 of 3 123 LastLast

Similar Threads

  1. Battery based tank circuit (tested)
    By Ricky327 in forum Power Supplies
    Replies: 241
    Last Post: 02-13-2008, 04:43 PM
  2. Reverse engineering cam file...Proposal for $$
    By RoyN in forum Software & Software Development
    Replies: 8
    Last Post: 10-20-2005, 01:54 PM
  3. Motor circuit with reverse
    By freestyler in forum Hardware Development
    Replies: 21
    Last Post: 08-25-2005, 01:44 PM
  4. Help with on/off circuit for Mobo
    By powerslide in forum General Hardware Discussion
    Replies: 1
    Last Post: 08-16-2004, 01:48 AM
  5. reverse engineering of cd-changer interface
    By sulten in forum General Hardware Discussion
    Replies: 2
    Last Post: 01-13-2000, 11:36 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •