Paul -let us know if this Hugo hex dumper works for you:

Thanks bro! Sent! I will try to try it out next week! Let me know if the payment did not reach you.

Ice Cream Jonsey wrote: Fri Apr 26, 2024 7:12 am Can you remind me again of the best address to use to PayPal you?

paul@paul-robinson.us

Thank you.

I'll let you know when the next update is released.

Can you remind me again of the best address to use to PayPal you?

I am calling this my "warts and all" edition. If you look at the code you'll find false starts, and tries that didn't work, pushed down in the code to try something else, lather, rinse, repeat.

Ice Cream Jonsey wrote: Thu Apr 25, 2024 7:39 pm

So I wrote a program, using QB64 Phoenix Edition, to load a Hugo Executable and display this information.

When you get a chance - no rush and no pressure - I shall gladly send you $20 if you are able to put it on Github.

Ice Cream Jonsey wrote: Thu Apr 25, 2024 7:39 pmOr mail me the source and I'll do it and pay you. This sounds cool!

Done. I even cleaned up the program a little (it uses the open dialog instead of asking you to type in a file name).

https://github.com/electric-socket/HugoDecompiler

That's why I put it up now, rather than wait to fix it and turd polish it, etc. I can always use the money.

As noted in the readme, it requires QB64 Phoenix Edition to recompile it (if you want to try making changes, or play around with what it does.)

The version is 0.1.16, and SHA-256 checksums for all related files are listed.

So I wrote a program, using QB64 Phoenix Edition, to load a Hugo Executable and display this information.

When you get a chance - no rush and no pressure - I shall gladly send you $20 if you are able to put it on Github. Or mail me the source and I'll do it and pay you. This sounds cool!

I even thought maybe I was supposed to add the magic constant 0x14, only that caused overflow, so that's not it. I mean, I looked at the source of the Hugo Compiler. I looked at the source of the run-time system, can't figure it out. And when I tried to read Nico's code, and I can't even begin to follow how the Hugo opcodes get executed, let alone how to decode the strings.

I'll keep looking around.

I have the feeling the source code of all of these - Hugo Compiler, Hugo Execution (Run Time System or RTS) are either trying to hide what they are doing, or, they're trying for first prize in the obfuscated C code contest.

The book explains how the start of the executable carries certain information about the tables. So I wrote a program, using QB64 Phoenix Edition, to load a Hugo Executable and display this information. When I saw that I had correctly read the table to get the number of entries in the dictionary, and I match what the compiler said when I compiled it, I felt pretty good.

Until I got to the dictionary. I'm doing something wrong, and I'm not sure what. Okay, the dictionary is located at bytes 0x15 and 0x16 (21 and 22) in the file. The number is retrieved by taking the second byte, multiplying it by 256, and adding the first byte. Hugo uses a "segmented" address, and to get around handling files as big as 1 meg, or in any case, bigger than 32,767 or 65,536 bytes, the number is indexed to the next 16-byte segment by dividing by 16. So the prior number has to be multiplied by 16,

Okay, so far, so good. Loading the entire file into a byte array, variable Dictionary = Bytes (0x16*256)+Bytes(0x15) * 16. Going to tha address, Byte(Dictionary+1)*256 + Byte(Dictionary), I get the dictionary size. Immediately following this is a null string, a byte of 0. Now, there are 2-byte addresses for each of the dictionary entries. So I look at the first one. I tried using that as a specific byte in the file. I processed the string by using the magic constant of -0x14 applied to each byte. I know the first byte is length, but in any case, it's garbage both raw and decrypted. So I tried as a byte in the file, offset by the start of the dictionary table. Same thing, no soap. So I thought maybe the dictionary table addresses are indexed, but multiplying the address by 16 exceeds the size of the file.

So I'm not sure what I'm doing wrong. But I'll keep trying.