I have installed a virtual open channel SSD on qemu and am trying to figure the LBA and the corresponding PBA mapping.
I have already gone through different documentation and successfully found the LBA for any file through fibmap API.
However, to find the physical address mapped on the SSD I have to use PBLK where I can find the L2P_MAP. Unfortunately, I can't find that file since it's never generated by my PBLK instance. I am not really sure what's the problem.
My question is : Is there any way to find this LBA to PBA mapping with/without using PBLK?
I would really appreciate any help or suggestion.
Thank you
Related
I know that UBIFS' superblock (starting point) is situated at LEB 0.
but how does kernel (or U-boot) knows where to look at?
I've heard that UBI volume maps PEB and LEB randomly, but I think user should know where physical entry point is located.
I couldn't find any explanation in Google.
please help. thank you.
This is by no means a "give me the solution" question, but more to gain a higher understanding. Please feel free to point to references where I can learn more about this, I've tried searching and all I get are how to's for setting up and accessing network drives.
I want to be able to monitor a file on a windows machine, but the file sits on a shared drive hosted locally. If it is manipulated by another machine, is there a process I can look for that will indicate that the file may be accessed by a resource elsewhere on the network? I understand that the host machine must be available in order to access the file in the first place, but what processes are called to actually manipulate the file. Is this below the OS level? I have access to a minifilter driver that I can ask a more experienced developer on the team to help me with if need be.
I want to upgrade my systems in the field using the uboot FIT images.
My system is a custom firmware, booted by uboot. So far the FIT filesystem works very good. It provides a shasum verified upload. I am using uboot scripts to update stuff on the target.
One intriguing type defined in uboot docs is type "filesystem". The actual content could be several things, like maybe tar'ed bunch of files, or an actual collection of separate individual files in one chunk in the FIT.
In another FIT question, Tom Rini implied that a filesystem is really just a binary blob. What goes into it is my problem and that uboot could then just mmc write ... or usb write ... to create the new filesystem on some partition. Is this really the case?
How can I build a filesystem (say FAT), on a host build computer for packaging with FIT?
Thanks, Steve
The creation of a filesystem image will depend on the filesystem itself. In many cases, build systems such as OpenEmbedded or buildroot can help you here as they will create the images for you.
how to get harddrive serial number(not the volume # wich change at each reinstall of windows) in C or asm, without wmi (cause wmi required admin right). Any clue would be helpfull cause right now i found nothing on web in C without wmi, in dayss of searching... Thank you.
EDIT : For windows system
Please try my open source tool, DiskId32, which also has the source code at http://www.winsim.com/diskid32/diskid32.html . I only have an Win32 version at this time. Maybe some day I will add a Win64 version.
Hard drive serial number and other information about the harddrive like firmware version, etc. can only be obtained using SMART as far as I know and that requires special ioctls to the the block device node (/dev/sda or /dev/sdb) which is usually not available to a regular user.
I know there is a tool called smartctl which does exactly this:
sudo smartctl -i /dev/sda
Similar tools exist (hdparm, lshw, etc.) as well.
As far as trying to figure it out this info without being a privileged user, it might be possible only if it is exposed via /proc or /sys which I highly doubt is being done in the current SATA block device drivers.
I am new to device driver programming. I've followed the available tutorials on the web which has provided helpful information to get started. However now I have embarked on a new project where the exclusive goal is to search for functions which have been hooked by malware or keyloggers. So I think I have sorted out what I need to accomplish this though I still need to be able to locate the load address of the system dll's (i.e. kernel32.dll, user32.dll and the like) that are already loaded in memory. I need the load address so that I can parse their PE to get to the export and import sections. Furthermore adding the load address to the file size will give me a address range to cross reference the addresses of the export functions no ? Cross referencing the the IMPORT address will be a little more involved but it can be done according to my estimates. I thought that building a kernel mode driver would be the right way to go since accessing memory outside the kernel driver's address range would not be an issue for the driver as opposed to a user mode app. How else will I be able to access the addresses located in the EAT and IAT of the target dll ? I know there exist a user mode API that can provide the load address mainly being GetModuleHandle but I would like to find the equivalent in kernel mode. I could write a user mode application that could relay this information to the driver but prefer that this all be done in kernel mode if possible. Any suggestions or comments would be most welcome.
Thanks in advance
Victor
p.s This post has been edited for more clarity. Hopefully it will make it more clear as what I am trying to accomplish.
This is probably not a very good idea to do in kernel mode. When are you going to actually do this and guarantee the process is in a state where you could walk the IAT?
What if the process is in the middle of loading a DLL? If you're executing in-thread (i.e. from a syscall or device IOCTL), what if other threads are executing too? Doing this when you're not the OS is a very difficult proposition to correctly do, and it's very easy to destabilize your customers' machines (hell, it's reasonably hard to do even if you are the OS)
Take a look at LdrGetProcedureAddress and the rest of the gang.
Edit:
MmGetSystemRoutineAddress might also be helpful.
Just wanted to thank everyone for their contribution. I did manage to some further research and discovered that there is a kernel mode API called PsLoadImageNotifyCallback that is able to find the base addresss of any process.