The content of a .tar firmware file

[John Kaufmann]

Someone may point out 'you don't need to know that' -- but I'd like to understand the content of a .tar firmware file.

As an example I take A0EDFW.tar for the bizhub C220/C280/C360 machines. It contains 35 files of the form

AMUR_???.bin
plus an INDEX file that is kinda-sorta-but-not-really an index of the .bin files.
(The INDEX claims to be of "@TYP=Amur", but there the connection to the .bin files seems to end.
For example, it only contains 29, not 35, entries, and none seem directly related to the .bin files.)


Equally important, I don't see a connection between the AMUR_???.bin files and the functional firmware modules listed in the service menu [Firmware Version], so I don't know the purpose of the individual files in the tarball.

In other words, I don't really know where the firmware update is going or how it's getting there. Although I don't need to understand that, I'd like to. Can someone point me toward enlightenment?

[Toxic]

KM software engineer can probably explain it but here we are mostly "small" technicians and i personaly never see anybody here who works directly for KM. :)
But lets wait, maybe i am wrong and we have some expert here who can clarify your question.

[tsbservice]

I highly doubt KM direct engineers or even their seniors have such knowledge.
Maybe jotuhn who's member here with more deep understanding/knowledge of 'forbidden fruits to eat'
Imho not something to be discussed in public.

[John Kaufmann]

I highly doubt KM direct engineers or even their seniors have such knowledge. ... Imho not something to be discussed in public.
Hmm... likely reflects a failure of imagination on my part, but I can't imagine why not. Seems like everybody would win with a better understanding, including KM. You think they make it deliberately obscure, even misleading?

[srvctec]

My take on this is that if it was public knowledge or made public, it might lead to possible hacking of the firmware if all the details are available on the inner workings of it. In this day and age, security is a HUGE selling point and KM has a long history of producing some of the most (if not THE most) secure mfp devices available.

[John Kaufmann]

My take on this is that if it was public knowledge or made public, it might lead to possible hacking of the firmware if all the details are available on the inner workings of it. In this day and age, security is a HUGE selling point and KM has a long history of producing some of the most (if not THE most) secure mfp devices available.
I appreciate that thought, and infer that your answer to my question -- Does this represent a KM intention to be obscure (or even deceptive)? -- is Yes. Do we have any examples of insecurities in other manufacturers' MFPs due to lack of obscurity?

I'm not sure as to KM intentions, and definitely not sure that obscurity is the way to security. That's of course a long-debated question (https://ithemes.com/blog/security-vs-security-through-obscurity/), and at this point open-source software (OSS or FOSS (free open-source software)) seems to be doing a good job at, say, running the Internet -- and probably is the basis of KM MFPs.
at least as capable, and at least as secure, as proprietary software. Often both the security and the functionality are enhanced by opening the software to more eyes and allowing user-initiated enhancements.]


That does not mean KM should open all of their code. There are plenty of commercial and engineering reasons, ranging from business advantages to machine safety (for example, the physical limits of their designs), for not publishing their application code. But where there is an interface with others -- such as in updating that operating firmware -- it seems like everyone benefits from a clear understanding of at least the outlines of what is happening. Take the example I offered: What is the purpose of that INDEX file? What would be the consequence of it being wrong? Transparency in issues like that -- even a comprehensive set of revision notes -- would seem to serve everyone, with no loss of security.

FWIW, I've seen my own company [not current] hide mistakes behind a "classified-proprietary" label, and only get them fixed -- to everyone's benefit -- when exposed. I certainly hope that is not happening here, and so far am not convinced that it is. We all want these machines to run as well as possible.

[tsbservice]

I appreciate that thought, and infer that your answer to my question -- Does this represent a KM intention to be obscure (or even deceptive)? -- is Yes. Do we have any examples of insecurities in other manufacturers' MFPs due to lack of obscurity?

I'm not sure as to KM intentions, and definitely not sure that obscurity is the way to security. That's of course a long-debated question (https://ithemes.com/blog/security-vs-security-through-obscurity/), and at this point open-source software (OSS or FOSS (free open-source software)) seems to be doing a good job at, say, running the Internet -- and probably is the basis of KM MFPs.
at least as capable, and at least as secure, as proprietary software. Often both the security and the functionality are enhanced by opening the software to more eyes and allowing user-initiated enhancements.]


That does not mean KM should open all of their code. There are plenty of commercial and engineering reasons, ranging from business advantages to machine safety (for example, the physical limits of their designs), for not publishing their application code. But where there is an interface with others -- such as in updating that operating firmware -- it seems like everyone benefits from a clear understanding of at least the outlines of what is happening. Take the example I offered: What is the purpose of that INDEX file? What would be the consequence of it being wrong? Transparency in issues like that -- even a comprehensive set of revision notes -- would seem to serve everyone, with no loss of security.

FWIW, I've seen my own company [not current] hide mistakes behind a "classified-proprietary" label, and only get them fixed -- to everyone's benefit -- when exposed. I certainly hope that is not happening here, and so far am not convinced that it is. We all want these machines to run as well as possible.

Instead of practice of sophisticated wordings your tirade/questions doesn't make sense at all to me. I quit.

[John Kaufmann]

Instead of practice of sophisticated wordings your tirade/questions doesn't make sense at all to me. I quit.
I am sorry. What you saw as a tirade [which I always thought involved anger] I saw as explanation. What you saw as questions were questions, with the same purpose: to understand. I respect your view. My view is that truth and transparency generally serve everyone, and that secrecy has limited value, especially when something apparently does not make sense.

[ejfel]

Good afternoon everyone. I understand that company policy does not approve of this, but is it possible to upload the A0EDFW.tar file with the ability to select the German language? No matter how much I searched in open sources, I couldn’t find it. Very important, thanks in advance.