CODEWITHSUNDEEP
assemblyencryptionreverse-engineering
binaryBigInt
binaryBigInt

Reputation: 1704

Reverse engineer assembler which probably encrypts code?

I use an IDE with integrated assembler to write code for microcontrollers of a company which also produces the IDE and assembler I just mentioned. Because the development kit with hardware in-circuit programmer is quite expensive I would like to reverse engineer their way of assembling the written source-code into the file format which is later transferred to the controller via the programming device.

So basically what I did was writing a very basic assembly program (like this):

mov a, 0x01

and changed very little of it (like this):

mov a, 0x02

then I took a look at the generated files in binary format. What I expected was not even close to what was actually happening:

Not only a single byte changed (what I was hoping for) but 2000 bytes of a total of 2300 changed!

The methods which would be possible to do this are either encryption or compression, or maybe both combined.

Is it possible to decrypt or decompress the files even though I have no idea what algorithm they are using?

Upvotes: 0

Views: 177

Answers (1)

Grigory Rechistov
Grigory Rechistov

Reputation: 2234

Do not assume the most complex answer to your questions; instead, always look for the simplest explanation of what you see. Why going all the way to encrypting and stuff when vendor's low market share and lack of documentation do almost as good job in keeping secrets? Adding encryption (and decryption in hardware!) will cost the vendor (a lot of) money.

It may simply be the case that the two instructions you used are very different, and also that your tools calculated difference incorrectly.

mov a, 0x1 may be encoded as inc a, which might be, let's imagine, one byte long, and mov a, 0x2 may be representable as a two byte machine instruction. After that all the subsequent bytes will be offset to one position in files being compared, and, if your comparison tools cannot accommodate for that, they will report a huge difference.

In general, it is possible to reverse things. It will be very time consuming, an undertaking proportionally big to the size of instruction set and to number of features the binary format you are studying.

Essentially, you want reconstruct the layout of a binary format, and machine encoding scheme. Providing minimally different inputs and looking at outputs is a correct first thing to do; but you cannot make conclusions just after a single experiment. It is simply not enough data collected.

If you are really decided to jump into this, I recommend you to start from studying papers, tools and approaches used by people for solving similar cases. Hackme tutorials, papers on reversing etc. Be prepared that it will take you a least several months before you could get first results. It is fun, but not always a well-paid activity.

Upvotes: 2

Related Questions