Let's make a closely MXT like detector!

[Aziz]

AI doesn’t replace thinking - and I honestly have no idea what your comments add to this discussion.

This is a fundamental issue. It fits fully to the discussion.
The AI gives you a lot of food for thinking and asking the right questions. You decide the path to go. AI helps in finding the path you want to go.

Believe me. AI is the best tool ever..

[boilcoil]

Hey Moodz,
Amazing performance.
You are an extremely smart guy, hats off to you.

[Taktyk]

So to answer your question .. .what did the AI achieve here ? ... plenty !

See the full assembly source attached ...

I reviewed your code. What you have is a completely different program architecture.

It looks like you generated an alternative assembly firmware.. That can be a valid clean-room reimplementation, but it is not the same as recovering the original firmware.

Your code does not match the disassembled MXT firmware. There are fundamental differences already at the reset vector, interrupt handling, watchdog usage, memory layout, and overall program flow.

For comparison, my own reverse-engineering work is still unfinished, but I am already building a RAM map directly from the disassembled firmware, tracking actual register usage, bank context, read/write sites, and unresolved aliases instead of assuming a clean high-level architecture.

So I would describe your project as an alternative firmware implementation that tries to emulate the original behavior, not as code that is consistent with the original disassembled firmware.

My goal is not to claim that I have recovered the original source code line-for-line. My goal is to build a semantic C reconstruction based on the actual disassembled firmware: something that documents the real control flow, RAM usage, register behavior, signal processing, UI logic, and unresolved ambiguities. Such a reconstruction can be used as a reference, as inspiration for compatible firmware, and potentially as a way to identify or fix design mistakes in the original firmware.

[moodz]

I reviewed your code. What you have is a completely different program architecture.

It looks like you generated an alternative assembly firmware.. That can be a valid clean-room reimplementation, but it is not the same as recovering the original firmware.

Your code does not match the disassembled MXT firmware. There are fundamental differences already at the reset vector, interrupt handling, watchdog usage, memory layout, and overall program flow.

For comparison, my own reverse-engineering work is still unfinished, but I am already building a RAM map directly from the disassembled firmware, tracking actual register usage, bank context, read/write sites, and unresolved aliases instead of assuming a clean high-level architecture.

So I would describe your project as an alternative firmware implementation that tries to emulate the original behavior, not as code that is consistent with the original disassembled firmware.

My goal is not to claim that I have recovered the original source code line-for-line. My goal is to build a semantic C reconstruction based on the actual disassembled firmware: something that documents the real control flow, RAM usage, register behavior, signal processing, UI logic, and unresolved ambiguities. Such a reconstruction can be used as a reference, as inspiration for compatible firmware, and potentially as a way to identify or fix design mistakes in the original firmware.

Thanks for reviewing the code ... If the arch is different then the clean room has done its job by not creating a "derivative work".

The fact that you are building the RAM map will be a red flag in regard to derivative work. I have no idea if Garret would chase you or anyone over this work.
Lets hypothetically say that Minelab buys Garret out ... dunno if that is possible ... but ... if it did happen and they aquired by that buyout the whites IP ( including copyright ) they will definitely sue the pants off you. ( they defend their IP very aggressively )
I have known people its happened to and its not nice.

Even if you write the port in COBOL it will still be a derivative work because you have said you are reverse engineering firmware and have admitted it in posts here.

Legally but not probably if I had a clean room build folder and there was a copy of the firmware in that folder that I never looked at or referenced ... I could still be done for copyright violation if a discovery order was made ( ie the lawyers sieze your computer ).

In music for example you only have to copy a few notes of the whole song to violate ... just depends who might want to chase you.

The Berne convention covers 180 countries for copyright .. in some places like the US . copyright can last 120 years ....much longer than patents.

So you are writing it in semantic C .. well there is no compiler that will regenerate the hand coded ASM as it is unless you use total inline assembly ( which defeats the purpose of C ).

To sum up its just not "nice" to reverse someones compiled code unless they give you permission ( company or hobbyist ) as you are gaining that benefit without attribution to the work of the author ( company or hobbyist ).

does anyone care .. probably not. :-)