Let's make a closely MXT like detector!

[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]

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.

[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.

[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]

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.

[boilcoil]

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

[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..

[Taktyk]

And my strong advise to the people out there:
Learn how to use the AI for yourself.
Learn how to use the AI for yourself.
Learn how to use the AI for yourself.

It is a peanut, if it is costing some money. But there are ways to use it for free too.

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

[Aziz]

And my strong advise to the people out there:
Learn how to use the AI for yourself.
Learn how to use the AI for yourself.
Learn how to use the AI for yourself.

It is a peanut, if it is costing some money. But there are ways to use it for free too.

[moodz]

You can approach it the way you described and even recreate the detector’s behavior from the manual, schematic, and engineering report. However, my original goal was to create semantically reconstructed code while also testing how well AI could handle such a task.

As for the ownership issue, you are right. That is why I changed the repository to private, and I will no longer publicly share any of this.

Good idea .... of course the danger of clean room implementations is that there is a certain "personality" in the detector that can be lost with a functional replication ( but not original code ).

[Taktyk]

Actually when I used to work ( LOL ) .... one of my engineering tasks was protecting intellectual property. If Garrett do own the whites IP rights then blatently putting up copies / reverse engineering the firmware is a violation of copyright and could result in a takedown notice to this forum at a minimum and something more threatening at worst. ( depending on jurisdiction firmware copyright can be 70 years + ).

I saw that you and others were doing ( presumably good work ) but you are still creating a derivative work ( by reverse engineering ) so you are back at my first statement above.

The AI claimed to have fully decoded and extracted everything the orignal code does .. this was trivial for the AI BUT again refer to my first statement. ( so I wont be publishing it here unless someone else cares to do it).
It did this by compiling the assembly code, running it in a simulator with code stubs that simulated all the inputs / ouputs ( like the adc, the pots, the swiches, the audio ) etc and seeing if it matched the behaviour from the schematic and the user manual. The AI looked into registers and memory in the simulator to figure out what was changing what ... this is an old hardware hacker method.

Unlike your commendable efforts I have only shown that there is an alternate path to achieve an outcome that does not involve reverse engineering the code but infers the required internal code from looking at the behaviour of the circuit, the signals at each pin and lastly reading the fine manual ( aka RTFM ) .. .that is the AI reading the manual ... not me.

You mention your analysis where claude etc spent hours determing the inner workings etc ... this is where context engineering comes into play.
My approach is to look at the schematic ... what is the circuit doing at each pin. What is the signal behvaviour at each pin. What is the code that could produce that behaviour or process that signal. Then read the user manual, what are the controls, the LCD display, the boot behaviour, the switch functions ( description of each ). What is the timing of all these signals. This is the context.

The most important part is to start generating code then run it through a compiler then a chip emulation ( cycle accurate ). Its not like there were no bugs ... there were quite a few ..particularly around interrupts. Then the AI changes the code ... runs the sim again etc. until the code runs in the sim with no errors and the timings / behaviours are all consistent.

There is no hype here .. the interface to any LLM seems to be "hypy" in nature. I am just reporting what it was reporting to me.

By doing a clean room build "the uncertainty" you mention is removed. Yes in the original firmware there are variables that are "uncertain what this does / is for". In hindsight there are no "magic" algorithms in the original code in fact there are quite a few shortcuts and space saving assembly kludges that were not needed since the code fits easily into the chip.

Could there still be bugs ... absolutely ! ... but I ( err the AI ) has only spent a couple of hours on it.

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

See the full assembly source attached ...

You can approach it the way you described and even recreate the detector’s behavior from the manual, schematic, and engineering report. However, my original goal was to create semantically reconstructed code while also testing how well AI could handle such a task.

As for the ownership issue, you are right. That is why I changed the repository to private, and I will no longer publicly share any of this.

[Aziz]

... bigger than the invention of the wheel IMHO

This is a good underestimation.

It is much much more.

[Aziz]

And can you imagine, that 1 TB of data (it is a small hard disc), which contains 2 trillion parameter neural network (4-bit floating point number) contains the whole world knowledge and the processing scheme for the knowledge?
We are heading to the multi-trillion parameter networks. Faster and faster.

[moodz]

Hi all,

some words about AI and the so called "hype".

There is no hype in AI at all. Absolutely no. It is real.
It is a damn fnk real thing.

There won't be real investments in billions/trillions dollars if this would be a "hype".

If the AI says nonsense, it has learned nonsense. Because the internet & publications contain these nonsense.
But the AI is getting better and better.
It's the beginning.
We will say in 10 years still "it is the beginning".
And we will say this again in 20 years "it is the beginning..".

AI ain't being hype. And it is getting better and better.

... bigger than the invention of the wheel IMHO

[Aziz]

Hi all,

some words about AI and the so called "hype".

There is no hype in AI at all. Absolutely no. It is real.
It is a damn fnk real thing.

There won't be real investments in billions/trillions dollars if this would be a "hype".

If the AI says nonsense, it has learned nonsense. Because the internet & publications contain these nonsense.
But the AI is getting better and better.
It's the beginning.
We will say in 10 years still "it is the beginning".
And we will say this again in 20 years "it is the beginning..".

AI ain't being hype. And it is getting better and better.