so this vendor is putting a CRC16 in INI files

🦋 vendor pointing at a C header: "is this an INI file?"

vendor pointing at the end of an INI file (clearly containing C source code): indeed... why should I not put something that is probably a CRC-32 here?

there's a hardcoded 32-byte AES key the firmware uses to encrypt passwords... except they fucked up (made an array of u32 and not u8) and 3/4 of the key is zeroes

not that it matters a lot given it's hardcoded

i was going to register http://crackhead.engineering but it's already gone :(

@whitequark lsd.engineering appears to be free, if that helps?

@darkling this is very much not the same thing!

to everybody suggesting other types of derangement: no, please understand, this is specifically crackhead engineering

kill it!!!

(there are 51 instance of killall something in this .so, of which 23 are killall -9)

@whitequark what font is that

@xyhhx Monaspace Neon

@whitequark thanks its pretty

@whitequark hmmm, what disassembler are you using that's doing the pseudo-rust syntax?

@cliffle https://binary.ninja

@whitequark lmao???

@whitequark Am I misreading, or it sprintfing to &buf[3] (to skip over a "ps " that's already supposed to be in the buffer?) and then immediately overwriting with sprintf to buf?

@snowfox crackhead engineering. yes.

@snowfox note the buffer is preloaded with a "ps " using a literal

@whitequark What tool is this? I thought it was Ghidra, but `let mut`s are rRusty, while Ghidra's pseudocode is C-like... Ta.

@vvv https://binary.ninja

@whitequark that is certainly a way to pre-expand the key

@whitequark I once came across an embedded system which not only hard-coded a fixed symmetric key like that, but the key was stored in the ROM pre-expanded. Guess they decided the key expansion for their chosen cipher would take too much CPU time and RAM space, or something.

@rachelplusplus if you're gonna hardcode your key might as well go all the way!

@whitequark Incredible.

I can't decide if that's a potential attempt at "optimization" (moving the static prefix from the format string to the variable initializer); it's the only thing I can come up with that makes sense (even though it doesn't actually make sense as an optimization).

But it's probably better not to try to make sense of it.

@snowfox @whitequark Nobody wrote crackhead code. Someone wrote something that a compiler compiled and what it compiled it to was decompiled by BN into something that was most definitely not what the original author wrote.
I'd guess whatever the original code was it wasn't C and didn't literally use sprintf to do the string composition. It perhaps incrementally modified some sort of CoW (or some sort of reallocate when it grows) string data type in whatever language it was.

@da77a9 @snowfox nope, there are actually two calls to sprintf. I spent quite a while confirming that it isn't a decompilation artifact; you're free to do that yourself if you want

and the language is C

@whitequark @snowfox
Wow. Nope, if you have checked I'm certainly not distrusting your work. Apologies.
Clearly I am underestimating the ability of crackheads to actually function well enough to produce C code under the influence.

@da77a9 @snowfox I am genuinely baffled at so many things in this .so, gimme a sec and I'll upload it for you

@da77a9 @snowfox

here https://upload.whitequark.org/1769258017-libtools.so

@whitequark Ah, 0x207370 is "ps "; I missed that (I wasn't sure what the numbers were but I don't Rust). That makes more sense, but the rest is still baffling.

Now I'm wondering if it would be a viable method of obfuscation. Probably not difficult to reverse, but annoying and fills the decompilation with chaff.

@snowfox fortunately, Binary Ninja is competently made software and lets you write a script to undo this type of damage very easily (I write them by hand but they have an "AI" thing which should allow basically anyone to do it in only a bit more time)