Work-around to get USB-C headset to work for calls (in Android smartphones)?

It is an interesting, albeit frustrating, phenomenon of late that manufacturers of soft- and hardware these days (including Huawei, Samsung and apparently also Google) release new products which do not function as advertized:

I use my usb-c setup for mostly listening to hi-res music, it’s annoying when I get a phone call and I have to disconnect my USB-c headphones to answer the call. Seriously Samsung needs to get there head out of the ass and fix this problem. How can every other flagship phone handle this including the OnePlus 6.

and

bump. So I did some bumming around. I don’t think it’s the equalizer that’s the problem. I think the phone app is incapable of routing calls through USB-C.

and

Google acknowledges Pixel 2 USB-C headphone adapter issue, says fix coming

and

It’s 2018 and USB Type-C is still a mess

and

How USB Type-C Has Failed Android Smartphone Users

Here’s what I’m confronted with: Huawei P10 with up-to-date software as of 3 Sep 2018, build nr. VTR-L09 8.0.0.375(C432) and “Dialer” app/process (?) version nr. 8.1.0.301 and Huawei Active Noise Cancel(l)ing Earphones 3 (cm-Q3) where sound works and calls through other apps like WhatsApp works but not through the standard telephone app. Any ideas on how to route standard phone calls through another (trustworthy…) app?

Other than finding a viable work-around all I can do is to hope that a fix will percolate through eventually through an update…

Please help to suggest workaround to prevent docker from this security issue while still not have update patch

According to this news from these URL.

https://www.bleepingcomputer.com/news/security/unpatched-flaw-affects-all-docker-versions-exploits-ready/

As the System Administrator Roles. I update Security Patch for OS Ubuntu 18.04.2 and Check Network / Firewall already. Our Docker version is 18.09.06. However I would like to find the best way to prevent docker’s system from this security issue until Security Patch is release.

Thank you.

Whatsapp workaround?

What I have:
– I don’t want to install Whatsapp on my phone because I don’t want it to access my personal data.
– There’s an organisation that requires me to use Whatsapp to communicate with them.
– These two statements are mutually exclusive….

What I want:
– Is there any way for me to use Whatsapp without installing it on my phone? (I already have a Whatsapp user account.)
– Alternatively, is there a way to install and use Whatsapp without giving it access to all my data? (Contacts, calendar, camera, photos, etc etc.) I use Android 7.1.2 because there’s no newer ROM for my phone.

I realize this might be offensive to some users (“use it or don’t!”) but please look past that. I’m trying to satisfy competing demands here.

Uploading of backdoor results in the server removing file extensions. Any workaround?

I am totally new within the scene of information security, but find it extremely interesting and thus taking a course at my university, where we have to break into a website/webserver. The website is an image sharing website. The website is badly secured and I am looking for a way to upload my php backdoor created through weevely.

I can without problems upload a php file to the server. The problem is that the server automatically removes the file extensions, which makes it impossible for me to access through weevely (or so I think). Is there anyway to access a backdoor, when the file extensions are missing or is there a workaround?

Apologize for the rookie question!

Thanks How the upload folder looks like

Buffer overflow return address with null byte, workaround

Practising BO using Free Float FTP Server 1.0 on Windows 7 SP1, done simple jmp esp examples on Win XP where system DLL are without rebase or ASLR, trying to write one for Win7 where I haven’t got any system DLL with rebase or ASLR disabled, I can still exploit it but it won’t survive reboot, so I’m very much left with opcodes from the FTPServer.exe but the problem is that they all use a low stack addresses (0x0040xxxx) , so they all end with NULL byte (eg, \xce\x11\x40\x00 ) and hence terminate my exploit. My question is what are the options, if any to workaround the NULL byte in address I want to use, more specifically I want to know whenever there is an option to use NULL byte at the end of return address if it is listed as a bad character?

extfs_fsck crash on macos 10.14.4. Any workaround or fix?

I am trying to mount an external HD with extfs, but apparently the latest unmount was non-successful, and now the disk requires an automatic fsck. When macos tries to perform the fsck, this happens

Process:               fsck_exfat [47683] Path:                  /System/Library/Filesystems/exfat.fs/Contents/Resources/fsck_exfat Identifier:            fsck_exfat Version:               90.200.1 Code Type:             X86-64 (Native) Parent Process:        diskarbitrationd [66] Responsible:           fsck_exfat [47683] User ID:               0  Date/Time:             2019-04-05 00:13:11.857 +0100 OS Version:            Mac OS X 10.14.3 (18D109) Report Version:        12 Bridge OS Version:     3.3 (16P3133) Anonymous UUID:        972E6B24-EE1F-B5A0-2545-E9EE3AE52D78   Time Awake Since Boot: 980000 seconds  System Integrity Protection: enabled  Crashed Thread:        0  Dispatch queue: com.apple.main-thread  Exception Type:        EXC_CRASH (SIGABRT) Exception Codes:       0x0000000000000000, 0x0000000000000000 Exception Note:        EXC_CORPSE_NOTIFY  Application Specific Information: dyld3 mode Assertion failed: (result->data == NULL), function fsck_exfat_cache_recycle, file /BuildRoot/Library/Caches/com.apple.xbs/Sources/exfat/exfat-90.200.1/fsck/fsck_exfat_cache.c, line 248.   Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0   libsystem_kernel.dylib          0x00007fff6ff9d23e __pthread_kill + 10 1   libsystem_pthread.dylib         0x00007fff70053c1c pthread_kill + 285 2   libsystem_c.dylib               0x00007fff6ff061c9 abort + 127 3   libsystem_c.dylib               0x00007fff6fece868 __assert_rtn + 320 4   fsck_exfat                      0x00000001099961a1 0x10998e000 + 33185 5   fsck_exfat                      0x000000010999634e 0x10998e000 + 33614 6   fsck_exfat                      0x00000001099953ff 0x10998e000 + 29695 7   fsck_exfat                      0x0000000109993068 0x10998e000 + 20584 8   fsck_exfat                      0x0000000109993461 0x10998e000 + 21601 9   libdyld.dylib                   0x00007fff6fe5ded9 start + 1  Thread 1: 0   libsystem_pthread.dylib         0x00007fff700503f8 start_wqthread + 0 1   ???                             0x0000000054485244 0 + 1414025796  Thread 0 crashed with X86 Thread State (64-bit):   rax: 0x0000000000000000  rbx: 0x00000001146785c0  rcx: 0x00007ffee6271998  rdx: 0x0000000000000000   rdi: 0x0000000000000507  rsi: 0x0000000000000006  rbp: 0x00007ffee62719d0  rsp: 0x00007ffee6271998    r8: 0x00000000000000f8   r9: 0xcccccccccccccccd  r10: 0x0000000000000000  r11: 0x0000000000000206   r12: 0x0000000000000507  r13: 0x0000000109ac9000  r14: 0x0000000000000006  r15: 0x000000000000002d   rip: 0x00007fff6ff9d23e  rfl: 0x0000000000000206  cr2: 0x00007fffa2c37188  Logical CPU:     0 Error Code:      0x02000148 Trap Number:     133   Binary Images:        0x10998e000 -        0x109999fff  fsck_exfat (90.200.1) <5040465B-D4D0-3486-8BC0-51662BCFAD1D> /System/Library/Filesystems/exfat.fs/Contents/Resources/fsck_exfat        0x1145c2000 -        0x114640a87  dyld (655.1) <3EBA447F-A546-366B-B302-8DC3B21A3E30> /usr/lib/dyld     0x7fff42bd5000 -     0x7fff43022fef  com.apple.CoreFoundation (6.9 - 1562) <02A2C178-9FF6-385C-A9C5-7F4FC9D66311> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation     0x7fff6cf1f000 -     0x7fff6cf20ff7  libDiagnosticMessagesClient.dylib (107) <15210AC0-61F9-3F9D-A159-A009F62EB537> /usr/lib/libDiagnosticMessagesClient.dylib     0x7fff6d2d1000 -     0x7fff6d2d2ffb  libSystem.B.dylib (1252.200.5) <C6201660-5E17-397D-BA21-C503420CD706> /usr/lib/libSystem.B.dylib     0x7fff6d52b000 -     0x7fff6d582ff7  libc++.1.dylib (400.9.4) <B260AC33-EB9A-30C6-8746-D011B3B02B08> /usr/lib/libc++.1.dylib     0x7fff6d583000 -     0x7fff6d598fff  libc++abi.dylib (400.17) <446F4748-8A89-3D2E-AE1C-27EEBE93A8AB> /usr/lib/libc++abi.dylib     0x7fff6e1e7000 -     0x7fff6e44affb  libicucore.A.dylib (62109.0.1) <FEB89BD3-79C4-3208-A754-7E6BC4D38548> /usr/lib/libicucore.A.dylib     0x7fff6ed79000 -     0x7fff6f4fffe7  libobjc.A.dylib (750.1) <804715F4-F52D-34D0-8FEC-A25DC08513C3> /usr/lib/libobjc.A.dylib     0x7fff6fc5c000 -     0x7fff6fc6effb  libz.1.dylib (70.200.4) <15F7B40A-424C-33BB-BF2C-7E8195128B78> /usr/lib/libz.1.dylib     0x7fff6fcdf000 -     0x7fff6fce3ff3  libcache.dylib (81) <704331AC-E43D-343A-8C24-39201142AF27> /usr/lib/system/libcache.dylib     0x7fff6fce4000 -     0x7fff6fceeff3  libcommonCrypto.dylib (60118.220.1) <9C865644-EE9A-3662-AB77-7C8A5E561784> /usr/lib/system/libcommonCrypto.dylib     0x7fff6fcef000 -     0x7fff6fcf6fff  libcompiler_rt.dylib (63.4) <817772E3-E836-3FFD-A39B-BDCD1C357221> /usr/lib/system/libcompiler_rt.dylib     0x7fff6fcf7000 -     0x7fff6fd00ff3  libcopyfile.dylib (146.200.3) <5C5C4F35-DAB7-3CF1-940F-F47192AB8289> /usr/lib/system/libcopyfile.dylib     0x7fff6fd01000 -     0x7fff6fd85fdf  libcorecrypto.dylib (602.230.1) <C78D1A87-5543-3561-BEB4-3B480BA94ECB> /usr/lib/system/libcorecrypto.dylib     0x7fff6fe0c000 -     0x7fff6fe46ff7  libdispatch.dylib (1008.220.2) <2FDB1401-5119-3DF0-91F5-F4E105F00CD7> /usr/lib/system/libdispatch.dylib     0x7fff6fe47000 -     0x7fff6fe76ff3  libdyld.dylib (655.1) <90C801E7-5D05-37A8-810C-B58E8C53953A> /usr/lib/system/libdyld.dylib     0x7fff6fe77000 -     0x7fff6fe77ffb  libkeymgr.dylib (30) <A4EFD9A4-2EF3-3E18-B325-F527E3821939> /usr/lib/system/libkeymgr.dylib     0x7fff6fe85000 -     0x7fff6fe85ff7  liblaunch.dylib (1336.240.2) <D5F0014D-CF46-3B04-9DE0-A1466DA14A2C> /usr/lib/system/liblaunch.dylib     0x7fff6fe86000 -     0x7fff6fe8bfff  libmacho.dylib (921) <6ADB99F3-D142-3A0A-B3CE-031354766ACC> /usr/lib/system/libmacho.dylib     0x7fff6fe8c000 -     0x7fff6fe8effb  libquarantine.dylib (86.220.1) <58524FD7-63C5-38E0-9D90-845A79551C14> /usr/lib/system/libquarantine.dylib     0x7fff6fe8f000 -     0x7fff6fe90ff3  libremovefile.dylib (45.200.2) <BA53CA8A-9974-3A43-9265-B110B1AE470F> /usr/lib/system/libremovefile.dylib     0x7fff6fe91000 -     0x7fff6fea8ff3  libsystem_asl.dylib (356.200.4) <33C62769-1242-3BC1-9459-13CBCDECC7FE> /usr/lib/system/libsystem_asl.dylib     0x7fff6fea9000 -     0x7fff6fea9fff  libsystem_blocks.dylib (73) <152EDADF-7D94-35F2-89B7-E66DCD945BBA> /usr/lib/system/libsystem_blocks.dylib     0x7fff6feaa000 -     0x7fff6ff32fff  libsystem_c.dylib (1272.200.26) <D6C701A2-9F17-308D-B6AC-9E17EF31B7DF> /usr/lib/system/libsystem_c.dylib     0x7fff6ff33000 -     0x7fff6ff36ff7  libsystem_configuration.dylib (963.200.27) <94898525-ECC8-3CC9-B312-CBEAAC305E32> /usr/lib/system/libsystem_configuration.dylib     0x7fff6ff37000 -     0x7fff6ff3aff7  libsystem_coreservices.dylib (66) <10818C17-70E1-328E-A3E3-C3EB81AEC590> /usr/lib/system/libsystem_coreservices.dylib     0x7fff6ff3b000 -     0x7fff6ff41ffb  libsystem_darwin.dylib (1272.200.26) <07468CF7-982F-37C4-83D0-D5E602A683AA> /usr/lib/system/libsystem_darwin.dylib     0x7fff6ff42000 -     0x7fff6ff48ff7  libsystem_dnssd.dylib (878.240.1) <5FEA5E1E-E80F-3616-AD33-8E936D61F31A> /usr/lib/system/libsystem_dnssd.dylib     0x7fff6ff49000 -     0x7fff6ff95ff3  libsystem_info.dylib (517.200.9) <54B65F21-2E93-3579-9B72-6637A03245D9> /usr/lib/system/libsystem_info.dylib     0x7fff6ff96000 -     0x7fff6ffbeff7  libsystem_kernel.dylib (4903.241.1) <CA10BC3A-5B09-32CE-B74F-BAD01755AA37> /usr/lib/system/libsystem_kernel.dylib     0x7fff6ffbf000 -     0x7fff7000aff7  libsystem_m.dylib (3158.200.7) <AF25F8E8-194C-314F-A2D3-A424853EE796> /usr/lib/system/libsystem_m.dylib     0x7fff7000b000 -     0x7fff7002fff7  libsystem_malloc.dylib (166.220.1) <4777DC06-F9C6-356E-82AB-86A1C6D62F3A> /usr/lib/system/libsystem_malloc.dylib     0x7fff70030000 -     0x7fff7003bff3  libsystem_networkextension.dylib (767.240.1) <4DB0D4A2-83E7-3638-AAA0-39CECD5C25F8> /usr/lib/system/libsystem_networkextension.dylib     0x7fff7003c000 -     0x7fff70043fff  libsystem_notify.dylib (172.200.21) <65B3061D-41D7-3485-B217-A861E05AD50B> /usr/lib/system/libsystem_notify.dylib     0x7fff70044000 -     0x7fff7004dfef  libsystem_platform.dylib (177.200.16) <83DED753-51EC-3B8C-A98D-883A5184086B> /usr/lib/system/libsystem_platform.dylib     0x7fff7004e000 -     0x7fff70058fff  libsystem_pthread.dylib (330.230.1) <80CC5992-823E-327E-BB6E-9D4568B84161> /usr/lib/system/libsystem_pthread.dylib     0x7fff70059000 -     0x7fff7005cff7  libsystem_sandbox.dylib (851.230.3) <D6469A17-C13C-3538-A300-D6517BB7F249> /usr/lib/system/libsystem_sandbox.dylib     0x7fff7005d000 -     0x7fff7005fff3  libsystem_secinit.dylib (30.220.1) <5964B6D2-19D4-3CF9-BDBC-4EB1D42348F1> /usr/lib/system/libsystem_secinit.dylib     0x7fff70060000 -     0x7fff70067ff7  libsystem_symptoms.dylib (820.237.2) <487E1794-4C6E-3B1B-9C55-95B1A5FF9B90> /usr/lib/system/libsystem_symptoms.dylib     0x7fff70068000 -     0x7fff7007dff7  libsystem_trace.dylib (906.220.1) <4D4BA88A-FA32-379D-8860-33838723B35F> /usr/lib/system/libsystem_trace.dylib     0x7fff7007f000 -     0x7fff70084ffb  libunwind.dylib (35.4) <EF1A77FD-A86B-39F5-ABEA-6100AB23583A> /usr/lib/system/libunwind.dylib     0x7fff70085000 -     0x7fff700b5fff  libxpc.dylib (1336.240.2) <EE0CDA53-6FF9-3B4E-A571-335A5FF6B6F4> /usr/lib/system/libxpc.dylib  External Modification Summary:   Calls made by other processes targeting this process:     task_for_pid: 0     thread_create: 0     thread_set_state: 0   Calls made by this process:     task_for_pid: 0     thread_create: 0     thread_set_state: 0   Calls made by all processes on this machine:     task_for_pid: 602965     thread_create: 0     thread_set_state: 0  VM Region Summary: ReadOnly portion of Libraries: Total=234.6M resident=0K(0%) swapped_out_or_unallocated=234.6M(100%) Writable regions: Total=356.0M written=0K(0%) resident=0K(0%) swapped_out=0K(0%) unallocated=356.0M(100%)                                  VIRTUAL   REGION  REGION TYPE                        SIZE    COUNT (non-coalesced)  ===========                     =======  =======  Dispatch continuations            24.0M        2  Kernel Alloc Once                    8K        2  MALLOC                           276.2M       23  MALLOC guard page                   16K        5  MALLOC_LARGE (reserved)           46.3M        2         reserved VM address space (unallocated) STACK GUARD                       56.0M        3  Stack                             8712K        3  VM_ALLOCATE                          4K        2  __DATA                            4664K       44  __LINKEDIT                       216.1M        4  __TEXT                            18.5M       44  __UNICODE                          564K        2  shared memory                        8K        3  ===========                     =======  =======  TOTAL                            650.8M      126  TOTAL, minus reserved VM space   604.5M      126   

It brings the whole system down with it. The mac reboots.

Is this a known issue? I could not find anything googling. Do you have a workaround for it?

Disable (or workaround) form rebuild with managed_file field

I’m using the Form API to create a custom form. It has a managed_file field and some other fields, some of which are required. If any of the required fields are not filled in, the file upload for the managed_file field doesn’t work, and produces an error informing the user to fill out the required field first before the image upload can process.

I’m assuming this is because the form is being rebuilt when the form uploads, but is there a way to stop it from checking for required fields? Surely there is a way, as node edit forms have this functionality working.

Here is my form code (simplified):

function create_event_form($  form, &$  form_state) {    $  form['event_image'] = array(     '#type' => 'managed_file',     '#upload_validators' => array(       'file_validate_extensions' => array('jpg jpeg gif png')     ),     '#upload_location' => 'public://event_images/',     '#required' => FALSE,   );    $  form['event_name'] = array(     '#type' => 'textfield',     '#title' => t('Event Name'),     '#required' => TRUE,   );    $  form['submit_button'] = array(     '#type' => 'submit',     '#value' => t('Create Event'),   );    return $  form; } 

If event_name field is empty when attempting to upload a file, the upload will not process.

api limit workaround

Are there any ways to avoid limitation for api calls (5/sec)?

I need the info about transactions and balance (of certain account), UTXOs and the ability to broadcast my transaction.

Currently I am using public blockchain explorers such as

https://www.blockcypher.com/

https://chain.so/

https://etherscan.io

However they have limits on their calls, which is unacceptable for cases if my service in use of at least 1000-2000 people.

I am begginer, so after some surfing I understood that the only way to tackle that issue is by saving the info in my own database or run my own full nodes (for each currency I have – eth/etc/bitcoin/btc/doge/dash.. etc) which might be pretty expensive and time-consuming.

Can you suggest any good solution?

Thank you!