• XDA Forums have been migrated to XenForo. We are aware of several issues including missing threads, logins not working, and more. To discuss, use this thread.
  • If you are experiencing issues logging in, we migrated and software and made it more secure. We recommend trying to reset your password.

[UNLOCK] Technical steps to make an unlocked bootloader

Shadicbypass

New member
Jun 11, 2014
486
131
0
Conway
So I've been looking at MM20B's aboot.img today. I was able to extract a number of keys and certificates, find them here. They're all in DER format (ie. binary). Unfortunately I'm not a crypto expert, but perhaps one it out there reading this.

Dump keys like this:


The rootca and one of the "LG attestation" certs are x509:


Here are some thoughts and observations I made:
Funniest one first, one x509 certificate has a CN id of "georgia.park" which seems really odd, perhaps even a hint to some pass-phrase?
The androidlk keys seems to be related to the Android Little Kernel boot loader code.
On of the keys is is named UNLOCK_RSA_02, I'll be damned if this doesn't have to do anything with unlock.bin
I could imagine that the unlock.bin is encrypted with a public key at LG's site. Then you flash it to a dedicated partition. aboot.img grabs unlock.bin, decrypts it with one of its private keys and checks it. I could imagine if we get to decrypt an existing unlock.bin, it just contains the device id and IMEI.
More generally, I think the process and keys is independent of the phone hardware. Every phone has to have identical boot loader and verification code. They will use the (unalterable) device id and IMEI to bind the process to devices


Next steps could be:
give those keys some more meaning and relate them to each other / other artifacts
most likely the unlock key is encrypted, so we'd need to find the pass phrase
some ARM guru could try to disassemble aboot.img to learn how those keys are used. Perhaps even find additional pass phrases embedded in the code


Spread the word. I'm new to the LG/LG4 community but I already learned that guy @autoprime is doing lots of gory work. Let's jailbreak this together and then donate the bounty to some noble cause!
In the build prop the ro.build.user is geprgia.park
 

ABotelho23

New member
Jun 1, 2013
184
65
0
Ottawa
So I've been looking at MM20B's aboot.img today. I was able to extract a number of keys and certificates, find them here. They're all in DER format (ie. binary). Unfortunately I'm not a crypto expert, but perhaps one it out there reading this.

Dump keys like this:
Code:
openssl  asn1parse -inform der -in KEYFILE
The rootca and one of the "LG attestation" certs are x509:
Code:
openssl x509 -inform der -in lgroot.crt 
openssl x509 -inform der -in lgattest.georgia.crt -text
Here are some thoughts and observations I made:
  • Funniest one first, one x509 certificate has a CN id of "georgia.park" which seems really odd, perhaps even a hint to some pass-phrase?
  • The androidlk keys seems to be related to the Android Little Kernel boot loader code.
  • On of the keys is is named UNLOCK_RSA_02, I'll be damned if this doesn't have to do anything with unlock.bin
  • I could imagine that the unlock.bin is encrypted with a public key at LG's site. Then you flash it to a dedicated partition. aboot.img grabs unlock.bin, decrypts it with one of its private keys and checks it. I could imagine if we get to decrypt an existing unlock.bin, it just contains the device id and IMEI.
  • More generally, I think the process and keys is independent of the phone hardware. Every phone has to have identical boot loader and verification code. They will use the (unalterable) device id and IMEI to bind the process to devices

Next steps could be:
  • give those keys some more meaning and relate them to each other / other artifacts
  • most likely the unlock key is encrypted, so we'd need to find the pass phrase
  • some ARM guru could try to disassemble aboot.img to learn how those keys are used. Perhaps even find additional pass phrases embedded in the code

Spread the word. I'm new to the LG/LG4 community but I already learned that guy @autoprime is doing lots of gory work. Let's jailbreak this together and then donate the bounty to some noble cause!
I love to see people go at this stuff. Unfortunately my specialty is more networking, I don't know enough about this specifically to help as much as I'd like!
 

ABotelho23

New member
Jun 1, 2013
184
65
0
Ottawa
While doing a bit of research, I stumbled on some particularly odd documents. Both documents have several mentions that are pretty specific about how LG secured the bootloader. I have no idea if it's handy, or if it's already been posted, by I figured what the heck!

https://drive.google.com/folderview?id=0B7oPC5i99NAZeXBOcnRZWk1ER3c&usp=sharing It's two PDF documents, both are in this shared folder of mine. Hope it helps!
 

xrad

Senior Member
Jul 3, 2012
1,134
796
113
The Internet
So I've been looking at MM20B's aboot.img today. [...]
Here's a quick update. I've spent a lot of time reverse engineering the bootloader and I have now a pretty solid picture how things work. With the valid combination of an unlock.bin and device-id/IMEI I was able to reproduce the stages the code takes to validate the key. Indeed the unlock key I recovered from the binary is a public key which the loader verifies the unlock.bin key. It then compares the digest thus recovered with a locally generated one and if they match - you're unlocked. So far for the good news. As expected, the bad news is that the corresponding private key is not in our hands, but needed to create valid unlock.bin files. So as of now there's still no hope to break in, but at least I know how the lock works. And I learned a bit about openssl, which has its own merits.
 

ChriKn

New member
Apr 18, 2012
592
280
0
France / Germany
Here's a quick update. I've spent a lot of time reverse engineering the bootloader and I have now a pretty solid picture how things work. With the valid combination of an unlock.bin and device-id/IMEI I was able to reproduce the stages the code takes to validate the key. Indeed the unlock key I recovered from the binary is a public key which the loader verifies the unlock.bin key. It then compares the digest thus recovered with a locally generated one and if they match - you're unlocked. So far for the good news. As expected, the bad news is that the corresponding private key is not in our hands, but needed to create valid unlock.bin files. So as of now there's still no hope to break in, but at least I know how the lock works. And I learned a bit about openssl, which has its own merits.
I assume that trying to bruteforce the key is not an option ?
Even if a huge amount of people as their Riggs to the process..
 

xrad

Senior Member
Jul 3, 2012
1,134
796
113
The Internet
I assume that trying to bruteforce the key is not an option ?
Even if a huge amount of people as their Riggs to the process..
I'm not a crypto expert, and I don't know the first thing about attacking keys. But from what I read about sha256 - no effing way on earth. It is much more likely that a frustrated (or noble?) LG engineer drops the private key somewhere... (such as in a box :angel:)
 

ChriKn

New member
Apr 18, 2012
592
280
0
France / Germany
I'm not a crypto expert, and I don't know the first thing about attacking keys. But from what I read about sha256 - no effing way on earth. It is much more likely that a frustrated (or noble?) LG engineer drops the private key somewhere... (such as in a box :angel:)
Some of us must infiltrate LG, find a low-wage job to earn their trust and respect. In some years we might be in the position to get the key and voilà ;)
 

xrad

Senior Member
Jul 3, 2012
1,134
796
113
The Internet
Here's a bit of brain dump to help me not forget my findings and to share the knowledge.

When you're requesting your unlock key from LG, and if you're lucky enough to own an EUR or SEA phone, this is what happens behind LG's firewall:

  • A 128 byte buffer is formed which contains your 64 byte device ID and the 15 byte IMEI. Let's call this buffer unlock.id:
    Code:
    00000000  33 41 38 43 38 45 46 34  42 36 46 41 41 41 41 38  |3A8C8EF4B6FAAAA8|
    00000010  31 35 34 42 45 33 34 31  33 31 44 46 34 45 43 42  |154BE34131DF4ECB|
    00000020  38 43 43 39 33 33 34 30  44 37 37 36 36 35 37 31  |8CC93340D7766571|
    00000030  38 34 42 33 36 45 46 44  44 35 36 41 44 35 34 46  |84B36EFDD56AD54F|
    00000040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
    [...all zero...]
    00000060  33 35 39 38 37 32 30 36  32 32 30 32 37 33 33 00  |359872062202733.|
    00000070  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
  • The sha256 sum (digest) is generated for this buffer:
    Code:
    openssl dgst -sha256 binary <unlock.id >unlock.sha256
    00000000  9c a8 74 02 34 f9 38 c6  15 62 53 61 9a 07 dc 14  |..t.4.8..bSa....|
    00000010  07 7b dd 13 6f 48 7f 0e  ff a4 cb ce bd 40 7a ff  |.{[email protected]|
  • The sha256 digest is signed using the private key:
    Code:
    openssl rsautl -inkey UNLOCK_RSA_02_PRIV.pem -sign <unlock.sha256  >unlock.bin
  • A header is prepended to unlock.signed:
    Code:
    9e15b78d -> magic #1
    6bd37e2d -> magic #2 
    00000001 -> magic #3 
    00000002 -> sha method (1=sha1, 2=sha256) 
    00000100 -> size of key (256 bytes)
  • The result of this process is the unlock.bin they send to you and which you can flash in fastboot (if you have enabled the OEM unlock option in the developer settings).

Now, when the phone boots, the following happens:

  • The unlock.bin is checked to have the proper magic IDs at the beginning
  • Using the phone's device ID and IMEI, the unlock.id buffer is built as described above and the SHA256 sum is generated
  • The unlock.bin key is verified using the public key. This recovers the sha-256 encoded unlock.id as it was initially prep'ed at LGr:
    Code:
    openssl rsautl -verify <UNLOCK_RSA_02.pem -inkey pub.pem -pubin
  • If the locally generated buffer and the verified one match -> You're UNLOCKED!

Things to note:
  • We do have the public key UNLOCK_RSA_02.pem, but we lack the private key UNLOCK_RSA_02_PRIV.pem.
  • The 4th word encodes the SHA method that is used to generate the signed digest. Currently LG seems to issue unlock.bins with SHA256, but from the code I think SHA1 should also work. Perhaps this is easier to attack.
  • We can't change any of the code because the bootloader, kernel, device tree and initial ramdisk are protected with similar SSL keys forming a chain of trust. We would need to find a hole here (aka Jailbreak)
  • Some of the values (IMEI, Device ID I'm not yet sure) are retrieved using a function called ftm_get_item(). I guess this refers to a thing called Field Test Mode which keeps a large number of device specific values. @autoprime once documented them somehwere here on XDA. Perhaps thare is a way to inject values here. AFAIU older LG phones could boot into something called MiniOS. Perhaps this is also possible on the G4 and gives access to those variables. If that was possible, we could perhaps force the phone to use a known combination of device ID, IMEI and unlock.bin -> unlock -> inject root -> restore original settings.
That's all folks for today. Perhaps this helps to further our efforts.
 
Last edited:

dpi295

New member
Sep 27, 2008
162
15
0
Here's a bit of brain dump to help me not forget my findings and to share the knowledge.

When you're requesting your unlock key from LG, and if you're lucky enough to own an EUR or SEA phone, this is what happens behind LG's firewall:

  • A 128 byte buffer is formed which contains your 64 byte device ID and the 15 byte IMEI. Let's call this buffer unlock.id:
    Code:
    00000000  33 41 38 43 38 45 46 34  42 36 46 41 41 41 41 38  |3A8C8EF4B6FAAAA8|
    00000010  31 35 34 42 45 33 34 31  33 31 44 46 34 45 43 42  |154BE34131DF4ECB|
    00000020  38 43 43 39 33 33 34 30  44 37 37 36 36 35 37 31  |8CC93340D7766571|
    00000030  38 34 42 33 36 45 46 44  44 35 36 41 44 35 34 46  |84B36EFDD56AD54F|
    00000040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
    [...all zero...]
    00000060  33 35 39 38 37 32 30 36  32 32 30 32 37 33 33 00  |359872062202733.|
    00000070  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
  • The sha256 sum (digest) is generated for this buffer:
    Code:
    openssl dgst -sha256 binary <unlock.id >unlock.sha256
    00000000  9c a8 74 02 34 f9 38 c6  15 62 53 61 9a 07 dc 14  |..t.4.8..bSa....|
    00000010  07 7b dd 13 6f 48 7f 0e  ff a4 cb ce bd 40 7a ff  |.{[email protected]|
  • The sha256 digest is signed using the private key:
    Code:
    openssl rsautl -inkey UNLOCK_RSA_02_PRIV.pem -sign <unlock.sha256  >unlock.bin
  • A header is prepended to unlock.signed:
    Code:
    9e15b78d -> magic #1
    6bd37e2d -> magic #2 
    00000001 -> magic #3 
    00000002 -> sha method (1=sha1, 2=sha256) 
    00000100 -> size of key (256 bytes)
  • The result of this process is the unlock.bin they send to you and which you can flash in fastboot (if you have enabled the OEM unlock option in the developer settings).

Now, when the phone boots, the following happens:

  • The unlock.bin is checked to have the proper magic IDs at the beginning
  • Using the phone's device ID and IMEI, the unlock.id buffer is built as described above and the SHA256 sum is generated
  • The unlock.bin key is verified using the public key. This recovers the sha-256 encoded unlock.id as it was initially prep'ed at LGr:
    Code:
    openssl rsautl -verify <UNLOCK_RSA_02.pem -inkey pub.pem -pubin
  • If the locally generated buffer and the verified one match -> You're UNLOCKED!

Things to note:
  • We do have the public key UNLOCK_RSA_02.pem, but we lack the private key UNLOCK_RSA_02_PRIV.pem.
  • The 4th word encodes the SHA method that is used to generate the signed digest. Currently LG seems to issue unlock.bins with SHA256, but from the
  • code I think SHA1 should also work. Perhaps this is easier to attack.
  • We can't change any of the code because the bootloader, kernel, device tree and initial ramdisk are protected with similar SSL keys forming a chain of trust. We would need to find a whole here (aka Jailbreak)
  • Some of the values (IMEI, Device ID I'm not yet sure) are retrieved using a function called ftm_get_item(). I guess this refers to a thing called Field Test Mode which keeps a large number of device specific values. @autoprime once documented them somehwere here on XDA. Perhaps thare is a way to inject values here. AFAIU older LG phones could boot into something called MiniOS. Perhaps this is also possible on the G4 and gives access to those variables. If that was possible, we could perhaps force the phone to use a known combination of device ID, IMEI and unlock.bin -> unlock -> inject root -> restore original settings.
That's all folks for today. Perhaps this helps to further our efforts.
It's possible to access MiniOS on the G4. Used it previously to recalibrate the proximity sensor.

1. Type "277634#*#" in dialer to access the hidden menu.

2. Select "Device Test"->"MT", the device should restart.

3. It should reboot into Genesis MiniOS.
 
  • Like
Reactions: xrad and autoprime

IllegalArgument

New member
Sep 28, 2014
19
205
0
Here's a bit of brain dump to help me not forget my findings and to share the knowledge.

When you're requesting your unlock key from LG, and if you're lucky enough to own an EUR or SEA phone, this is what happens behind LG's firewall:

  • A 128 byte buffer is formed which contains your 64 byte device ID and the 15 byte IMEI. Let's call this buffer unlock.id:
    Code:
    00000000  33 41 38 43 38 45 46 34  42 36 46 41 41 41 41 38  |3A8C8EF4B6FAAAA8|
    00000010  31 35 34 42 45 33 34 31  33 31 44 46 34 45 43 42  |154BE34131DF4ECB|
    00000020  38 43 43 39 33 33 34 30  44 37 37 36 36 35 37 31  |8CC93340D7766571|
    00000030  38 34 42 33 36 45 46 44  44 35 36 41 44 35 34 46  |84B36EFDD56AD54F|
    00000040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
    [...all zero...]
    00000060  33 35 39 38 37 32 30 36  32 32 30 32 37 33 33 00  |359872062202733.|
    00000070  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
  • The sha256 sum (digest) is generated for this buffer:
    Code:
    openssl dgst -sha256 binary <unlock.id >unlock.sha256
    00000000  9c a8 74 02 34 f9 38 c6  15 62 53 61 9a 07 dc 14  |..t.4.8..bSa....|
    00000010  07 7b dd 13 6f 48 7f 0e  ff a4 cb ce bd 40 7a ff  |.{[email protected]|
  • The sha256 digest is signed using the private key:
    Code:
    openssl rsautl -inkey UNLOCK_RSA_02_PRIV.pem -sign <unlock.sha256  >unlock.bin
  • A header is prepended to unlock.signed:
    Code:
    9e15b78d -> magic #1
    6bd37e2d -> magic #2 
    00000001 -> magic #3 
    00000002 -> sha method (1=sha1, 2=sha256) 
    00000100 -> size of key (256 bytes)
  • The result of this process is the unlock.bin they send to you and which you can flash in fastboot (if you have enabled the OEM unlock option in the developer settings).

Now, when the phone boots, the following happens:

  • The unlock.bin is checked to have the proper magic IDs at the beginning
  • Using the phone's device ID and IMEI, the unlock.id buffer is built as described above and the SHA256 sum is generated
  • The unlock.bin key is verified using the public key. This recovers the sha-256 encoded unlock.id as it was initially prep'ed at LGr:
    Code:
    openssl rsautl -verify <UNLOCK_RSA_02.pem -inkey pub.pem -pubin
  • If the locally generated buffer and the verified one match -> You're UNLOCKED!

Things to note:
  • We do have the public key UNLOCK_RSA_02.pem, but we lack the private key UNLOCK_RSA_02_PRIV.pem.
  • The 4th word encodes the SHA method that is used to generate the signed digest. Currently LG seems to issue unlock.bins with SHA256, but from the
  • code I think SHA1 should also work. Perhaps this is easier to attack.
  • We can't change any of the code because the bootloader, kernel, device tree and initial ramdisk are protected with similar SSL keys forming a chain of trust. We would need to find a whole here (aka Jailbreak)
  • Some of the values (IMEI, Device ID I'm not yet sure) are retrieved using a function called ftm_get_item(). I guess this refers to a thing called Field Test Mode which keeps a large number of device specific values. @autoprime once documented them somehwere here on XDA. Perhaps thare is a way to inject values here. AFAIU older LG phones could boot into something called MiniOS. Perhaps this is also possible on the G4 and gives access to those variables. If that was possible, we could perhaps force the phone to use a known combination of device ID, IMEI and unlock.bin -> unlock -> inject root -> restore original settings.
That's all folks for today. Perhaps this helps to further our efforts.
Excellent analysis, all of the info you've shared looks accurate to me. I just had a couple notes I wanted to add regarding the device ID, IMEI, and ftm_get_item().

First, to compute the device ID, you start by reading the SoC serial number from QFPROM. The serial number is eight bytes long and is stored as two 32-bit words (in order): QFPROM_RAW_SERIAL_NUM_LSB at physical address 0xFC4B81F0 and QFPROM_RAW_SERIAL_NUM_MSB at physical address 0xFC4B81F4. Next, you convert the serial number to an uppercase hex string, i.e., sprintf(buf, "%08X%08X", QFPROM_RAW_SERIAL_NUM_LSB, QFPROM_RAW_SERIAL_NUM_MSB). Then you compute the SHA-256 hash of the hex string from the previous step. Finally, you convert the hash to another uppercase hex string, which becomes the 64 byte device ID used to form the unlock token.

As for the IMEI used in generating and validating the unlock token, it is not read from the modem, but from an ftm_item, as you noted. But what is an ftm_item? On LG devices, ftm_items are stored in the misc partition. Each ftm_item has an ID associated with it; for example, the ftm_imei item, which is used to generate and validate the unlock token, has ID 0xD. To compute the offset an ftm_item in the misc partition, simply multiply its ID by 0x800; continuing the previous example, this puts the ftm_imei item at byte offset 0x6800 in the misc partition.

While having the IMEI part of the token in the misc partition does give you easy control over it, the QFPROM serial number is quite challenging, since it physically cannot be modified. Downgrading the hash to SHA-1 instead of SHA-256 may be possible, but even SHA-1 isn't very fun to attack. That's not to say the scheme used here is unbreakable - there may very well be some weakness that hasn't been noticed yet. If there is such a weakness, analysis like that which you're doing is the best way to discover it.
 

xrad

Senior Member
Jul 3, 2012
1,134
796
113
The Internet
Excellent analysis, all of the info you've shared looks accurate to me. I just had a couple notes I wanted to add regarding the device ID, IMEI, and ftm_get_item().
(...)
While having the IMEI part of the token in the misc partition does give you easy control over it, the QFPROM serial number is quite challenging, since it physically cannot be modified.
How could one alter the misc partition on an unlocked and unrooted system though?
Downgrading the hash to SHA-1 instead of SHA-256 may be possible, but even SHA-1 isn't very fun to attack. That's not to say the scheme used here is unbreakable - there may very well be some weakness that hasn't been noticed yet. If there is such a weakness, analysis like that which you're doing is the best way to discover it.
Indeed. More eyes on the code would help though, so I would like to share my annotated disassembly of aboot but I'm unsure how to do that in a legally safe manner. Any advice?

---------- Post added at 08:25 PM ---------- Previous post was at 08:21 PM ----------

It's possible to access MiniOS on the G4. Used it previously to recalibrate the proximity sensor.

1. Type "277634#*#" in dialer to access the hidden menu.

2. Select "Device Test"->"MT", the device should restart.

3. It should reboot into Genesis MiniOS.
Very interesting! Yesterday I read about that (related to the G3) and remember people not finding a way out of this mode again? Is that still an issue? Haven't tried your codes yet.
 

dpi295

New member
Sep 27, 2008
162
15
0
How could one alter the misc partition on an unlocked and unrooted system though?

Indeed. More eyes on the code would help though, so I would like to share my annotated disassembly of aboot but I'm unsure how to do that in a legally safe manner. Any advice?

---------- Post added at 08:25 PM ---------- Previous post was at 08:21 PM ----------


Very interesting! Yesterday I read about that (related to the G3) and remember people not finding a way out of this mode again? Is that still an issue? Haven't tried your codes yet.
You mean not being able to exit? I have not had any issues. This post has a short guide on navigating it (for the purpose of calibrating the proximity sensor) and also some screenshots of the OS.

Hope it helps! Appreciate the work you're doing :)
 
  • Like
Reactions: Nekator

ericralph

New member
Mar 11, 2012
53
9
0
I'm not a crypto expert, and I don't know the first thing about attacking keys. But from what I read about sha256 - no effing way on earth. It is much more likely that a frustrated (or noble?) LG engineer drops the private key somewhere... (such as in a box :angel:)
I mean not without a quantum computer... ;)
 

xrad

Senior Member
Jul 3, 2012
1,134
796
113
The Internet
It's possible to access MiniOS on the G4. Used it previously to recalibrate the proximity sensor.

1. Type "277634#*#" in dialer to access the hidden menu.

2. Select "Device Test"->"MT", the device should restart.

3. It should reboot into Genesis MiniOS.
For the records, on phone that code does not work. I found this one after a while: *#546368#*815#
 

amune14

New member
Apr 27, 2015
16
10
0
Kremenchuk
Code:
seg000:0000000000000000 ;
seg000:0000000000000000 ; +-------------------------------------------------------------------------+
seg000:0000000000000000 ; |   This file has been generated by The Interactive Disassembler (IDA)    |
seg000:0000000000000000 ; |           Copyright (c) 2014 Hex-Rays, <[email protected]>           |
seg000:0000000000000000 ; |                      License info: 48-3057-7374-2C                      |
seg000:0000000000000000 ; |     Zhou Tao, Jiangsu Australia Sinuo Network Technology Co., Ltd.      |
seg000:0000000000000000 ; +-------------------------------------------------------------------------+
seg000:0000000000000000 ;
seg000:0000000000000000 ; Input MD5   : 293445143C7460E5C823DA3512C58DBB
seg000:0000000000000000 ; Input CRC32 : F6A626E9
seg000:0000000000000000
seg000:0000000000000000 ; File Name   : C:\Users\+шыют\Desktop\unlock.bin
seg000:0000000000000000 ; Format      : Binary file
seg000:0000000000000000 ; Base Address: 0000h Range: 0000h - 0400h Loaded length: 00000400h
seg000:0000000000000000
seg000:0000000000000000                 .686p
seg000:0000000000000000                 .mmx
seg000:0000000000000000                 .model flat
seg000:0000000000000000
seg000:0000000000000000 ; ===========================================================================
seg000:0000000000000000
seg000:0000000000000000 ; Segment type: Pure code
seg000:0000000000000000 seg000          segment byte public 'CODE' use64
seg000:0000000000000000                 assume cs:seg000
seg000:0000000000000000                 assume es:nothing, ss:nothing, ds:nothing, fs:nothing, gs:nothing
seg000:0000000000000000                 db  9Eh ; Ю
seg000:0000000000000001                 db 15h, 0B7h, 8Dh, 6Bh, 0D3h, 7Eh, 2Dh
seg000:0000000000000008                 dq 200000001h, 64F1F1900000100h, 204B15C652FEAB37h, 0D373DFE9DB6ED2E4h
seg000:0000000000000008                 dq 0C5871456D523F189h, 8C2ECC2AFCC96969h, 0AE377CD7EDFC591Ch
seg000:0000000000000008                 dq 0D9699210D2DF5325h, 0F417563C1FCE974Eh, 8BD500816BADD90Dh
seg000:0000000000000008                 dq 0B6A76C5DB29B1540h, 9264C8141FE4BD4Eh, 5933C7C5DB86DAB8h
seg000:0000000000000008                 dq 0A281ED79F2D73B6Bh, 30892075905D0E19h, 0B131F2AA154D942Bh
seg000:0000000000000008                 dq 0D8B351873A3F03EBh, 1E6165A5DA67E3B5h, 29AE549074A3CF76h
seg000:0000000000000008                 dq 7666109352D75814h, 515A79F656A631FAh, 0FDDA48CB6B404905h
seg000:0000000000000008                 dq 352DE0CCF66CD1h, 5456C8BD8249DF7Eh, 99D09202775E8F74h
seg000:0000000000000008                 dq 0B8952F012EE0BDD4h, 1E9C96F18C59330Eh, 9C51492CB41804Bh
seg000:0000000000000008                 dq 5922EA9952CC2F68h, 6CF3B16C50B1A007h, 7031925C78AB4B29h
seg000:0000000000000008                 dq 60DB139BDF82A203h, 27BE1E0D203B6155h, 986D71CAh, 5Dh dup(0)
seg000:0000000000000008 seg000          ends
seg000:0000000000000008
seg000:0000000000000008
seg000:0000000000000008                 end
This is disassembled unlock.bin
 
  • Like
Reactions: MSephiroth

ABotelho23

New member
Jun 1, 2013
184
65
0
Ottawa
Code:
seg000:0000000000000000 ;
seg000:0000000000000000 ; +-------------------------------------------------------------------------+
seg000:0000000000000000 ; |   This file has been generated by The Interactive Disassembler (IDA)    |
seg000:0000000000000000 ; |           Copyright (c) 2014 Hex-Rays, <[email protected]>           |
seg000:0000000000000000 ; |                      License info: 48-3057-7374-2C                      |
seg000:0000000000000000 ; |     Zhou Tao, Jiangsu Australia Sinuo Network Technology Co., Ltd.      |
seg000:0000000000000000 ; +-------------------------------------------------------------------------+
seg000:0000000000000000 ;
seg000:0000000000000000 ; Input MD5   : 293445143C7460E5C823DA3512C58DBB
seg000:0000000000000000 ; Input CRC32 : F6A626E9
seg000:0000000000000000
seg000:0000000000000000 ; File Name   : C:\Users\+шыют\Desktop\unlock.bin
seg000:0000000000000000 ; Format      : Binary file
seg000:0000000000000000 ; Base Address: 0000h Range: 0000h - 0400h Loaded length: 00000400h
seg000:0000000000000000
seg000:0000000000000000                 .686p
seg000:0000000000000000                 .mmx
seg000:0000000000000000                 .model flat
seg000:0000000000000000
seg000:0000000000000000 ; ===========================================================================
seg000:0000000000000000
seg000:0000000000000000 ; Segment type: Pure code
seg000:0000000000000000 seg000          segment byte public 'CODE' use64
seg000:0000000000000000                 assume cs:seg000
seg000:0000000000000000                 assume es:nothing, ss:nothing, ds:nothing, fs:nothing, gs:nothing
seg000:0000000000000000                 db  9Eh ; Ю
seg000:0000000000000001                 db 15h, 0B7h, 8Dh, 6Bh, 0D3h, 7Eh, 2Dh
seg000:0000000000000008                 dq 200000001h, 64F1F1900000100h, 204B15C652FEAB37h, 0D373DFE9DB6ED2E4h
seg000:0000000000000008                 dq 0C5871456D523F189h, 8C2ECC2AFCC96969h, 0AE377CD7EDFC591Ch
seg000:0000000000000008                 dq 0D9699210D2DF5325h, 0F417563C1FCE974Eh, 8BD500816BADD90Dh
seg000:0000000000000008                 dq 0B6A76C5DB29B1540h, 9264C8141FE4BD4Eh, 5933C7C5DB86DAB8h
seg000:0000000000000008                 dq 0A281ED79F2D73B6Bh, 30892075905D0E19h, 0B131F2AA154D942Bh
seg000:0000000000000008                 dq 0D8B351873A3F03EBh, 1E6165A5DA67E3B5h, 29AE549074A3CF76h
seg000:0000000000000008                 dq 7666109352D75814h, 515A79F656A631FAh, 0FDDA48CB6B404905h
seg000:0000000000000008                 dq 352DE0CCF66CD1h, 5456C8BD8249DF7Eh, 99D09202775E8F74h
seg000:0000000000000008                 dq 0B8952F012EE0BDD4h, 1E9C96F18C59330Eh, 9C51492CB41804Bh
seg000:0000000000000008                 dq 5922EA9952CC2F68h, 6CF3B16C50B1A007h, 7031925C78AB4B29h
seg000:0000000000000008                 dq 60DB139BDF82A203h, 27BE1E0D203B6155h, 986D71CAh, 5Dh dup(0)
seg000:0000000000000008 seg000          ends
seg000:0000000000000008
seg000:0000000000000008
seg000:0000000000000008                 end
This is disassembled unlock.bin
Make anything of it?