Newsletter # 13 - Let's write some assembly code in macOS for Intel x86_64 Dec 13 2019
Hello,
I found an interesting thread on Twitter explaining that when the Apple II early documentation was being written, they had to tell people to differentiate between how they type using typewriters and how they'll type in the Apple II computer.
I don't remember the typewriters I used missing the 0(zero) or 1(one) key, but I see how it was possible to use O(oh) and l(el) to replace 0 and 1 respectively. Or if you made a mistake typing -(dash) when you wanted to type = you could move your carriage back and put a _(underscore) under it :). I thought you might find it interesting.
Anyways, the holiday season is here and also means that the SANS - KringleCon is back for its second edition. KringleCon is a security conference that includes a holiday hack challenge. You can find the link here. The good thing is that you can play their holiday hack challenge from the comfort of your browser :). It has some fun mini-games and stuff. Have a look. You might find something you like.
I've been exploring some Reverse Engineering topics, and that, as you might expect, lead me to dust-off my assembly knowledge. It's been a long time since I've done any work using assembly, so it was surprising how hard it is to find a simple example on how to write an assembly program in macOS and which tools I would need. So this week's post is exactly that, a short post on how to write an assembly program and execute it in macOS. If you are interested here is the link:
https://rderik.com/blog/let-s-write-some-assembly-code-in-macos-for-intel-x86-64/
It includes enough information to get you started. Then you can go on and follow any other more extensive tutorial that uses assembly code. I think it is useful as a refresher and as a starting point, I hope you find it helpful too.
Ok, that's it for this week. Have a fun weekend.
Derik
Tip of the week
Have you ever needed a file with data? No matter what data, but a file to test any of your programs. Instead of roaming through your filesystem searching for a file that fits your need just create one using dd.
1
$ dd if=/dev/zero of=NAME_OF_YOUR_FILE bs=1m count=1024
The bs argument indicates the block size (1m here, but it could be 1g). And the count just how many blocks, in the example we create a file of 1GB with 1024 blocks of 1M of size. Having a smaller block size is less taxing for memory than creating a 1Gb by bs=1g count=1, but you can experiment.
The previous command would create a file full of zeros. What if you wanted it to contain random data? Well, use /dev/urandom
1
$ dd if=/dev/urandom of=NAME_OF_YOUR_FILE bs=1m count=1024
For example:
(Take into account that dd writes in batches of 512bytes, so even if you specify something smaller it'll round to the nearest 512bytes).
1
2
3
4
$ dd if=/dev/zero of=hello bs=1b count=1
1+0 records in
1+0 records out
512 bytes transferred in 0.000095 secs (5382165 bytes/sec)
As you can see, 512 bytes were written. If you want to see the content on the file in hex, use xxd:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
$ xxd hello
00000000: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000040: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000050: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000060: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000070: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000080: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000090: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000100: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000110: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000120: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000130: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000140: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000150: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000160: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000170: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000180: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000190: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000001a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000001b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000001c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000001d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000001e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000001f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
Now you can try with /dev/urandom.
1
2
3
4
$ dd if=/dev/urandom of=hello bs=1b count=1
1+0 records in
1+0 records out
512 bytes transferred in 0.000042 secs (12201612 bytes/sec)
And you can check on your computer what you get with xxd. Quite interesting, right?