A Security Bug ? (Or Feature) that affect PGP Virtual Disks & PGP SDA , PGP 8.x, 9.x and Truecrypt but for Truecrypt it is a documented FEATURE (Based on their answer). (Version 2)


Disclaimer

This document is presented for informational and educational purposes only. I do not condone or encourage vandalism or theft. I do not accept any liability for anything anyone does with this information. Remember to use a computer in ways that ensure respect for your fellows.

 

Permission to use this document is granted, provided that:

  1. The below copyright notice appears in all copies.

  2. Use of such document is for informational and non-commercial or personal use only.

 

NEVER UNDERESTIMATE RADICAL VISION (NURV)

 

Author: Adonis a.K.a NtWaK0, Abed, a.K.a. nophie

Date: 2006-05-08

2006 All rights reserved www.isiq.ca

 


 

Affected Products:

 

FORENSIC INVESTIGATORS MUST KNOW ABOUT THESE ISSUE BECAUSE THEY HAVE TO DEFEND THEIR CASES IF IT END UP IN COURT. We will explain how PGP evidence can be manipulated ENOUGH to make your case go BAD or go in a unexpected direction. Something you do not want in court right?.

 

 

LESSON LEARNED, this advisory should be a wakeup call for other products. We should concentrate on secure coding and a GOOD AUDIT.

 


Change / Update Date 06/09/2006

We would like to thank truecrypt team for their professional nice answer. It turned out that Truecrypt (OpenProject) software are much more professional than a COMMERCIAL company like PGP. PGP answer was illogical, maybe they did not bother watching/reading or debugging before answering.

 

Related Links

--Mr. Jon Callas (CTO PGP) Comments--

> You bring up an excellent point. As I said in my previous post, we are considering a change to the way we're doing things. Unfortunately, there's no one thing that's clear the the right thing to do. Let me examine some of them.

We could make a documentation change. I don't like documentation changes like this because it's a cover-your-ass solution. Let's face it, no one reads the documentation. If we put in something there, we can answer any further objection with saying "this is a documented situation," but it doesn't *solve* anything. It is in my opinion, a cop out. We're better off doing nothing or making a code change.

Now then, we could make a code change. But what code change?

Security is a strange business, because you quickly go from things that a absolute dos and don'ts into things upon which gentlepersons can disagree. Part of this is because doing the right thing for the user is a good design principle, but so is less is more. Simplicity makes for better security, and that means doing less.

We could put a dialog box up warning the user. This is a reasonable thing to do. The Truecrypt folks do that. One can argue on the other side that is is just one step forward from a documentation change, that it is a CYA move that doesn't really solve the problem, it just allows you to wash your hands of the situation. I have to think about it for a while. I can see both sides of it. I lean towards less is more, particularly because there are lots of moving parts here. My main PGP disk is not passphase-based, it is public-key-based. If I change the passphrase on my key, does that mean that the PGP program should grovel over my disk looking for virtual disk volumes that are encrypted to that public key? If not, why not? Extend this to virtual volumes that are managed by a smart card or security token, and you can see it gets very hard very quickly.  

-- End Comment--

 


--Adonis, Abed Comments--

 

We like to clear up some stuff. We think a lot of peoples did not fully understand our posting. We are talking about multiples issues here.

  1. BASED ON OUR FINDING WE CAN SEE A MAJOR PROBLEM IN PGP SPECIALLY IF YOU ARE WORKING WITH FORENSIC EVIDENCE AND THE COURT. WE ARE NOT TALKING HERE ABOUT A BACKUP AND RESTORE ISSUE LIKE Mr. Jon callas (CTO at PGP)) ANSWER. WE ARE TALKING ABOUT AUTHENTICATION BYPASS AND OTHER ISSUES.
  2. PGP 8.X AND 9.X USE A STATIC LOCATION to save the passphrase. PGP 8.x and 9.x AUTHENTICATION can be bypassed using a simple debugger (Does not include extraction). Extraction is possible in some cases and in other cases it may take couples of hours and a good knowledge of assembly language and debugging tools.
  3. If PGP virtual disk or PGP Self Decrypting Archive to be used in some forensic investigation, the investigator must be aware that PGP is not a FULL proof LOCK and EVIDENCE CAN BE MADE USELESS WITHOUT KNOWING THE CORRECT PASSPHRASE. Say you have an evidence file PGP Self Decrypting Archive called "CPcase.sda.exe". You are the ONLY one who know the passphrase, so you think your evidence file is secure because no one can CHANGE IT IS CONTENT without the knowledge of your passphrase. Well the found bug will prove that is possible to change the file CONTENT WITHOUT the knowledge of the ORIGINAL passphrase. OF COURSE YOUR PASSPHRASE WONT WORK AFTER THAT.
  4. PGP Self Decrypting Archive file can be extracted without problem if the input file is the same. What do I mean? If you create a file "a" and the content is "a". Now encrypt that file using two different passphrase, that will create two .sda.exe files. Patch the passphrase location from one file to another. You should be able to extract the file if you follow the steps described in "PROOF-OF-CONCEPT PGP SDA PROTECTED FILES". This area need more work and time to allow the extraction of any sda file or pdg disk.
  5. PGP Virtual Disk can be mounted without the knowledge of the passphrase. If the volume is EMPTY this will work just just by changing some bytes inside the .pgd file. If the volume is NOT EMPTY, it can be mounted without the passphrase knowledge after patching the passphrase location BUT WHEN YOU CLICK THE DISK IT WILL SAY IT NEED TO BE FORMATTED. At this point you can delete users add users and re-encrypt the disk. We believe that extraction of any disk is possible if you spent some time in your debugger. Here were time must be invested. -- Scenario -- If you have TWO say File A.PGD and File B.PGD PGP disks with the SAME CONTENT but different passphrases say FILE A.PGD pass is 123 and FILE B.PGD is 12345678. You can access file B.PGD using FILE A.PGP pass(123) after changing some bytes in the .PGD file.
  6. We hope that (PGP) see that their password verification can be simply bypassed, besides a respected company like PGP Inc. do not use ANTI-DEBUGGING in their Encryption Products. Irony?. An encryption software that use a fixed location and reveal it is operation by using a simple debugger... Irony?.


-- End Comment--

 


The Why?

Mr. X who is working on some Forensic Investigation case, called me and asked me if their is a way to get into PGP encrypted disk if you do not have the correct passphrase. I was like Hmmm, hmmm on the phone, then I said I am not aware of any recent known public way. I had suggested to try the user login password or the email password in case they are using the same password on the PGP disks.

While sitting in the train on my way back home, I was thinking about that PGP issue and how to Help Mr. X and other forensic Investigators who are facing similar problem. I know it is not my problem but now it became my problem why ? curiosity/challenge/help I guess.


The How?

I Was able to ACCESS PGP encrypted disks if the disk was encrypted with a passphrase or a public Key.

You need the followings tools:

  1. A Brain

  2. A Hex Editor.

  3. A Debugger e.g. olldbg

  4. PGP 8.1 Enterprise or Personal. You can use 9.x too.

During our tests we have found out that PGP virtual DISK and PGP Self Extractable file SDA have a SERIOUS security bug. Maybe we can say a design bug or a hidden feature?.

 

Major Steps to Bypass PGP SDA Authentication

  1. Use a debugger and load your SDA file

  2. Locate were you need to patch and patch it as described in this article

Major Steps to Bypass PGP Virtual Disk Authentication

  1. Use a hex editor to patch the binary file as described in this article. This will give you access to user management and other disk utilities. Even the disk will mount this does not grant you access to the data inside the virtual disk. To extract the data you need to spend more time with your debugger


Users Management Problem

Once you have patched the passphrase location you can do whatever you like to the users. The problem with user management is a clear issue. When the passphrase is changed PGP does not change the underlying key which will allow any user who had access to regain that access back.

 

Note to forensic investigators: Imagine you are working on some cases and for some reason you do not want Mr. Y to have access to some of the evidence file, so you decided to change the passphrase on your PGP virtual Disk. Mr. Y can still access the evidence if he patch the Virtual Disk binary file. Watch a proof-of-Concept.

 

This is clear issue and should be prevented. In mean time this can prevented by RE-ENCRYPTING the PGP volume after changing your the passphrase.

 


Static Passphrase Location (Why making it easy?)

The passphrase location can be discovered pretty easy. Here is how, create a PGP disk make a backup copy, change the passphrase on one of them, use a hex editor to do a binary comparison of these files, you will notice the passphrase location. Second place that you can see the passphrase is inside your debugger if you do a dump and search for 803E you will be able to find it. This is a clear problem and should be prevented. If a simple hash was done on the binary file we could not have DONE ANY CHANGES. 

Where is the Passphrase ?

After setting the correct break point and entering a GOOD passphrase we check wish address has 00BBXxxx.

In my example I have
ESP 00BBF6AC
EBP 00BBF7C4
ESI 00BBFC54
<-- Right click it and select Follow in Dump (Ollydg).

Look at the left lower corner in your ollydg. You will see the HEX dump of your passphrase. After breaking on USER32.GetWindowTextA we will see 00405CD7 |. FF15 24124100 CALL DWORD PTR DS:[<&USER32.GetWindowTex>; \GetWindowTextA

Search for 803E in the dump and you will see the important bytes.

00BBFF6E 00 00 56 08 81 7C 50 47 ..V |PG
00BBFF76 50 53 44 41 00 B0 01 00 PSDA. .
00BBFF7E 11 00 00 00 00 00 00 00 .......
00BBFF86 01 00 00 00 00 00 00 00 .......
00BBFF8E 2B 30 34 3B 1D 34 24 7E +04; 4$~
00BBFF96 80 3E C6 F8 6F 9A CC 27 €>oš'
00BBFF9E B1 E1 00 00 00 00 EC FF ....
00BBFFA6 BB 00 EF 51 40 00 76 03 .Q@.v
00BBFFAE 86 00 00 00 00 00 04 F9 †.....
00BBFFB6 12 00 0B B5 80 7C 30 0F . €|0
00BBFFBE 89 00 00 00 00 00 04 F9 ‰.....
00BBFFC6 12 00 30 0F 89 00 00 E0 .0 ‰..
00BBFFCE FD 7F 00 26 3C 82 C0 FF .&<‚
00BBFFD6 BB 00 E8 A1 15 82 FF FF . ‚
00BBFFDE FF FF F3 99 83 7C 18 B5 ™ƒ|
00BBFFE6 80 7C 00 00 00 00 00 00 €|......


PGP SDA authentication method

Let's say you created a text file and wrote inside it "aa", then created an SDA.
IF you hex edit the output exe, you will notice at the very buttom of the file some bytes seperated by 803E.
Ex:

E7 93 A0 90 E9 62 D1 21
803E
A1 50 AF 5F 6F 9E FE D6


Analyzing the bytes carefully, you will notice that 803E is the value used for a loop. The loop starts at 0040590D. Further analysis showed that the bytes right before 803E, are used for extraction and authentication. Authentication is done in the following way:
 

When some enters a passphrase a series of instructions is executed against the bytes right before 803E, to be exact in the function at address 00404E8F. This function generates a series of bytes which are compared later on to the bytes AFTER 803E. If they match you are granted auth. More debugging details can be found here.


PROOF-OF-CONCEPT PGP SDA PROTECTED FILES

Steps to extract a PGP SDA USING ANY PASSPHRASE and a bebugger

proof_of_concept_PGP_Authentication_BYPASS.html (Flashvideo)
 

Extraction a PGP SDA file is a 2 steps process.

  1. You bypass Authentication using ESI=EDI Method

  2. You generate the correct 78 DA 63 etc. Sequence

1- Step #1 Patching Authentication


We load the file in the debugger and set the break points then we start by hitting F9 we will see the password dialog, we enter ANY password here. we hit 6 times F9. A break point should be set on 00405D70 to see this.

--> BREAK IS SET AT 00409797 TO CAPTURE PASSPHRASE KEYING
--> BREAK IS SET AT 004015A6 TO CAPTURE REGISTERS CHANGES


We hit F9 couples of time then we change ESI EDI
ON 00409797 |. F3:A7 REPE CMPS DWORD PTR ES:[EDI],DWORD PTR D>;

 

We see the stack values
ECX=00000002 (decimal 2.)
DS:[ESI]=stack [00BBF68C]=DC3F5C82 <-- IF WE ENTER A BAD PASSWORD THESE WONT BE THE SAME
ES:[EDI]=stack [00BBFF98]=DC3F5C82 <-- WE JUST MAKE THEM EQUAL THEN CONTINUE THE QUEST.

 

We change decimal 2 and decimal 1. Once you have changed decimal 2 hit F7 to see decimal 1.

AT THIS POINT PGP Authentication is bypassed. After the changes continue tracing and you will see you wont get ask again to re-enter your passphrase even the passphrase is a wrong one.
 

Screen Capture #1 Screen Capture #2

 

 

 

2- Step #2 Generating the correct 78 DA 63 etc Sequence

 

Two Ways to bypass PGP SDA Authentication and EXTRACT with success.

 

Extraction bytes GENERATION location for PGP SDA file. The sequence start with 78 DA 63 and it has to be these values IF NOT you wont extract or you will extract crap.

 

Extraction bytes IDENTICATION for SDA. The sequence start with 78 DA 63 and it has to be these values IF NOT you wont extract or you will extract crap.

 


Two Ways to bypass PGP SDA Authentication and EXTRACT with success

 

After spending a lot of time debugging and analyzing PGP SDA, we came up with a conclusion that we can successfully extract the contents of PGP SDA in 2 ways.

1) Modifying the contents of the address 00890D70. (Screen Capture)

The modification should be done in:
0040598F |. E8 AC3D0000 CALL filename_s.00409740

At: 00409740 /$ 8B4424 0C MOV EAX,DWORD PTR SS:[ESP+C]

At this point change the contents of 00890D70.

After the bytes change, you will have to bypass authentication. After bypassing authentication you will be able to extract.

2) Modifying the contents of the address 00BAF670. (Screen Capture)

The Modification should be done in:
0040595F FF15 90324100 CALL DWORD PTR DS:[413290]

At: 004019DA /$ FF7424 08 PUSH DWORD PTR SS:[ESP+8]

At this point change the contents of 00BAF670.
NOTE: At this point if you change the contents of 00BAF670, you won't have to bypass authentication, it will work like a charm, and it will grant auth/extract.
 


Steps to access PGP Encrypted Disk (Passphrase) Proof-of-concept

You can watch this flash video pgpdiskvideo.html

NOTE: if your input file is the same for the original and the backup copy the drive will mount with no problem. if the files are different then you have to use a debugger and play some with it. if you follow this example you should not have a problem.

NOTE At this point you can add/del users, re-encrypt drive and other stuff. The problem with user management is a clear issue.

When the passphrase is changed PGP does not change the underlying key which will allow any user who had access to regain that access back. This is clear issue and should be prevented I guess.


Accessing PGP Encrypted Disk (Public Key) Proof-of-concept

If the disk that you want to mount is encrypted using a Public key you can still access it using the same steps describe above. The only difference is what you need to replace. Follow the screen captures. PGP will consider the drive protected by a passphrase if you replace the indicated bytes. That mean you can mount a protected PGP disk even if the disk is using a Public Key not only a passphrase.

Screen 1 | Screen 2


Accessing ANY PGP VIRTUAL Disk . (Need more testing and free time, Check Debugging Notes at the end)

Screen 1 | Screen 2 | Screen 3

At this point you can add users change existing users passphrase Re-encrypt disk and do other stuff. But when you try to access the disk you will get Disk is not formatted. This is when you need to use your debugger.


Proof-of-concept using a debugger to extract a PGP SDA.

Screen 1 | Screen 2 | Screen 3 | Screen 4 | Screen 5 | Screen 6 | Screen 7 | Screen 8 | Screen 9 | Screen 10 | Screen 11 | Screen 12


Debugging Notes

Important Functions summary:
----------------------------

00405D70 |. E8 4FFBFFFF CALL H1_txt_s.004058C4
This function does the AUTH, and generates various bytes
responsible for decryption in alot of memory addresses.
-------------------------------------------------------------------------------
004058D4 |. E8 173D0000 CALL H1_txt_s.004095F0

This function clears the contents of the memory address
00B9F630, ending up with 00B9F680.
-------------------------------------------------------------------------------
004058DD |. E8 F9DCFFFF CALL H1_txt_s.004035DB

This function adds a series of bytes to the addresses
00B9F670-80, for example:
01 23 45 67 89 AB CD EF FE DC BA 98 76 54 32 10 F0 E1 D2 C3
-------------------------------------------------------------------------------
004058F2 |. E8 46F4FFFF CALL H1_txt_s.00404D3D

This function adds a series of bytes to the address 00B9F630.
For example:
53 63 BD 73 84 FE 78 44
-------------------------------------------------------------------------------
0040593D |. E8 D9F4FFFF CALL H1_txt_s.00404E1B

Builds decryption/authentication bytes, by modifying bytes
in the addresses 00B9F630-80.
-------------------------------------------------------------------------------
00404E8F |. E8 77E7FFFF CALL H1_txt_s.0040360B

Launches instructions that builds initial decryption/authentication bytes.
-------------------------------------------------------------------------------
0040595F FF15 90324100 CALL DWORD PTR DS:[413290]

Builds bytes in the address 00890D70 responsible for decryption.
-------------------------------------------------------------------------------
0040598F |. E8 AC3D0000 CALL H1_txt_s.00409740

This function is responsible for authentication. (ESI/EDI change happens here.)
-------------------------------------------------------------------------------
Function starting with the address: 00401511
This function is responsible for building the decryption sig., starting with 78 DA.
This function then extracts the filename, then extracts the contents of the filename.
-------------------------------------------------------------------------------

The auth. byte comparison is done in the following instruction:
00409797 |. F3:A7 REPE CMPS DWORD PTR ES:[EDI],DWORD PTR DS:[ESI]
 

This function returns the number of characters entered as a passphrase.

-----------------------------------------------------------------------

00409520 /$ 8B4C24 04 MOV ECX,DWORD PTR SS:[ESP+4] //ECX = address of ESP+4 which is 00890E00.
00409524 |. F7C1 03000000 TEST ECX,3 //Test ECX against 3.
0040952A |. 74 14 JE SHORT aa_txt_s.00409540 //Jump is taken.
0040952C |> 8A01 /MOV AL,BYTE PTR DS:[ECX]
0040952E |. 41 |INC ECX
0040952F |. 84C0 |TEST AL,AL
00409531 |. 74 40 |JE SHORT aa_txt_s.00409573
00409533 |. F7C1 03000000 |TEST ECX,3
00409539 |.^75 F1 \JNZ SHORT aa_txt_s.0040952C
0040953B |. 05 00000000 ADD EAX,0
00409540 |> 8B01 /MOV EAX,DWORD PTR DS:[ECX] //copy contents of [ECX] into EAX which is 44490032.
00409542 |. BA FFFEFE7E |MOV EDX,7EFEFEFF //Put 7EFEFEFF in EDX.
00409547 |. 03D0 |ADD EDX,EAX //Now EDX=C347FF31.
00409549 |. 83F0 FF |XOR EAX,FFFFFFFF //Now EAX=BBB6FFCD.
0040954C |. 33C2 |XOR EAX,EDX //Now EAX=78F100FC.
0040954E |. 83C1 04 |ADD ECX,4 //ECX=00890E04.
00409551 |. A9 00010181 |TEST EAX,81010100 //Test against 81010100.
00409556 |.^74 E8 |JE SHORT aa_txt_s.00409540 //Jump is not taken.
00409558 |. 8B41 FC |MOV EAX,DWORD PTR DS:[ECX-4]//Put 44490032 in EAX.
0040955B |. 84C0 |TEST AL,AL //AL=32, test if it's zero.
0040955D 74 32 JE SHORT aa_txt_s.00409591 //Jump is not taken.
0040955F |. 84E4 |TEST AH,AH //AH=0, test if it's zero.
00409561 |. 74 24 |JE SHORT aa_txt_s.00409587 //Jump is taken.
--cut--
0040959A \. C3 RETN



Break on 00405D70 |. E8 4FFBFFFF CALL #_sda.004058C4

--------------------------------------------------------------------

00404E1B /$ 53 PUSH EBX //EBX=00DE03A4 Local call from 0040593D
00404E1C |. 56 PUSH ESI //ESI=00BBFC54
00404E1D |. 8B7424 0C MOV ESI,DWORD PTR SS:[ESP+C] //Address contains 00B9F630, now ESI=00B9F630. <--DIFF
00404E21 |. 57 PUSH EDI //EDI=00000000 Push 00000000 to stack.
00404E22 |. 6A 3F PUSH 3F //Push 0000003F to stack.
00404E24 |. 8B4E 58 MOV ECX,DWORD PTR DS:[ESI+58] //Stack DS:[00BBF688]=0000FA08 ECX=FFFFFFFD STACK 0000003F
00404E27 |. 58 POP EAX //Stack [00BBF60C]=0000003F EAX=00BBF630
00404E28 |. 23C8 AND ECX,EAX //EAX=0000003F ECX=0000FA08
00404E2A |. 2BC1 SUB EAX,ECX //ECX=00000008 EAX=0000003F
00404E2C |. 8D1431 LEA EDX,DWORD PTR DS:[ECX+ESI] //Stack address=00BBF638 EDX=00000003
00404E2F |. C602 80 MOV BYTE PTR DS:[EDX],80 //FIRST CHAR IN THE FILE Stack DS:[00BBF638]=61 ('a')
00404E32 |. 42 INC EDX //EDX=00BBF638
00404E33 |. 83F8 08 CMP EAX,8 //EAX=00000037 Test 00000037 against 8.
00404E36 |. 73 24 JNB SHORT aa_txt_s.00404E5C //Jump is taken. //EAX 00000037 ECX 00000008 STACK 00000000
 

--cut--

004095F0 /$ 8B5424 0C MOV EDX,DWORD PTR SS:[ESP+C] //Address contains 0000002F, Now EDX=0000002F.
004095F4 |. 8B4C24 04 MOV ECX,DWORD PTR SS:[ESP+4] //Address contains 00B9F639, Now ECX=00B9F639.
004095F8 |. 85D2 TEST EDX,EDX //Test if EDX=0(which is not).
004095FA |. 74 47 JE SHORT aa_txt_s.00409643 //Jump is NOT taken.
004095FC |. 33C0 XOR EAX,EAX //EAX=0.
004095FE |. 8A4424 08 MOV AL,BYTE PTR SS:[ESP+8] //Address contains 00, now AL=00.
00409602 |. 57 PUSH EDI //Push 00000000 to stack.
00409603 |. 8BF9 MOV EDI,ECX //ECX=00B9F639, Now EDI=00B9F639.
00409605 |. 83FA 04 CMP EDX,4 //Compare 0000002F, to 00000004.
00409608 |. 72 2D JB SHORT aa_txt_s.00409637 //Jump is NOT taken.
0040960A |. F7D9 NEG ECX //Now ECX=FF4609C7.
0040960C |. 83E1 03 AND ECX,3 //Now ECX=00000003.
0040960F |. 74 08 JE SHORT aa_txt_s.00409619 //Jump is NOT taken.
00409611 |. 2BD1 SUB EDX,ECX //Now EDX=0000002C.
00409613 |> 8807 /MOV BYTE PTR DS:[EDI],AL //Now the first byte of 00B9F639 is 00.
00409615 |. 47 |INC EDI //EDI=00B9F63A.
00409616 |. 49 |DEC ECX //Now ECX=00000002.
00409617 |.^75 FA \JNZ SHORT aa_txt_s.00409613 //Jump is taken.


This will LOOP and the address 00B9F638 will have the values: 80 00 00 00
--------------------------------------------------------------------------------------------
00409619 |> 8BC8 MOV ECX,EAX //Both are zeros.
0040961B |. C1E0 08 SHL EAX,8 //EAX=00000000.
0040961E |. 03C1 ADD EAX,ECX //Both are zeros.
00409620 |. 8BC8 MOV ECX,EAX //Zeros.
00409622 |. C1E0 10 SHL EAX,10 //Zeros.
00409625 |. 03C1 ADD EAX,ECX //Zeros.
00409627 |. 8BCA MOV ECX,EDX //Now ECX=0000002C.
00409629 |. 83E2 03 AND EDX,3 //Now EDX=00000000.
0040962C |. C1E9 02 SHR ECX,2 //Now ECX=0000000B.
0040962F |. 74 06 JE SHORT aa_txt_s.00409637 //Jump is NOT taken.
00409631 |. F3:AB REP STOS DWORD PTR ES:[EDI] //Will zero everything from 00B9F638 to 00B9F668.
00409633 |. 85D2 TEST EDX,EDX //Test if zero, EDX is zero.
00409635 |. 74 06 JE SHORT aa_txt_s.0040963D //Jump is taken.
00409637 |> 8807 /MOV BYTE PTR DS:[EDI],AL
00409639 |. 47 |INC EDI
0040963A |. 4A |DEC EDX
0040963B |.^75 FA \JNZ SHORT aa_txt_s.00409637
0040963D |> 8B4424 08 MOV EAX,DWORD PTR SS:[ESP+8] //Put 00B9F639 in EAX.
00409641 |. 5F POP EDI //Now EDI=00000000.
00409642 |. C3 RETN
00409643 |> 8B4424 04 MOV EAX,DWORD PTR SS:[ESP+4]
00409647 \. C3 RETN



00404E68 |. 6A 0E PUSH 0E //Push 0E for function call.
00404E6A |. 56 PUSH ESI //Push 00B9F630 for function call.
00404E6B |. 56 PUSH ESI //Push 00B9F630 for function call.
00404E6C |. E8 78FFFFFF CALL aa_txt_s.00404DE9 //CALL aa_txt_s.00404DE9(00B9F630,00B9F630,0E).

00404DE9 /$ 8B4424 08 MOV EAX,DWORD PTR SS:[ESP+8]//Address contains 00B9F630, now EAX=00B9F630.
00404DED |. 8B4C24 04 MOV ECX,DWORD PTR SS:[ESP+4]//Address contains 00B9F630, now ECX=00B9F630.
00404DF1 |. 56 PUSH ESI //Push 00B9F630.
00404DF2 |> 0FB670 02 /MOVZX ESI,BYTE PTR DS:[EAX+2]//Address contains 32 '2', now ESI=32.
00404DF6 |. 33D2 |XOR EDX,EDX //EDX=0.
00404DF8 |. 8A30 |MOV DH,BYTE PTR DS:[EAX] //Address (00B9F630)contains 32 '2',Now DH=32.
00404DFA |. 8A50 01 |MOV DL,BYTE PTR DS:[EAX+1] //Address contains 7c '|' now DL=7C.
00404DFD |. 83C0 04 |ADD EAX,4 //Now EAX=00B9F634. has the values 32 7e 32 7f
00404E00 |. C1E2 08 |SHL EDX,8 //Now EDX=00327C00.
00404E03 |. 0BD6 |OR EDX,ESI //Now EDX=00327C32.
00404E05 |. 0FB670 FF |MOVZX ESI,BYTE PTR DS:[EAX-1]//Addres contains 7D now ESI=7D.
00404E09 |. C1E2 08 |SHL EDX,8 //Now EDX=327C3200.
00404E0C |. 0BD6 |OR EDX,ESI //Now EDX=327C327D.
00404E0E |. 8911 |MOV DWORD PTR DS:[ECX],EDX //Address contains 327c327d now it contains 7d327c32.
00404E10 |. 83C1 04 |ADD ECX,4 //Now ECX=00B9F634.
00404E13 |. FF4C24 10 |DEC DWORD PTR SS:[ESP+10] //Now ESP+10=D.
00404E17 |.^75 D9 \JNZ SHORT aa_txt_s.00404DF2
00404E19 |. 5E POP ESI
00404E1A \. C3 RETN

This function reverses the hex values in memory now it has the following values:
7D 32 7C 32 7F 32 7E 32 00 00 00 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

-------------------------------------------------------------------------------------------------------

00404E71 |. 8B46 58 MOV EAX,DWORD PTR DS:[ESI+58] //Address (00B9F668) contains 00007D08, Now EAX=00007D08.
00404E74 |. 8B4E 54 MOV ECX,DWORD PTR DS:[ESI+54] //Address contains 00000000, now ECX=00000000.
00404E77 |. 8BD0 MOV EDX,EAX //EAX=00007D08, Now EDX=00007D08.
00404E79 |. 8D7E 40 LEA EDI,DWORD PTR DS:[ESI+40] //Address is 00B9F670, now EDI=00B9F670.
00404E7C |. C1E1 03 SHL ECX,3 //ECX=00000000.
00404E7F |. C1EA 1D SHR EDX,1D //EDX=00000000.
00404E82 |. 0BCA OR ECX,EDX //Both are zeros.
00404E84 |. 56 PUSH ESI //Push 00B9F630 to stack.
00404E85 |. C1E0 03 SHL EAX,3 //Now EAX=0003E840.
00404E88 |. 57 PUSH EDI //Push 00B9F670 to stack.
00404E89 |. 894E 38 MOV DWORD PTR DS:[ESI+38],ECX //Address(00B9F668) contains DFBD0655, now it's zeros.
00404E8C |. 8946 3C MOV DWORD PTR DS:[ESI+3C],EAX //Address contains B3176A7F, EAX contains 0003E840,Addr=0003E840.
--cut--
00404EC8 \. C3 RETN

99 33 0A 23 CE 6F B5 F7 0C F6 97 EF A3 4A 9D 83 F8 4E FC 43 BC AC 73 DA C7 2C A8 BB 8B 8D 7D 8B
87 7D AA 83 59 D7 B1 B2 3D 7C 89 0B A7 55 9D 72 42 45 F3 0C 1C 88 D9 25 94 24 51 34 9B B3 26 AF
B7


Screen 1 This screen will show what some bytes related to file size and how they increment.

Screen 2 This screen will show what some bytes related to file size and how they increment.


That is it for now, Peace to you all:all


www.safehack.com
$Adonis, Abed: PGPcrack.html,v 1.000 2006/05/08 NtWaK0, nophie $

2006 All rights reserved www.isiq.ca