So I'm learning x86 and to do that I've chosen to do so alongside understanding how to hook functions. I already have a pretty good understanding of C++ so thats the language I've chosen to do it in. At the moment I have a jump which jumps to my trampoline but its currently erroring saying the code references memory at 0xFFFFFFFFFFFFFFFF but I can't see where that is
This is the code that its saying its erroring at (Using IDA as my disassembler/debugger)
FF 25 8A B9 FD FF jmp qword ptr cs:unk_7FF8C3700000
This jump is based on a displacement of 0xfffdb98a (-149110)
The code at 07FF8C3700000
48 B8 90 10 20 B8 F8 7F mov rax, 7FF8B8201090h
FF E0 jmp rax
48 89 5C 24 10 mov [rsp+10h], rbx
48 89 74 24 20 mov [rsp+20h], rsi
FF 25 74 46 02 00 jmp qword ptr cs:loc_7FF8C372468A+6
The first jump is too my hooked function, The two mov are the damaged instructions from overriting with my jmp hook and the last jump is back to the original function just past my added jump/hook. However going off IDA it isnt even reaching my trampoline its just not able to execute my jump to my trampoline
Related
I'm currently trying to interface a cs5530 ADC to a raspberry pi 4b 8g using SPI. When I attempt to communicate with the ADC I repeatly get return bits that make no sense and am running out of ideas to trouble shoot. When using the Spidev-test script I'm recieving the following response:
spi mode: 0x4 bits per word: 8 max speed: 2000000 Hz (2000 KHz)
TX | FF FF FF FF FF FF 40 00 00 00 00 95 FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF F0 0D
RX | FF FF FF FF FF FF FF F8 00 00 00 27
F8 00 00 00 27 F8 00 00 00 27 FF FF FF FF FF FF FF FF FF FF
As you can see there's something causing the MISO line to be recieving incorrect bits. If I use a jumper from MOSI to MISO to the bits return as should be expected. I've tried different clk speeds while staying under 2MHz as that is specified as the max clk speed in the cs5530 data sheet. I'm also recieving similar junk back using the spidev libary in python.
I'm thinking the most likely problem I have is for some reason the clk on the rpi isn't producing a proper signal. I don't own a logic analyser (thinking I'll properlly have to order one) so I've mapped the signal the best I can using piscope.
this image shows what looks like to me the clk line not functioning as you should expect.
I'm a novice at this sort of thing but it looks to me that the clk line is all over the show instead of regular sine wave you'd expect to see there. I'm not sure if this is what's casuing me issues or if it's due to the limitations of piscope.
this image also shows similar behaviour happening when I'm shorting MOSI and MISO to test the lines.
So while I think I've found the cause of my issues I'm about out of ideas of what could be causing this issue and how to fix it. So far all the things I've tried when trying to troubleshoot this is:
Swapping out Raspberry Pi's - Problem presists exactly the same.
Swapping out cs5530
checked all my solders on the prototyping board and continuity between all points, test resistor values and cap's are all at correct values. Swapped crystals due to not having a scope to test it.
Tested the cs5530 at both 3v and 5v modes (using an external power supply)
Grounded rpi to external power supply
Tried running a cs5530 off rpi 3.3v supply
set core_freq=250 on rpi
set dvfs=2 to rpi to prevent any issues caused by core being under voltaged
tested on spi0 (CE 0 and 1) and spi1
temp was 53 degrees when the tests in the pictures where done so I think I can rule out thermal throttling as well. At this point I'm completely out of ideas what else to try. Might be worth noting that I am booting off a high quality 16gb USB flash drive, I haven't bothered coping the img to a sd card just yet as I wouldn't have thought that this would be causing any problems but I might try it just to fully rule that possiblity out.
link for cs5530 datasheet : Cs5530 Datasheet
Thanks in advance for any help, hoping that there's someone much smarter than me out there that can shine some light on this for me.
Cheers
For my assembler, I want to encode the operation mov eax, [addr]. In 64 bits this would only possible using a SIB byte, as the mod r/m combination 00 101 was changed to indicate rip-relative addressing. The problem I find is that, in 32 bits, encoding this instruction using a SIB byte doesn't work. For example I have:
8B 84 25 1C FE 43 00
(mov) (10 000 100) (00 100 101) (address)
but disassemblers don't seem to accept it, I get:
mov eax,DWORD PTR [ebp+eiz*1+0x43fe1c] (defuse.ca)
mov eax, ss:off_43FE1C[ebp] (ida)
and when the instruction is executed it generates an exception. I know that there is the shorter encoding in 32 bits, but don't understand what's wrong with the longer one.
I'm trying to turn my raspberry to an iBeacon but I cannot make it transmit with lower power, I've changed Tx power many times, when I use my BLE scanner I see that Tx power has changed but RSSI hasn't at all while with other beacon devices changing transmission power leads to a lower powered measure. Has anyone had the same problem? this is the command that I run.(I've changed C8 to 88, CE, E7 and etc.)
sudo hcitool -i hci0 cmd 0x08 0x0008 1E 02 01 1A 1A FF 4C 00 02 15 63 6F 3F 8F 64 91 4B EE 95 F7 D8 CC 64 A8 63 B5 00 00 00 00 C8
The byte you are changing does not control the strength of the output of the transmitter. That byte is referred to by either "tx power" or "measured power". There latter term is more accurate. It is used to communicate to receivers what the expected rssi should be at a range of 1 meter to aid in distance estimates. Again, changing it does not actually change the strength of the transmitter.
Unfortunately, there is no API in the raspberry Pi to alter the strength of the Bluetooth transmitter.
I have those 3 Events in a Midi file:
00 FF 51 03 0E 15 C3 86 A6
20 FF 51 03 15 20 A5 83
5C FF 51 03 0E 15 C3
But what is, in this case, important is, that FF 51 stands for a Tempo Change and the 03 for the number of following Byte-Pairs describing the tempo. As it is "3 Byte Pairs" in Each Event Why are there 5 Byte Pairs describing the first Event, 4 describing the second, and 3 describing the third? (I hope the image helps)
How does the encoding program know, when a new Event starts? The File can be played without any Problems.
All three events have three data bytes.
The delta times between the events are encoded as variable-length quantities, so you have to continue to read bytes until the most significant bit is clear. The three times before each event are 00, 86 A6 20, and 83 5C, resulting in the decoded delta times of 0, 109344, and 476.
In his famous blog post The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!) Joel said :
The earliest idea for Unicode encoding, which led to the myth about
the two bytes, was, hey, let's just store those numbers in two bytes
each. So Hello becomes
00 48 00 65 00 6C 00 6C 00 6F
Right? Not so fast! Couldn't it also be:
48 00 65 00 6C 00 6C 00 6F 00 ?
The second representation is faster ? why ?
How does swapping the high and low bytes affect performance ?
The sentence "Not so fast!" isn't about computing performance but a way to say "hey, don't make assumptions so fast, here's another way to look at it".
The question is Mu.