0

I was wondering if there was a way to reliably cipher, encrypt, or hide a number in m68k (or assembly in general).

I.e: 01=09, 32=1F

Or something inconsistent like that.

Thanks!

Luis Miguel
  • 5,057
  • 8
  • 42
  • 75
Andrew Edwards
  • 3
  • 3

2 Answers2

1

Short answer: no.

Longer answer: There is not a good way to handle this in most CPUs. The CPUs that do this have a hardware encryption block for the IO so the data when referenced from the outside of the box is encrypted. You can actually do certain mathematics on encrypted data on certain types of ciphers. For instance, you can add two encrypted values in IDEA and get an encrypted output that is that addition, but that's not very useful.

The closest thing that I can think of would be to set some offset value into several of the 68k registers and then make a simple Fiestel Network around that. This would allow you to operate on the data. It would just be some ROR and XOR masks, but it would make it so you could get data in and out, but you'd need to waste cycles so you could de-obfuscate the data

If you have a soft core on a FPGA, I've seen encryption at the register level with isolated keys using PRESENT. Dartmouth's BEAR OS integrates with hardware to give you isolation at the process level. That might be a good place to start if you need some leads. Good luck.

b degnan
  • 672
  • 1
  • 14
  • 31
1

Only way I can think without wasting any extra cycles, is abusing the fact that 68k address bus is only 24-bits (at least on some earliest models). You can indent random 8-bit integer after each longword address, e.g.

dc.l ($30<<24)|$FF1234.l
jsr ($EA<<24)|DisplayText
lea ($1F<<24)|MainPalette,a2
clr.b ($1F<<24)|$FF890D.l

This will not affect 68k processor at the slightest as the high 8 bits are ignored, but anyone trying to use IDA Pro for instance will go insane, as IDA Pro uses full 32-bits for addressing! This means it now can not find any referenced data, subroutine, or RAM address, as long as the high 8 bits aren't 0 or 0xFF (for ROM and RAM respectively). Of course anyone clever enough this is not much of a problem but it would require manual work a lot more.

Other forms of encryption you may try, is using Turing complete instruction sets, to reduce the instructions used, and have the program flow be harder to understand. However, it is likely to use more CPU time and ROM space, which may not be ideal. Nonetheless, I've made something with move only, if you wish to see.

Green Snake
  • 76
  • 1
  • 9