kicken

The markers seem to all be valid, the list just includes markers that belong to embedded images as well. ffe1 0x00000004 (4) --------------------- Embedded image markers: ffdb 0x00000140 (320) ffdd 0x000001C6 (454) ffee 0x000001CC (460) ffc0 0x000001DC (476) ffc4 0x000001EF (495) ffda 0x00000293 (659) ffd0 0x0000044F (1103) ffd1 0x000005DE (1502) ffd2 0x0000078C (1932) ffd3 0x00000920 (2336) ffd4 0x00000ABA (2746) ffd5 0x00000C13 (3091) ffd6 0x00000DC0 (3520) ffd7 0x00000FB4 (4020) ffd0 0x0000128E (4750) ffd1 0x000015EA (5610) ffd2 0x00001904 (6404) ffd3 0x00001BB3 (7091) ffd4 0x00001DAD (7597) ffd5 0x00001F51 (8017) ffd6 0x0000204F (8271) ffd7 0x0000211D (8477) ffd0 0x000021FC (8700) --------------------------- ffed 0x000022DB (8923) --------------------------- Another embedded image: ffd8 0x00002525 (9509) ffdb 0x00002527 (9511) ffdd 0x000025AD (9645) ffee 0x000025B3 (9651) ffc0 0x000025C3 (9667) ffc4 0x000025D6 (9686) ffda 0x0000267A (9850) ffd0 0x00002836 (10294) ffd1 0x000029C5 (10693) ffd2 0x00002B73 (11123) ffd3 0x00002D07 (11527) ffd4 0x00002EA1 (11937) ffd5 0x00002FFA (12282) ffd6 0x000031A7 (12711) ffd7 0x0000339B (13211) ffd0 0x00003675 (13941) ffd1 0x000039D1 (14801) ffd2 0x00003CEB (15595) ffd3 0x00003F9A (16282) ffd4 0x00004194 (16788) ffd5 0x00004338 (17208) ffd6 0x00004436 (17462) ffd7 0x00004504 (17668) ffd0 0x000045E3 (17891) --------------------------- ffe2 0x000046DF (18143) ffe1 0x00004921 (18721) ffdb 0x00007547 (30023) ffdd 0x000075CD (30157) ffee 0x000075D3 (30163) ffc0 0x000075E3 (30179) ffc4 0x000075F6 (30198) ffda 0x000076BE (30398) --------------------------- Image data reset markers. ffd0 0x00008DBC (36284) ffd1 0x0000A42C (42028) ffd2 0x0000BAAD (47789) ffd3 0x0000D199 (53657) ffd4 0x0000E7F0 (59376) ffd5 0x0000FDEB (65003) ffd6 0x0001140D (70669) ffd7 0x00012950 (76112) ffd0 0x00013ED0 (81616) ffd1 0x000154A9 (87209) ffd2 0x000169E2 (92642) ffd3 0x00017F3B (98107) ffd4 0x000193FA (103418) ffd5 0x0001A893 (108691) ffd6 0x0001BD88 (114056) ffd7 0x0001D20F (119311) ffd0 0x0001E65C (124508) ffd1 0x0001FA60 (129632) ffd2 0x00020ED1 (134865) ffd3 0x0002238A (140170) ffd4 0x00023930 (145712) ffd5 0x00024E24 (151076) ffd6 0x00026282 (156290) ffd7 0x000276E6 (161510) ffd0 0x00028AD5 (166613) ffd1 0x00029EA4 (171684) ffd2 0x0002B2B8 (176824) ffd3 0x0002C630 (181808) ffd4 0x0002D9C1 (186817) ffd5 0x0002EDBD (191933) ffd6 0x000301A4 (197028) ffd7 0x00031568 (202088) ffd0 0x00032A54 (207444) ffd1 0x00033E82 (212610) ffd2 0x000352E1 (217825) ffd3 0x0003684F (223311) ffd4 0x00037C6E (228462) ffd5 0x00039026 (233510) ffd6 0x0003A491 (238737) ffd7 0x0003B7FA (243706) ffd0 0x0003CB84 (248708) ffd1 0x0003E025 (253989) ffd2 0x0003F3DB (259035) ffd3 0x0004081C (264220) ffd4 0x00041D17 (269591) ffd5 0x000431A8 (274856) ffd6 0x000446D3 (280275) ffd7 0x00045D4C (286028) ffd0 0x0004725A (291418) ffd1 0x000486B4 (296628) ffd2 0x00049BDA (302042) ffd3 0x0004B056 (307286) ffd4 0x0004C554 (312660) ffd5 0x0004DB3B (318267) ffd6 0x0004F0E7 (323815) ffd7 0x000506E2 (329442) ffd0 0x00051EA4 (335524) ffd1 0x000535E4 (341476) ffd2 0x00054DBE (347582) ffd3 0x0005657B (353659) ffd4 0x00057CED (359661) ffd5 0x00059477 (365687) ffd6 0x0005AD39 (372025) ffd7 0x0005C9C3 (379331) ffd0 0x0005E7F8 (387064) ffd1 0x000606AD (394925) ffd2 0x000628A8 (403624) ffd3 0x00064D67 (413031) ffd4 0x0006733E (422718) ffd5 0x00069A78 (432760) ffd6 0x0006C461 (443489) ffd7 0x0006EFAA (454570) ffd0 0x000718D7 (465111) ffd1 0x00073FF1 (475121) ffd2 0x00076644 (484932) ffd3 0x00078CF9 (494841) ffd4 0x0007B2A9 (504489) ffd5 0x0007D426 (513062) ffd6 0x0007F3E8 (521192) ffd7 0x000813E5 (529381) ffd0 0x0008341D (537629) ffd1 0x00085447 (545863) ffd2 0x000875B0 (554416) ffd3 0x000896E0 (562912) ffd4 0x0008B959 (571737) ffd5 0x0008DB57 (580439) ffd6 0x0008FDA6 (589222) ffd7 0x00091F2E (597806) ffd0 0x0009402B (606251) ffd1 0x0009603A (614458) ffd2 0x00097F5D (622429) ffd3 0x00099D30 (630064) ffd4 0x0009B79D (636829) ffd5 0x0009D0B8 (643256) ffd6 0x0009E7FB (649211) ffd7 0x0009FE20 (654880) ffd0 0x000A13FA (660474) ffd1 0x000A2908 (665864) ffd2 0x000A3E2C (671276) ffd3 0x000A541E (676894) ffd4 0x000A692F (682287) ffd5 0x000A7E5E (687710) ffd6 0x000A9425 (693285) ffd7 0x000AA79E (698270) ffd0 0x000ABA70 (703088) ffd1 0x000ACDE5 (708069) ffd2 0x000ADFB9 (712633) ffd3 0x000AF1B3 (717235) ffd4 0x000B0422 (721954) ffd5 0x000B153C (726332) ffd6 0x000B2632 (730674) ffd7 0x000B37DC (735196) ffd0 0x000B4917 (739607) ffd1 0x000B59DD (743901) ffd2 0x000B6BA0 (748448) ffd3 0x000B7C95 (752789) ffd4 0x000B8D4F (757071) ffd5 0x000B9EBD (761533) ffd6 0x000BAFB5 (765877) ffd7 0x000BC03C (770108) ffd0 0x000BD152 (774482) ffd1 0x000BE20A (778762) ffd2 0x000BF29C (783004) ffd3 0x000C035D (787293) ffd4 0x000C1444 (791620) ffd5 0x000C24F4 (795892) ffd6 0x000C35D0 (800208) ffd7 0x000C4699 (804505) ffd0 0x000C57AE (808878) ffd1 0x000C688F (813199) ffd2 0x000C7906 (817414) ffd3 0x000C89A3 (821667) ffd4 0x000C9A7E (825982) ffd5 0x000CAB50 (830288) --------------------------- ffd9 0x000CBC23 (834595) All the 0xFFD0 - 0xFFD7 markers are reset markers within the image data. My code skips those since they are only relevant to decoding the image data and not the overall file structure. If you prefer to code in spaghetti style, go ahead. Functions are not some horrible thing to be avoided though, one would generally be hard pressed to ever have "too many". Functions let you name a block of code, which can make the overall code much easier to understand what is happening. Your code requires careful reading of each line to know what is happening. My code can be easily skimmed through and still know what's happening thanks to the function names. While not used much here, functions allow you to easily re-use code rather than copy/pasting it and having to maintain separate instances. Main reason I have a parseJpeg function to start with instead of just a block of code was so I could re-use it in separate web (easier to share) and cli (easier to develop/debug) versions of the script.

My code uses memory because it captures the data to generate the hexdumps. Remove that, and it'd probably use barely any more than yours. I know ways it could certainly use less, but memory usage isn't generally a huge concern for me. Memory exists to be used, not using it is a waste of resources. Your code: ffe1 4 ffdb 320 ffc0 476 ffc4 495 ffda 659 ffd9 8921 Peak memory usage: 429.30KB (pre-mature end of image due to thumbnail) My code, without the hexdump stuff. Found marker 0xE1 @ 0x00000002 (2) Found marker 0xED @ 0x000022D9 (8921) Found marker 0xE2 @ 0x000046DD (18141) Found marker 0xE1 @ 0x0000491F (18719) Found marker 0xDB @ 0x00007545 (30021) Found marker 0xDD @ 0x000075CB (30155) Found marker 0xEE @ 0x000075D1 (30161) Found marker 0xC0 @ 0x000075E1 (30177) Found marker 0xC4 @ 0x000075F4 (30196) Found marker 0xDA @ 0x000076BC (30396) Found marker 0xD9 @ 0x000CBC21 (834593) Peak memory usage: 433.62KB The extra memory is probably just due to the code structure differences.

Given the recommendation to move it out of the document root, I'm assuming they are using that extension for a template file where PHP itself is the template language. Symfony uses the same extension if you opt to use raw PHP templates instead of twig ones. If that's not the case though, then yea that extension seems silly.

It's not trusting user input, it's the format. Unless you find some specification that explicitly says "Marker C0 has 17 bytes of data" then you shouldn't hard-code that condition. The validation would go a little something like this: Read 0xFF?? marker Read length value (ie, $length=0x0011 / 17 bytes) Read $length bytes loop If the file is valid, each iteration of the loop would read a marker, read it's length, then read it's data. If someone tried to sneak in a file with an invalid length, the first read of the loop would not be a valid marker and you can abort. Once you have the marker list, then for each marker you're interested in you'd have to parse the associated data. If that data is invalid, then you can fail during that parsing. Parsing data for validity can get complex and time consuming (which is why I'd just use a trusted library if possible). As an example of this, try an image that contains an embedded thumbnail with your code, such as this one.

The list of marker codes you are checking for is only a limited subset of possible marker codes. That means you'll be missing a bunch of potential markers. For example, 0xFFFE - Comment 0xFFDD - Restart interval 0xFFE2 - 0xFFEF - App specific markers. and more You may not care what those markers do, but you need to correctly identify them to ensure the file as a whole is parsed correctly. By marker data I am referring to the data attached to the marker, ie. the hexdump of stuff shown after a marker in my script's output. The next two byte after a marker define a length value, then after that is arbitrary data. You need to skip over all that as you're searching for markers or you might catch something that looks like a marker but actually is not. Skipping over that would save a bunch of time reading bytes as well. Your idea of just finding the markers then using ftell to record their offsets is fine. As you noted you can then go back and fseek to that position and read the marker data. You just want to ensure you're finding the markers correctly by skipping past that data and the image data during your initial scan. Just make sure you are using the encoded length value to and not try to hard-code data lengths. The length of the data attached to a marker isn't necessarily fixed.

Better, though you're still a bit too specific in that you're looking for specific marker sequences instead of the more generic 0xFF0x?? (where ?? is no 00) sequence. You want to find the generic sequence to find all markers. Then you can just ignore the ones you're not interested in. I don't believe there's anything in the format that says there cannot be multiple. In fact, the example given in the reference above shows multiple huffman table markers (0xFFC4). Since you're not yet scanning properly for the marker and image data (which is fine, baby steps remember) you might be getting some false markers in your output. I had to make a small update to my code since posting it here as it was incorrectly seeing reset markers as the end of image data instead of ignoring them. I'm not sure what you mean here. ftell gives you the current offset of the file pointer. In most cases, you don't need that. My code uses it (along with fseek) to reset the file pointer when scanning the image data, but other than that it's not necessary. You should feel like looking at example code is somehow cheating. You should look at it, but rather than just copy/paste it try to determine how it works then re-implement that logic yourself. Maybe you end up with the same code, maybe not. The key is to get an understanding of the logic and what the code is doing. One of the first things I do when digging into a new library aside from reading the docs is to try and find example code I can look at. That's one of the great things about Github, finding and viewing example code.

It gives a result using the example data in my post above. Changing to const missing = requesterList.filter((i) => !arrayA.requesters.includes(i)); console.log(missing, missing.length); Gives the result [ 'Example' ] 1 Log your arrays and make sure they are what you think they are.

I know that, but your logic doesn't make sense. This is the logic you've implemented: $id = $_GET['id']; if ($id exists in cic_remus.contacts) { echo "Already copied"; } else if ($id does not exist in cic_remus.contacts){ copy data for $id from cic_remus.contacts into cic_kenobi.contacts } You're trying to copy data that doesn't exist into another table. Copying nothing will give you nothing.

Doesn't make any sense to check the source table though. Your copying from cic_remus.contacts into cic_kenobi.contacts. So of course the data already exists in cic_remus.contacts, if it didn't there wouldn't be anything to copy in the first place.

If you're inserting the data into cic_kenobi.contacts, why are you checking if it already exists by selecting from cic_remus.contacts?

You did not specify any columns to select.

Magic Constants

The document root of your project should be a sub-directory within your project, rather than the project folder itself. project └── www ├── count.html.php └── index.php They are saying to move that file out of the document root sub-directory and put it into the project folder itself. project ├── count.html.php └── www └── index.php Since the document root of the web server would point to the www sub directory, the count.html.php file is now inaccessible by any url.

Did you get that query from your code by echoing out $sql? echo $sql; $result = oci_parse($conn,$sql); The question is whether the query your generating is what you're expecting it to be, so you will want to echo it and verify it. If you can copy/paste the echo'ed query from the page into sql developer and get results, but get no results in PHP then maybe there is some environment difference or the code for reading the results is problematic. I've not used oracle so cannot say much about it.

Echo out your query so you can see what query is being generated.

It's pseudo-code, it doesn't search for anything specific. Pseudo code is only an outline of the steps, not a full implementation. The function is called 'findNextMarker'. A marker is defined in the file format as: the type is defined by a marker: 2 bytes, FF then a non-zero byte (*). So no, it's not supposed to look for just any 0xFF. It supposed to look for 0xFF followed by any byte other than 0x00. It's not skipping SOI or EOI. It's just not parsing them for a data segment because they do not have one. Again, from the file format reference: A string is effectively just an array of characters. There's no difference between the two from a security perspective. PHP code also isn't subject to something like a buffer overflow error leading to arbitrary code execution (unless there's some problem in the PHP engine itself). You can also analyze a string just as easily (or easier) as an array of individual characters. Then ignore that step, it doesn't change the others. You haven't even seen my actual code yet, so I'm not sure how you're able to judge it. Since I said I'd share after letting you ponder the advice for a while though, here it is: <?php function parseJpeg(string $file) : array{ $fp = fopen($file, 'rb'); if (!$fp){ throw new \RuntimeException('Unable to open file'); } //First two bytes should be \xFFD8. if (fread($fp, 2) !== "\xFF\xD8"){ throw new \RuntimeException('Invalid image file.'); } $output = []; //Find each segment by looking for the marker values \xFF?? while (!feof($fp) && ($marker = findNextMarker($fp))){ $blockData = [ 'marker' => $marker ]; //If the marker is not the end of image marker. if ($marker !== 0xD9){ //Parse the segment data for this marker. $blockData['segmentData'] = parseSegmentData($fp); if ($marker === 0xDA){ //If the marker is a start of scan marker. //Parse the image data that follows. $blockData['imageData'] = parseImageData($fp); } else if ($marker === 0xE0){ //If the marker is the app0 header. $blockData['headerData'] = parseApp0Header($blockData['segmentData']); } $output[] = $blockData; } else { $output[] = $blockData; break; } } fclose($fp); return $output; } function parseSegmentData($fp) : string{ //Markers indicate the start of a segment which is composed of <length><data> sections. //The length is two bytes and is the length of the entire segment including the two bytes //used to define the length. //Extract the length from the next two bytes. $dataLength = unpack('nlength', fread($fp, 2))['length']; //Read the remaining data using that length value. Subtract 2 because //$dataLength includes the two bytes we just read to obtain the length $data = fread($fp, $dataLength - 2); return $data; } function parseImageData($fp) : string{ $imageData = []; //Read data until we find another marker or hit end of file. while (!feof($fp)){ $c = fread($fp, 1); //We might have found another marker. if ($c === "\xFF"){ //Save our position in the file //If we found a marker, we need to rewind to just before it. $pos = ftell($fp); //We only found a marker if the next byte is not \x00 $next = fread($fp, 1); if ($next !== "\x00"){ //Rewind the file to just before the marker we just found and exit the loop. fseek($fp, $pos - 1); break; } } $imageData[] = $c; } $imageData = implode('', $imageData); return $imageData; } function parseApp0Header(string $data) : ?array{ $unpacked = unpack('Z5id/c2version/cunits/n2dpi/c2thumb', $data); if (!$unpacked){ return null; } return [ 'id' => $unpacked['id'] , 'version' => $unpacked['version1'] . '.' . $unpacked['version2'] , 'units' => $unpacked['units'] , 'density' => $unpacked['dpi1'] . 'x' . $unpacked['dpi2'] , 'thumbnail' => $unpacked['thumb1'] . 'x' . $unpacked['thumb2'] ]; } function findNextMarker($fp) : int{ //Scan the file content for the next \xFF?? marker. //This scans one byte at a time which is terrible for //performance but easy. Loading more data into memory //and using strpos would be better, but since you like //low-memory... do { $markerIndicator = fread($fp, 1); if ($markerIndicator === "\xFF"){ $marker = fread($fp, 1); if ($marker !== "\x00"){ return ord($marker); } } } while (!feof($fp)); throw new \RuntimeException('Marker not found'); }

That's what you said you needed as far as I understood it. If you want the other way, you could just reverse the array's.

That is the end goal, not something you should be jumping straight to. Basic problem solving is to break the problem down into smaller components, so the problem of "How do I verify JPEG and strip unwanted stuff" breaks down into steps How do I parse a jpeg? How do I find the unwanted stuff? How do I remove the unwanted stuff? Step one, how do you parse the jpeg can be further broken down into it's own steps: How do I find the markers? How do I extract the data associated with those markers? How do I parse that marker data (will vary for each marker type) If you can successfully find each marker type and it's associated data, you can easily make a function to parse that marker's data for the details you need. Extending the pseudo code above for example: while (!feof($file)){ $marker = findNextMarker($file); //Scan the file until you find a 0xFF?? value, return the ??. if ($marker !== 0xD8 && $marker !== 0xD9){ $length = parseLength($file); //Read two bytes, convert them to a integer length value $data = fread($file, $length - 2); // -2 because the encoded length includes the two bytes read above. switch ($marker){ case 0xE0: parseApp0Header($data); break; case 0xC0: parseStartOfFrame($data); break; case 0xC4: parseHuffmanTable($data); break; //... whatever other markers you're interested in. } } }

It's better in that you're not doing a line-based approach any more. What I would say is you're getting a little too specific right now. If you look at the linked reference, you'll see: What you can take from that, is your file will essentially a repeating sequence of "\xFF\x??<marker>\x????<length>\x??...<data>". The two exceptions to worry about right away are the start of image and end of image markers, they don't have a length and data component. As such, you should start by being able to parse that repeating sequence. Don't worry about parsing what exactly is contained inside the data, just get the individual blocks. In pseudo code that'd be something like: while (!feof($file)){ $marker = findNextMarker($file); //Scan the file until you find a 0xFF?? value, return the ??. if ($marker !== 0xD8 && $marker !== 0xD9){ $length = parseLength($file); //Read two bytes, convert them to a integer length value $data = fread($file, $length - 2); // -2 because the encoded length includes the two bytes read above. } } I did this, and have a simple script that does like I said above, just parses out the different blocks and shows a hex dump of their data. I'll share eventually, but I want to see what you come up with after taking the above into consideration first.

Make your functions just do nothing if the condition is not met. function Mileage($entry, $form){ $MileageQty = $entry["5"]; if ($MileageQty <= 0){ return; } $Name = $entry["1"]; $Service = "Fixed-Milage"; $MileageRate = $entry["10"]; $con=mysqli_connect(""); mysqli_query($con,"INSERT INTO beta_pay (Name,Type,Value,Qty) VALUES ('$Name','$Service','$MileageRate','$MileageQty')"); } Since you only want the function to run if $MileageQty is > 0, you check if it's 0 or less and if so, return. Return will exit the function, so nothing that comes after it will be executed.

So far you've posted The HTML code for your UI layout, but without any of the data (just placeholder values) PHP code that outputs some JSON data to something. Presumably there is a third bit of code somewhere (likely Javascript) that takes that JSON output from the PHP and populates your UI with that data. If that third bit of code exists, then you need to post it for anyone to determine why it's not populating the UI (along with an errors you might see in your browser's developer console). If that third bit of code does not exist, then you either need to create it, or change your PHP code to output the value directly into your HTML rather than as JSON data.

Your tag nesting seems strange. Why is your google translate box a child of your logo? Your use of flex seems off as well. Your logo a translate elements should probably be siblings, both children of the logo_bar element. You could make logo_bar then either flex or grid to allocate most of the space to your logo div, and the minimum space to the translate element. HTML: <div class="header_container"> <div class="logo_bar"> <div class="logo"></div> <div id="google_translate_element">Google translate box</div> </div> <div class="menu_bar" style="background-color: #ffffff;"> <div class="menu"> <a href='<?=$HOST?>index.php' class='w3-bar-item w3-button w3-round-tiny w3-hover-white'>Hjem</a> <a href='<?=$HOST?>index.php' class='w3-bar-item w3-button w3-round-tiny w3-hover-white'>Hjem</a> <a href='<?=$HOST?>index.php' class='w3-bar-item w3-button w3-round-tiny w3-hover-white'>Hjem</a> </div> </div> </div> CSS: div.logo_bar { display: grid; grid-template-columns: auto max-content; background-color: #003333; margin: auto; margin-top: 0px; width: 100%; height: 64px; padding: 0px; position: fixed; } div.logo { width: 300px; height: 35px; margin-top:9px; margin-left: 10px; } div#google_translate_element { width: 300px; height: 45px; margin-top:3px; margin-left: 10px; color: white; } div.menu_bar { font-size: 13px; background-color: #ffffff; box-shadow: rgba(99, 99, 99, 0.2) 0px 2px 8px 0px; margin: auto; margin-top: 54px; width: 100%; height: 50px; position: fixed; } div.menu { background-color: #ffffff; display: inline-flex; flex-direction: row; align-items: middle; margin-left: 0px; margin-top: 8px; } P.S. Remember to use Code blocks when posting your code.

I don't know where you got that idea from. I don't care what you ultimately decide to do, I'm merely point out out how dumb and misguided your "libraries are not worth using, they have bugs/vulnerabilities" argument is. If you ever want to get out of hobbyist programming (or just create more advanced projects) you'll have to get over your apparent fear of libraries, or else waste a ton of time re-inventing the wheel so to speak. I don't know much about the JPEG format, but binary files are rarely line-oriented which means your approach is flawed from the start, You shouldn't be trying to parse the file "line-by-line" as there's typically no such thing as a line in a binary file. You need to learn the format, then parse according to that. If this reference is accurate, then you should be parsing the data by looking for byte sequence of \xFF\x?? where the second byte is something other than \x00. Then depending on what that second byte is, read some other amount of data to get to the next block. I don't really have the time to learn the format and provide a complete example (I'd just use a library and move on to the next problem). Maybe if I'm feeling up to it later tonight I will try something. The dechex(ord()) dance is not really necessary. Character \x2A is *, so if you want to test if $byte is * you can either just test that directly such as: if ($byte === '*'){ break; } or if you'd prefer to keep things in hex, then test: if ($byte === "\x2a"){ break; } For starters, 'H' doesn't have anything to do with that byte's meaning. If you look at that reference above, it's probably part of the density value, a 2-byte integer. 0x0048 == 72. You'll want to learn about using unpack to parse out such multi-byte integer value.

That's telling you that arrayA.requesters is undefined, not an array as expected. If it's possible for it to be undefined, add a check for that. If it should not ever be undefined, you need to figure out why it is.

If you want to DIY something for your own education or just for fun, so be it, but don't try and say libraries are bad because they've had bugs/vulnerabilities. That's just objectively wrong. Pretty much every code base will have bugs/vulnerabilities, yours included. A popular library having a serious bug/vulnerability is going to be rare. Bugs/vulnerabilities found will be quickly fixed. By that logic, why even use PHP? It's had it's fair share of problems over the years, surely you'd be better off just writing your code in C or assembler, right? /s One of the main benefits of libraries and open source software is that common problems can be solved once, and everyone can benefit from that solution instead of every developer having to come up with their own (likely broken) solution. If you're talking about the strings utility, that works by just looking for printable characters in a sequence of a particular length. If you wanted to do that in PHP, you'd just read the file character by character and note if it is printable or not. strings.php <?php $file = $argv[1] ?? null; $minStringLength = $argv[2] ?? 4; if (!$file || !is_readable($file)){ die('File not specified or not readable'); } $fp = fopen($file, 'rb'); if (!$fp){ die('Unable to open file'); } $currentString = ''; while (!feof($fp)){ $char = fgetc($fp); if (ctype_print($char)){ $currentString .= $char; } else { if (strlen($currentString) > $minStringLength){ echo 'Found: ', $currentString, PHP_EOL; } $currentString = ''; } } fclose($fp); I don't know what phpBB does, but a lot of software probably doesn't even look for code inside an image. A lot may not do any validation, or may only validate it can be at least parsed as an image file. Having code inside your image files is only really a problem if you're somehow letting that image be run as code. If you just treat it as an image and that's it, then there's no problem. Stripping the code / other unnecessary info from the image is a good security in depth idea, but making sure your server isn't trying to parse your images for PHP code in the first place is better.