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. :-)

[Taktyk]

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. :-)

I am not convinced that the mere analysis of firmware, building a RAM map, or the semantic reconstruction of a program's behavior automatically constitutes a derivative work. If that were the case, a significant portion of reverse engineering, security research, documenting legacy systems, or implementing compatibility would be impossible.

Copyright law protects the expression (the specific code), not ideas, procedures, or facts. Building a RAM map is simply discovering facts about how the program manages memory. It is akin to claiming that creating a table of contents for someone else's book constitutes copyright infringement.

Furthermore, comparing this to music, where 'you only have to copy a few notes,' is a classic misconception. Music is a purely artistic work, whereas software is inherently utilitarian and functional. In the context of software, courts (such as in the famous Google v. Oracle case regarding the Java API) have repeatedly ruled that duplicating elements necessary for functionality (e.g., to make a system operate) falls under fair use.

My goal is not to copy or distribute the firmware, but to understand how it works. This is fundamentally different from publishing or distributing the original code.

Stating that reverse engineering is 'not nice' towards the creators is naive. Without reverse engineering, half of the modern IT industry simply would not exist. It is thanks to RE that we have compatible software (e.g., the Samba project, ReactOS), classic console emulators, aftermarket replacement parts, and the entire cybersecurity industry (such as malware analysis).

It is also worth noting that at the beginning of this thread, the original White's schematic was posted along with the manufacturer's copyright notices. It is not my place to judge the legal aspects of such publications, but it shows that the boundary between technical analysis, historical documentation, and copyright infringement is not always as clear-cut as it might seem.

Regardless of that, I agree that publicly sharing a full reconstruction of the firmware could cause unnecessary legal issues, which is why I do not intend to publish any fragments of the firmware reconstruction.

Anyway, this is all AI's and Claude's fault. I merely asked it to translate a small snippet of assembly, and it spat out a much longer fragment of code. Therefore, please direct any potential legal claims to Anthropic. The company is already facing lawsuits from writers and authors accusing them of massively training their LLMs on copyrighted books without permission, so I suppose they can handle this case as well.

With this, I am concluding my participation in this thread.

[boilcoil]

Extremely useful topic, especially for people like me. I, as an old and stupid person, very often do not even know what to ask. In this topic I found answers to many questions that I would never have thought of asking.
Therefore, I thank KRinAZ for starting this topic.
I also thank Carl-NC, moodz, ivconic, Taktyk, Aziz, Okelm, PetraDiamond5, pito, Altra, Skippy and Hristo for their participation.
I think, in view of the specificity and ethics of the presented topic, it is good to strictly limit ourselves in publications, according to the things explained at the end of the topic, or for Carl to close it.

[moodz]

I think the point of the recent discussion is missed. Why do Clean Room Builds exist.

I have done a clean room build. I have expressed an honest opinion. I have released the files.

nuff said .... its a public forum - expect robust discussion.

[boilcoil]

Maybe a new topic?

[Carl-NC]

I dunno if Garrett read this forum ... but putting up a fully reverse engineered copy of the source code would be a copyright infringement IMHO.
Maybe Carl knows ....

Here is what I understand... It is legal to reverse-engineer code for the purpose of understanding how the code works. First Texas did this with the Quest detector to determine that they had exactly copied the T2 code. But it is probably not legal to then use that code to develop a derivative product, unless you substantially re-write the code. "Substantially" is a gray area. Publicly posting the code probably violates copyright, but this can also be gray because we are attempting (as a group) to understand how the code works. It may be easier to pass a "sniff test" if this thread were private to the few people involved.

Here is where I am at on the issue:

If you want to stay on the safe side of copyright, don't publicly post any of the exact MXT code. Post pseudo code, or just describe what is happening.

We can move this to a private thread if preferred.

If Garrett complains, the whole thread may disappear.

[moodz]

Private thread sounds good. Maybe split the firmware research/discussion from the general project.

[moodz]

Here is the semantic C verision of the Clean Room firmware - derived from the clean room assembly.

[pechkata]

Hello all, I've been away for a while, getting back to detecting as I have found a few remote old gold mines here in AZ with apparently untouched mine dumps :^>

So, since White's is sadly no more and the MXT no longer made, I propose a project to make a detector as close as possible to the original White's MXT - with the following few changes:
Essential
1) Highly water (rain) resistant if not waterproof
2) More ergonomic - the MXT's wide control box frequently hits my hip while in motion
3) Powered by Li Ion or Li Po batteries
4) Circuit to charge the batts
5) Bluetooth to output audio to Bluetooth earbuds
Would be nice
2) Maybe a strange option, but option to switch between, or even blend, PI and VLF, both modes with ground balance

The VLF's I have experience with are the Tesoro Lobo SuperTraq (great detector), White's GMT (fantastic but fragile from my experience), White's IDX (good detector), Garrett AT Gold (OK but didn't compare to the MXT or GMT detection), Gold Bug (also great detector). Of all these if I had to pick only one (as I actually did) - the MXT wins.

Why this project?
I'm currently using my old White's MXT to detect the dumps - IMO the MXT the best detector for this and actually IMO the most versatile VLF detector that I have used.
But, I am terrified it will die as it's predecessor - a White's GMT did after getting - not rained on, but just sprinkled on, and White's could not repair it. If my MXT were to die I would try to repair it, but without schematics, firmware, and such...
Hoping there are other MXT fans that would also like to see this project happen, thoughts?

These changes would not infringe the patent rights of the manufacturer.

[moodz]

These changes would not infringe the patent rights of the manufacturer.

There has been enough posted on here to fix your detector ... ( files / schems / etc ). I think all the whites patents have expired but copyright has not.
The only real concern would be if someone started manufacturing MXT clones with the original or derivative firmware ... then Garrett may complain .. maybe they dont care .. maybe they do.

No one will get you for repairing a detector you own.

[moodz]

Now here is a python harness that exercises the firmware and you can see if its working or not.
But its real power is that the AI can "see" this interface and debug the software in a loop without me having to flash and check it manually.

Files attached below openmd cref with python harness gui ... see the readme .... Its all clean room code.

[Okelm]

It's true, Mxt is an outstanding detector, I'm following this thread with bated breath, unfortunately Garrett buried the best projects in the depths,White, and apart from 24k they did nothing, it's a great pity, unfortunately, Vortex is unfortunately, in terms of its structure and programming, like an unfinished project, it lacks that White Spirit, I don't know if they are so proud that they decided not to touch White's projects, I have the intuitive impression that the Vortex is to some extent a GTI 2500, and although I know it was a great detector, it lacked the accuracy that the Mxt lacks.,Anyway, best regards and thanks to everyone who has tried to improve such a great detector as Mxt