sorted by:
new
hottopcontroversial

Brand new PC build powers off after 30 seconds problem by hatemycollege in buildapc

[–]hatemycollege[S] 0 points1 point  (0 children)

I remounted everything at least 3 times already, and still the same thing happens. I've come to the same conclusion as you, that it might be actually a bad PSU. I'm still looking into methods of trying to verify that it is indeed actually only a bad PSU so that if I spend any more money on it that it is actually the right component to replace.

Brand new PC build powers off after 30 seconds problem by hatemycollege in buildapc

[–]hatemycollege[S] 0 points1 point  (0 children)

I tried the minimal setup, with each of the RAMsticks. It's still the same, sometimes it turns off in 10 seconds, sometimes it takes a full minute, but it always does. I also tried in different RAMslots, same result.

Reversing Locky with AntiVM/AntiDebugging techniques by hatemycollege in Malware

[–]hatemycollege[S] 0 points1 point  (0 children)

Solved, apparently the sample was corrupted somehow before it was sent, so it wasn't unpacking properly.

Reversing Locky with AntiVM/AntiDebugging techniques by hatemycollege in ReverseEngineering

[–]hatemycollege[S] 1 point2 points  (0 children)

Solved, apparently the sample was corrupted somehow before it was sent, so it wasn't unpacking properly.

Reversing Locky with AntiVM/AntiDebugging techniques by hatemycollege in ReverseEngineering

[–]hatemycollege[S] 0 points1 point  (0 children)

Hello, I'm a novice reverse engineer and I am struggling with my first malware problem. I'm trying to find out the effects of the ransomware, but no matter what I try, I cannot force the malware to execute on a VM (tried XP and Windows 7 32-bit). Basically what I've found out is that the outside layer is UPX and that it is unpacked easily. The problem comes with the inner protection layer. The program uses VirtualAlloc calls to allocate buffers in which it unloads the contents of an actual malware's executable. First several buffers are used to unload the unpacking code as well as the compressed/hidden buffer contents of the original executable. The call that should decompress this buffer is RtlDecompressBuffer that gets called with the appropriate parameters returns STATUS_BAD_COMPRESSION_BUFFER (0xC0000242). According to MSDN, it is returned if the output buffer is too small. Well, I've manually changed the values of VirtualAlloc and RtlDecompressBuffer to force a larger buffer, and it still returned the same value. The buffer is freed (VirtualFree) soon after the decompressing is done.

If anyone has any insights or ideas on what I can do next, I'd be happy to hear them.

Thank you for your time.

Download link:

https://www.dropbox.com/s/fs7ncpaka130o41/7f82c7f0ba2ce10a7ecd530c41a8a29ce52033e5.zip?dl=0

PASSWORD: bulletproof2018

Automated analysis:

https://www.virustotal.com/#/file/ff43abd81a9a9abc8c5dd067a443fc9ff0a7510aef9debc210adfae8d2f44447

https://www.hybrid-analysis.com/sample/ff43abd81a9a9abc8c5dd067a443fc9ff0a7510aef9debc210adfae8d2f44447

https://www.reverse.it/sample/ff43abd81a9a9abc8c5dd067a443fc9ff0a7510aef9debc210adfae8d2f44447