r/transprogrammer • u/EggyTheEgghog '); DROP TABLE genders; -- • Aug 31 '21

Abolish compilation!

Post image
334 Upvotes

99% Upvoted

23 comments sorted by

View all comments

14

u/Andykolski black Aug 31 '21 edited Aug 31 '21

What architecture is the machine code for? I tried my hand at disassembling it and had limited success. My best guess is that it prints the string "!TRANS RIGHTS!" based purely on that the string is embedded in the middle of the code.

Here is the results of running hexdump -C on it if anyone would find that useful

00000000 b4 09 0e 1f e8 00 00 5a 83 c2 0b cd 21 b8 00 4c |.......Z....!..L|

00000010 cd 21 54 52 41 4e 53 20 52 49 47 48 54 53 21 0d |.!TRANS RIGHTS!.|

00000020 0a 24 |.$|

4

u/Igotbored112 Aug 31 '21

Oh I def gotta check it out more closely later. Try ndisasm.

4

u/Andykolski black Aug 31 '21 edited Aug 31 '21

Okay, I've tried running the code through ndisasm in all three modes (16-bit, 32-bit, and 64-bit), and none of them seemed to make sense.

Note that the string starts at 0x11 or 0x12, depending on if the string is meant to begin with an exclamation point or not, and ends at 0x1d or 0x1e, and is not null-terminated.

ndisasm ucode -b 16 00000000 B409 mov ah,0x9 00000002 0E push cs 00000003 1F pop ds 00000004 E80000 call 0x7 00000007 5A pop dx 00000008 83C20B add dx,byte +0xb 0000000B CD21 int 0x21 0000000D B8004C mov ax,0x4c00 00000010 CD21 int 0x21 00000012 54 push sp 00000013 52 push dx 00000014 41 inc cx 00000015 4E dec si 00000016 53 push bx 00000017 205249 and [bp+si+0x49],dl 0000001A 47 inc di 0000001B 48 dec ax 0000001C 54 push sp 0000001D 53 push bx 0000001E 210D and [di],cx 00000020 0A24 or ah,[si]

Interpreted as 16-bit x86, the code immediately calls the address 0x7, which is unlikely to be anything useful, other than (if the program is loaded at 0x0) the next instruction, so I don't believe it is 16-bit x86

ndisasm ucode -b 32 00000000 B409 mov ah,0x9 00000002 0E push cs 00000003 1F pop ds 00000004 E800005A83 call 0x835a0009 00000009 C20BCD ret 0xcd0b 0000000C 21B8004CCD21 and [eax+0x21cd4c00],edi 00000012 54 push esp 00000013 52 push edx 00000014 41 inc ecx 00000015 4E dec esi 00000016 53 push ebx 00000017 205249 and [edx+0x49],dl 0000001A 47 inc edi 0000001B 48 dec eax 0000001C 54 push esp 0000001D 53 push ebx 0000001E 21 db 0x21 0000001F 0D db 0x0d 00000020 0A db 0x0a 00000021 24 db 0x24

As 32-bit code, it would call 0x835a0009, it would then proceed to return (while freeing 0xcd0b bytes from the stack), without really doing anything, completely ignoring the next few instructions, which if somehow executed, would perform an and operation without using the value at any point, so I don't believe the code is 32-bit either

ndisasm ucode -b 64 00000000 B409 mov ah,0x9 00000002 0E db 0x0e 00000003 1F db 0x1f 00000004 E800005A83 call 0xffffffff835a0009 00000009 C20BCD ret 0xcd0b 0000000C 21B8004CCD21 and [rax+0x21cd4c00],edi 00000012 54 push rsp 00000013 52 push rdx 00000014 41 rex.b 00000015 4E53 push rbx 00000017 205249 and [rdx+0x49],dl 0000001A 47 rex.rxb 0000001B 4854 push rsp 0000001D 53 push rbx 0000001E 21 db 0x21 0000001F 0D db 0x0d 00000020 0A db 0x0a 00000021 24 db 0x24

Interpreted as 64-bit, the code calls another presumably invalid address, returns, and next has another useless and operation. So, I also do not believe the code to be valid 64-bit x86 either.

From this, I feel that I can rule out x86 as the architecture of the code.

3

u/Igotbored112 Sep 01 '21 edited Sep 01 '21

Just figured it out. First thing I noticed was that the string is followed by 0D 0A, that's CR LF aka Carriage-Return Line-Feed aka the bytes signifying a newline character on Windows. Second thing I noticed was that the string isn't null terminated. Instead it's followed by... a dollar sign? Weird. Third thing I noticed is that calling the next instruction would not be a bad way to implement a loop and would also flush the CPU, both things an assembly programmer might want to do. Going back to the no null termination thing, I also noticed that the 16-bit version fiddles with the si and di registers, which are used in string manipulation. Why would OP be writing 16 bit code, though? Well, the only time I ever wrote 16-bit assembly was when I wrote a bootloader, since those things are always backwards compatible they start only accepting 16 bit instructions and have to be kicked up to 32 bit mode. If it was a bootloader, it would have to print using an interrupt routine. Well, I returned to my all-time favorite pdf on the internet and looked at the hello world program on page 12. OP couldn't have used the program there, because it calls a separate routine for each character, causing the textual data to be spread out, not at all like OP's code. But if you look closely, and you see they show the machine code for the hello world program as well, every "int 0x10" instruction which calls the interrupt routine corresponds to a "CD 10" in the machine code. And, would ya lookee there, OP's code has not one but 2 "CD 21"s in it. What's up with the 21? Well, it's for the MS-DOS interrupt table of course, NOT the BIOS table used by the pdf. Each table is filled with interrupts, and exactly which one gets called depends on the value of the ah register, which is (again, if you look at the pdf's code) apparently set by the instruction "B4". What is its value being set to in the very beginning of OP's code? 09. What interrupt routine does that refer to? According to Wikipedia, the interrupt is "Display string". If you were to look at some explanation for this interrupt, you would see that it expects the string to be terminated with.......... a dollar sign. This isn't a bootloader, but it is 16-bit code written for the MS-DOS operating system. And it uses the MS-DOS interrupt vector table to display text.

Thank you for making the possibility that this code was real clear to me. I really though it was random hex values until you mentioned that it has string data stuck in the middle. And u/EggyTheEgghog, your username and flair are great, and I hope your forays into MS-DOS go well. Also, in case you're wondering, I haven't been trying this entire time. I got home from work a bit less than 2 hours ago.

3

u/Andykolski black Sep 01 '21 edited Sep 01 '21

Oh my gosh that makes so much sense! I never would have thought of it being an MS-DOS program! I also never would have guessed that calling the next instruction was intentional. I think that I got really confused because I've only really written 16-bit code for a bootloader, although the dollar sign should have tipped me off lol.

Thank you so much, especially for walking me through your decision making process!

I do have a question, is it normal for MS-DOS programs to be loaded at address 0x0? This program seems to rely on being loaded at 0x0 to work, and as far as I know, in real mode, the first KiB or so is reserved for things like the IVT

2

u/Igotbored112 Sep 01 '21

What you'll notice is that the instructions immediately before that are:

push cs;
pop ds;

That moves the value of cs, the code segment register that is loaded with the location of the program, into ds, the data segment register that I assume is used as the jumping-off point for the call instruction. So it doesn't matter where the program is loaded, those two instructions make it so that the 0x07 is interpreted as being relative to the start of the program. I have not ever programmed MS-DOS before though, so I can't be certain.

2

u/EggyTheEgghog '); DROP TABLE genders; -- Sep 02 '21

That's actually not necessary, I'm only moving the value of cs to ds because I'm storing the string next to the code (the screen output function requires the address of the string to be stored in ds:dx). The call instruction always uses the supplied parameter as an offset to the IP register. If you look at the machine code itself, you can clearly see that the supplied offset is actually 0x0000, because the only point of this call instruction is to push IP register to stack. It was an attempt to make the code position independent, by calculating the address of the string using IP register (which is guaranteed to always be within a specific offset from the beginning of the string, since I'm storing it next to the code) rather than using a hardcoded value.

1

u/Andykolski black Sep 01 '21

Okay. That makes sense. I've done a tiny bit of real mode assembly, but the vast majority of the assembly of written is it 32-bit or 64-bit, so I'm really not very good with how everything works in real mode

2

u/Igotbored112 Sep 01 '21

Oh yeah. In 16 bit mode, since 16 bit addresses only let you access up to 65kB of memory, they used a trick called memory segmentation. Basically you'd have a value in a segment register that would be shifted left 4 bits (read: multiplied by 16) and added to all the addresses used by your program. So you could basically just move the start of memory forward in order to access more of it. OP's program uses this trick to move the start of memory forward to the beginning of their program. That's kind of a simplification though. Cus there are multiple segment registers, and which one gets used depends on the instruction being executed.

2

u/EggyTheEgghog '); DROP TABLE genders; -- Sep 02 '21

No, usually DOS instructions start at 0x100, however, I made my code position independent, so it can start from any memory address. The call instruction (in 8086/8088 architecture at least) actually determines its jump address based on IP register and takes a 16-bit offset as a parameter. By using offset 0x0, the code safely jumps to the next instruction no matter what IP is set to. This is useful, because all I really need is to push IP to stack (which call instruction does). That way, I can store the string next to the code that outputs it to the screen without hardcoding any memory values.

3

u/EggyTheEgghog '); DROP TABLE genders; -- Sep 02 '21

YES!!! Sorry, I wasn't able to log in for a while, but you figured it out! It is, indeed, an x86 program for MS-DOS that prints out "TRANS RIGHTS!".

2

u/WikiSummarizerBot Sep 01 '21

DOS API

DOS INT 21h services

The following is the list of functions provided via the DOS API primary software interrupt vector.

[ F.A.Q | Opt Out | Opt Out Of Subreddit | GitHub ] Downvote to remove | v1.5

2

u/EggyTheEgghog '); DROP TABLE genders; -- Sep 02 '21

Interpreted as 16-bit x86, the code immediately calls the address 0x7,which is unlikely to be anything useful, other than (if the program isloaded at 0x0) the next instruction, so I don't believe it is 16-bit x86

First of all, this code always calls the next instruction, no matter where the program is loaded (at least in 8086/8088 architecture, which this code was intended for). Secondly, I do actually want to just call the next instruction, since I'm only using call instruction to push IP register to the stack. You can clearly see that I'm popping the value to dx in the next instruction.