Does anyone know if there is a library that provides the functionality to obtain a processes base/load address? I would like to programmatically add breakpoints using Ragweed, however I only have the breakpoint offsets exported from IDA. The only thing I could find was:
Getting process base address in Mac OSX
Via Ragweed (https://github.com/tduehr/ragweed)
x = Ragweed::Debuggerosx.new(pid)
x.attach
puts x.region_info(0).base_address
Related
I am trying to use COM RS232 serialport-rs example receive_data and it only works on Mac or and Linux. It does not work on Windows 10. The example is blocked waiting for data and not receiving anything.
If I open the COM port with Arduino's serial monitor I see data coming into the PC's port, but Rust's serialport-rs example does not seems to receive anything. Anybody else have the same issue?
Library sources for reference https://gitlab.com/susurrus/serialport-rs
I know you might've found your issue but figures I'll post it anyway. You might need to change your flow control. I encountered this exact issue and I had to change my flow control to hardware control.
let mut final_port = serialport::new(&port_str, 115_200)
.timeout(Duration::from_millis(1000))
.open().expect("Failed to open port");
final_port.set_flow_control(serialport::FlowControl::Hardware).unwrap();
Description of goal:
I'm trying to get matlab to determine if the computer is running windows, or mac. My main goal for this is to write a robust script to determine what serial ports are available, and USB ports (for the same reason) to identify which is an Arduino.
Current work:
I have a script that queries the registry on Windows and successfully identifies this information. However, I'm trying to make this script robust and identify for both mac and windows.
Request:
If there is a better way to do this in matlab? And how do I do it robustly, hopefully independent of OS if possible, or if not, how do I do this on a Mac! Note, (instrfindall) only identifies objects to ports, which are therefore already open. So it is sadly not a solution.
EDIT: I can determine if it's MAC or WINDOWS via ismac, and ispc calls. However, the main guts of this question still remains!
Even easier. MATLAB has a method to flag each OS without going to the level of CPU architecture.
if ismac
% Code to run on Mac platform
elseif isunix
% Code to run on Linux platform
elseif ispc
% Code to run on Windows platform
else
disp('Platform not supported')
end
Note: I am a MathWorks employee.
The MATLAB command you need to identify OS is computer
For example, on a Mac:
>> computer
ans =
MACI64
The command from inside MATLAB is computer. The following returns the value MACI which is for Mac OS X (Intel):
>> c = computer;
>>
c =
MACI
>>
Type help computer for more.
This is simple.
You need to use the function ispc. The reference is http://www.mathworks.com/help/matlab/ref/ispc.html.
Returns 0 if Mac and 1 if Windows.
Serial port:http://www.mathworks.com/help/matlab/serial-port-devices.html. Read up on this.
If you have instrument control toolbox you may check the
instrhwinfo function to get available serial ports.
If not I would suggest to go to system command.
For example, on windows you may parse output of the mode command:
[status,cmdout] = system('mode');
Variable cmdout will contain something like this:
Status for device CON:
----------------------
Lines: 2048
Columns: 200
Keyboard rate: 31
Keyboard delay: 1
Code page: 866
for each device like serial ports and LPT ports.
I'm not MAC user, but I suspect you may find something similar there too.
UPD1
I do not think that this way you can distinguish between real serial ports and USB-to-serial adapters, but it should give you list of available serial ports at the moment you call the mode function.
Im development an app for OSX that will check the status of a MAC. I would like check:
Memory in Hard Drive
Memory Ram
OS System...
Does anyone know how I can access these parameters?
Thanks for all!
Best Regards.
Apple's already written that app. It's called System Information.
There is a command-line version of the app, called system_profiler. You can make it print out the information in XML for easy parsing.
The simplest way to get lots of information about the Mac programmatically is by running system_profiler as a child process and parsing its output. You will want to look at using NSTask and NSXMLParser.
For my current embedded application I am trying to put GDB watch point at a fixed memory address.
As an example, my application updates the following address: 0x10793ad0. In order to be sure which part of the code is corrupting the value, I tried
watch 0x10793ad0
Even though GDB does not print any error after this, it is not able to break during execution even though I verified the value is getting modified at between start and end of execution.
Questions:
Can I really put watch at a fixed address? I didn't come across any such example online.
Is this the right way or am I missing something?
The right way to set watchpoint on address is watch *0x10793ad0. See gdb doc
I'm debugging an intermittent problem in which an application (created using C++ in Visual Studio 2005) is faulting. The event log provides the following information:
faulting module msvcr80.dll
version 8.0.50727.1433
fault address 0x00008aa0
I did a Google search and found many other examples of applications crashing with this particular fault address, but no indication of what it means.
Is there any way to find out what msvcr80.dll is doing at this address?
I tried attaching to a running instance of the application from Visual Studio to see what code is located at 0x00008aa0 -- but there doesn't seem to be anything there!
More generally, given an address somewhere in a Windows DLL, is there a way to figure out what the code is doing?
Windows will never map anything to addresses lower than 0x10000, so you are definitely AV'ing.
Googling myself, someone suggested using dependency walker to find out which module you're using that is directly dependent on msvcr80.dll -- since you are using VS 2005.
That might give you a clue where to start isolating the bug.
Address this low usually indicates a null pointer access violation. The offset of the member access accessed to the base pointer is 8aa0. Looks like a pretty large object. I would suggest you add null-asserts when you dereference pointers to objects of large data type.
You can try to use Microsoft debug symbols, in this case you will see normal function name instead of address.
In VS2005 you should do:
Go to Tools -> Options -> Debugging -> Symbols
Insert http://msdl.microsoft.com/download/symbols as a symbol location
Attach VS to your app instance and repeat the crash