IRC channel logs

2020-08-20.log

back to list of logs

<OriansJ`>bauen1: you would also have to properly parse the ELF header as it would be trivial to add dummy segments with wrong values for file size.
<OriansJ`>as one could easily change e_phoff and e_shoff then you'll have to use those values to determine where to find the values you want but p_filesz and p_memsz and be zero; which makes it hard to know there the end of the file will be
<OriansJ`>EI_PAD also has enough space for a 7byte checksum if we so desire
<OriansJ`>and since we don't dynamicly link our ELF files (as they are static only) we can also steal the byte from EI_ABIVERSION
<OriansJ`>as Linux completely ignores it
<OriansJ`>so 8bytes or 256bit checksum inside of the binary itself. wonder how many rounds it would take to determine a value that matches the sha256sum of the file itself (including the checksum in those 8 bytes)
<OriansJ`>we can also use p_align to play further games (with p_vaddr equating p_offset modulus p_align)
<OriansJ`>we could possibly do a proof of concept by just embedding an md5sum in the padding; that matches the md5sum of the file itself
<xentrac>how would you do that?
<OriansJ`>good question as I have not done something like this previously but I do have a gif which displays an MD5SUM which exactly matches the MD5SUM of the file itself
<OriansJ`> https://shells.aachen.ccc.de/~spq/md5.gif
<xentrac>oh, I think I remember that
<OriansJ`> https://news.ycombinator.com/item?id=13823704
<xentrac>more detailed link: https://old.reddit.com/r/programming/comments/5y03g9/animated_gif_displaying_its_own_md5_hash/
<xentrac>you could maybe do something similar in ASCII with sequences like d7s9W^H^H^H^H^Hf for "f"
<OriansJ`>or we could do a simpler prototype; 1 bit per byte of the binary
<xentrac>like, "if you run md5sum on this file, it gives you the same result as if you run the following algorithm on this file"?
<xentrac>not sure that's an equally surprising result :)
<OriansJ`>true
<xentrac>I think if you can get the result in your terminal by typing "cat file" it's probably surprising though. even if it's only the last line of the file. thus my suggestion of backspaces
<OriansJ`>I was thinking of seeing what would happen if I just took the output of md5sum and feed it back into the data in that block and looping until collision
<OriansJ`>oh right I got the math wrong 8bytes is only 64bits
<OriansJ`>what 64bit checksum would we use?
<OriansJ`>say crc64
<bauen1>OriansJ`: you're right
<bauen1>OriansJ`: https://github.com/oriansj/mes-m2/blob/master/lib/x86-mes/elf32-header.hex2 seems to be the ELF header used by mes
<bauen1>OriansJ`: so that would mean i would have to do a bit of adjusting to find the pt_filesz / pt_memsz and automatically determine the offset of the _start symbol
<bauen1>*entry point
<bauen1>and actually i'm targeting amd64
<bauen1>which i suppose isn't supported by mes-m2 yet
<fossy>bauen1: it is supported
<bauen1>fossy: i haven't really been able to get mes-m2 to work (as in run test200)
<bauen1>fossy: so where is the source of the elf64 header that mes-m2 uses ?
<fossy>bauen1: mes-m2 is an interpreter, not a compiler
<fossy>so it dosent make any elfs
<bauen1>sorry, i meant mescc (which is included in mes-m2 ?)
<bauen1>debugging a compiler backdoor is ~~bloody hell~~ fun
<bauen1>i just figured out that hex1_amd64 actually writes past the end of its own binary (into my backdoor)
<bauen1>which probably isn't guaranteed to be allowed (according to POSIX)
<xentrac>haha
<fossy>ohhh
<fossy>bauen1: mescc dosent run under mes m2 yet
<fossy>Thats the missing stage of the chain
<fossy>but it uses hex2
<fossy>and m1