Epic reverse-engineering

[Howardlong]

pink hair is hot

Yip.

[ataradov]

This is how hacking should look in movies. And not typing a bunch of random characters into turned off notebook

[mikeselectricstuff]

How hard is really to figure out a Commodore 64 really?

In those days, systems where so simple that it doesn't compare to now, 20 KB of Rom with 6502 code is hardly a challenge.

We are going off topic, but it mostly relied on clever tricks, e.g. one of the "encryption" techniques used was to execute a loader code in screen memory, so in case you break the execution, the screen clears and the code is gone.

ISTR when I was hacking game protection on the BBC Micro, one clever scheme used a hardware timer as the XOR key to decrypt code, so any change to the code would make the results meaningless. They also arranged it so that on completion it dropped straight into the code, so you couldn't easily stop it once the decrypt had happenned. I think the first pass of the loop modified part of the decrypt code as well.

[Kjelt]

one clever scheme used a hardware timer as the XOR key to decrypt code

I don't get this. That would imply that the flow of the program code has to be 100% predictable (always the same) and fully (hardware) time(r) aligned?

[mikeselectricstuff]

one clever scheme used a hardware timer as the XOR key to decrypt code

I don't get this. That would imply that the flow of the program code has to be 100% predictable (always the same) and fully (hardware) time(r) aligned?

Yes. That is why it was so clever. Remember this was a 2MHz 6502 where you have very tight control over timing - the timing between the code initialising the timer and using the value is fixed - it just makes it hard to simulate.

[madires]

one clever scheme used a hardware timer as the XOR key to decrypt code

I don't get this. That would imply that the flow of the program code has to be 100% predictable (always the same) and fully (hardware) time(r) aligned?

Take the code as binary blob, write the decoder function (setting up the timer and a XOR loop) and determine the start value of the timer for the first XOR and the cycles needed for each loop run. Then use those numbers to encrypt the code, put the decoder in front of the encrypted code and have a cup of tea. The timer's start value is the first key. The second key is the start value plus the number of cycles for one loop run. And so on for the other keys. If you don't count CPU cycles, i.e. using the timer with a prescaler, you have to devide the cycles per loop run too. Basically you could use the decoder to encode too

[Kjelt]

the code initialising the timer and using the value is fixed

Ok that could work, I read it as that the software was using a free running hardware timer which will not work.
Still tricky if there are HW interrupts that could interfere.
And I guess you have to (re)set that timer for every branch in the code?
Still the regular setting of the timer gives this neat trick away to the hacker.

[Kalvin]

the code initialising the timer and using the value is fixed

Still tricky if there are HW interrupts that could interfere.

Like a [HW] debugger used for reverese-engineering the copy protection?

[SArepairman]

pink hair is hot

Yip.

bro common whats next goatse

[Muxr]

Old school reverse engineering was hard core because there was no web or google. Now days it's all about how much time you want to spend cracking something, provided you have some fundamentals, time and will.

[ataradov]

And grass was greener and trees were taller as well.

In the old days they could not have engineered that much in a first place. Both engineering and reverse-engineering techniques go hand in hand, so no need to complain.

[mikeselectricstuff]

And grass was greener and trees were taller as well.

In the old days they could not have engineered that much in a first place. Both engineering and reverse-engineering techniques go hand in hand, so no need to complain.

A major difference is that nowadays, the amount of code is vastly bigger, and may well have stuff like bought-in libraries and leftovers from other versions, which makes disassembly a lot harder.
Gone are the days when you could hook up a logic analyser to an address/data bus to capture every read/write cycle & follow code execution paths

[Kjelt]

That said look at the Rigol scope hack, I2C and the hint of an ECC lib and a very talented hacker/engineer.

[Muxr]

And grass was greener and trees were taller as well.

In the old days they could not have engineered that much in a first place. Both engineering and reverse-engineering techniques go hand in hand, so no need to complain.

True. Also agree with Mike's point.

I believe that democratization that Internet provided has made it far more accessible than it used to be however. Sure the technical complexity has gone up, but so have the tools, like this for instance: https://hackaday.io/project/956-chipwhisperer-security-research

As well as the accessibility of tools in general. I am looking at it from the other side. If you were tasked with securing something I think it would be harder today.

I am not complaining at all, I think it's fascinating, just reading through that Rigol thread was pretty cool, to see the community coming together to hack the product in such a short amount of time.

[eneuro]

Now days it's all about how much time you want to spend cracking something, provided you have some fundamentals, time and will.

Probably you watched too many james Bond films 
Try to crack this message:


Ok, maybe it is not message but... ATTiny85 code?

I can help you-do not waste your time-it is not possible to crack this 

[mikeselectricstuff]

Of course the flipside of code sizes getting bigger is that when manufacturers are effectively forced to choose an off-the-shelf OS, this allows all sorts of potential ways in because of it's general-purpose functionality, like with the Flir E4 !
Bigger code can sometimes mean more ways in

[T3sl4co1l]

A major difference is that nowadays, the amount of code is vastly bigger, and may well have stuff like bought-in libraries and leftovers from other versions, which makes disassembly a lot harder.

And you can't tell what they were thinking.

What is this shit?  It's all just moving around, going in circles...

Why are we jumping into this?  We were already here a hundred times...

Nevermind, probably just some dumbass compiler...

...But then, if you gain familiarity with the typical compilers, you can recognize their output.  It may be dumb output, but it's characteristically dumb.  Like the dull kid at school, easily recognized.  That helps to distinguish not just between functions, but between internal and library functions, for example.

Same goes for libraries, whether purchased or free -- it's all bad!  Free software is often better, rarely so much in quality (unless it's an exceedingly popular distribution with a lot of exposure), but just because, at least you can fix it from the source level when it does break.

Tim

[Dongulus]

Take a look at 2:18 into her second video. It seems that Scanlime is a fan of Dave's videos.