New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
multiple memory reading issue #206
Comments
|
Fixed on devel branch which will be pushed shortly. Note: bugs in decompression (upx -d or upx -t) are more significant that bugs in compression. If upx fails to compress then the workaround is just to forgo the reduction in space. If upx fails to decompress, then that's a mild security risk because it limits the ability of a malware scanner to see the entire original contents. |
|
@jreiser Could you explain more about the |
Look at phdr[4]: PT_DYNAMIC. It has a file Offset of 0xf28 and VirtAddr/PhysAddr of 0x600e28; but the Offset is not congruent to the Addr modulo the Align of 0x200000 for phdr[3] PT_LOAD which is mapped into memory and supposedly contains the PT_DYNAMIC. So one of Offset or Addr is wrong. Looking at we see that the PT_DYNAMIC actually begins at offset 0xe28. So the program that wrote poc1 must fix its bug of the wrong value in Elf64_Phdr[4].p_offset. [The "excessive checking" is to protect upx against malware which tries to cause SIGSEGV or bad output by overwriting the ELF headers. Anti-malware scanners rely on upx -d to remove compression and reveal the code which will be executed, so that the scanner can analyze it.] |
|
Thanks @jreiser, that's very informative, although I didn't fully understand the alignment part nor how to determine whether which of Offset or Addr is correct. I checked both locations with |
|
Ah, I see one cause of the exception now. I added some debugging prints to Probably should have printed them in hex, come to think of it. Is this the congruence check you mentioned? |
|
Yes, the congruence check. .p_offset and .p_vaddr must be at the same position on a page. rust (probably llvm) has had problems setting the right .p_offset. In this case 0xf28 should be 0xe28 instead. |
./upx.out --version
upx 3.95-git-614c86fb7d7b+
this time is the devel branch , everything up-to-date
the call stack for POC1
#0 0x00000000006647f8 in get_le32 (p=0x30) at bele.h:164
#1 N_BELE_RTP::LEPolicy::get32 (this=0x9b63c0 <N_BELE_RTP::le_policy>, p=0x30) at bele_policy.h:192
the poc.zip , contains POC1 & POC2
poc.zip
The text was updated successfully, but these errors were encountered: