Winocm (not mathieullh) explains how to decrypt isolated loaders

[Varela]

Source: Long hiatus, and how asecure_loaders work. « rms's crypt

Hi, it’s been a long time, hasn’t it? Life has just been really busy, finals coming up in the following weeks, so yeah, have been preparing for those nasty buggers.

Meh, anyway, so how do isolated loaders work? Asecure_loaders in specific (metldr)? Well, metldr is a raw binary, not an ELF, and here are the segments of it I have figured out at least:

Name                   Start    End
.local_storage_cleanup 00000400 00000860
.text                  00000860 0000CB70
.rodata                0000CB70 0000FCD0
.data                  0000FCD0 0003E400
.ram                   0003E400 00040000
The entrypoint of metldr is at 0×400, and in essence it just does the following:

    ULONG *pStart = (ULONG*)&start;
    (pStart)();

The start routine prepares the DMA buffer, and essentially is crt0.c, branches to main, then exits. The main routine prepares the global isolated loader constructor (yes, this is C++ code), then branches to loader_start, which sets up the mailbox for recieving mail, and then loads the actual isolated module, after this, it sends back the mail twice, once normally, second with an interrupt. The actual loader decryption subroutine (load_isolated_loader) sets the prepares the SELF for decryption, verifies the header, then gets the program information headers, then verifies each segment. The code for verifying the header essentially sets up a buffer and then calls verify_header. Then metldr loads its AES decryption key, IV, ECDSA public key and curve type then calls verify_header again. Verify_header sets up the buffer manager, and eventually calls verify_signature after running aes_ctr and aes_decrypt. Verify_signature loads the digest, and performs the SHA1 hash checks. Then we verify the signature by using ECDSA signature algorithms. Verify_self_segment loads the elf segment after several buffers are initialized, then the necessary program structures needed for loader initialization are created then control is passed to the cleanup subroutine. This routine essentially zeroes out every register except $r3 (yes, $SP, $LR, $r0-r2, $r4-r127), and branches to the address in $r3. Ta-da! We have successfully decrypted a binary.

Hope this article was useful.

Another step forward to being able to dump keys perhaps?

[ironhide666]

looks that math got pissed about posting that without asking him (seems another leaked conversation) and now winocm deleted that post.

[Varela]

looks that math got pissed about posting that without asking him (seems another leaked conversation) and now winocm deleted that post.

Yeah, good thing we saved it here. I've always defended math and acknowledged his contribution to the scene but fact is he is a whiner.

[xPreatorianx]

looks that math got pissed about posting that without asking him (seems another leaked conversation) and now winocm deleted that post.

EDIT: Disregard. Stuff is sorted so no need for this post.

[afiser]

looks that math got pissed about posting that without asking him (seems another leaked conversation) and now winocm deleted that post.

this is how rumor's get started.

just because it got deleted does not mean that math is mad, unless you have seen otherwise.

[jarmster]

post it to the wiki....

[xPreatorianx]

Well he said he was mad/angry/dissatisfied because he didn't get credit, or rather he didn't get permission before releasing it. But still credit is what lead to the scene's current problems. As long as your private group of "uber developers" know that you were the original person who "discovered the mighty exploit." who bloody cares!

Anyways this is what he said : @xPreatorianx In fact I told him he could put it back, I just asked him not to do anything like this again.

So I guess it was restored. So..... yea...

EDIT: I have no idea on what the link is now. This one is still returning 404.