I have an existing executable for which a small amount of source code has been lost. In particular, the executable uses a few functions from a static library, and the source code for that library is missing. I do have an older version of that library's code, but the executable uses three or four methods that aren't in the old version. I have a header file for the new version of the code, which includes prototypes of the missing functions, but the .c file containing the actual function definitions is missing. Since the executable is statically linked, I wonder if there is a way to rebuild the static library by extracting the object code from it. I can find the symbols I need using nm and objdump, but I don't know if there's a way to extract those functions and re-package them into object files or a static library. As an example, it looks something like this:

$ nm ./theApplication

001721dc T _missingFunction1

00171ed8 T _missingFunction2


$ objdump --disassemble-all ./theApplication

00171ed8 :
  171ed8:       1a e5 f8 14     P2 = [P3 + 0x53e0];

001721dc :
  1721dc:       c5 04           [--SP] = (P5:5);

I'd like to pull missingFunction1() and missingFunction2() out into a static library or object files so I can link against them in other executables. Is that possible, and if so, how can it be done?

I am learning the elf file format for Android, but I have found that some elf files can specify the loader through the interpreter path in the program header. However, the elf test file I wrote myself through Android Studio does not have this attribute. What is the reason for this? In elf files with an interpreter path, I can specify my own loader linker to get an earlier elf debugging time, but now many files do not have an interpreter path. Is there any other alternative?

I Am very confused because I am trying to understand the architecture without documentation,we have a NFS architecture of a cluster of PCs that share the same home directory ( Server1 is a Pc of a cluster ) and every user has a home in the Server 2 used for a specific purpose from the users. I've collected the following information from both servers: Server 1: Output of cat /etc/exports > /disk28 172.16.13.115(rw) 172.16.13.114(rw) ....etc Output of showmount -e N/A cat /etc/fstab > 172.16.15.20:/disk38 /disk38 nfs defaults,bg,rw 0 0 172.16.15.17:/disk36 /disk36 nfs defaults,bg,rw 0 0 ...etc Server 2: Output of cat /etc/exports >/home 172.16.14.86(rw) 172.16.37.221(rw) 172.16.11.30(rw) 172.16.11.51(rw) 172.16.37.222(rw) 172.16.37.219(rw) 172.16.37.253(rw) 172.16.10.154(rw) 172.16.11.219(rw) 172.16.12.16(rw) 172.16.12.20(rw) 172.16.12.32(rw) 172.16.12.40(rw) 172.16.12.125(rw) 172.16.12.126(rw) 172.16.12.127(rw) ...etc Output of showmount -a >All mount points on a.server: 172.16.11.219:/home 172.16.11.30:/home 172.16.11.51:/home 172.16.12.125:/home 172.16.12.126:/home 172.16.12.127:/home ...etc cat /etc/fstab >/dev/VolGroup00/LogVol00 / ext3 defaults 1 1 LABEL=/boot /boot ext3 defaults 1 2 none /dev/pts devpts gid=5,mode=620 0 0 none /dev/shm tmpfs defaults 0 0 none /proc proc defaults 0 0 none /sys sysfs defaults 0 0 /dev/VolGroup00/LogVol01 swap swap defaults 0 0 /dev/hda /media/cdrom auto pamconsole,fscontext=system_u:object_r:removable_t,exec,noauto,managed 0 0 Now, I'd like to comprehend how these servers are configured to share the home directory and how the interaction between the cluster PCs and these NFS servers works. What specific details should I be looking for in these outputs to get a complete picture of the NFS architecture? Thanks in advance for any help or insights you can provide. I'm willing to share the full outputs if needed.

After finding out that several common commands (such as read) are actually Bash builtins (and when running them at the prompt I'm actually running a two-line shell script which just forwards to the builtin), I was looking to see if the same is true for true and false. Well, they are definitely binaries. sh-4.2$ which true /usr/bin/true sh-4.2$ which false /usr/bin/false sh-4.2$ file /usr/bin/true /usr/bin/true: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=2697339d3c19235 06e10af65aa3120b12295277e, stripped sh-4.2$ file /usr/bin/false /usr/bin/false: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=b160fa513fcc13 537d7293f05e40444fe5843640, stripped sh-4.2$ However, what I found most surprising was their size. I expected them to be only a few bytes each, as true is basically just exit 0 and false is exit 1. sh-4.2$ true sh-4.2$ echo $? 0 sh-4.2$ false sh-4.2$ echo $? 1 sh-4.2$ However I found to my surprise that both files are over 28KB in size. sh-4.2$ stat /usr/bin/true File: '/usr/bin/true' Size: 28920 Blocks: 64 IO Block: 4096 regular file Device: fd2ch/64812d Inode: 530320 Links: 1 Access: (0755/-rwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2018-01-25 19:46:32.703463708 +0000 Modify: 2016-06-30 09:44:27.000000000 +0100 Change: 2017-12-22 09:43:17.447563336 +0000 Birth: - sh-4.2$ stat /usr/bin/false File: '/usr/bin/false' Size: 28920 Blocks: 64 IO Block: 4096 regular file Device: fd2ch/64812d Inode: 530697 Links: 1 Access: (0755/-rwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2018-01-25 20:06:27.210764704 +0000 Modify: 2016-06-30 09:44:27.000000000 +0100 Change: 2017-12-22 09:43:18.148561245 +0000 Birth: - sh-4.2$ So my question is: Why are they so big? What's in the executable other than the return code? PS: I am using RHEL 7.4

I am trying to understand what is written here and how it can be done. Maybe someone will be able to help and understand this: https://forum.videohelp.com/threads/306345-some-problem-with-DVR560H-s-HDD-replacement#post1906393 This is probably a method to remove the disk size limit that a DVD writer can use after initialize HDD, prevent to change hdd to bigger size. GGV disc: https://archive.org/details/pioneer-ggv-1321-type-2 This iso must be burn on dvd disc and loading in dvd recorded to initialize new HDD. Question is how **"remark* reCompile Kernel and rc.local edit it GGV disk"**. Thank you.

I want to learn reverse app, I'm confused how to dump network of an app, I tried tcpflow, ngrep, etc. it works but the output data is not human readable, can you give me a linux command to get network receive / send data, from an app / hosts? i try this

sudo ngrep -W byline port 80

ouput

interface: wlp1s0 (192.168.230.0/255.255.255.0)
filter: ( port 80 ) and ((ip || ip6) || (vlan && (ip || ip6)))
####
T 192.168.230.135:29464 -> 91.108.56.124:80 [AP] #4
POST /api HTTP/1.1.
Host: 91.108.56.124:80.
Content-Length: 148.
Content-Type: application/x-www-form-urlencoded.
Connection: Keep-Alive.
Accept-Encoding: gzip, deflate.
Accept-Language: en-US,*.
User-Agent: Mozilla/5.0.
.
.............g[c....x.F$..>o-...O:2..3ib.W.q.._.,.)1.....k.........!..z...M^.g^...I.p...5.yx.Ys...Y*.m.. ....w...uK.%..0....~.f.&...Q..br..W...3..

which is easy to read like a regular text string?

Is it possible to reverse engineer PCI drivers for a device which has none? The device in question was a PCI ESCON card that allowed you to connect a mainframe ESCON channel to a specialty unix computer. As far as I know, this device never had any drivers released publicly, but still uses a standard PCI bus. Would it be possible to put together drivers without having an existing set to reverse engineer? Any info would be appreciated.

Unfortunately I lost my source code and I just have the output file that made with gcc in linux and I don’t have any access to my pc now.is there any way to convert output file to source file (in c under linux)?

Commonly for arm systems, *device trees* supply hardware information to the kernel (Linux). These device trees exist as dts (device tree source) files that are compiled and loaded to the kernel. Problem is that I do not have access to such a dts file, not even to a dtb file. I have access to /sys and /proc on the machine and I wanted to ask if that would allow me to "guess the correct values" to be used in a dts? Also potential answer could highlight additionally the aspect if the answer to this question also depends on whether the device tree interface was used in the first place (i.e. a dtb was created and provided to the kernel) instead of some more hacking "we simply divert from vanilla and patch the kernel so as to solve the device information problem for our kernel only"-solution?

This is similar to the issue posted here and here . I want to reverse engineer a binary called **gpslogger** but before debugging it using GDB, I wish to simply emulate it using QEMU (qemu-aarch64) since when I run file gpslogger I get gpslogger: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-musl-aarch64.so.1, not stripped. I start by downloading the exact interpreter file and pasting it in my Ubuntu 16.04 x86_64 /lib folder and then other errors show up asking for other .so files, e.g., libgps.so. I then download those .so files for the AARCH64 architecture and paste them in the /lib folder of my Ubuntu. Once all the .so errors, i.e., no such file or directory are gone, I'm left with

Error relocating /lib/libgps.so: __strdup: symbol not found
Error relocating /lib/libgps.so: __fdelt_chk: symbol not found
Error relocating /lib/libgps.so: __fprintf_chk: symbol not found
Error relocating /lib/libgps.so: __snprintf_chk: symbol not found
Error relocating /lib/libgps.so: __isnan: symbol not found
Error relocating /lib/libgps.so: __syslog_chk: symbol not found
Error relocating /lib/libgps.so: __vsnprintf_chk: symbol not found
Error relocating /lib/libdbus-1.so.3: __snprintf_chk: symbol not found
Error relocating /lib/libdbus-1.so.3: __vsnprintf_chk: symbol not found
Error relocating /lib/libdbus-1.so.3: __strncpy_chk: symbol not found
Error relocating /lib/libdbus-1.so.3: __vfprintf_chk: symbol not found
Error relocating /lib/libdbus-1.so.3: __fprintf_chk: symbol not found
Error relocating /lib/libdbus-1.so.3: __vsprintf_chk: symbol not found
Error relocating /lib/libsystemd.so.0: __sprintf_chk: symbol not found
Error relocating /lib/libsystemd.so.0: reallocarray: symbol not found
Error relocating /lib/libsystemd.so.0: __register_atfork: symbol not found
Error relocating /lib/libsystemd.so.0: __memcpy_chk: symbol not found
Error relocating /lib/libsystemd.so.0: __snprintf_chk: symbol not found
Error relocating /lib/libsystemd.so.0: __vsnprintf_chk: symbol not found
Error relocating /lib/libsystemd.so.0: __strncpy_chk: symbol not found
Error relocating /lib/libsystemd.so.0: __vasprintf_chk: symbol not found
Error relocating /lib/libsystemd.so.0: __open64_2: symbol not found
Error relocating /lib/libsystemd.so.0: __asprintf_chk: symbol not found
Error relocating /lib/libsystemd.so.0: __fprintf_chk: symbol not found
Error relocating /lib/libsystemd.so.0: __ppoll_chk: symbol not found
Error relocating /lib/libsystemd.so.0: fcntl64: symbol not found
Error relocating /lib/libsystemd.so.0: __explicit_bzero_chk: symbol not found
Error relocating /lib/libsystemd.so.0: parse_printf_format: symbol not found
Error relocating /lib/libsystemd.so.0: __openat64_2: symbol not found
Error relocating /lib/libgcrypt.so.20: __memcpy_chk: symbol not found
Error relocating /lib/libgcrypt.so.20: __snprintf_chk: symbol not found
Error relocating /lib/libgcrypt.so.20: __fdelt_chk: symbol not found
Error relocating /lib/libgcrypt.so.20: __vfprintf_chk: symbol not found
Error relocating /lib/libgcrypt.so.20: __memset_chk: symbol not found
Error relocating /lib/libgcrypt.so.20: __fprintf_chk: symbol not found
Error relocating /lib/libgcrypt.so.20: __read_chk: symbol not found
Error relocating /lib/libgcrypt.so.20: __syslog_chk: symbol not found
Error relocating /lib/libgpg-error.so.0: __sprintf_chk: symbol not found
Error relocating /lib/libgpg-error.so.0: __fdelt_chk: symbol not found
Error relocating /lib/libgpg-error.so.0: __vfprintf_chk: symbol not found
Error relocating /lib/libgpg-error.so.0: __memset_chk: symbol not found
Error relocating /lib/libgpg-error.so.0: __fprintf_chk: symbol not found
Error relocating gpslogger: GPSNMEA: symbol not found

Except for the last relocation error, I believe all the other functions should be implemented in glibc. Therefore, I simply downloaded the libc-2.32.so file from here for the AARCH64 architecture and pasted it in the /lib folder of my Ubuntu. However, the errors didn't go away. Please let me know if more information is needed. I appreciate any help on the issue. **Edit:** readelf -d gpslogger | grep 'NEEDED' returns: 0x0000000000000001 (NEEDED) Shared library: [libgps.so] 0x0000000000000001 (NEEDED) Shared library: [libc.musl-aarch64.so.1] Does this mean that the libc is coming from musl and is not glibc?

I have 2 packed shared libraries, the second one is probably dependent on first one. The first one is packed with UPX, and the unpacking code is in .init_proc. I have tried attaching a debugger and dumping the application in .init_proc, but i cant get to it while debugging. It just skips to the EP. And segfaults. Which is very strange. It is being loaded using LD_PRELOAD. Anoter executable has the unpacking code in the EP, but it is unknown which packer have been used to pack it. This library segfaults when i try to load it too. Also, both are prooven to work on another machine. So my question is, is there any guide to unpacking ELF executables or anything like that?

I would like to know if the ghostcat bug can be exploited through an Apache web server reverse proxy setup. This is our web server config. ServerName 192.168.178.1 ProxyPass / ajp://127.0.0.1:8009/sample/ ProxyPassReverse "^/(.*)" /sample/ ProxyPassReverseCookiePath /sample/ / I've tried to use some exploits from GitHub, but they only seem to work through the [Apache JServ Protocol](https://en.wikipedia.org/wiki/Apache_JServ_Protocol) port (8009) directly, and not through the reverse proxy (80). Does this mean that applications running behind reverse proxies are safe? Or is it possible to make use of the vulnerability, since Apache is simply forwarding all traffic to the AJP. We are also sometimes using a simple RewriteRule to redirect to the AJP RewriteRule / ajp://127.0.0.1:8009/sample/ [P] Which one is more secure?

I have a friend who has a PCI device that has no driver. Is there a command that will allow me to speak to this device without a driver? (we are trying to reverse engineer its protocols.) I will basically be fuzzing it with random data.

I'm conjecturing [SQL Server on Linux is checking /proc/self/status for TracerPID and then dying if it's not 0](https://dba.stackexchange.com/q/194205/2639) . I want to test that. Playing around, here is the strace, ... lots of stuff openat(AT_FDCWD, "/proc/self/status", O_RDONLY) = 5 fstat(5, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 read(5, "Name:\tsqlservr\nUmask:\t0022\nState"..., 1024) = 1024 close(5) = 0 rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0 rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1], [], 8) = 0 getpid() = 28046 gettid() = 28046 tgkill(28046, 28046, SIGABRT) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 --- SIGABRT {si_signo=SIGABRT, si_code=SI_TKILL, si_pid=28046, si_uid=999} --- gettid() = 28046 write(2, "Dump collecting thread h"..., 59Dump collecting thread hit exception . Exiting. ) = 59 exit_group(-1) = ? The ltrace is even more damning, thankfully they're using strstr which makes it seem *really* likely my theory is correct. strstr("PPid:\t28515\n", "TracerPid:") = nil __getdelim(0x7ffc0b7d2330, 0x7ffc0b7d2328, 10, 0x7f12f5811980) = 17 strstr("TracerPid:\t28515\n", "TracerPid:") = "TracerPid:\t28515\n" strtol(0x7f12f581840b, 0x7ffc0b7d2320, 10, 0) = 0x6f63 free(0x7f12f5818400) = fclose(0x7f12f5811980) = 0 abort( --- SIGABRT (Aborted) --- syscall(186, 6, 0, 0) = 0x6f64 fprintf(0x7f12f6ec4640, "Dump collecting thread [%d] hit "..., 28516, 6Dump collecting thread hit exception . Exiting. ) = 59 fflush(0x7f12f6ec4640) = 0 exit(-1 The last line on the file they check (with strstr) before they abort() is the line with TracerPid:, however with my /proc/self/status there are many lines after it. In order of preference, I'd like /proc/self/status to report ...stuff... TracerPid: 0 ...stuff... for this process. If that can't be achieved, I'd like it to report 0 for all processes. Is it possible to create a wrapper that changes the value of TracerPID for /proc/self/status and then exec the argument given to it resulting in it not having access to TracerPID?

I have a quick question. I have generated a ELF binary from a c code using following code: gcc -o simple simple.c Then I do objdump for that ELF binary: objdump --disassemble-all simple I have checked my directory with ls -a that there is no .o file there. My question still how objdump show me the full disassemble code? Does objdump do static analysis in the binary to cover all the code?

I recently had a task at work to understand a binary Linux program. However, the program was in binary form. I used the commands file, strings, and objdump to have a slight idea of what it was doing, and what functions it was calling. It seems the binary is compiled with debugging information. What more can I learn about it?

Is there a way to create files in /proc/ without actually writing a kernel module? This is for reverse engineering purposes, an app expects certain things in /proc/ and I do not want to write a kernel module to supply it. The app simply just reads /proc/something/some_key and expects certain/known values. EDIT: Union mount doesn't seem to work as I need a new directory, e.g. /proc/new_dir/ and some files in there and making union on top of /proc/ itself seems to break it.

I have an Asus GL503VD for which the touchpad doesn't work on linux. I tried many different distros: Arch, Debian, Ubuntu 16/17/18, Sabayon, Pop_OS, Fedora. None of them made the touchpad work so I settled with Ubuntu 18.04 and decided to debug it myself. First of, this laptop is pretty new so it will not boot without the acpi=force GRUB parameter. Secondly, it will boot to a black-screen if the module i2c-hid is allowed to load (so I had to blacklist i2c-hid). I am pretty sure i2c-hid is the driver supposed to take care of my touchpad so this is a problem probably worth looking into. The thing is when the module is allowed to load I can't even reach a terminal with a ctrl+alt+f* combo, it's just black, nothingness. From my Windows partition I could tell that the touchpad is an ELAN1200(not elantech). I tried loading the module hid-elan without any success. Out of desperation I also tried the synaptics module without any luck. Tried various x.org.conf.d configurations which only stopped my laptop from reaching Gnome DE. Tried using libinput, in vain. Tried i8042.nomux=1, i8042.noloop, i8042.nopnp, i8042.kdbreset=1, i8042.reset; none of those worked. (From what I gather, my touchpad/keyboard combo might be managed by an i8042 chip; though from the xinput output it looks more like an ITE8910 is managing the combo.) The xinput output is also what tells me the touchpad might be part of a touchpad/keyboard combo. I think the touchpad and the keyboard are one device: ITE8910 xinput output: ⎡ Virtual core pointer id=2 [master pointer (3)] ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)] ⎜ ↳ MOSART Semi. USB Device id=12 [slave pointer (2)] ⎜ ↳ ITE Tech. Inc. ITE Device(8910) id=14 [slave pointer (2)] ⎣ Virtual core keyboard id=3 [master keyboard (2)] ↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)] ↳ Power Button id=6 [slave keyboard (3)] ↳ Asus Wireless Radio Control id=7 [slave keyboard (3)] ↳ Video Bus id=8 [slave keyboard (3)] ↳ Video Bus id=9 [slave keyboard (3)] ↳ Power Button id=10 [slave keyboard (3)] ↳ Sleep Button id=11 [slave keyboard (3)] ↳ USB2.0 HD UVC WebCam: USB2.0 HD id=13 [slave keyboard (3)] ↳ Asus WMI hotkeys id=15 [slave keyboard (3)] ↳ AT Translated Set 2 keyboard id=16 [slave keyboard (3)] ↳ ITE Tech. Inc. ITE Device(8910) id=17 [slave keyboard (3)] The ouput of dmesg tells me the device is connected through USB: [ 2.408602] usb 1-8: new full-speed USB device number 5 using xhci_hcd [ 2.562105] usb 1-8: New USB device found, idVendor=0b05, idProduct=1869 [ 2.562106] usb 1-8: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 2.562107] usb 1-8: Product: ITE Device(8910) [ 2.562108] usb 1-8: Manufacturer: ITE Tech. Inc. If I lsusb I see the right device with vendor ID and product ID: Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 005: ID 0b05:1869 ASUSTek Computer, Inc. Bus 001 Device 004: ID 13d3:5666 IMC Networks Bus 001 Device 003: ID 8087:0a2b Intel Corp. Bus 001 Device 002: ID 062a:410c Creative Labs Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Note: The Creative Labs device is an external mouse. When I lsusb -vd 0b05:1869 I only see keyboard related descriptors: Bus 001 Device 005: ID 0b05:1869 ASUSTek Computer, Inc. Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x0b05 ASUSTek Computer, Inc. idProduct 0x1869 bcdDevice 0.03 iManufacturer 1 ITE Tech. Inc. iProduct 2 ITE Device(8910) iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 34 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 1 Boot Interface Subclass bInterfaceProtocol 1 Keyboard iInterface 0 HID Device Descriptor: bLength 9 bDescriptorType 33 bcdHID 1.10 bCountryCode 0 Not supported bNumDescriptors 1 bDescriptorType 34 Report wDescriptorLength 263 Report Descriptor: (length is 263) Item(Global): Usage Page, data= [ 0x89 0xff ] 65417 (null) Item(Local ): Usage, data= [ 0x10 ] 16 (null) Item(Main ): Collection, data= [ 0x01 ] 1 Application Item(Global): Report ID, data= [ 0xa5 ] 165 Item(Local ): Usage, data= [ 0x01 ] 1 (null) Item(Global): Logical Minimum, data= [ 0x00 ] 0 Item(Global): Logical Maximum, data= [ 0xff 0x00 ] 255 Item(Global): Report Size, data= [ 0x08 ] 8 Item(Global): Report Count, data= [ 0x10 ] 16 Item(Main ): Feature, data= [ 0x00 ] 0 Data Array Absolute No_Wrap Linear Preferred_State No_Null_Position Non_Volatile Bitfield Item(Main ): End Collection, data=none Item(Global): Usage Page, data= [ 0x89 0xff ] 65417 (null) Item(Local ): Usage, data= [ 0x0f 0xff ] 65295 (null) Item(Main ): Collection, data= [ 0x01 ] 1 Application Item(Global): Report ID, data= [ 0x05 ] 5 Item(Local ): Usage Minimum, data= [ 0x00 ] 0 (null) Item(Local ): Usage Maximum, data= [ 0xff ] 255 (null) Item(Global): Logical Minimum, data= [ 0x00 ] 0 Item(Global): Logical Maximum, data= [ 0xff ] 255 Item(Global): Report Count, data= [ 0x08 ] 8 Item(Global): Report Size, data= [ 0x01 ] 1 Item(Main ): Input, data= [ 0x06 ] 6 Data Variable Relative No_Wrap Linear Preferred_State No_Null_Position Non_Volatile Bitfield Item(Main ): End Collection, data=none Item(Global): Usage Page, data= [ 0x01 ] 1 Generic Desktop Controls Item(Local ): Usage, data= [ 0x06 ] 6 Keyboard Item(Main ): Collection, data= [ 0x01 ] 1 Application Item(Global): Report ID, data= [ 0x01 ] 1 Item(Global): Report Size, data= [ 0x01 ] 1 Item(Global): Report Count, data= [ 0x08 ] 8 Item(Global): Usage Page, data= [ 0x07 ] 7 Keyboard Item(Local ): Usage Minimum, data= [ 0xe0 ] 224 Control Left Item(Local ): Usage Maximum, data= [ 0xe7 ] 231 GUI Right Item(Global): Logical Minimum, data= [ 0x00 ] 0 Item(Global): Logical Maximum, data= [ 0x01 ] 1 Item(Main ): Input, data= [ 0x02 ] 2 Data Variable Absolute No_Wrap Linear Preferred_State No_Null_Position Non_Volatile Bitfield Item(Global): Report Count, data= [ 0x01 ] 1 Item(Global): Report Size, data= [ 0x08 ] 8 Item(Main ): Input, data= [ 0x03 ] 3 Constant Variable Absolute No_Wrap Linear Preferred_State No_Null_Position Non_Volatile Bitfield Item(Global): Report Count, data= [ 0x05 ] 5 Item(Global): Report Size, data= [ 0x01 ] 1 Item(Global): Usage Page, data= [ 0x08 ] 8 LEDs Item(Local ): Usage Minimum, data= [ 0x01 ] 1 NumLock Item(Local ): Usage Maximum, data= [ 0x05 ] 5 Kana Item(Main ): Output, data= [ 0x02 ] 2 Data Variable Absolute No_Wrap Linear Preferred_State No_Null_Position Non_Volatile Bitfield Item(Global): Report Count, data= [ 0x01 ] 1 Item(Global): Report Size, data= [ 0x03 ] 3 Item(Main ): Output, data= [ 0x03 ] 3 Constant Variable Absolute No_Wrap Linear Preferred_State No_Null_Position Non_Volatile Bitfield Item(Global): Usage Page, data= [ 0x07 ] 7 Keyboard Item(Local ): Usage Minimum, data= [ 0x00 ] 0 No Event Item(Local ): Usage Maximum, data= [ 0xff 0x00 ] 255 (null) Item(Global): Logical Minimum, data= [ 0x00 ] 0 Item(Global): Logical Maximum, data= [ 0xff 0x00 ] 255 Item(Global): Report Count, data= [ 0x06 ] 6 Item(Global): Report Size, data= [ 0x08 ] 8 Item(Main ): Input, data= [ 0x00 ] 0 Data Array Absolute No_Wrap Linear Preferred_State No_Null_Position Non_Volatile Bitfield Item(Global): Usage Page, data= [ 0x07 ] 7 Keyboard Item(Local ): Usage Minimum, data= [ 0x00 ] 0 No Event Item(Local ): Usage Maximum, data= [ 0xdf ] 223 (null) Item(Global): Logical Minimum, data= [ 0x00 ] 0 Item(Global): Logical Maximum, data= [ 0x01 ] 1 Item(Global): Report Count, data= [ 0xe0 ] 224 Item(Global): Report Size, data= [ 0x01 ] 1 Item(Main ): Input, data= [ 0x02 ] 2 Data Variable Absolute No_Wrap Linear Preferred_State No_Null_Position Non_Volatile Bitfield Item(Main ): End Collection, data=none Item(Global): Usage Page, data= [ 0x31 0xff ] 65329 (null) Item(Local ): Usage, data= [ 0x76 ] 118 (null) Item(Main ): Collection, data= [ 0x01 ] 1 Application Item(Global): Report ID, data= [ 0x5a ] 90 Item(Local ): Usage Minimum, data= [ 0x00 ] 0 (null) Item(Local ): Usage Maximum, data= [ 0xff 0x00 ] 255 (null) Item(Global): Logical Minimum, data= [ 0x00 ] 0 Item(Global): Logical Maximum, data= [ 0xff 0x00 ] 255 Item(Global): Report Size, data= [ 0x08 ] 8 Item(Global): Report Count, data= [ 0x01 ] 1 Item(Main ): Input, data= [ 0x00 ] 0 Data Array Absolute No_Wrap Linear Preferred_State No_Null_Position Non_Volatile Bitfield Item(Local ): Usage Minimum, data= [ 0x00 ] 0 (null) Item(Local ): Usage Maximum, data= [ 0xff 0x00 ] 255 (null) Item(Global): Logical Minimum, data= [ 0x00 ] 0 Item(Global): Logical Maximum, data= [ 0xff 0x00 ] 255 Item(Global): Report Size, data= [ 0x08 ] 8 Item(Global): Report Count, data= [ 0x10 ] 16 Item(Main ): Feature, data= [ 0x00 ] 0 Data Array Absolute No_Wrap Linear Preferred_State No_Null_Position Non_Volatile Bitfield Item(Main ): End Collection, data=none Item(Global): Usage Page, data= [ 0x31 0xff ] 65329 (null) Item(Local ): Usage, data= [ 0x79 ] 121 (null) Item(Main ): Collection, data= [ 0x01 ] 1 Application Item(Global): Report ID, data= [ 0x5d ] 93 Item(Local ): Usage Minimum, data= [ 0x00 ] 0 (null) Item(Local ): Usage Maximum, data= [ 0xff 0x00 ] 255 (null) Item(Global): Logical Minimum, data= [ 0x00 ] 0 Item(Global): Logical Maximum, data= [ 0xff 0x00 ] 255 Item(Global): Report Size, data= [ 0x08 ] 8 Item(Global): Report Count, data= [ 0x05 ] 5 Item(Main ): Input, data= [ 0x00 ] 0 Data Array Absolute No_Wrap Linear Preferred_State No_Null_Position Non_Volatile Bitfield Item(Local ): Usage Minimum, data= [ 0x00 ] 0 (null) Item(Local ): Usage Maximum, data= [ 0xff 0x00 ] 255 (null) Item(Global): Logical Minimum, data= [ 0x00 ] 0 Item(Global): Logical Maximum, data= [ 0xff 0x00 ] 255 Item(Global): Report Size, data= [ 0x08 ] 8 Item(Global): Report Count, data= [ 0x10 ] 16 Item(Main ): Feature, data= [ 0x00 ] 0 Data Array Absolute No_Wrap Linear Preferred_State No_Null_Position Non_Volatile Bitfield Item(Main ): End Collection, data=none Item(Global): Usage Page, data= [ 0x0c ] 12 Consumer Item(Local ): Usage, data= [ 0x01 ] 1 Consumer Control Item(Main ): Collection, data= [ 0x01 ] 1 Application Item(Global): Report ID, data= [ 0x02 ] 2 Item(Local ): Usage Minimum, data= [ 0x00 ] 0 Unassigned Item(Local ): Usage Maximum, data= [ 0x3c 0x02 ] 572 AC Format Item(Global): Logical Minimum, data= [ 0x00 ] 0 Item(Global): Logical Maximum, data= [ 0x3c 0x02 ] 572 Item(Global): Report Size, data= [ 0x10 ] 16 Item(Global): Report Count, data= [ 0x01 ] 1 Item(Main ): Input, data= [ 0x00 ] 0 Data Array Absolute No_Wrap Linear Preferred_State No_Null_Position Non_Volatile Bitfield Item(Main ): End Collection, data=none Item(Global): Usage Page, data= [ 0x01 ] 1 Generic Desktop Controls Item(Local ): Usage, data= [ 0x80 ] 128 System Control Item(Main ): Collection, data= [ 0x01 ] 1 Application Item(Global): Report ID, data= [ 0x04 ] 4 Item(Local ): Usage Minimum, data= [ 0x81 ] 129 System Power Down Item(Local ): Usage Maximum, data= [ 0x83 ] 131 System Wake Up Item(Global): Logical Minimum, data= [ 0x00 ] 0 Item(Global): Logical Maximum, data= [ 0x01 ] 1 Item(Global): Report Count, data= [ 0x08 ] 8 Item(Global): Report Size, data= [ 0x01 ] 1 Item(Main ): Input, data= [ 0x02 ] 2 Data Variable Absolute No_Wrap Linear Preferred_State No_Null_Position Non_Volatile Bitfield Item(Main ): End Collection, data=none Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 4 Device Status: 0x0001 Self Powered This tells me the touchpad side of things is not available to me right now. I can't even see it. So here are my questions: Why can't I see the touchpad? What can I do to find it and start reverse engineering its driver? Link to launchpad bug report(with a lot more log files)

I have a simple c code which is compiled and then the text code extracted using *objdump* utility. here is the dump file (A piece of dumped file): 0804841b : 804841b: 8d 4c 24 04 lea 0x4(%esp),%ecx 804841f: 83 e4 f0 and $0xfffffff0,%esp 8048422: ff 71 fc pushl -0x4(%ecx) 8048425: 55 push %ebp 8048426: 89 e5 mov %esp,%ebp 8048428: 51 push %ecx 8048429: 83 ec 14 sub $0x14,%esp 804842c: c7 45 f0 00 00 00 00 movl $0x0,-0x10(%ebp) 8048433: c7 45 f4 0a 00 00 00 movl $0xa,-0xc(%ebp) 804843a: 8b 45 f4 mov -0xc(%ebp),%eax 804843d: 01 45 f0 add %eax,-0x10(%ebp) 8048440: 8b 45 f0 mov -0x10(%ebp),%eax 8048443: 3b 45 f4 cmp -0xc(%ebp),%eax 8048446: 7e 0f jle 8048457 8048448: 83 ec 0c sub $0xc,%esp 804844b: 6a 78 push $0x78 804844d: e8 be fe ff ff call 8048310 8048452: 83 c4 10 add $0x10,%esp 8048455: eb 15 jmp 804846c 8048457: 8b 45 f4 mov -0xc(%ebp),%eax 804845a: 3b 45 f0 cmp -0x10(%ebp),%eax 804845d: 7e 0d jle 804846c the instruction at address 8048446 is jle 8048457 which has the machine code 7e 0f the `` statement is refer to the location of target instruction shifted from the main address, i.e. the 3c is equal 60 which mean that after 60 bytes from the main, the instruction 8048457: 8b 45 f4 mov -0xc(%ebp),%eax is located. The machine code of the instruction at address 8048446 is 7e 0f 7e is the machine code of jle. **The 0f what is?** In another branch instruction like this: 8048455: eb 15 jmp 804846c **what is 15 means?**

reverse engineering the hex file Written in c language From atmega16 Want source code from the hex code By reverse engineering need to extract the library file of the code is their any possible way to do that Thank you