How to automate task in OllyDBG? I want to create a script.
I bp on a certain address and go to its stack arguments. There are four stack arguments. I use the address of the 2nd argument and the size from the 4th argument and dump the HEX data into a log file.
For example :
I set a breakpoint at 512A12 and I see the following in stack:
00192003 005DB123 RETURN to program.005DB123 from program.00512A12
00192011 0018F058 - 1st argument
00192028 03F48D78 - 2nd argument
00192032 03F48D78 - 3rd argument
00192036 00000500 - 4th argument
So I dump the data from address starting at 00192028 03F48D78 - 2nd argument where 03F48D78 is the address to start the dump from.
And I use the size from the 4th argument 00192036 00000500 - 4th argument where 500 is the size of the data to be dumped.
The data is saved in a log file. It is a hex data from the dump section in OllyDBG.
Now I want to loop this function and automate it. How can this automation be done in Ollyscript or something else?
Afaik none of existing plugins offer windbg's .writemem functionality
uploaded below is an ollydbg plugin enhanced from anonymouse (openrce blog)
modified cmdline plugin with an added command .writemem
Download and put the dll in ollydbg 1.10 plugin path.
possible crash path fixed (FindModule -> Mod-name can be null if FindModule return null in such cases added "unknown_module" string as modulename for sprintf_s)
http://wikisend.com/download/750442/cmdline.dll
This plugin is an enhanced version of modified cmdline plugin for ollydbg 1.10 by anonymouse (openrce blog) and contains one extra command .writemem
enhancements being original source altered considerably to make it compile with visual studio 2010 express (old commands not tested)
one extra command .writemem added (similar to windbg's .writemem)
usage as follows alt+f1 or plugin -> cmdline plugin .
in the dialog box type
writemem [esp+0x4] dword [esp+0x10] c:\dumps
or may be
writemem 0x403085 0x45 f:\foo\blah
first command will dump 0xxxx bytes pointed by [esp+0x10] from address pointed by [esp+0x4] to the preexisting folder c:\dumps
second command will dump 0x45 bytes from 0x402085 to the specified folder
to automate use this command with conditional log breakpoint pass commands to plugin when paused functionality (shift+f4)
in the edit box enter
.writemem <address> <size> <folder path>
.run
when ever the breakpoint is hit the memory contents will be dumped
another snapshot to explain the words better below
This tutorial might help:
http://x9090.blogspot.com/2009/07/ollyscript-tutorial-unpack-upx.html
Also, you can read some scripts carefully to learn more about Olly scripting.
The actual function I need in the end to complete my task is as following.
Its an encryption / Decyption function
0x1 PUSH EBP - the encrypted data is loaded.
0x5 RETN - the data is decrypted
So the encrypted/decrypted data is loaded in the stack values as I earlier explained.
1 - When bp hits 0x1 PUSH EBP
2 - We goto stack values
3 - We follow the 2nd argument as start address for the chunk of encrypted data and the 4th argument for the size of the data.
4- We dump using wrtiemem from cmdline mod
Also we follow the same for decrypted data
1 - When bp hits 0x5 RETN
2 - We goto stack values
3 - We follow the 2nd argument as start address for the chunk of decrypted data and the 4th argument for the size of the data.
4- We dump using wrtiemem from cmdline mod.
I was wondering if the data could be saved in one text file called encdec.txt
Encrypted HEX Values
Decrypted HEX Values.
For exammple:
ENC - 88 F4 62 71 3D 25 CD 7C 72 76 8E 14 95 0B D1 8B
DEC - 3E 2E BA 24 FA 22 47 A0 00 0F A5 0E F7 B0 9C 32
If the above is done then I need to automate the HEX search and replace values from encdec.txt on the target encrypted file.
So the automation would check the line " ENC - 88 F4 62 71 3D 25 CD 7C 72 76 8E 14 95 0B D1 8B " and search for it on the targeted file and replace the values with hex values in "DEC - 3E 2E BA 24 FA 22 47 A0 00 0F A5 0E F7 B0 9C 32"
Related
I'm working through a reverse engineering exercise using olly.
00402D71 |. 6A 00 PUSH 0 ; /hTemplateFile = NULL
00402D73 |. 68 80000000 PUSH 80 ; |Attributes = NORMAL
00402D78 |. 6A 03 PUSH 3 ; |Mode = OPEN_EXISTING
00402D7A |. 6A 00 PUSH 0 ; |pSecurity = NULL
00402D7C |. 6A 00 PUSH 0 ; |ShareMode = 0
00402D7E |. 68 00000080 PUSH 80000000 ; |Access = GENERIC_READ
00402D83 |. FF75 F0 PUSH DWORD PTR SS:[EBP-10] ; |C:\Windows\system32\eLearnRE#5.dat
00402D86 |. E8 DF642300 CALL <JMP.&KERNEL32.CreateFileA> ; \CreateFileA
On Windows 10, I created the eLearnRE#5.dat file and verified that NTFS permissions make it readable. But even like that I get 0xFFFFFFFF with ERROR_FILE_NOT_FOUND (00000002) as a result of the CALL CreateFileA.
This is what I tried already (without success)
Copy and pasted the name from ollydbg to make sure I don't have any typos
Compared the two filenames letter by letter in notepad to check for typos
Patched the process memory to try reading an existing file in C:\temp\test.txt (just in case c:\windows\System32\eLearnRE#5.dat had some special restrictions because it's in a system folder)
Put some data into the file just in case it had trouble handling a blank file for some reason.
Ran olly as Administrator
This works perfectly fine in Windows XP, but not in Windows 10. Why?
The credit for the answer goes to Hans Passant for https://learn.microsoft.com/en-us/windows/win32/winprog64/file-system-redirector
On 64bit windows, 32bit applications are redirected to C:\windows\syswow64
As soon as I moved the file to C:\windows\syswos64, things started to work as expected
I have x64dbg and ghidra synchronized via ret-sync. I found an interesting point in ghidra:
1800382b1 4d 8b e0 MOV R12,rebitData
1800382b4 48 63 f2 MOVSXD packetSize_,packetSize
in the listing view; the file my.dll starts at 180000000.
So, then in x64dbg I add a dll break for my.dll, and when I'm in, I go to the file offset with ctrl+shift+g and enter 328b4, but I end up at (first line):
00007FF8B2FB32B4 | 06 | ???
00007FF8B2FB32B5 | E9 80000000 | jmp my.7FF8B2FB333A
00007FF8B2FB32BA | 45:8BC6 | mov r8d,r14d
00007FF8B2FB32BD | EB 7B | jmp my.7FF8B2FB333A
00007FF8B2FB32BF | 3BFB | cmp edi,ebx
00007FF8B2FB32C1 | 73 22 | jae my.7FF8B2FB32E5
00007FF8B2FB32C3 | 41:3BDB | cmp ebx,r11d
00007FF8B2FB32C6 | 76 18 | jbe my.7FF8B2FB32E0
where in x64dbg, the file starts at: 00007FF8B2F81000 (CPU tab, module my.dll, main thread X, PID Y).
Obviously the instructions are not the same. (I believe I did the rebase correctly)
How can I make the correspondance ghidra -> x64dbg and break in x64dbg at the "same place" ie., same instructions ?
ret-sync allows to add a breakpoint directly from ghidra (to x64dbg) with F2:
https://github.com/bootleg/ret-sync#ghidra-usage
However, this does not work with ret-sync being built in release, only in debug version. This is a bug.
For manual rebase+jump, from x64dbg it is possible to enter the offset (current offset - base offset) in expression in x64dbg calculator, and ask follow in disassembler to jump directly to the offset. One can calculate an expression that does a rebase or a more complex function (eg., offset + sizeof X * Ntimes).
If the final offset is known, another way to jump to the desired offset in x64dbg is ctrl+shift+g (go to file offset), if the desired module is in the CPU disassembly. If not, one need to go to symbols, and follow the module of interest in the CPU disassembly and then go to file offset.
You said you wanted to go to 328b4 but your second snippet is at ...32B4 and looks like you ended up in the middle of an instruction. I would expect the correct address to be 0x00007FF8B2F81000 + 0x328b4 = 0x7ff8b2fb38b4.
I am not aware of ret-sync supporting setting breakpoints, but you can do the address translation more easily by either getting the relative offset by hovering
Source: https://twitter.com/dev747368/status/1347360276476293125
and then adding the x64dbg offset of 00007FF8B2F81000 to offset (2008h in the screenshot, in your case 328b4h )
Or you can script this by running currentAddress.subtract(currentProgram.imageBase) in the shell to get the relative offset for the current address (again 328b4h in your example) and then adding the x64dbg offset. So the complete command would be: currentAddress.subtract(currentProgram.imageBase).add(0x00007FF8B2F81000)
Run this in the Python REPL and the correct x64dbg address for the current address should result.
I have been working on some device that allowed login via telnet and I extracted some data from devices and made some reports, without any problems. recently, I had to switch to SSH while rest of the script is all the same, only login procedure has been changed from telnet to SSH. after switching to SSH, I am facing some problem with the data extracted that there are some invalid characters in some of the lines, below is an example: as can be seen, there is an invalid character after PON7 in the line:
OLT:LT6.PON7.ONT1,ALARM,Date time,
problem is that this invalid character is not even visible in the bash/csv file, but it was discovered when I copied the line in notepad++ or while posting it here.
now I have two problems:
1st: if someone knows what is causing these invalid characters while switching between telnet/ssh.
2nd: how to deal with this invalid character in BASH as it is not even visible in BASH, but this report is being used somewhere and these invalid characters are causing problems.
Edit:
Pasting the text into a text-to-hex converter produces this:
4f 4c 54 3a 4c 54 36 2e 50 4f 4e 37 11 2e 4f 4e 54 31 2c 41 4c 41 52 4d 2c 44 61 74 65 20 74 69 6d 65 2c
It looks like there's a DC1 character (hex 11) between the "7" and the ".".
Unfortunately, this edit also has the side effect of removing the character from the sample text.
Passing your text through a text to hexadecimal converter shows that the invisible character is an ASCII DC1 character (hex 11, octal 021). This character is also known as Ctrl-Q or XON. It's sometimes used in flow control.
In a bash script, you could filter it out using the tr program:
echo $badtext | tr -d '\021'
SSH doesn't inherently insert DC1 characters into text streams. If you're getting a DC1 character in the output from a device, presumably the device sent that character.
Most high-level representations of files are as streams. C's fopen, ActiveX's Scripting.FileSystemObject and ADODB.Stream - in fact, anything built on top of C is very likely to use a stream representation to edit files.
However, when modifying large (~4MiB) fixed-structure binary files, it seems wasteful to read the whole file into memory and write almost exactly the same thing back to disk - this will almost certainly have a performance penalty attached. Looking at the majority of uncompressed filesystems, there seems to me to be no reason why a section of the file couldn't be read from and written to without touching the surrounding data. At a maximum, the block would have to be rewritten, but that's usually on the order of 4KiB; much less than the entire file for large files.
Example:
00 01 02 03
04 05 06 07
08 09 0A 0B
0C 0D 0E 0F
might become:
00 01 02 03
04 F0 F1 F2
F3 F4 F5 0B
0C 0D 0E 0F
A solution using existing ActiveX objects would be ideal, but any way of doing this without having to re-write the entire file would be good.
Okay, here's how to do the exercise in powershell (e.g. hello.ps1):
$path = "hello.txt"
$bw = New-Object System.IO.BinaryWriter([System.IO.File]::Open($path, [System.IO.FileMode]::Open, [System.IO.FileAccess]::ReadWrite, [System.IO.FileShare]::ReadWrite))
$bw.BaseStream.Seek(5, [System.IO.SeekOrigin]::Begin)
$bw.Write([byte] 0xF0)
$bw.Write([byte] 0xF1)
$bw.Write([byte] 0xF2)
$bw.Write([byte] 0xF3)
$bw.Write([byte] 0xF4)
$bw.Write([byte] 0xF5)
$bw.Close()
You can test it from command line:
powershell -file hello.ps1
Then, you can invoke this from your HTA as:
var wsh = new ActiveXObject("WScript.Shell");
wsh.Run("powershell -file hello.ps1");
Good afternoon.
I am running pcl6.exe version 9.15 on Windows 8.1.
I am running into a problem where pcl6.exe in silently converting any APOSTROPHE characters into RIGHT SINGLE QUOTATION MARK characters using the 16602 typeface in a PCL5 file.
Here is the command line I am using:
pcl6.exe -dNOPAUSE -sDEVICE=txtwrite -sOutputFile=test.txt test.prn
test.prn input (hex)
1B 28 30 55 1B 28 73 31 70 31 30 76 31 36 36 30 32 54 1B 26 61 30 76 30 48 3E 27 3C
test.prn input (text ['.' is the escape character])
.(0U.(s1p10v16602T.&a0v0H>'<
test.txt output (hex)
20 20 3E E2 80 99 3C 0D 0A
test.txt output (text)
>’<..
expected test.txt output (hex)
20 20 3E 27 3C 0D 0A
expected test.txt output (text)
>'<..
Is there a flag or an option somewhere that can disable this conversion?
Thank you for your time.
txtwrite does the best it can with the input, PCL tends not to have much information in the PCL file to allow us to determine what the glyph should be (PostScript is better, and PDF often still better).
If you think there is a real problem I would suggest your best bet is to open a bug report. Apart from anything else, I would need to see the PCL file to determine what's going on. Most lkely the character code you are using corresponds to an apostrophe, which in the specific font is a right quote. There is no way for the text extraction device to know what shape the font will draw in response to a character code. At least, not in PCL
The problem was caused by the symbolset.
The sample was using the PCL ISO 6: ASCII symbolset (code 0U )
http://www.pcl.to/symbolset/pcl_0u.pdf
According to the 0U symbolset reference, APOSTROPHE (0x27) is replaced with RIGHT SINGLE QUOTATION MARK (0x2019). Pcl6.exe then converts these UTF-16 bytes into their UTF-8 equivalent: 0xE28099