There are status bits, which "set" the type of the next busoperation at the 80x86.
Is there any possibility to read those statusbits from any register? If so which one?
thank you!
I know now that you can not get any information about those status bits from a register.
Related
I'm currently tuning some code written for an STM32F070, where we use one byte on user option byte to keep some flags between Resets, using:
FLASH_ProgramOptionByteData(ADRESSE_OPTION_BYTE_DATA0, status_to_store);
Reading carefully the datasheet from our new STM32F446 lets me think that it is no longer possible to use option bytes to store one user byte...
1 - Am I Right with this assertion ? If not, what did I miss ?
2 - Is there some workaround, not involving to rewrite a sector of the flash ?
I am not an expert on stm32, rather still a beginner, but maybe you could have a look on the RTC backup register to hold your data ?
I don't make sure, but I think the ScadaLTS no have the modbus 16 function. I need write in 9 registers simultaneously, but the data type that ScadaLTS give does not satisfy my need. I did try to use the type data "fixed length string" but I can't represent the code 0 in ASCII, if I could, it would work.
Finally, I hope to find help and thank you very much in advance.
Modbus function 16 is writing multiple holding register address at once, we cannot write it one by one, and must use fc 16 code. But there is no option to write to multiple address at modbus datapoint. I need this feature also,
I'm working on some shellcoding, and have this weird result on my Windows VM. The idea is, starting from Zero, carve out some value. In this case, I need that the value is equals to: 0x50505353
(gdb) print /x 0 - 0x38383536 - 0x77777777
$1 = 0x50505353
In Python, GDB, OSX, Linux and everything else, this operation works as expected. On the Windows VM, when I perform the PUSH on OllyDBG or Immunity the result is: 0x52535051
So the question is, WHY? What I'm missing here?
This is the operation done in ASM:
AND EAX,65656565
AND EAX,1A1A1A1A
SUB EAX,38383536
SUB EAX,77777777
PUSH EAX
The first couple of AND transform EAX = 0x00000000. Then I can subtract from that. Just to be clear, I cannot use XOR on this test.
This is because you are not subtracting 0x38383536, you are subtracting 0x36353838, which gives the result you stated.
I just found the problem. When I do the calculations outside the Debugger, forgot the small detail that in order to use them in the shellcode, I should use the same values in reverse Endian Order.
Mental note: Always remember to check the order that you are working.
Thanks to all.
To be clear, are you saying error happens on the gdb command line as well as in your windows VM program? If gdb is giving rubbish then something is wrong with the VM.
Do you have gdb or another debugger working on the Windows VM? I'm a little confused about your runtime environment where you are seeing the error
If you have gdb where the error is occurring then here is how to debug.
If it is the program only then use stepi and info regs to see what is going on. The value of $eax before that last subtraction is likely the one of interest but check each instruction. If $eax has the correct value at the push then look around $sp in memory for the value. If it is still correct then follow the return from the function and look for the corresponding pop or stack read and check the value there. Perhaps the stack is getting corrupted before you actually print/use the value?
Calling editbin for a dll with the options /swaprun:CD and /swaprun:NET changes the PE header word of the dll, setting bits $0400 and $0800 (so actually it only changes the high byte).
That's what it is supposed to do.
But it also changes another byte (see hex comparison).
Can anybody explain to me what this byte means and why it is being changed?
edit: To clarify:
editbin with these options is supposed to set the
IMAGE_FILE_REMOVABLE_RUN_FROM_SWAP and IMAGE_FILE_NET_RUN_FROM_SWAP bits in the PE header's Characteristics field (which is a 16 bit word). This is the first byte I am talking about. None of these flags is stored in the second byte, so why does the tool change more than necessary and what does it mean?
IMAGE_FILE_HEADER.Characteristics |= IMAGE_FILE_REMOVABLE_RUN_FROM_SWAP|IMAGE_FILE_NET_RUN_FROM_SWAP;
So 0x2122 -> 0x2d22 (=2122|0x0c00)
And
IMAGE_OPTIONAL_HEADER.CheckSum is changed from 0x000a3c31 to 0x000a4831
Test platform is windows 32bit.
I use IDA pro to disassemble a PE file, do some very tedious transform work, and re-assembly it into a new PE file.
But there is some difference in the re-assembled PE file and the original one if I use OllyDbg
to debug the new PE file (although there is no difference of this part in the assembly file I transformed)
Here is part of the original one:
See the
PUSH 8
PUSH 0
is correct.
Here is part of my new PE file:
See now the
PUSH 8
PUSH 0
is changed to
66:6A 08
66:6A 00
and it lead to the failure of the new PE's execution.
Basically, from what I have seen, it lead to the un-align of stack.
So does anyone know what is wrong with this part? I don't see any difference in the assembly code I transform....
Could anyone give me some help? Thank you!
66h is the operand-size override prefix. In 32-bit code, it switches the operand size to 16-bit from the default 32-bit. So what happens here is that the PUSH instruction pushes a 16-bit value on the stack instead of the 32-bit one, and the ESP is decremented by 2 instead of 4. That's why you get unbalanced stack after the call.
You should check your assembler's documentation to see how you can force 32-bit operand size for the PUSH imm instructions. Different assemblers use different conventions for that. For example, in NASM you'd probably use something like push dword 8.
It is a "prefix" opcode byte: See http://wiki.osdev.org/X86-64_Instruction_Encoding#Legacy_Prefixes
0x66 means "operand size override". Your code is apparantly operating in 32-bit mode; PUSH without the prefix will push a 32 bit value. I think what this does is cause the PUSH to fetch a 16 bit value, and push that as a 32 bit value on the stack. (I write a lot of assembly code, and have never had need to do that).