nwindow.dll (2007-06-19) MD5: 6c1b532f8fb48657d5bac6b2944e83b8
Learn how edit-box types are numbered
Look for the function that parses the editBoxType attribute. It compares a string against a list of names and returns a number. In the Interlude build the mapping was:
• 0 = default/normal
• 1 = Chat
• 2 = Password
• 3 = Number
• 4 = Date
• 5 = Time
• 6 = ID
Names and numbers can differ between builds, so confirm them in your own file. The strings ID, Time, Date, Number, Password, Chat sit next to the text XMLNode::GetAttributeEditBoxType, which is an easy anchor to search for.
Find the login window's creation code
Find the UTF-16 string NCAuthWnd::OnCreate and search the code for the address that references it (the address is pushed in the function's error/trace path). Walk backwards to the start of the function (usually after a run of int3 bytes, beginning with push ebp; mov ebp, esp).
Inside it you will see the same pattern repeated for each field:
1. Allocate the object.
2. Push six arguments and call the edit-box constructor.
3. Store the result in the window object.
4. Assign a control ID (for example 0x1502 for ID and 0x1503 for password).
Because arguments are pushed right to left, the last push before the call is the first parameter. The first parameter is the type.
Confirm which parameter is the type
Open the constructor and check that its first parameter ([ebp+8]) is stored into the object at some offset (0x334 in Interlude). Then check the edit-box drawing code: it compares that same offset against 2 before drawing *. This confirms that 2 means Password in that build.
Compare the two fields
In the Interlude build, the two constructor calls differed only in the last push:
• ID field: push 6 (bytes 6A 06)
• Password field: push 2 (bytes 6A 02)
If your client is different, the pushes may use a different instruction form, such as mov to a register.
Patch
Change only the ID field's type byte to the Password value. In the example this is 6A 06 to 6A 02 at file offset 0x181d32, so one byte at 0x181d33 changes from 06 to 02. Keep the file length identical and do not insert or delete bytes.
For these DLLs the .text section's raw file offset equals its RVA minus 0x1000 offset difference only if the section table says so, so always compute the offset from the section table: file_offset = RVA - section.VirtualAddress + section.PointerToRawData. In the Interlude NWindow.dll the code section had matching raw offset and RVA for the addresses used.
Learn how edit-box types are numbered
Look for the function that parses the editBoxType attribute. It compares a string against a list of names and returns a number. In the Interlude build the mapping was:
• 0 = default/normal
• 1 = Chat
• 2 = Password
• 3 = Number
• 4 = Date
• 5 = Time
• 6 = ID
Names and numbers can differ between builds, so confirm them in your own file. The strings ID, Time, Date, Number, Password, Chat sit next to the text XMLNode::GetAttributeEditBoxType, which is an easy anchor to search for.
Find the login window's creation code
Find the UTF-16 string NCAuthWnd::OnCreate and search the code for the address that references it (the address is pushed in the function's error/trace path). Walk backwards to the start of the function (usually after a run of int3 bytes, beginning with push ebp; mov ebp, esp).
Inside it you will see the same pattern repeated for each field:
1. Allocate the object.
2. Push six arguments and call the edit-box constructor.
3. Store the result in the window object.
4. Assign a control ID (for example 0x1502 for ID and 0x1503 for password).
Because arguments are pushed right to left, the last push before the call is the first parameter. The first parameter is the type.
Confirm which parameter is the type
Open the constructor and check that its first parameter ([ebp+8]) is stored into the object at some offset (0x334 in Interlude). Then check the edit-box drawing code: it compares that same offset against 2 before drawing *. This confirms that 2 means Password in that build.
Compare the two fields
In the Interlude build, the two constructor calls differed only in the last push:
• ID field: push 6 (bytes 6A 06)
• Password field: push 2 (bytes 6A 02)
If your client is different, the pushes may use a different instruction form, such as mov to a register.
Patch
Change only the ID field's type byte to the Password value. In the example this is 6A 06 to 6A 02 at file offset 0x181d32, so one byte at 0x181d33 changes from 06 to 02. Keep the file length identical and do not insert or delete bytes.
For these DLLs the .text section's raw file offset equals its RVA minus 0x1000 offset difference only if the section table says so, so always compute the offset from the section table: file_offset = RVA - section.VirtualAddress + section.PointerToRawData. In the Interlude NWindow.dll the code section had matching raw offset and RVA for the addresses used.