I want to change many of parts of a unicode string in ollydbg.
Is there any plugin or trick that can be used to replace bulky of unicode string at once?
For example, if 100 unicode 'test' words exist in the string reference then I want to change all 'test' to 'test2'
00459FD0 5C 00 55 00 6C 00 74 00 72 00 61 00 4D 00 61 00 \test\.J.
00459FF0 5C 00 4D 00 69 00 63 00 72 00 6F 00 73 00 6F 00 \Microso
0045A000 66 00 74 00 20 00 53 00 68 00 61 00 72 00 65 00 ft Share
0045A010 64 00 5C 00 54 00 72 00 69 00 45 00 64 00 69 00 d\TriEdi
0045A020 74 00 5C 00 44 00 68 00 74 00 6D 00 6C 00 45 00 t\DhtmlE
0045A030 64 00 2E 00 6F 00 63 00 78 00 00 00 0C 00 00 00 d.ocx...
0045A040 3F 00 6C 00 61 00 6E 00 67 00 3D 00 00 00 00 00 ?lang=..
0045A050 22 00 00 00 5C 00 55 00 6C 00 74 00 72 00 61 00 ".\test.︁ൃᇏ
0045A080 89 40 00 A0 C9 05 42 28 10 9D 0B 2A 87 4B D3 11 䂉ꀀ⡂鴐⨋䮇ᇓ
Until now I was trying to find a trick or plugin but I have been unsuccessful.
How can I accomplish this task?
Thank you.
I struggled few hours to figure this, so here is the way I replaced all my strings with Olly (it was ascii, but no difference).
First we can't do hardcoding, except if the string are at the same size. So go find a free space in your executable, and paste it your string (you have to put a zero byte right after).
Keep your string offset in mind, and in your CPU view, search for all referenced text strings.
Then select the string you want to replace, press enter then space to open the assemble window, then replace your offset with the one of your new string.
Cheerz! :)
Related
how to you know what code format is..?
Is this below code is Binary or bit? and how to convert in any other format or number decimal format
01 00 00 00 04 00 00 00 00 00 00 00 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F
Binary means that you have two possible states (base 2). 1 and 0.
Something that bears that atomic information is usually referred to as a bit.
What you see there are hexadecimal numbers. (base 16)
This notation is often used to display binary data in a more compact form.
The decimal number 255 can be written as 11111111 (binary) or FF (hex)
So each pair is one byte. What they mean depends on where you got those numbers from.
I have to find out how to reproduce the CRC32 algorithm used on a proprietary database file, the file consists of many "chunks" of 128 bytes, each being a record. I know that for each record, bytes 1-4 are the CRC32 Checksum, and the next 35 bytes don't seem to matter, as I can change them easily without the application telling me the CRC Check has failed. Therefore, I am looking to find out what polynomial and other parameters are being used to calculate the latter. Below is an example.
Text version:
00 27 AE 3B 9F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 41 08 41 41 41 41 41 41 41 41
19 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42
42 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00
If we take just the bytes we can't change, breaking the record, we get this:
41 08 41 41 41 41 41 41 41 41 19 42 42 42 42 42 42 42 42 42 42 42 42 42 42
42 42 42 42 42 42 42 42 42 42 42 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00
the CRC32 for the above is 27 AE 3B 9F
Real Record Example 1.1, differing only by one byte from the above (CRC is BC D4 84 FB):
41 08 41 41 41 41 41 41 41 41 19 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42
42 42 42 42 42 42 42 42 42 43 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00
Real Record Example 2 (Output CRC is 3B 6A D1 AF):
41 07 41 41 41 41 41 41 41 00 19 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42
42 42 42 42 42 42 42 42 42 42 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00
Real Record Example 3 (Output CRC is 0B 54 CC 09):
41 01 31 00 00 00 00 00 00 00 03 41 73 61 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00
Real Record Example 4 (Output CRC is 12 91 EA 8E):
41 B4 A8 D0 02 46 00 B4 A8 00 03 52 4D 31 03 53 54 50 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 25 00 00 00 00 00 00 00
00 00 A3 05 00 00 00 64 00 64 00 64 00 64 00 64 00 64 00 64 00 64 00 64 00 64
00 64 00 64 00 64 00 64 00 64 00 64 00 64 00 64 00 64 00 64 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Real Record Example 5 (Output CRC is 8A 68 00 3B):
41 B4 A8 D0 02 46 00 B4 A8 01 03 52 4D 31 03 53 54 50 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 25 00 00 00 00 00 00 00
00 00 A3 05 00 00 00 64 00 64 00 64 00 64 00 64 00 64 00 64 00 64 00 64 00 64
00 64 00 64 00 64 00 64 00 64 00 64 00 64 00 64 00 64 00 64 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
The two last records differ on only one byte. By using the approach #rcgldr specified, I was able to get a final Xor value of 0x9902539d and I could successfully change data without the application complaining. I ran some code to find these final xor values for every entitity/file on the application and was successful on all of them, but being able to find a single crc parameter set would be a great addition.
EDIT: Added two more example records
EDIT 2: Added one more example that only differs from one byte comparing to the first one
EDIT 3: Added two more examples, with a different size, as their from another type of record within the application. Also deleted part of the question as it became irrelevant
xor'ing 1.0 and 1.1 results in:
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00
xor'ing the two crcs results in
9b 7a bf 64
Assuming "little endian" for the stored crc, the calculated crc is
0x64bf7a9b
By xor'ing two records, the initial value and final xor value are canceled out due to the xor, which allows the crc polynomial to be determined based on the data alone, assuming that initial value = 0 and that final xor value = 0. Taking advantage of this, I tried some common crc polynomials and determined that the crc polynomial is
0x104C11DB7 or ignoring the msb: 0x04C11DB7
Using this web site that you linked to in your comment:
http://www.sunshine2k.de/coding/javascript/crc/crc_js.html
The parameters are:
crc32
custom
input: not reflected
result: not reflected
polynomial: 0x04C11DB7
initial value: 0x0
final xor value: 0x0
If the data is always the same size, then either the initial value or the final xor value or a combination of both can be used to adjust the crc so that it matches the actual crc's shown in the examples, but it is simplest to use the final xor to match the examples, since it just requires calculating a crc with one of the examples, assuming initial value = 0 and final xor value = 0, then xor'ing the calculated crc with the actual crc from the example crc to calculate a final xor value for a specific length of data.
So for the data size in the first examples, a final xor value of 0x189B52BC will produce crc's that match the examples. These are the parameters for the crc calculator.
crc32
custom
input: not reflected
result: not reflected
polynomial: 0x04C11DB7
initial value: 0x0
final xor value: 0x189B52BC
These parameters match all of the first examples you posted. Again, note that the crc's are stored "little endian", most significant byte first.
If the data size is variable, then an initial value is needed (and it's possible both an initial value and final xor value are used). Once the polynomial is known, it's possible to do a "reverse" CRC to find the initial value, or a brute force search can be used. I did a brute force search for an initial value using a fast crc calculator (since I don't have a "reverse" CRC program yet), and it appears that it will work for any data size, at least based on the new examples you added. These parameters work with all of the examples above, include the new ones you added:
crc32
custom
input: not reflected
result: not reflected
polynomial: 0x04C11DB7
initial value: 0xc704dd7b
final xor value: 0x0
The initial value of 0xc704dd7b is the crc that is generated with a data pattern of {ff ff ff ff}, with initial value = 0 and final xor value = 0. It's the same as prefixing the data with {ff ff ff ff}.
My program was able to craft and send raw transactions to geth v1.3.3 before, but after I upgrade to geth v1.4.0, calling sendRawTransaction over RPC always returns invalid sender error.
Is transaction serialization (i.e. RLP) changed somehow from v1.3.3 to v1.4.0? Here is a dump of by raw transaction that triggers an invalid user error:
0x0000: F8 CA 80 85 0B A4 3B 74 00 83 01 5F 90 94 08 BE ......;t..._....
0x0010: 24 CD 8D CF 73 F8 FA 5D B4 2B 85 5B 43 70 BD 5C $...s..].+.[Cp.\
0x0020: 44 8B 80 B8 64 B0 70 B9 BA 00 00 00 00 00 00 00 D...d.p.........
0x0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x0040: 00 00 00 00 00 00 00 00 01 87 44 2E B8 96 6A 07 ..........D...j.
0x0050: 0C 31 C1 E8 AE A3 60 F5 35 32 47 81 13 34 31 D4 .1....`.52G..41.
0x0060: 4B FA 0A 0B 1B 9F 13 C6 F5 00 00 00 00 00 00 00 K...............
0x0070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x0080: 00 00 00 00 00 00 00 00 00 1B A0 DE A4 6B 8C E8 .............k..
0x0090: 72 5A 31 49 92 EC 6B 6F C6 89 8C BB D7 A4 B9 8A rZ1I..ko........
0x00A0: 10 D2 F7 9E CE 6B D5 0F C5 19 E9 A0 8F 74 57 C2 .....k.......tW.
0x00B0: 1C DA CB 7D 7A 2B 46 58 98 53 31 C3 4B CF 50 1F ...}z+FX.S1.K.P.
0x00C0: 17 CE 16 80 95 30 38 9B 98 3C 5B B8 .....08..<[.
A more machine readable version of my transaction is:
F8CA80850BA43B740083015F909408BE24CD8DCF73F8FA5DB42B855B4370BD5C448B80B864B070B9BA000000000000000000000000000000000000000000000000000000000000000187442EB8966A070C31C1E8AEA360F535324781133431D44BFA0A0B1B9F13C6F500000000000000000000000000000000000000000000000000000000000000001BA0DEA46B8CE8725A314992EC6B6FC6898CBBD7A4B98A10D2F79ECE6BD50FC519E9A08F7457C21CDACB7D7A2B4658985331C34BCF501F17CE16809530389B983C5BB8
Log from geth gives
I0504 20:22:27.392581 9768 types.go:106] Generated response: *shared.ErrorResponse &{%!s(float64=1) 2.0 %!s(*shared.ErrorObject=&{-32603 Invalid sender})}
I0504 20:22:27.392886 9768 http.go:157] Sending payload: {
"id": 1,
"jsonrpc": "2.0",
"error": {
"code": -32603,
"message": "Invalid sender"
}
}
I believe the JSON RPC stuff changed in geth v1.4.0. I can't tell why this is happening without seeing the full sendRawTransaction you are calling but check out the docs: https://github.com/ethereum/wiki/wiki/JSON-RPC#eth_sendtransaction
Also, this should be migrated to https://ethereum.stackexchange.com/
I have a binary file that I want to open as (or to convert to) jpeg image.
The file is only supposed by me to be a jpeg within a binary format, therefore I include a part of it so that You can tell me if I'm wrong ('cause unfortunately I never saw one of those before):
0000000000 0E 03 13 01 00 10 00 00 EC B0 00 1E 00 01 00 00 [................]
0000000016 00 CA 00 00 00 5C 00 0F 00 01 00 00 01 26 00 00 [.....\.......&..]
0000000032 00 00 01 2F 00 01 00 00 01 26 00 00 83 B2 00 6A [.../.....&.....j]
0000000048 00 01 00 00 84 D8 00 00 00 04 01 2C 00 01 00 00 [...........,....]
0000000064 84 DC 00 00 00 14 01 32 00 01 00 00 84 F0 00 00 [.......2........]
0000000080 00 08 07 AD 00 02 00 00 84 F8 00 00 00 19 00 0F [................]
0000000096 00 02 00 00 85 11 00 00 00 00 01 2F 00 02 00 00 [.........../....]
0000000112 85 11 00 00 0D D3 01 2C 00 02 00 00 92 E4 00 00 [.......,........]
0000000128 00 14 01 32 00 02 00 00 92 F8 00 00 00 08 07 AD [...2............]
0000000144 00 03 00 00 93 00 00 00 00 19 00 0F 00 03 00 00 [................]
0000000160 93 19 00 00 00 00 01 2F 00 03 00 00 93 19 00 00 [......./........]
0000000176 59 7B 01 2C 00 03 00 00 EC 94 00 00 00 14 01 32 [Y{.,...........2]
0000000192 00 03 00 00 EC A8 00 00 00 08 00 00 00 04 00 00 [................]
0000000208 00 02 00 00 00 00 4E 43 53 41 20 48 44 46 20 56 [......NCSA HDF V]
0000000224 65 72 73 69 6F 6E 20 34 2E 32 20 52 65 6C 65 61 [ersion 4.2 Relea]
0000000240 73 65 20 30 2C 20 44 65 63 65 6D 62 65 72 20 32 [se 0, December 2]
0000000256 2C 20 32 30 30 33 00 00 00 00 00 00 00 00 00 00 [, 2003..........]
0000000272 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [................]
0000000288 00 00 00 00 00 00 FF D8 FF E0 00 10 4A 46 49 46 [............JFIF]
0000000304 00 01 01 00 00 01 00 01 00 00 FF DB 00 43 00 10 [.............C..]
0000000320 0B 0C 0E 0C 0A 10 0E 0D 0E 12 11 10 13 18 28 1A [..............(.]
0000000336 18 16 16 18 31 23 25 1D 28 3A 33 3D 3C 39 33 38 [....1#%.(:3=<938]
0000000352 37 40 48 5C 4E 40 44 57 45 37 38 50 6D 51 57 5F [7#H\N#DWE78PmQW_]
0000000368 62 67 68 67 3E 4D 71 79 70 64 78 5C 65 67 63 FF [bghg>Mqypdx\egc.]
0000000384 DB 00 43 01 11 12 12 18 15 18 2F 1A 1A 2F 63 42 [..C......./../cB]
0000000400 38 42 63 63 63 63 63 63 63 63 63 63 63 63 63 63 [8Bcccccccccccccc]
0000000416 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 [cccccccccccccccc]
0000000432 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 [cccccccccccccccc]
0000000448 63 63 63 63 FF C0 00 11 08 01 A0 01 C0 03 01 22 [cccc..........."]
0000000464 00 02 11 01 03 11 01 FF C4 00 1F 00 00 01 05 01 [................]
0000000480 01 01 01 01 01 00 00 00 00 00 00 00 00 01 02 03 [................]
0000000496 04 05 06 07 08 09 0A 0B FF C4 00 B5 10 00 02 01 [................]
How can I convert it to jpeg to view its content (that is supposed to be an image)?
Is this conversion necessary or would You reccomend a software that can open it as I like?
I hope someone could help me, thanks in advance.
ANSWER
(As I can't answer my own question right now, I'm doing it here...)
At the end I came up with a solution thanks to the input information of unwind.
I downloaded HEX editor (http://www.hhdsoftware.com/free-hex-editor) to edit my binary file. Then I searched for the string where the 0xff 0xd8 was (in may case in line 0000000288). This is supposed to be the beginning of a JPEG file. Then I deleted everything that came before of that (also the six pair of zeros within the same line). Then I saved m edits and tried again to open it with an image processing program (in my case, I'm usin ENVI), and....IT WORKS! Now the binary file is red as an image file!
The problem now is that I have plenty of those files (302), and I need to edit all of them. Moreover, they each contain more than one jpeg, so I need to modify each one ore times. Guess I need to improve my programming knowledge...
Well, according to this page JPEG files begin with the byte pair 0xff 0xd8, so you could search forwards for that sequence, and throw away the data before it.
In your file, it happens on the line starting 0000000288.
Suppose I wanted to write a program to display "hello world", and I wanted to write it in binary. How could I do this?
I have some idea that:
I'd need to determine what chip architecture I'm using
I'd need to find out what kind of binary it uses
I'd need some reference for that flavor of binary
I might need to change a setting in my editor (Vim)
Can anybody walk me through this?
It's bit more complicated, because actually printing "Hello, world!" to stdout is a system call, thus you need to know the correct kernel syscall number. Which of course varies by operating system. Also you need to know the binary format, which also tend to vary, although ELF (Executable and Linkable Format) is universal across few flavors of Unix and Linux.
See Hello, world! in assembler.
This is Linux assembler code:
section .text
global _start ;must be declared for linker (ld)
_start: ;tell linker entry point
mov edx,len ;message length
mov ecx,msg ;message to write
mov ebx,1 ;file descriptor (stdout)
mov eax,4 ;system call number (sys_write)
int 0x80 ;call kernel
mov eax,1 ;system call number (sys_exit)
int 0x80 ;call kernel
section .data
msg db 'Hello, world!',0xa ;our dear string
len equ $ - msg ;length of our dear string
... which on 32-bit Linux, compilation results in binary of 360 bytes, although it's mostly zeros:
00000000 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 |.ELF............|
00000010 02 00 03 00 01 00 00 00 80 80 04 08 34 00 00 00 |............4...|
00000020 c8 00 00 00 00 00 00 00 34 00 20 00 02 00 28 00 |........4. ...(.|
00000030 04 00 03 00 01 00 00 00 00 00 00 00 00 80 04 08 |................|
00000040 00 80 04 08 9d 00 00 00 9d 00 00 00 05 00 00 00 |................|
00000050 00 10 00 00 01 00 00 00 a0 00 00 00 a0 90 04 08 |................|
00000060 a0 90 04 08 0e 00 00 00 0e 00 00 00 06 00 00 00 |................|
00000070 00 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000080 ba 0e 00 00 00 b9 a0 90 04 08 bb 01 00 00 00 b8 |................|
00000090 04 00 00 00 cd 80 b8 01 00 00 00 cd 80 00 00 00 |................|
000000a0 48 65 6c 6c 6f 2c 20 77 6f 72 6c 64 21 0a 00 2e |Hello, world!...|
000000b0 73 68 73 74 72 74 61 62 00 2e 74 65 78 74 00 2e |shstrtab..text..|
000000c0 64 61 74 61 00 00 00 00 00 00 00 00 00 00 00 00 |data............|
000000d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
000000f0 0b 00 00 00 01 00 00 00 06 00 00 00 80 80 04 08 |................|
00000100 80 00 00 00 1d 00 00 00 00 00 00 00 00 00 00 00 |................|
00000110 10 00 00 00 00 00 00 00 11 00 00 00 01 00 00 00 |................|
00000120 03 00 00 00 a0 90 04 08 a0 00 00 00 0e 00 00 00 |................|
00000130 00 00 00 00 00 00 00 00 04 00 00 00 00 00 00 00 |................|
00000140 01 00 00 00 03 00 00 00 00 00 00 00 00 00 00 00 |................|
00000150 ae 00 00 00 17 00 00 00 00 00 00 00 00 00 00 00 |................|
00000160 01 00 00 00 00 00 00 00 |........|
Since you want to "compile by hand", this basically means translating assembler mnemonics above to their opcodes, and then wrapping the result in correct binary format (ELF in the example above)
UPDATE: As this answer shows by #adam-rosenfield, the ELF binary for "Hello, world!" can be handcrafted down to 116 bytes. Original answer is now deleted, but still visible to moderators, so here's a copy:
Here's a 32-byte version using Linux system calls:
.globl _start
_start:
movb $4, %al
xor %ebx, %ebx
inc %ebx
movl $hello, %ecx
xor %edx, %edx
movb $11, %dl
int $0x80 ;;; sys_write(1, $hello, 11)
xor %eax, %eax
inc %eax
int $0x80 ;;; sys_exit(something) hello:
.ascii "Hello world"
When compiled into a minimal ELF file, the full executable is 116
bytes:
00000000 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 |.ELF............|
00000010 02 00 03 00 01 00 00 00 54 80 04 08 34 00 00 00 |........T...4...|
00000020 00 00 00 00 00 00 00 00 34 00 20 00 01 00 00 00 |........4. .....|
00000030 00 00 00 00 01 00 00 00 00 00 00 00 00 80 04 08 |................|
00000040 00 80 04 08 74 00 00 00 74 00 00 00 05 00 00 00 |....t...t.......|
00000050 00 10 00 00 b0 04 31 db 43 b9 69 80 04 08 31 d2 |......1.C.i...1.|
00000060 b2 0b cd 80 31 c0 40 cd 80 48 65 6c 6c 6f 20 77 |....1.#..Hello w|
00000070 6f 72 6c 64 |orld|
00000074
Normally, you'd use a hex editor for this. Figure out the assembly code, hand-assemble it, use the hex editor to enter the binary values, then save them to a file. Once you have your file, drop into your machine monitor and load the file at an available address, then jump to the first instruction. This was pretty common practice on single-board computers and is still done on microcontrollers today, but it's not something you're going to do on a contemporary OS. If you really want to do this, I'd recommend running a low-level emulator (SIMH will work) or working with a microcontroller (you can pick up a TI MSP430 development kit for less than five bucks).