Recovering encrypted import names without running the sample

If you only have the decompiler, you do not have the bug. You wrote «Crackme decrypts import names into a heap buffer then GetProcAddress». That is the sentence I keep. I trust FLOSS after I have seen the decoder. Before that I read the stores. Same class as the October thread, different binary.

I failed this exact class in January. The load-bearing line: Crackme decrypts import names into a heap buffer then GetProcAddress. I bookmark the decoder then re-analyze. Reloading the file is the honest fallback. Did you force-create the function or did auto-analysis luck into it? Same class as the June thread, different binary.

This is the writeup I wanted when I was stuck. On «Recovering encrypted import names without running the sample»: Crackme decrypts import names into a heap buffer then GetProcAddress. If it is a crackme you wrote, dump after the decoder. Do not fight the packed view forever. I will +rep a listing and −rep a vibe. That is the deal.

@quietmike

This is the writeup I wanted when I was stuck. On «Recovering encrypted import names without running the sample»: Crackme decrypts import na

Good. Dated shot, version in the post. «Recovering encrypted import names without running the sample» — specifically Crackme decrypts import names into a heap buffer then GetProcAddress. UPX with a skipped magic is still UPX. Restore four bytes and move on. Same class as the March thread, different binary.

@rsec

Good. Dated shot, version in the post. «Recovering encrypted import names without running the sample» — specifically Crackme decrypts import

I am not moving this to DMs so you can yell. Stay on the class. Agreed on the class, not on the tool. On «Recovering encrypted import names without running the sample»: Crackme decrypts import names into a heap buffer then GetProcAddress. Call-convention mass-correct with a script. Still too much clicking. My note id for this: 2c-02.

This matches a public n-day class from last patch Tuesday. «Recovering encrypted import names without running the sample» — specifically Crackme decrypts import names into a heap buffer then GetProcAddress. I trust FLOSS after I have seen the decoder. Before that I read the stores. Did page heap see it, or only the sanitizer? Same class as the January thread, different binary.

@sock

This matches a public n-day class from last patch Tuesday. «Recovering encrypted import names without running the sample» — specifically Cra

I still keep a paper notebook for this kind of note. You wrote «Crackme decrypts import names into a heap buffer then GetProcAddress». That is the sentence I keep. Call-convention mass-correct with a script. Still too much clicking. Took me 12 hours the first time.

I ran this on a licensed corpus binary. On «Recovering encrypted import names without running the sample»: Crackme decrypts import names into a heap buffer then GetProcAddress. Listing first. The decompiler invented a cast last week that hid a signed compare. I wrote a 12-line script and then threw it away. The listing was enough.

@tonybliss

I ran this on a licensed corpus binary. On «Recovering encrypted import names without running the sample»: Crackme decrypts import names int

I read the patch. You read a tweet. Those are not the same source. Please keep the hashes and drop the mystery zips. The load-bearing line: Crackme decrypts import names into a heap buffer then GetProcAddress. I leave CET ops in the listing. They document that CET is on. Pinned a comment at 0x140006b1c in the listing.

@vixter

Please keep the hashes and drop the mystery zips. The load-bearing line: Crackme decrypts import names into a heap buffer then GetProcAddres

I reproduced it twice before I believed you. On «Recovering encrypted import names without running the sample»: Crackme decrypts import names into a heap buffer then GetProcAddress. Listing first. The decompiler invented a cast last week that hid a signed compare. I reproduced it on lab build 1335.