How are the binary files passed to those stage-0 commands?
They already exist in the source. They're split in the compression test files themselves. (Unless you meant some other binaries?)
Xz/liblzma: Bash-stage Obfuscation Explained
11–20 of 137 posts
Re: Xz/liblzma: Bash-stage Obfuscation Explained
#12How on earth did any of this make it through a code review and get merged in? It seems absurdly careless, unless I am missing something.
Re: Xz/liblzma: Bash-stage Obfuscation Explained
#13Thanks the simplified explanation and noisy image comparison is quite appreciated. It gives me a good grasp of what people mean by the sophistication involved. I also saw a comment on reddit mentioning that the "sandboxing" method was sabotaged with a dot. It's on the line just after "#include " you can see a dot all the way on the left. https://git.tukaani.org/?p=xz.git;a=commitdiff;h=328c52da8a2... https://old.redd…
OMG that's evil. The diff just shows: + +. + and the dot goes unnoticed
Re: Xz/liblzma: Bash-stage Obfuscation Explained
#14Earlier quoted context omitted.
They already exist in the source. They're split in the compression test files themselves. (Unless you meant some other binaries?)
Yeah, but how exactly are they passed to those commands? I don't see/understand that part. I don't see the "take this file here" part.
1. It might not be there in the place where you're looking. It exists in the m4 in the release tarballs, not in the git repo.
2. It's highly obfuscated.
Re: Xz/liblzma: Bash-stage Obfuscation Explained
#15Earlier quoted context omitted.
Yeah, but how exactly are they passed to those commands? I don't see/understand that part. I don't see the "take this file here" part.
That's for 2 reasons: 1. It might not be there in the place where you're looking. It exists in the m4 in the release tarballs, not in the git repo. 2. It's highly obfuscated.
This: 'gl_am_configmake=`grep -aErls "#{4}[[:alnum:]]{5}#{4}$" $srcdir/`' seem to match the '####Hello####', but, as far as I can see, that's supposed to be the already converted script?! I presumed the binary files not to contain human readable strings, maybe that's the whole confusion.
Re: Xz/liblzma: Bash-stage Obfuscation Explained
#16Thanks the simplified explanation and noisy image comparison is quite appreciated. It gives me a good grasp of what people mean by the sophistication involved. I also saw a comment on reddit mentioning that the "sandboxing" method was sabotaged with a dot. It's on the line just after "#include " you can see a dot all the way on the left. https://git.tukaani.org/?p=xz.git;a=commitdiff;h=328c52da8a2... https://old.redd…
OMG that's evil. The diff just shows: + +. + and the dot goes unnoticed
Re: Xz/liblzma: Bash-stage Obfuscation Explained
#17How on earth did any of this make it through a code review and get merged in? It seems absurdly careless, unless I am missing something.
edit: also this was heavily obfuscated in some binary files that were marked as test files ("good" and "bad" xz compressed test file). No way to spot this if you don't know what you're looking for.
Re: Xz/liblzma: Bash-stage Obfuscation Explained
#18Re: Xz/liblzma: Bash-stage Obfuscation Explained
#19Earlier quoted context omitted.
That's for 2 reasons: 1. It might not be there in the place where you're looking. It exists in the m4 in the release tarballs, not in the git repo. 2. It's highly obfuscated.
No, as far as I understand the binary files must be pointed at here: '$gl_am_configmake' ... But I don't see how. This: 'gl_am_configmake=`grep -aErls "#{4}[[:alnum:]]{5}#{4}$" $srcdir/`' seem to match the '####Hello####', but, as far as I can see, that's supposed to be the already converted script?! I presumed the binary files not to contain human readable strings, maybe that's the whole confusion.
Re: Xz/liblzma: Bash-stage Obfuscation Explained
#20Earlier quoted context omitted.
Yeah, but how exactly are they passed to those commands? I don't see/understand that part. I don't see the "take this file here" part.
That's for 2 reasons: 1. It might not be there in the place where you're looking. It exists in the m4 in the release tarballs, not in the git repo. 2. It's highly obfuscated.