Patching 68K Software – SimpleText | Hacker News Reader

Patching 68K Software – SimpleText

tinkerdifferent.com

106 pointsmmoogle17 comments

This is beautiful, but the real takeaway should be that even proprietary software you only have binaries for is still mutable. The computer runs the code you want it to run. We always need to maintain that and prevent scenarios where general purpose computers stop being the default.

We were always doing this kind of thing on these platforms. This is how we used to hack copy protection out of games.

Stepping through, line by line, editing the code and adding JMPs to get around the copy protection code after loading the magic numbers into the register...

Happy, happy times.

Then they started loading the protection code from disk doing tricky things. One I cracked recently was a pair of Commodore 1541 sectors that appeared to be the same logical sector (because the drive head is blind). It needed to hit both of them to compile the next portion of the loader. Naturally the segment up to that point was encrypted as well, but nothing survives a VICE breakpoint. https://oldvcr.blogspot.com/2023/08/cracking-designwares-gra...

Obviously this is nothing on things like V-MAX! and Rapidlok which even nowadays have variations that are tough to remaster.

That's beautiful.

That's how I first learned assembly. Armed with a monitor program that can disassemble and modify memory, I read and modified programs stepping through them. Mostly games, naturally. I never got an actual assembler/linker chain that would work and useful software was hard to come by.

Unfortunately the whole "open source" movement has diverted attention away from that and brainwashed countless would-be power-users and even developers into believing that they are powerless to do anything without the source code. It's convenient to have the source, but not necessary for freedom.

Cat's out of the bag there already. We all have general purpose computing devices in our pockets, locked down on purpose. Android used to allow you to gain admin rights but it's been getting more and more impossible to do so while still keeping most of your programs working. It's not only a cat-and-mouse game against "rooting detection" SDKs companies licence and plug into their apps out of a misguided duty of care, but it's especially bad with anything that uses Google's remote attestation lately.

Android is also about to lock down "sideloading", another "great" dysphemism for "installing software".

Moving the Overton window on this has been so successful, that even people in our industry happily accepted the much maligned dysphemisms of "jailbreaking" and "rooting" for what used to be called "local admin rights" and look upon such access as if it's only something pirates, criminals or malware spreaders would want to do.

I say this as someone who is running an Android phone with a kernel with some backported patches applied and compiled by myself. The fact that I can do it is great. The fact that the entire industry is trying to make it as frustrating as possible for me to do this under the guise of false premises such as "security" is disheartening.

> even proprietary software you only have binaries for is still mutable

POKE 35136, 0

thus it ever was.

For people not used to reading MC8k assembly [1], it's helpful to point out the basic fact that the syntax is in general

    opcode  source, destination

which is the other way around from most contemporary ISA:s. So a line like

    move.l d0, -(a7)

will first decrement the value of register a7, then write the contents of register d0 to the resulting address (it's a "push" for a downwards-growing stack).

Edit: added Wiki-linkage.

[1]: https://en.wikipedia.org/wiki/Motorola_68000#Instruction_set...

68K style always made more sense to me: we read left-to-right, after all. Why should we suddenly switch directions for the operand order? It's confusing.

I believe the reasoning for the "Intel style" ("op dst, src") is that it reads more like "dst = src" which is how it's written in higher-level languages.

I thought option-resize was supposed to resize the default (new document) window?

My recent pet peeve is that macOS doesn't seem to remember window sizes and locations properly. Things are certainly complicated by multi-monitor setups, but it seems like some sensible default behavior could be implemented.

I don't dislike the column browser, but I wish macOS would preserve/revive its spatial UI in both the Finder and document window positions.

I really miss the spatial classic Mac OS too. I don't think spatial orientation will ever come back to the Mac. Apple seems to have moved on completely.

In some ways, the world has moved on as well. Spatial orientation worked really well when the number of files and folders we typically dealt with was fairly small in number. Now we tend to deal with huge numbers of files, most of which aren't even on our local computer. It's hard for me to imagine how a spatial system like that could be made to work with all of that. What would a "spatial Wikipedia" look like?

I fondly remember patching 68K code in memory on an industrial control system my company was developing. I was able to decode the instructions just by looking at the hex display. Daresay, I could not do that with any modern system.

The first assembler I had to look at was PDP-11 code. 68k is kind of like a 32 bit PDP-11, easy to see what's happening. One of my very first paid tech jobs was maintaining an ST506 driver written in 68k asm by game hackers using self modifying code for no specific reason other than that's how they roll.

I used to love doing this sort of thing back in the early '90s. What a nostalgic read! Funny that there are still people doing it today.

I had to do this at work once

Reply on news.ycombinator.com