Search the Community

Erroare: An unhandled exception of type 'System.IO.FileNotFoundException' occurred in System.Windows.Forms.dll Additional information: Could not load file or assembly 'TCtrl Connection, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified. Source: Imports Admin_Tool_4s Public Class Form2 Dim TCTRLCon As Connection Private Sub Button8_Click(sender As Object, e As EventArgs) Handles Button8.Click TCTRLCon.Kick(TextBox1.Text) End Sub Private Sub Form2_Load(sender As Object, e As EventArgs) Handles MyBase.Load TCTRLCon = New Connection("#", #) TCTRLCon.Connect() TCTRLCon.Login("#", "#") End Sub Private Sub TextBox1_TextChanged(sender As Object, e As EventArgs) Handles TextBox1.TextChanged End Sub End Class Cand deschid form2.vb primesc eroare asta... An unhandled exception of type 'System.IO.FileNotFoundException' occurred in System.Windows.Forms.dll Additional information: Could not load file or assembly 'TCtrl Connection, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.

# Affected software: phplist # Type of vulnerability: insecure object reference # URL:phplist.com # Discovered by: Provensec # Website: http://www.provensec.com #version: phpList ltd. - v3.0.10 # Proof of concept insecure object refrenced on page deltetation vuln param:delete example: http://demo.phplist.com/lists/admin/?page=send&delete=2&tk=035d99 ref: https://www.owasp.org/index.php/Testing_for_Insecure_Direct_Object_References_%28OTG-AUTHZ-004%29 Source

XP is a little more complicated than newer systems due to the use of a single driver for both port and miniport; however, getting the original pointers is fairly straight forward depending on how you do it. IRP_MJ_SCSI & DriverStartIo - Method 1 (Windows XP) A common method is to programmatically disassemble the miniport's DriverEntry, looking for the code which initializes the driver's object, then you can extract and calculate the addresses from "mov [esi+30h], offset" and "mov [esi+74h], offset" for DriverStartIo and IRP_MJ_SCSI respectively. The obvious problem with this method is the initialization code may not be in DriverEntry, but a sub function called from it (it may even be necessary to follow jumps). It's also not guaranteed that the instruction will use esi as the pointer to the driver object or an immediate for the function address, in fact you're probably going to have to account for quite a few different instructions. IRP_MJ_SCSI & DriverStartIo - Method 2 (Windows XP) In my tests, it was possible to simply call the DriverEntry of the miniport driver with the parameters from your own driver entry, thus having the miniport set up your driver's object as if it were its own. The only issue with this method is if the driver uses GsDriverEntry (it usually does), the entry point will be invalidated after the driver is initialized, so you cannot call it. To deal with GsDriverEntry you'd first need to load the original image from disk, then search until you reach an unconditional relative jump (this is the offset to real entry point and you can use it to calculate the same address within the loaded driver). IRP_MJ_SCSI (Windows Vista+) On newer systems, things are wonderfully easier: There's no DriverStartIo field and you can initialize all the major functions in your DriverObject with a call to AtaPortInitialize, ScsiPortInitialize, or StorPortInitialize which are all exported from the relevant port drivers (ataport.sys, scsiport.sys, or storport.sys). Bypassing Inline Hooks Although not many bootkits actually perform inline hooking on miniports, it's worth taking care of. You'll need to read a the original miniport or port driver's file into memory, then do a bit of pointer math to calculate the addresses of IRP_MJ_SCSI or DriverStartIo within the clean image. I'm not too sure of the best way to call the clean functions, but here are 2 viable methods to chose from. Trampoline Usually a hook is placed within the first few bytes of a function, so you can simply read and relocate the first few bytes from the clean function into a buffer, then append it with a jump to the same offset within the real driver(this is the same way a hooking engine would call the unhooked version of a function). Manual Mapping A more difficult but effective method is to manually map a clean copy of the driver into memory, then relocate it so that all absolute instructions will reference the real driver, meaning you don't have to worry about initializing any global variables or such. Creating a Clean Call Path Due to the fact a lot of bootkits run persistence threads for replacing any driver object hooks which get removed, you don't want to unhook the real driver but instead create a parallel one, so you can maintain your own hook-free call path. Step 1 (XP & Vista) Get the device object for the boot disk miniport, this is usually \Device\Harddisk0\Dr0 Use the size field of the device object to allocate some non paged memory and copy the entire object (this is your clean miniport). Set the DriverObject field to point to your own driver's object, in which you've set the IRP_MJ_SCSI and DriverStartIo field appropriately (DriverStartIo can be skipped on Vista+). Step 2 (XP Only) Set the DeviceExtension field of your clean miniport device object to point to directly after its device object (DeviceObject + sizeof(DEVICE_OBJECT)). Get the address stored at offset 0x5C into your clean miniport's device extension and check it's valid (this is the address of the corresponding port's device extension). Read the addresses stored at offset 0x0C into the port's device extension (this is the address of the port's device object). Use the size field of the port's device object to allocate some non paged memory and copy the entire object (this is your clean port). Set the DeviceExtension field of your clean port's device object to point to directly after its device object (DeviceObject + sizeof(DEVICE_OBJECT)). Set the DriverObject field of your clean port's device object to point to your own driver's object, in which you've set the IRP_MJ_SCSI field appropriately. Change offset 0x5C into your clean miniport's device extension to contain the address of the clean port's device extension. Set offset 0x0C into the clean port's device extension to contain the address of the clean port's device object. Using the Clean Path You're going to need to build a raw SCSI request which is pretty complicated; however, the Chinese are already a step ahead, so you can look to this example for help (This request can be issued by passing the clean miniport device object and the IRP to IofCallDriver). It's important to note that miniport drivers are PnP, so if you don't create any devices (IoCreateDevice): the driver will be unloaded as soon as DriverEntry returns, if you do: the driver can't be unloaded at all. Although it's not recommended, you can set the driver back to a legacy driver by setting the AddDevice pointer within the driver's extension to 0, allowing the driver to be unloaded normally. Conclusion This concludes my 3 part series, any feedback in the comments would be greatly appreciated and will be taken into consideration when I create a whitepaper version of the series in a few weeks. Other resources of note Debugging TDL4 Subverting Bootkits using the Crash Dump Driver Stack Exposing Bootkits With BIOS Emulation Source

Part 1 .: https://rstforums.com/forum/98013-bootkit-disk-forensics-1-a.rst As I explained in the previous article: DriverStartIo is used by older miniports to actually perform the disk I/O, it takes 2 parameters (a device object and an IRP), exactly the same as IoCallDriver does. The call to DriverStartIo is done with IoStartPacket; however, the device object passed is not that of the miniport, but instead a device associated with the port the target disk is connected to (in my case IdePort1). IRP_MJ_SCSI points to IdePortDispatch in atapi.sys, by disassembling it we can see exactly how the required device object is retrieved from the DeviceExtension field of the miniport's device object. The call logic is something like this: Get the miniport's device extension from its device object (passed to us in the call). Get IdePort1's device extension from offset 0x5C into the miniport's device extension. Get IdePort1's device object from offset 0x0C into its device extension. Call IoStartPacket with the IRP and IdePort1's device object. As both the miniport and IdePort devices are created by atapi.sys, the DriverObject field of both devices' objects point to the same driver object; thus, hooking DriverStartIo is as simple as replacing the address in the driver's object. Detecting DriverStartIo hook with WinDbg For basic DriverStartIo hook detection we can simply follow the same process as for major function hooks: First, we find the boot disk and list it's stack. As I explained in the previous article, modifications made by TDL4 will cause the !drvobj and !devobj commands to think the object is invalid, it's not. You will probably want to check each driver object in the stack (for the invalid DeviceObject you can again use "dt _DEVICE_OBJECT <address>" to find the DriverObject field). With most bootkits, the lowest level driver is always the one hooked, so I'll use this in my example. You can see here that DriverStartIo isn't hooked because the address resolve to its proper symbol; however, this isn't actually the real driver object. Earlier i explained that IoStartPacket is always called with the device object of IdePort1, not the disk miniport: This means that when IoStartPacket called DriverStartIo internally, it does so by getting the driver object from the DriverObject field of IdePort1's device object, then getting the DriverStartIo field from that. Obviously this means that to hook DriverStartIo, one could simply just create a copy of atapi's driver object, with the DriverStartIo field modified, then set the DriverObject field of IdePort1's device object to point to the new, malicious driver object (this way on IdePort1 will point to the hooked driver, the rest will point to the original). As it happens TDL4 actually does the opposite, it hooks the real atapi driver object, then replaces the DriverObject field of the disk miniport's device object with the address of an identical driver object, without the DriverStartIo field modified.). If you know what you're looking for, fake driver objects are easy to detect. All devices created by a driver should point the same driver object, so simply enumerating the devices created by the miniport's driver then making sure all the DriverObject fields point to the same address is all that's needed. This can be done a multitude of ways. Method 1: DrvObj The fake driver object will have the same name as the real one (in my case "\driver\atapi"), all you need to do is type "!drvobj \driver\atapi 2" to get the real driver's object (this is a downside of TDL4 hooking the real driver object instead of a spoofed one). Method 2: NextDevice Starting with the miniport device, enumerate devices using "dt _DEVICE_OBJECT <address>" and the NextDevice field of each device's object. We're looking for any DriverObject field that dosen't match that of the miniport (this is the real driver object). Method 3: DeviceExtension This is the least reliable way, as the device extension could change from system to system, but as I mentioned earlier: you can find IdePort1's device extension at offset 0x5C isn't the miniport's device extension, then from IdePort1's device extension you can find its device object at offset 0x0C (IdePort1's device object will point to the real driver object). We can actually find the DeviceObject in a single commands using this overly complicated WinDbg-C++ syntax: "dt _DEVICE_OBJECT poi(poi(@@C++(((nt!_DEVICE_OBJECT *)<address>)->DeviceExtension)+0x5C)+0x0C)", where "<address>" is the miniport device object. Source

Windows Object Explorer 64-bit (WinObjEx64) WinObjEx64 is an advanced utility that lets you explore the Windows Object Manager namespace. For certain object types, you can double-click on it or use the "Properties..." toolbar button to get more information, such as description, attributes, resource usage etc. WinObjEx64 let you view and edit object-related security information if you have required access rights. System Requirements WinObjEx64 does not require administrative privileges. However administrative privilege is required to view much of the namespace and to edit object-related security information. WinObjEx64 works only on the following x64 Windows: Windows 7, Windows 8, Windows 8.1 and Windows 10, including Server variants. WinObjEx64 does not work on Windows XP, Windows Vista is partially supported. We have no plans of their full support. In order to use all program features Windows must be booted in the DEBUG mode. Build WinObjEx64 comes with full source code. In order to build from source you need Microsoft Visual Studio 2013 U4 and later versions. Authors © 2015 WinObjEx64 Project Original WinObjEx © 2003 - 2005 Four-F Acknowledgements We would like to thanks the following people for their contributions (in the alphabetical order): Andrew Ivlev aka Four-F - author of the original x86-32 WinObjEx Giuseppe Bonfa aka Evilcry - KDSubmarine author Mark Russinovich - author of the original proof-of-concept tool WinObj Microsoft WinDBG developers team Source and compiled binary here https://github.com/hfiref0x/WinObjEx64 Project files SHA1: https://github.com/hfiref0x/WinObjEx64/blob/master/Source/SHA1.hash Copy: 818bf9f0d4189347e9bd157a2810615109423e62 *Release\WinObjEx64.chm 957157318a64482f446b97c82afe786444b1b2ff *Release\WinObjEx64.exe 6f4df146c341d7f2dafbe5e3d1aee5f2c7b3488b *WinObjAdv\aboutDlg.c d0e500c0092000d73fd711a5d20c35b69f4ac447 *WinObjAdv\aboutDlg.h 74fcc74b3d7d7a4467869a888dcd4f67797ca156 *WinObjAdv\excepth.c 2ba8ded754090338b733797accdb696162866e75 *WinObjAdv\excepth.h fbad8de8cbc2eb1ed7612a495ac5e0206210d241 *WinObjAdv\findDlg.c 68449112b665b763729ef78fec2d7e2dd2bca653 *WinObjAdv\findDlg.h 08f9599cc724cda5a8148a09dc31655e1eefe345 *WinObjAdv\global.h 80c6e0253371e8debbf7389ffe954231ad5bf705 *WinObjAdv\instdrv.c 2a943159f01da7516f1a49c5bd1407a69835bbce *WinObjAdv\instdrv.h 0f68ede96ad12ad93f594525b98b3daf25e2383a *WinObjAdv\kldbg.c 1892a89b673214b71d08854f39ee55342ae72c88 *WinObjAdv\kldbg.h 37814686c9a82fdfdc568f2759cea117fc2a9952 *WinObjAdv\list.c f26030f75546ec594fd5a87ee2fc82796480599d *WinObjAdv\list.h 9f98dd38d9b13f7572f59589973d3033d7d34fcb *WinObjAdv\main.c e9cf1468a3ebcb67fcea1b86730a25e6669b096b *WinObjAdv\minirtl.c 500a94a62e9ba78c38833670302537cf6fb0e3d0 *WinObjAdv\minirtl.h ef02d79e830000af6efbd0cb527eaa7a60efa917 *WinObjAdv\ntos.h 4c1698b624baaa52f6b2ff2c536b9df644e52820 *WinObjAdv\obex.manifest 92c7dfb2face6bc570fb63ee123702ebf30764f4 *WinObjAdv\propBasic.c ff406cb1a50504533e367eca67e759f044ddd5ab *WinObjAdv\propBasic.h a00e7fa470faad601bde2219e596c20c2294acd0 *WinObjAdv\propBasicConsts.h 4328cb76fcb70930fe8be27e7c89ad768273224f *WinObjAdv\propDesktop.c cf5e6d7616c776aff3bcf6ec7698fb18bfd76950 *WinObjAdv\propDesktop.h 9364e13a1eb1c2c8062ce1002fcbf7d5dfba344c *WinObjAdv\propDlg.c bdc4258b60a8c512c487cfd6c726caa0ff3b0976 *WinObjAdv\propDlg.h 72cb46536bd855f9ee2b6be32bd097ec48267909 *WinObjAdv\propDriver.c d4bf75d244002db8da4cd5314ea757896bbcbd3e *WinObjAdv\propDriver.h b72b9ee8ccfbbd78844548e40d6bebf42d497a67 *WinObjAdv\propDriverConsts.h a82596fc8914f384049c68469eb45c0468866c44 *WinObjAdv\propObjectDump.c df95b45770b80b5e88fd5cfea593eb51790222a2 *WinObjAdv\propObjectDump.h f4de0f1071031d2ae108a683ca9deb5066a9f3a3 *WinObjAdv\propObjectDumpConsts.h 1e3d3e0747dd2bf464f9351018309e78fe02870e *WinObjAdv\propProcess.c 4a050a42f7bf083fafe23f0fe94bf34d45287559 *WinObjAdv\propProcess.h 0325abb4e9bf8867eea50fdb7f508b010d702d70 *WinObjAdv\propSecurity.c ac8356ce68b06cbd917bd54ed463d3ea15f06856 *WinObjAdv\propSecurity.h aefd3c0d9ea1a5506cafa3425fbb6128aab132d4 *WinObjAdv\propSecurityConsts.h 7513279bf1104150e0a1608176b899f2b5073fa3 *WinObjAdv\propType.c b01ee5835191e2e2e47106630f5f42fcab789b92 *WinObjAdv\propType.h 565a332243f0beb23970bf4e0180c9607bd7a246 *WinObjAdv\propTypeConsts.h 21028096ddc34328c1c098ca3de2de59aa6e9075 *WinObjAdv\resource.h 4d063a98918873efcc86682d31c18aeb821e2367 *WinObjAdv\Resource.rc f2c93d88f1a5dbfa8cafa1c31e02c866dc975371 *WinObjAdv\rsrc\100.ico 69a5a4ed71a85e99b4806563a2739d7de5dc2e38 *WinObjAdv\rsrc\101.ico fd979dd62fdbeba6298ac1dabbc678fe0dbb0ae5 *WinObjAdv\rsrc\102.ico c16779a0fef28aab679eda6c18e7c6f5e68a5c20 *WinObjAdv\rsrc\103.ico bcd4d1222ebdcf1545209451c5247cb61549ec23 *WinObjAdv\rsrc\104.ico a0b22a0e9ab1401926aef939df99acc1a7a7d9ad *WinObjAdv\rsrc\105.ico e94d7aad576eccad0d8d8c52249700230dab76c8 *WinObjAdv\rsrc\106.ico 824001cd7bae24b7217b075d32da7618c93bdd00 *WinObjAdv\rsrc\107.ico c5c1a26d3e2bab8086d663ce2326f476e73f0f08 *WinObjAdv\rsrc\108.ico 65f8d9d565b00930920fbff580c87d399b90f9cc *WinObjAdv\rsrc\109.ico 56c27e823eb044da4d7726f0d35d98822bd79344 *WinObjAdv\rsrc\110.ico 08b8573a1efd1803099698a011f3c3d6eb00d3da *WinObjAdv\rsrc\111.ico f9ea074c8c152d30af74f4b266ab80aaf10a2821 *WinObjAdv\rsrc\112.ico 13e524fbc7b803ab711e11fb61f1014641cff8b6 *WinObjAdv\rsrc\113.ico 69a5a4ed71a85e99b4806563a2739d7de5dc2e38 *WinObjAdv\rsrc\114.ico 3a9b58b48fd4dfcb356abfd915036d7195c3c29c *WinObjAdv\rsrc\115.ico 335fd760d495b9a68ccafbcfb52f4f1ddc90b3fc *WinObjAdv\rsrc\116.ico 2d9b7e5622ef1c6f96cf85d344a989df7d129530 *WinObjAdv\rsrc\117.ico aa221c069f9a53f9afa7fbccb4465ce4da6baf58 *WinObjAdv\rsrc\118.ico 530ac9c2d277d9908decb955618ab2b43995cd1f *WinObjAdv\rsrc\119.ico 4ef03bb6bbc10b1723770a03b6fd899d3be1044a *WinObjAdv\rsrc\120.ico d84cd22bab028700050a644be5c2a7dafcc4553a *WinObjAdv\rsrc\121.ico 557be784a62110a81aa0f4b620c210e165857905 *WinObjAdv\rsrc\122.ico 674f4875596c907ee8da940edff1e98401e8b7fa *WinObjAdv\rsrc\123.ico 041a38d1522858aaede0df6d42b2479c8300c988 *WinObjAdv\rsrc\124.ico c0832fe5bf96f11a8133bbed66449574a3fd9089 *WinObjAdv\rsrc\125.ico 0a2aeedde4dc3934e28d727396c1ff93fddf6a6e *WinObjAdv\rsrc\126.ico 56d12ceb51825d502ba3a096396404af56b8f817 *WinObjAdv\rsrc\127.ico b7c0bf31dd02382e151e4d62fc078bc292303ff9 *WinObjAdv\rsrc\128.ico 267f398bd643e7c1591412b2c7538b79e1159ca9 *WinObjAdv\rsrc\129.ico 1be3fd5b055f60b2c2357e9cb87dddad22542a95 *WinObjAdv\rsrc\130.ico 8b725d0d5552061a6cd88e17eda3d580c4fa7fde *WinObjAdv\rsrc\131.ico 9e89e0564daacd2bb36f906e4754d3a3b95141d7 *WinObjAdv\rsrc\132.ico f57a70dbb02c43ffcf8b6d028f775606a2be5d91 *WinObjAdv\rsrc\133.ico 863ce1668eccc967273a8fbaff5e29db81d4d047 *WinObjAdv\rsrc\134.ico d9bb1b62d374b1cfb0892d5e1437342701db2a1f *WinObjAdv\rsrc\135.ico 8c64531a70ad2bf61c050fd1e69a9d7e87549c35 *WinObjAdv\rsrc\136.ico 34356dcf20c4dd0adc3d363d25dcd7ed4e98bfa9 *WinObjAdv\rsrc\137.ico 656ccfe0b2a147b61b16321e14516e0c2dccbd57 *WinObjAdv\rsrc\138.ico 1721fe712b75808604318f015c09f6b2b469baf7 *WinObjAdv\rsrc\6001.ico 68b25362609b6db97c40b375e2497e2db4f5ee48 *WinObjAdv\rsrc\6002.ico 8f4a9ec169d9c6e80ae2a8ee1947dab63665337d *WinObjAdv\rsrc\Bitmap_125.bmp 6f5b29fffb021bf80ca91d6d67cfc019d63f7175 *WinObjAdv\rsrc\kldbgdrv.sys da3fa9f3a72da9bde1d73dd4b5f7d93b909fe3d6 *WinObjAdv\sup.c 38c463dcf6a834eea357bc766135dfa5210ba99c *WinObjAdv\sup.h 09ca1ed7f052113f24bf2f11c877538b772701a3 *WinObjAdv\supConsts.h e87a6e82d41f9b065e58fdc5a2acf362ca6969cb *WinObjAdv\treelist.c 7d5d97dcc923a87d5f6064fe1b9fdba5e04674fe *WinObjAdv\treelist.h a99d9f26e6df31641a6780993b96b76d0e0ce088 *WinObjAdv\ui.h e78a55a5c4a562c54d77b16f24b88c42fd6b3816 *WinObjAdv\WinObjAdv.vcxproj e9ba01dd003e20ab20191dabbebde20921abe3f6 *FILELIST.txt 5eedad7ce5b95dd191d1556072481e18295676fd *README.md 0d66462034a77394dc5272acdb8d13758f448b19 *TODO.txt 16ee9f3cf034a76595910177b911832de6a4081c *WinObjAdv.sln In attach compiled version. SHA1 818bf9f0d4189347e9bd157a2810615109423e62 *WinObjEx64.chm 957157318a64482f446b97c82afe786444b1b2ff *WinObjEx64.exe Copyrights WinObjEx64 developed by WinObjEx64 Project group, in the alphabetical order: EP_X0FF MP_ART This program uses Windows Debugger Local Kernel Debugging Driver © Microsoft Corporation. Please use this thread for bugreports. Also take a note that Windows 10 is supported *AS IS* since it wasn't released yet, official support will be added after official release. Download Source

Buna ziua tuturor, In cadrul unei sesiuni de recrutare prevazuta pentru luna aprilie la Bucuresti, firma de recrutare Cooptalis cauta, pentru unul din clientii ei francezi (o importanta firma ICT implantata in mai bine de 40 de tari) PHP Developeri cu experienta si care cunosc programarea orientata obiect, precum si limba franceza. Posturile sunt bazate in nordul Frantei (Lille). Daca doriti mai multe informatii despre aceasta oportunitate, va rog sa ma contactati : raluca.sandu@cooptalis.com !