EFIDynoTuning Forum

wwhite

It's a little more complicated than a config file, but yes.
Ghidra uses 'Sleigh', a language for rapid processor specification, as well as 'P-Code', a register transfer language designed for reverse engineering applications.
There are five(5) mandatory files,
- language definitions (.ldefs)
- processor specification (.pspec)
- compiler specification (.cspec)
- sleigh specification (.slaspec)
And those are compiled to create to a .sla file.

I'm writing a readme.md and also working on having the contextual opcode help pop up.
It will be super simple to create another for the 8065 processor as well.

I'll create a new project in github, and post a link here in the next day or two.

Ahh, why wait, here are the files to download:

806x.zip: Ghidra EEC-IV 8061 processor; (61.12 KiB) Downloaded 365 times

wwhite

Ghidra is a free and open source reverse engineering tool developed by the National Security Agency.

I've been playing around with Ghidra, similar disassembly to IDA.
I've created the 8061 processor from the 8096 processor. Works well, took a few days to get 100% disassemble my bin.

This would not have been possible without the help of this forum (decipha) and the excellent work of SAD.
The disassembly is a bit of a manual process, and allows you to define different areas of RAM(SFR, General, etc.) and ROM.

The usefulness of this tool is that it shows you C code style disassembly, graphical flow of code, and references to and from routines, and much much more. Actual debugging (like IDA) is not yet possible, but maybe soon. There are many other features, like adding parameters to functions, and setting return values. With memory mapped out, you can set/clear registers, so you can see how the values are used in different parts of the code.

Below is a screen shot, showing the code browser, graph window, register window:

Download image here:

wwhite

Hi,
Since the new forum, I've received the "Server Hangup" message a few times.

From my quick research, it could mean you have default php settings for session timeout, max file size, post size, etc.

If it because a continuous issue, you'll have to investigate the server logs.

This happened between 10:35am and 10:50am (PST), Friday Feb. 26, 2021.

I'll log the time if it happens again.

wwhite

efloth wrote: ↑2021 Feb 24, 20:07 Are the extra values in the parameter list just garbage left over?

No, some of them are bytes. The 0000 and 1F1F are separators i think. You have to step through the logging code to figure out exactly what's going on.

If the Payload references values like 0x0D8D(twice) that were not copied by the patch then how could that data be relevant? Placeholders?

8D is a byte. The memory location 0x8c is copied by the patch. One word of 0x8c includes 2 bytes (0x8c and 0x8d), stored [0x8d], [0x8c].

The only AD channel that is being referenced by the payload is ChB. Is that normal?

Could be, depends. The other channels probably are read into a register, and stored there as a value.
Then, that value is probably used in another equation, or compared with max/min, clipped, etc... then stored in a different register, which is then shadowed copied and read by payload.
The AD channel registers would be the RAW data, may or may not be useful.

wwhite

I wouldn't change the parameter list, unless your not using A1C.bin.

If your not using A1C.bin, your going to have to disassemble enough, to know what memory address locations are what parameters.
Then you will have to update the parameter list, to match the packet offsets.

The only thing universal, is the mapping of returned bytes from the payload list, maps to packet offsets in the .adx for displaying of data.

wwhite

efloth wrote: ↑2021 Feb 22, 18:06 Ok that is good to know, I will try to log directly. I really appreciate your help. FYI the universal ADX has selectable payloads configured for every strategy. A1C Payload Looks like this: I am just adapting for a different box code.
Code: Select all
0x51 0x40 0x01 0x03 0x1F 0x1F 0x02 0x03... 

QuarterHorse protocol:

Code: Select all

5140 // set up data query format
01031F1F // offset 0 - not in list but polled for superlogger offset
02030DD6 // packet offset 1, ram 0xd6, 2 bytes, memory location 3
02030396 // packet offset 2, ram 0x396, 2 bytes, ...
01030DB6 // packet offset 3, ram 0xb6, 1 byte
01030DB7 // packet offset 4, ram 0xb7, 1 byte, ....
02030D9 ......

wwhite

efloth wrote: ↑2021 Feb 22, 16:13 Please correct me if I am wrong, the above addresses are not directly readable by the QH so they are being copied by the datalogging routine to readable addresses. The ADX is configured to read shadow addresses so the big question is in what order are these shadowed? My Datalogging List function below is a copy from the A1C DL Patch. Can I assume that 010a=3030? I think I am missing part of the equation. Thanks for all your help.

The datalogging function is to copy addresses 0xff and below to shadow ram so QH can read and be logged.

There are three parts to the patch:
- first, the function that copies addresses from list to be shadowed, this is hardcoded into bin, the patch
- second, the list of specific address that are below 0x100, this is hardcoded into bin.
- third, payloads are sent from QH to read specific address locations.

It is the ordering of payloads that are important.

Example:
- data logging list: "D600 9603 B600 9A00 CC00 BA00....'
- data logging function copies "0x00d6" to [d00] = 0x0dd6
- payload read from xdf has "0DD60203", second packet (first 0-index based), means Read address 0x0dd6, 2 bytes from bank 3.
You will see that in the adx, packetoffset 0x01 is QH_ATMR1.

So, if you were looking for 0x010a, which isn't logged, or read in the payload, your not going to find it unless you put it there.

If your bin is anything like mine, 0x010a could be key power or battery voltage, maybe:

Code: Select all

02,0a,01            struct    2, Key_Pwr

I do not see where you get 0x010a = 3030, that doesn't make sense, you are missing something there.

wwhite

AKshadow wrote: ↑2021 Feb 17, 23:08 How about Tapatalk? Big fan of the interface, makes it easy to participate on the fly and in the garage.

There is also Discourse: https://github.com/discourse
100% opensource, simple discussion feed.

phpBB is good, and definitely overkill for what your doing here on efidynotuning.

What ever gets the job done.

wwhite

Any outside link to your website is broken.
All Search Engine Optimizations (SEO) are gone, search engines will start to degrade your site, harder to find.

Sorry to be blunt, but you are doing an extremely poor job of maintaining your website.

No backup, just "yep old stuff is gone"?

I think you are going to lose a lot of the community, unless that was your plan, to start fresh.

How long until the next crash, or update, where all the data is "just gone" again, at your discretion?

wwhite

What about programming and software section, that generalizes all EEC-IV and V?
There were a lot of threads to do with SAD, decompiling and assembly code in general.

This new forum has zero threads that relate to my setup, and what I'm working on. Would be nice to restore the history.

EFIDynoTuning Forum

Search found 320 matches

Re: Ghidra - open source reverse engineering tool

Ghidra - open source reverse engineering tool

Server Side Errors - Server Hang Up - php settings

Re: Ford Universal ADX

Re: Ford Universal ADX

Re: Ford Universal ADX

Re: Ford Universal ADX

Re: New Forum

Re: New Forum

Re: New Forum