Monday, July 25, 2016
Sunday, July 24, 2016
Loading custom DLLs instead of original DLLs (Let's talk about Stuxnet again and forget Kapsersky...)
The question below is for educational purposes only and the discussed featured are not meant to alter registered DLLs or develop a malware but for learning and experiencing.
Recently I've been exploring few methods to load my own custom DLLs instead of an application's original DLLs. One of the methods that came up was the
.local After experiencing with this method a little bit and after I removed the
KnownDlls entry from the registry I managed to replace some system DLLs with my patched DLLs successfully.These are the DLLs:
However, the DLLs are IN the local folder:
However, there are still some DLLs that insist loading from the
system32 directory, although they are present in the local folder.Is there any way I can force the DLL's to load from the local folder instead of the system32 folder?
|
This is not an answer so much as a rambling, unsourced, brain dump.
It does serve to explain why I am not surprised at your result. This boils down, for me, to the crucial difference between CreateProcess and LoadLibrary, and how Win32 processes work. Normally, when using LoadLibrary, you are using it from within the process you want the dll to be loaded into. As such, it can take advantage of a whole bunch of in-process context information about activation contexts, dll search paths etc. including knowledge of things like the app.local flag. All these values are specific to the current process and it is not the job of any other process (or even the Kernel) to track stuff like this. But, if we look at CreateProcess we can see some problems. When it is initially called, it is called in the context of the launching, not destination, process, so it knows nothing of the destination processes activation context. In fact, the destination process does not exist yet. The CreateProcess implementation needs to create a NT process, and execute some code in it asap to perform the process load as it doesn't make any sense to instantiate all that per process context stuff in the current process. But, to do that, there needs to be at least some code in the destination process: The kernel code responsible for parsing the EXE files header, extracting the headers and building the activation contexts that will be used to load the remaining dlls. This means that, unfortunately for you, kernel32.dll and some dependencies need to be mapped into a process long before that process is capable of building a dll search context, noticing the app.local flag etc. |
|||
|
You should look at how the Windows loader works. This is OS version
dependent, but some of those DLLs load before your program and the
loader always looks for them on a path provided by the system. Look at
the sequence by starting your program with WinDbg.
http://stackoverflow.com/questions/38042757/loading-custom-dlls-instead-of-original-dlls |
This is a very, very nice tool...what I mean by this is that, on the case of bilock's casino and vault chit, there's a vulnerability called "pull plug forward and not turn"...but as the description says : "The tool is also especially useful in car openings applying picking techniques (e.g. in the case of BMW, Daimler-Chrysler), because here the lock must be picked in the locking direction and then must be flipped into the unlocking direction very quickly..."
Thursday, July 21, 2016
Wednesday, July 20, 2016
Hack the diagnostics connector, steal yourself a BMW in 3 minutes
Your BMW comes with a $160 key
with a computer chip and security code inside to make the car hard to
steal. The common thief can’t steal your Bimmer, but in Europe, at
least, hacker-thieves apparently have been able to subvert the car’s
intrusion alarm in a separate step to break in, then access the car’s
OBD (on-board diagnostics) connector, collect unsecured or easily
decoded information on the key codes, program a new key, and drive away.
Hacking Automotive Ultrasonic Sensors
Step 1: Hardware
Each sensor has three pins. The pins are +8.5 volt supply, single wire half duplex comm, and ground. In a vehicle, the UPA module provides the 8.5 volt regulated supply to the sensors. The UPA is able to switch this supply on, and off, at will. As an example, while traveling down the highway the sensors are switched off. When the vehicle slows below some magic speed threshold the sensors are switched back on.
The single wire comm between the UPA module and sensor seems a bit strange to me. When inactive the bus is idle at eight volts. In an open collector kinda fashion, the UPA module and sensor communicate using pulses which pull the bus low for short pulses. The strange part is that the UPA sends digital commands to the sensor and the sensor responds with either a digital waveform that looks like the actual echo, or normal digital bits. It depends on the command. For the echo response it's like they just took the analog right off the piezo element, ran it through a op-amp comparator, and sent the op-amp output out into the comm wire. It's strange and slick at the same time. Downside is, the micro has to use a fast timer to measure all those echo pulses. No simple UART action to receive an echo response.
After power-up, the UPA sends a bunch of data to the sensor. I'm guessing the first set of pulses initialize the sensor with a certain gain level. I'm guessing each different type of vehicle has a different initialization string of data pulses. Looks like the UPA then sends a couple of reset commands to the sensor. Of course, there is an acknowledgment from the sensor. Finally, a sensor scan sequence starts on the UPA where one sensors is commanded to ping while one or two other sensors are simultaneously commanded to listen only. Using one sensor to ping and one / two sensors to listen allows very close objects to be detected. All the results from the sensors are sucked up by the micro in the UPA. Note, the Star12 micro in the UPA can capture timer values based on pulses come in. There are eight pins on the Star12 that have this ability. So, a pulse triggers the Start12 to capture the timer automatically, at the same time an interrupt flag is set for that pin. In the interrupt routine the micro buffers off the captured value, clears the interrupt flag, and returns. The cool part is that captured timer value is done in hardware right when the trigger happens. So, even if there is jitter in the interrupt response, it doesn't matter because the timer had already been captured. Motorola really knows how to design automotive micros. OK, I admit it, as an X Motorola employee I still have a soft spot for old Moto. Note, Motorola sold the micro division to Freescale some 6 / 8 years ago. Motorola has also sold my old automotive division.
Do you how Motorola got it's name? Well, a 100 years ago a Victrola played records. So, Motorola got it's name by putting a Victrola (not an actual Victrola but just the idea playing a record) in a Motor vehicle. Motor Car + Victrola = Motorola Car Radio. Motorola got its start by manufacturing automotive radios. Now, Motorola is totally out of the automotive business. Makes me sad. Anyway, a bit of trivia.
Back to the hardware setup. The development board shown below that I built interfaces four sensors to an MBed development micro. Each sensor must have a buffer circuit to convert the bus voltages down to the 3.3V TTL values used by the MBed micro. You can think of the sensor bus as a half duplex communications bus. It appears the communications on the bus is 9600 baud serial. At lease my LSA (logic state analyzer) can decode the pulses if set to 9600 baud.
I simply used pins P21 through P28 on the MBed to interface to the four sensors on my development board. The MBed looks to be even better at processing pulse trains than the Star12. It has all the bells and whistles that the Star12 does, plus a lot more.
STEP 2 AND STEP 3 :
http://www.instructables.com/id/Hacking-Automotive-Ultrasonic-Sensors/
How to read BMW fault codes with c110 code reader
C110 BMW code reader is readily available at most automotive retailers.
How to use BMW c110 OBD2 scanner read BMW fault codes?
First: Slide the key into the ignition. Don’t start your car or switch on the electrical system, just leave the key there.
Second: Connect the c110 OBD2 scan tool to the OBD port beneath the dashboard and steering column. You may have to feel around for it, but it’s a large outlet and you will not need tools to find it.
Third: Turn the BMW c110 OBD2 scanner on.
Fifth: Wait for the code to appear on the c110 OBD2 scanner, then jot the alpha-numeric code onto a scrap of paper before unplug the c110 scanner and turn off the vehicle ignition.
Finally: Copy the alpha-numeric trouble code into google.com. You will likely get a page of results that offer definitions for that particular fault code.
Monday, July 18, 2016
Subscribe to:
Posts (Atom)
Energy Blackouts total electric outage graphite carbon balls trow 2 ground impact
https://www.alibaba.com/product-detail/Graphite-Carbon-Ball-C80-Instead-of_1601156433008.html?spm=a2700.galleryofferlist.normal_offer.d_ti...
LoadLibraryandLoadLibraryEx.ntdll.dllandkernel32.dllare what provideLoadLibrary(Ex), so by chicken-and-egg analysis you can see that they aren't loaded byLoadLibrary(Ex), and therefore are not affected by DLL redirection. In fact, I think you'll find thatntdllandkernel32aren't loaded into a new process at all, they are in the initial module table. – Ben Voigt Jun 26 at 21:59