Monday, March 23, 2015

The Principle of Reverse Engineering and the Sensen Papyrus

When I know the values already of something, I am not trying to find values.  What I'm doing here in this blog is an exercise in FINDING THE PROCESS AND THE PRINCIPLES behind something.

When you step on the gas pedal, you have one known thing, A.  And when you see the car go, you have another known thing, Z.  If you are not a mechanic, and you have no mechanic to teach you, you have to open up the hood and start looking to figure out how you got from A to Z.  In fact you may have to dismantle the whole engine to figure it out.  You observed that cause (gas pedal press) led to effect (car moving).  And you have another known:  that you have to put gas in to get it to go.  It doesn't help that you don't know yet the steps inbetween and the mechanism.  As in Computer Science, that which is under the hood is ENCAPSULATED and out of your view.

It is a black box, until you rip that box open.  When software testers do black box testing, they are agnostic about the inner workings of the thing in the box.  But this is about ripping open the box.  As a software engineer, I know that the existence of a black box is helpful in management of complexity, because it is the Abstraction principle in object oriented programming.  But in the end of the day, I have to have conciousness of what is inside the box if I have a bug that is hard to track down.  When I really need to know, especially when some other engineer designed the thing inside the black box, I have to go from the known to the unknown, tracking down and understanding what that person did that originally programmed that thing inside the black box.  And if there is no good documentation, and the programming style is confusing, then I have to go into debug mode in my programming environment, and trace down what is actually going on, inside that box.  Just trying to understand what another programmer did when there is a bug, is an exercise in reverse engineering.

If it is something where I have a component that is compiled down to some level of something closer to machine code, maybe .NET or Java bytecode/IL code from another company and a bug exists in it, then I am even in further trouble, because I have to decompile the thing from that lower level code and then dive in.  And in those cases, variable names are not there anymore so I have nothing to guide me, and no documentation.  All I have is my ability to trace through the code and watch it do what it does in each step.

Hashing in cryptology is similar to reverse engineering, as I mentioned in the previous blog post.  Hashing only means anything if you know the answer and work backwards.  I presume that you know that as someone knowledgeable in math.

Calculus, by its very nature, is an exercise in reverse-engineering.

Here is another point.  Egyptian was solved from seeing the answer:  The rosetta stone gave the answer, and they had to work backwards.

That's the nature of reverse-engineering.  Knowing the answer and working backwards, because the true answer is the process and the mechanism, not the answer.  The so-called answer is really not the "answer," just one of the the things that are known.  The true answer is really the unknown thing, and is in this case, the process in the middle.  The thing at the start and the thing at the end are known.

Moving from the known to the unknown.  Really, that is the point of algebra too, to discover the unknown from the known.  There is no fundamental difference really.

I am reverse-engineering things.  That's what reverse means.  Backwards.  That's the nature of the thing.  So, now, if someone presumes to lecture an someone knowledgeable in Egyptian history and language and tell him reverse engineering cannot deliver results, then he will give you a lecture on the history of Champollion and the Rosetta Stone, and you will quickly realize that it was a mistake to lecture someone about the fundamental nature of how the knowledge of Egyptian translation was rediscovered.

Since it took the Rosetta Stone to decipher regular Egyptian, it isn't surprising that it takes the KEP and the Facsimiles Explanations to decipher what is going on with the Book of Abraham.  After all, these are Egyptian characters.  It's not the so-called "answers" that needed to be found.  Its about how the answers are arrived at that we had to decipher.  It is moving from the known backwards.

Some food for thought and real world examples, since this is a real world thing:

http://refineandfocus.com/2012/05/reverse-engineering-refinefocus-approach-to-business/

http://www.muppetlabs.com/~breadbox/txt/acre.html

http://stackoverflow.com/questions/988642/how-would-i-reverse-engineer-a-cryptographic-algorithm

http://www.muppetlabs.com/~breadbox/txt/acre.html