@blinry tried to teach me some binary from scratch, which worked pretty well, but now I'm stuck.
-
@blinry tried to teach me some binary from scratch, which worked pretty well, but now I'm stuck. I have two versions of a program, one works, one doesn't, and I can't figure out why...
I marked the differences of the two with yellow circles.
#fedihelp #askfedi
-
As I can't add binary files to posts, you get the hex dump of the working file here :>
454c4602010103000000000000000002003e000100000082000100000000004000000000000000000000000000000000000000400038000100400000000000010000000500000078000000000000007800010000000000deadbeefc0ffee992c000000000000002c00000000000000000000000000000048454c4c20574f524c44b801000000bf01000000be78000100ba0a0000000f05b83c000000bf2a0000000f05 -
The three differences pertain to the amount of data which gets loaded into memory.
The first one (broken 0a... vs. working 82...) are the address in RAM, where the program starts. In the working version, this is 0x10082 (we're little endian, so 82-00-01 gets converted to 01-00-82), so if we would put the whole program on the address 1-00-00, then the first command of the program (directly after the faultless and accurate string we want to print) starts on position 1-00-82.
-
The last post was a little misleading; we actually don't put the whole program at 1-00-00, we only put the part after the program header table (the computer knows that this table ends in the middle of line "70" (where the green "4845 4c4c ..." starts)) at the position we indicate in the second yellow circle. As every line is 16 bytes long, the middle of line "70" is position 78.
-
The "78" in the second yellow circle is the place to which we copy the whole interesting part (the string data (the green "4845...") and after that the commands). It's convenient that this is the same number as the relative start of the interesting part in our little hex dump, because then every other position in the program also matches. This means we can rely on the loaded data also starting at 78, which we actually do in the third yellow circle:
-
There we say "fetch the data from position 78" with the bytes "be".
-
(Actually I still simplyfied a bit, because I omitted the 00 01 after the three marked bytes. As I mentioned earier, "82-00-01-00" actually means "00-01-00-82", or 10082. So the numbers aren't 82 and 78, but 10082 and 10078, (and even actuallier 0x10082 and 0x10078, but please ignore this if you don't immediatly recognize it). So we put the stuff not in position 78, but in position 10078, but the math still works out, it's just 10000 positions later.)
-
Soooo, this is how the working one works. But how does the not working one *not* work?
Let's start with the second yellow circle: Here's a 00 where we had a 78. So we put the interesting part (string data + commands) at position 00 (or more precisely 1-00-00 instead of 1-00-78) in the RAM. This means the green "4845 ..." starts at 1-00-00. The first command (the red "b801 ..." after the data) is ten positions after that, which is "0a" in hexadecimal. Oh look, it's the first yellow circle! -
And that's good, because the first yellow circle tells the computer where in RAM to look for the commands. So if we put our data at 00, we have the commands at 0a. Or, if we put it at 1-00-00, we have it at 1-00-0a, which is what actually happens.
So everything should work as before, just in RAM 78 positions earlier... But it doesn't :(
Please tell me what I missed! -
G gustavinobevilacqua@mastodon.cisti.org shared this topic on
