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!

RSS Feed HTTPS Workaround

I’ve been tasked to add RSS feeds to our SP site but am not myself permitted, or even able, to adjust the authentication on the server to allow for the use of an “https://” feed address. I need to use an “http://” address. I am using SharePoint 2013 Online and the RSS Viewer web-part.

What options exist that I could explore?

Google import contacts from CSV not working – workaround?

I’m trying to import contacts from my Microsoft Outlook (company server) to my Gmail, but whatever I try, it fails.

Even when I export my contacts in Gmail to a CSV and then try to import it again, Gmail gives the annoying error, saying it experienced an “unknown error”. Hence Google is not even accepting its own export as import format.

I don’t have the illusion that anyone is going to fix this specific problem, so my question is: does anyone know a workaround to migrate/import contacts to/in Gmail? Some tool somewhere maybe, other inspiration on how to migrate contacts from Outlook to Gmail?

CGPathContainsPoint broken in iOS 12? Is a workaround possible?

I will try to keep this short.

Take the following test code:

CGPath* path =  CGPathCreateMutable(); CGPathMoveToPoint(path, nil, 318.43, 183.47); CGPathAddCurveToPoint(path, nil, 322.98, 189.32, 327, 194.93, 329.81, 201.62); CGPathAddLineToPoint(path, nil, 339.36, 182.58); CGPathCloseSubpath(path); CGPathMoveToPoint(path, nil, 327.8, 193.04); CGPathAddCurveToPoint(path, nil, 323.06, 193.04, 323.06, 185.5, 327.8, 185.5); CGPathAddCurveToPoint(path, nil, 332.54, 185.5, 332.54, 193.04, 327.8, 193.04); CGPathCloseSubpath(path); CGRect boundingBox = CGPathGetBoundingBox(path);  CGPoint testPoint = CGPointMake(200,185);  NSLog(@"path contains point=%d | bounding box contains point=%d",CGPathContainsPoint(path, nil,  testPoint, NO), CGRectContainsPoint(boundingBox, testPoint) ); 

This code returns correctly on iOS 10:

path contains point=0 | bounding box contains point=0

The same code on iOS 12 returns:

path contains point=1 | bounding box contains point=0

As you can see, on iOS 12 CGPathContainsPoint says my testPoint is inside the shape even if the bounding box of the shape says it is not.

Changing the fill rule to NO in CGPathContainsPoint does not change anything.

Is there a solution to this? I tried apple forums before but nobody seems to answer there.

Thank you for any help!

AWS SQS FIFO Limit Workaround

According to the AWS feature page for SQS:

FIFO queues support up to 300 messages per second

Standard queues support a nearly unlimited number of transactions per second (TPS) per API action.

I’m trying to build a system that will add notifications to a queue that will then be sent to a customers device using push notifications.

There will be a Lambda function that will read items off this queue and actually handle sending the message to the user.

Problem is, I’d like this system to be able to scale as efficiently as possible. Being constrained to 300 notifications per second might cause problems in the future. So I want to design this in a way that is much more scalable than that.

I have thought about building some type of system that will use a standard queue then check to see if that notification has already been sent by having a database that stores the ID of notifications that have been sent. Which might work. But at that point I think I’d be opening the door for race conditions. What happens if for the same notification two Lambda functions got triggered at the exact same time? Neither of them have been sent yet. And the user will send up with 2 notifications instead of one.


How can I design a system that has the best of both worlds? nearly unlimited number of transactions per second while ensuring that no duplicate notifications are sent.

I don’t think I mind quite as much if a Lambda function gets triggered twice for 1 notification, so long as it doesn’t get sent multiple times to the user. Of course if I can completely prevent this, that’d be awesome too, so that I can reduce cost.


I’d also love to keep using AWS and the more serverless technologies of AWS if possible. I know there is software and ways I could provision EC2 or other types of instances for this. But that takes out the huge advantage of serverless, which is what I’m really aiming for.