OpenRCE_Saphex
May 24th, 2008, 00:02
Hi,
I was shilling out with two friends, after a long day of classes and studying when one of them showed me a feature on his laptop that prevented damage in the hard drive in case the laptop suffered from a sudden impact. His laptop is a Fujitsu LifeBook that comes equiped with Fujitsu 3D Shock Sensor ("http://www.fujitsu.com/sg/services/computing/pc/news/articles/shock-sensor.html").
My friend told me it would be cool to access the values from the sensor, so that he could use those values in other applications. So I told him he could try to reverse the application, FJSSGUI.exe. In the next day, I asked him how was the reversing going, since he didn't knew what to look for, I decided to help him out. After connecting IDA to his remote debugger session I started too look for CreateFileW or CreateFileA, since the application is accessing hardware values, it needs to use a driver. After finding all CreateFileW calls, I started investigating one by one until I found the one that is important, located at 0x0040B7E3.
Trying to access the hard drive?? Strange uh? Not quite so, a quick look at the Device Manager, revealed what I think to be a filter driver called FJGSDisk.sys, associated with the hard drive. This explains why it's trying to access the hard drive. The next step was to find all calls to DeviceIoControl ("http://msdn.microsoft.com/en-us/library/aa363216(VS.85).aspx") function. There is only one call to this function, it's located at 0x004098D3.
This function is requesting data from the device, since the lpOutBuffer parameter is provided. The size of the buffer is 4 bytes. After this call, starts the maths that convert this dword into the 3 axis acceleration values. With all of this information I started coding a C# application (for the sake of fastness) that reed the values from the device. This application was later tested and corrected by my friend, since I ain't very good at unmanaged C#. The following is the values transformation pseudo code.
As you can read, it was fairly easy to find how the application got the values. The application isn't protected in anyway. The next step is to make a socket application that reads the values from the device and provides them to other applications through sockets. But that is a story for another day :P
Hope y'all enjoyed it, best regards,
saphex
https://www.openrce.org/blog/view/1143/Fujitsu_3D_Shock_Sensor_Application_Reversing
I was shilling out with two friends, after a long day of classes and studying when one of them showed me a feature on his laptop that prevented damage in the hard drive in case the laptop suffered from a sudden impact. His laptop is a Fujitsu LifeBook that comes equiped with Fujitsu 3D Shock Sensor ("http://www.fujitsu.com/sg/services/computing/pc/news/articles/shock-sensor.html").
My friend told me it would be cool to access the values from the sensor, so that he could use those values in other applications. So I told him he could try to reverse the application, FJSSGUI.exe. In the next day, I asked him how was the reversing going, since he didn't knew what to look for, I decided to help him out. After connecting IDA to his remote debugger session I started too look for CreateFileW or CreateFileA, since the application is accessing hardware values, it needs to use a driver. After finding all CreateFileW calls, I started investigating one by one until I found the one that is important, located at 0x0040B7E3.
Code:
00000000 6A 00 push 0
00000002 6A 00 push 0
00000004 6A 03 push 3
00000006 6A 00 push 0
00000008 6A 03 push 3
00000010 6A 00 push 0
00000012 68 8C AB 41 00 push offset g_pDeviceName ; "\\\\.\\PhysicalDrive0"
00000017 FF 15 D8 71 41 00 call ds:CreateFileW
0000001D A3 4C A2 41 00 mov g_pDevice, eax
Trying to access the hard drive?? Strange uh? Not quite so, a quick look at the Device Manager, revealed what I think to be a filter driver called FJGSDisk.sys, associated with the hard drive. This explains why it's trying to access the hard drive. The next step was to find all calls to DeviceIoControl ("http://msdn.microsoft.com/en-us/library/aa363216(VS.85).aspx") function. There is only one call to this function, it's located at 0x004098D3.
Code:
00000000 6A 00 push 0
00000002 8D 4D F8 lea ecx, [ebp-8]
00000005 51 push ecx
00000006 6A 04 push 4 ; nOutBufferSize
00000008 8D 55 FC lea edx, [ebp-4]
00000011 52 push edx ; lpOutBuffer
00000012 6A 00 push 0
00000014 6A 00 push 0
00000016 68 08 02 22 00 push 220208h ; dwIoControlCode
0000001B A1 4C A2 41 00 mov eax, g_pDevice
00000020 50 push eax
00000021 FF 15 BC 70 41 00 call dseviceIoControl
This function is requesting data from the device, since the lpOutBuffer parameter is provided. The size of the buffer is 4 bytes. After this call, starts the maths that convert this dword into the 3 axis acceleration values. With all of this information I started coding a C# application (for the sake of fastness) that reed the values from the device. This application was later tested and corrected by my friend, since I ain't very good at unmanaged C#. The following is the values transformation pseudo code.
Code:
# The l_Result holds the dword
# l_Temp1, l_Temp2 are helper variables
# l_ValueX, l_ValueY, l_ValueZ will contain the acceleration values
sint32 l_Temp1 = l_Result >> 16;
sint8 l_Temp2 = (sint8)(l_Temp & 0xFF);
float l_ValueX = l_Temp2 / 3.0f;
l_Temp1 = l_Result >> 8;
l_Temp2 = (sint8)l_Temp1;
float l_ValueY = l_Temp2 / 3.0f;
l_Temp1 = l_Result & 0xFF;
l_Temp2 = (sint8)(l_Temp1 - 33);
float l_ValueZ = l_Temp2 / 3.0f;
As you can read, it was fairly easy to find how the application got the values. The application isn't protected in anyway. The next step is to make a socket application that reads the values from the device and provides them to other applications through sockets. But that is a story for another day :P
Hope y'all enjoyed it, best regards,
saphex
https://www.openrce.org/blog/view/1143/Fujitsu_3D_Shock_Sensor_Application_Reversing