Page 1 of 2 12 LastLast
Results 1 to 15 of 16

Thread: decoding and understanding BIN files

  1. #1
    Fuel Injected!
    Join Date
    Dec 2013
    Location
    Marianna, FL
    Posts
    108

    decoding and understanding BIN files

    In the last few weeks of working with my $8D and $EE computers I have begun to wonder how the computer uses the Hex code and the deciphering of the instructions. I have a very basic grasp of how programming works but would like to try my hand at simply picking appart the files to see what makes them "tick". I want to figure out how to decipher the bits we cant see with tunerpro so changes could be made or for a better understanding of why it cant be done. There is a feature I want to work on figuring out that I believe is unique to the ARFP bin as a place to start. The 1990 Corvette has an upshift light that is directly wired to the ecu. Existing documentation says for an L98 engine that it only works to tell you to upshift to 6th at highway speeds. I want to see if that can be changed to a set RPM.

    So far I know the code must be disassembled but I can not find a program to do this at least with the information I have. I have heard about IDA but the freeware doesn't look like it will support this bin file. Any help would be great

  2. #2
    Administrator
    Join Date
    May 2011
    Location
    Lakes Region, NH
    Age
    54
    Posts
    3,847
    Hello,

    Congratulations on realizing there is more to tuning than just the variables. You're in luck! Much of the work has already been done for you. $8D information here:
    http://www.gearhead-efi.com/Fuel-Inj...Information-8D

    Two different disassemblies are here:
    http://www.gearhead-efi.com/Fuel-Inj...ll=1#post14220

    http://www.gearhead-efi.com/Fuel-Inj...ll=1#post27785

    Shift light parameters are adjustable. There are a number of tables and constants involved. See photo for more information.
    Attached Images Attached Images

  3. #3

  4. #4
    Fuel Injected!
    Join Date
    Dec 2013
    Location
    Marianna, FL
    Posts
    108
    Quote Originally Posted by 1project2many View Post
    Hello,

    Congratulations on realizing there is more to tuning than just the variables. You're in luck! Much of the work has already been done for you. $8D information here:
    http://www.gearhead-efi.com/Fuel-Inj...Information-8D

    Two different disassemblies are here:
    http://www.gearhead-efi.com/Fuel-Inj...ll=1#post14220

    http://www.gearhead-efi.com/Fuel-Inj...ll=1#post27785

    Shift light parameters are adjustable. There are a number of tables and constants involved. See photo for more information.
    The $8D xdf I have is not very descriptive of what is what and looking at the S_AUJP xdf most are removed, but thanks for the links as they have steered me down a rabit hole of figuring out what I want that is not already programmed in.

    Quote Originally Posted by steveo View Post
    you need to know some motorola 68000 assembly code. start with a 68HC11 reference like this or you will be totally lost: https://www.clear.rice.edu/elec201/Book/6811_asm.html
    Thanks for the read, this will have me for a while it looks like.

  5. #5
    Fuel Injected!
    Join Date
    Dec 2013
    Location
    Marianna, FL
    Posts
    108
    So I have attempted to decompile the ARFP bin I am using and was successful at getting a response but I dont think I did it correctly. Every value reads like an address of 0xXX where the XX is a hex value. If this is correct then I guess the question is how do I go from hex to value and stick to the confines of this language?
    Attached Files Attached Files

  6. #6
    Administrator
    Join Date
    May 2011
    Location
    Lakes Region, NH
    Age
    54
    Posts
    3,847
    So I have attempted to decompile the ARFP bin I am using and was successful at getting a response
    Hmmm.... Are you trying to describe the operation of obtaining a file directly from the chip? That's generally called "reading" as all that's involved is ascertaining each byte in a series of addresses within the chip.

    Every value reads like an address of 0xXX where the XX is a hex value.
    Each address in the chip contains one byte of data. Bytes are typically represented as base 16, or hexadecimal, values of 00 through FF. When communicating these value in writing one typically uses notations such as $00 or 0x00 to indicate they are communicating hexadecimal data. If you view the data in a tool such as a "Hex editor" you will see rows and columns of hexadecimal values, exactly the way they are stored in the chip. Some programs will output the results with the same notation attached to the values.

    You can confirm that your "read" is good by using Bithoist. The file you ulpoaded is recognized as a valid .bin.

    File 'ARFP-3.bin'
    Address: 0x8000,0xffff
    CRC: 0xa5831bc9
    Mask ID: 8Da
    ID byte: 0x8D
    Sum word: 0xcf2a
    Sequence: Mar 20, 1990 #3909 (03160F45)
    Scan ID: 5801
    BCC: ARFP7185


    If this is correct then I guess the question is how do I go from hex to value and stick to the confines of this language?
    The "values" are "hexadecimal." Some Hex editors allow you to convert the values to decimal. 8 bits can be used to represent 256 values, or decimal 0 through d255. Seeing the numbers as decimal can make them more relatable, but they do not help understand their meaning. In order to get the correct information you need a secret decoder ring, also known as a disassembler. The disassembler will look at hexadecimal values such as 18 A7 05 and turn them into assembly instructions such as STAA $05,Y. A good disassembler will also try to determine where jump instructions lead to, will attempt to replace numeric labels with mnemonic labels (which you will need to supply) and will attempt to determine whether or not sections of code are broken up by sections of variables or non-code. IDA Pro is an excellent disassembler with many functions. A smaller tool that is still powerful is [url=https://github.com/dewhisna/m6811dis]Donald Whisnant's Code Seeking Disassembler.[/quote]


    The reason I linked to those files previously is because they take a massive amount of work out of the task ahead of you. Using an existing disassembly gives you a framework to work with, allows you to learn code flow, allows you to ask questions based on work that others can download, and really puts you ahead of the game. It's like the difference between working with a car built by GM and building a car from scratch. In addition to the disassemblies I linked above there is also a very old one that's been a reference for many years located here: http://www.gearhead-efi.com/Fuel-Inj...6&d=1331601116 .

  7. #7
    Fuel Injected!
    Join Date
    Dec 2013
    Location
    Marianna, FL
    Posts
    108
    What I was trying to do was take the bin file and break it down to replicate the JP_AUJP.ASM from the .zip file you linked to above. What I wanted to do was to attempt to start from scratch and transition from BIN to DIS to readable and alterable code for the sake of understanding. I understand that what I get will not be commented and laid out nearly as nicely. I wanted to try and replicate what was done to learn the process so if I venture to a less ventured mask I am not trying to learn in the dark. Thank you for the link so I can compare the ANHT to the S_AUJP mentioned above

    *edit, so I just looked and realized I uploaded the wrong file. The one in the zip on this post is the one I sent through m6811dis which lead me to the post earlier.
    Attached Files Attached Files
    Last edited by space387; 01-29-2020 at 06:18 AM.

  8. #8
    LT1 specialist steveo's Avatar
    Join Date
    Aug 2013
    Posts
    4,008
    have you configured your disassembler with the appropriate ram/rom regions and an entry point?

    an entry point is where the code starts. lets say you have a byte, 0x8B, located somewhere on your ROM. this could either be an opcode (instruction) that adds to register A or your injector constant. if you are a disassembler, you have no way to tell the difference, it's just a number. but if you point the disassembler at an 'entry point' which you know to be a real instruction, it can follow the rest of the gigantic sequence of instructions to get the entire executable code.

    this requires processor knowledge or some major guesswork, do you know for sure what processor your ECM uses? if you truly want to start from scratch (like the person that did the existing disassembly surely did) you need to analyze your hardware first so you know what you're working with.

    if it's a 68HC11 or based on that, maybe read this whole thing or something like it, as low level software like you're working with here is really just a routine to work with all of these aspects of the processor... https://www.nxp.com/docs/en/data-sheet/M68HC11E.pdf

    do you have a headache yet?

    that's why i dabble in disassembly and know how to mangle existing stuff but ask for a ton of help from people that are better at it than me. my head still hurts a lot of years later from the two weeks of zero sleep i put into getting the 8051's execution loop to transfer from the eeprom to RAM as well as sequentially upload that program during execution so i could even think about a reflash routine being implemented. it's a god damn miracle it works at all and it's just lucky we have people around here that helped me figure out stuff like 'setting this byte actually flips a hardware switch to send VPP to the eeprom'. that level of complexity is nothing compared to trying to understand some of the more advanced fueling/timing routines in these things. i'd rather write an entire program for a fuel injection system than read an existing one. i hope you do better than i have.

  9. #9
    Fuel Injected!
    Join Date
    Dec 2013
    Location
    Marianna, FL
    Posts
    108
    Steveo Im sure I have not set it up properly based on the result I got. The start of calibration values and chipset ID starts at address 0x00 and to my understanding runs to 0x989 I have been told. The last non zero value is 0x987. It is my understanding that 0x3000 starts the instructions for the ECU but once again this is the best of what I can surmise. With that being the case do I start the disassembler at 00 or 3000? Is there a listing of what hex code translates into specific instruction words that I can give the disassembler to work with?

  10. #10
    Administrator
    Join Date
    May 2011
    Location
    Lakes Region, NH
    Age
    54
    Posts
    3,847
    Quote Originally Posted by space387 View Post
    What I was trying to do was take the bin file and break it down to replicate the JP_AUJP.ASM from the .zip file you linked to above. What I wanted to do was to attempt to start from scratch and transition from BIN to DIS to readable and alterable code for the sake of understanding. I understand that what I get will not be commented and laid out nearly as nicely. I wanted to try and replicate what was done to learn the process so if I venture to a less ventured mask I am not trying to learn in the dark. Thank you for the link so I can compare the ANHT to the S_AUJP mentioned above

    *edit, so I just looked and realized I uploaded the wrong file. The one in the zip on this post is the one I sent through m6811dis which lead me to the post earlier.
    That's better. To make progress you need to locate and identify the code entry point. You've already labeled the reset vector. The reset vector at 0xfffe and 0xffff contains the address which is loaded into the program counter on reset. In the ecm the program resides at addresses 0x8000 to 0xFFFF. Your disassembler is addressing from 0x0000 to 0x7FFF. The difference is $8000 so subtract $8000 from the reset vector to get the code entry point, 0x3000. Double check that the instruction at 0x3000 is a real instruction that makes sense. The first instruction in P4 code is usually LDS, load stack pointer. Doing it this way makes it so you can easier match addresses in your disassembly with addresses in someone's definition file.

    You should also locate and download the appropriate aldl file so you can begin to tag some of the sensor variables. Look for hardware addresses that are called out in other P4 ECM's for possible guidance. Look at other disassemblies for code routines such as the 8X16 multiply which is often coded the same in different cals or for code which follows the same pattern, i.e. subtracting the reference angle from the desired spark timing then checking the result against the "maximum retard" limit. Also look for blocks of data which are not code and exclude them from the disassembly.

  11. #11
    LT1 specialist steveo's Avatar
    Join Date
    Aug 2013
    Posts
    4,008
    Quote Originally Posted by space387 View Post
    Steveo Im sure I have not set it up properly based on the result I got. The start of calibration values and chipset ID starts at address 0x00 and to my understanding runs to 0x989 I have been told. The last non zero value is 0x987. It is my understanding that 0x3000 starts the instructions for the ECU but once again this is the best of what I can surmise. With that being the case do I start the disassembler at 00 or 3000? Is there a listing of what hex code translates into specific instruction words that I can give the disassembler to work with?
    the disassembler should know the instruction set of your processor so you don't have to manually describe hundreds of opcodes, if not, get one that knows your processor

    but it's nice to know your processor's instruction set anyway so you know how things work, like this for the 68hc11

    https://www.ele.uri.edu/Courses/ele2...ons/index.html

    each instruction is two or three parts.

    the opcode is really what the 'processor instruction' is and it's 8 bits.

    the 'prebyte' sometimes precedes the opcode to modify its behavior (usually the type of operand) and i guess it's kind of a hack to allow more than 256 functional opcodes while still kinda being an 8 bit processor...?

    the operand is kind of like your 'parameter' and is either data or an address of data that the instruction will work with, and there is a different opcode for each kind of input allowed. there is direct addressing that takes the entire memory address, or offsets that read a certain number of bytes ahead, or immediate addressing for literal bytes of data right in the code itself.

    some instructions have no operand or prebyte, and just clear an accumulator or whatever.

    to make sense of it read the bottom of the page first. with this knowledge you could disassemble the entire program by hand (but it would take forever)...

    it's pretty cool once you realize how much complex work can be done in a compact space by an 8 bit processor like this

  12. #12
    Fuel Injected!
    Join Date
    Dec 2013
    Location
    Marianna, FL
    Posts
    108
    I have entered a few entry addresses at this point and have cleared from 0x3000 to about 0x6000 with 40 entry points. Is this normal or am I doing this the hard way and overlooking something?

    At this point I run the disassembler and look for the next data point thats not broken down, add that address as an entry point and re run it. Its not too time consuming but wanted to be sure its the proper way to do this.

  13. #13
    Administrator
    Join Date
    May 2011
    Location
    Lakes Region, NH
    Age
    54
    Posts
    3,847
    That's the right approach but you can do some sanity checks to ensure the entry point is actually real code. If you find a series of instructions that don't make sense, for example, a series of the same instructions with little code in between, you're probably looking at a data table rather than code.

  14. #14
    Fuel Injected!
    Join Date
    Dec 2013
    Location
    Marianna, FL
    Posts
    108
    Quote Originally Posted by 1project2many View Post
    That's the right approach but you can do some sanity checks to ensure the entry point is actually real code. If you find a series of instructions that don't make sense, for example, a series of the same instructions with little code in between, you're probably looking at a data table rather than code.
    are there any other instructions to enter for that kind of information? I have also noticed that the use of 00 is turned into test for just about everything, can these just be removed from 0989 - 2fff?

    I added where I currently am and changed it to an ASM file so Notepad++ will color everything by the variable type.
    Attached Files Attached Files
    Last edited by space387; 01-30-2020 at 01:05 AM.

  15. #15
    Administrator
    Join Date
    May 2011
    Location
    Lakes Region, NH
    Age
    54
    Posts
    3,847
    Please note that I realize not all of this is new to you, but I am including it for completeness and for others who may follow.

    -------

    I wouldn't advise removing the data from the calibration sections below 0x3000. It can be helpful to have the actual values present when working through the code. Your disassembler should have a control file... enter "org 3000 entry 3000" or similar so the origination point is marked and the data at lower addresses is treated as data. Some examples from a control file I created for $6D, also a 7727 calibration:

    load 8000 ; Beginning of file

    org A000 ; Places label org at 0xA000
    entry A000 ; begin disassembly at 0xA000
    entry a1fb ; End of a data table
    entry a741 ; end of a data table

    label 3ff6 IGNTIM ; replaces "3ff6" with "IGNTIM" in all locations in the disassembly
    label 400C CPUCOP ; replaces "400C" with "CPUCOP" in all locations in the disassembly

    -----------------------

    Here's a section of code the disassembler missed:

    Code:
    brset	*L0029,#0x01,LB00D
    clra	
    clrb	
    subd	*L005D		
    bra	LB00F
    .byte	0x7E,0xB0,0xA1 <-----------------
    LB00D:	ldd	*L005D
    LB00F:	subd	L801E
    It recognized the unconditional branch at 0xB00f. But it skipped code immediately after the branch. But it recognized the code at 0xB00D because there is a conditional branch to that address earlier in the code. Jumps and branches often cause this disassembler to skip bytes. So what to do? I could add an "entry B00A" in the control file and let the disassembler go. But a good sanity check, especilly if there are a large number of skipped bytes, is to grab the instruction set and look up some machine code.

    Code:
    Mnemonic  Operation Addressing               Instruction               Bytes          Cycles
                                   Mode         Prebyte  Opcode  Operand
    JMP             Jump        EXT             —         7E       hh   ll          3               3
    so 7EB0A1 is JMP $B081. Since it's a real piece of code that makes sense I'll go ahead and add "entry b00a" to the control file.

    You'll also notice it's common for the disassembler to choke after RTS:
    Code:
    LCA76:	clc	
    LCA77:	rts	
    	        .byte	0x3D,0xFC,0x3F,0xFA,0x85,0x40,0x27,0x0D
    	        .byte	0x14,0x2D,0xC0,0x15,0x2E,0x20,0x13,0x2E
    	        .byte	0x40,0x03,0x14,0x2E,0x20,0x85,0x08,0x26
    	        .byte	0x18,0x14,0x27,0x80,0x3C,0xCE,0x40,0x02
    For these I usually just add another entry into the control file. RTS is a one byte opcode so the entry address will be CA78. Easy as pi. In the file above I find this:

    Code:
    3C8B			bra 	L3C90
    3C8D	L3C8D:  	rts 												; CRef: 0x3CDE,0x3CE3,0x3CE8,0x3CEF,0x3CF6
    3C8E	L3C8E: 	pulb												; CRef: 0x3C84
    After the RTS we have 3C DE 3C E3 3C EF 3C F6
    This might be code. It would be "psh x ldx 3C addd 3C LDAB..." This is a tough combination to believe is code imo due to the pattern of the numbers. I'd say its more likely a short table.

Similar Threads

  1. Decoding data bus message
    By PeteS in forum GM EFI Systems
    Replies: 17
    Last Post: 09-04-2017, 10:38 PM
  2. Help understanding cts spark
    By myburb in forum GM EFI Systems
    Replies: 7
    Last Post: 07-26-2016, 10:32 PM
  3. Need help Understanding INT and BLM
    By ZEDRATED in forum GM EFI Systems
    Replies: 0
    Last Post: 05-12-2015, 11:09 PM
  4. understanding what the engine is doing.
    By drewkimble48 in forum GM EFI Systems
    Replies: 7
    Last Post: 01-01-2015, 05:38 AM
  5. Need some help with understanding the DFCO.
    By damanx in forum GM EFI Systems
    Replies: 23
    Last Post: 12-07-2013, 06:26 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
  •